Introducing Web Application Security - Secure Java: For Web Application Development - page 49

◾

Legacy code

◾ Business case issues

3.4.1 Client-Side Control and Trust

In the case of desktop applications, the application runs on one computer in a similar manner as
it runs on any other system it is installed on. he developer is in control of the interface and there
is no dependency on an external application to deliver the content to the user. Web applications
difer from desktop applications in certain important aspects. In the case of Web applications, a
Web browser is used to access the Web application. he Web browser is a client-side application
that provides a way to look at and interact on the Web. Internet Explorer from Microsoft, Mozilla
Firefox from the Mozilla Foundation, Opera from Opera Software ASA, and Safari from Apple
are a few of the popular browsers that will help in accessing the Web applications. Because the
browser controls the way the Web application is delivered to a user, a Web application user is con-
strained to use the application in the browser environment. Several Web application attacks like
cross-site scripting and cross-site request forgery manipulate the way the browser handles HTML
code and client-side scripts like JavaScript, which the attacker uses to inject malicious code into
a Web site, allowing attacks, such as phishing attacks and session hijacking attacks, to be perpe-
trated. In several cases, a hostile user of the Web application may use the browser. In a typical
scenario involving an Internet forum site, a malicious user could inject a script into an input ield,
which would be stored in the site, and whenever any other users of the site access it, it would steal
their sessions and the user credentials in the bargain. In some other cases, the browser could itself
have been compromised. hese are sometimes called man-in-the-browser attacks. For instance, if a
user's computer has been afected with malware that afects the browser, then the malicious code
could throw up fake banking sites inviting the user to log in with his credentials and the malware
would transmit these credentials to an attacker.
Browsers, being desktop applications, are subject to security vulnerabilities. Each browser is
replete with its own set of vulnerabilities. Browser platforms have constantly been plagued with
multifarious vulnerabilities, which attackers have successfully exploited to attack Web applications.
For instance, there were several issues with Apple's Safari Web browser, which had a vulnerable
bufer overlow condition in the way the browser engine handled JavaScript regular expressions, as
a result of which an attacker could maliciously direct the user to a Web site and exploit the vulner-
ability and could go so far as to execute code remotely on the machine and gain access to it. In
the similar vein, vulnerabilities and exploit code have been found and written for several browser
platforms, particularly Internet Explorer and Mozilla Firefox. Browser security is, therefore, one of
the prime concerns with Web application security, because several Web application attacks hinge
on browser security issues or insecure handling of a particular activity.
Browsers also come with their own rendering and interpretation mechanisms as well as a totally
diferent set of security features. For instance, Internet Explorer 8 protects users against cross-site
scripting attacks with the use of a security feature known as XSS Filter . When the browser detects
a cross-site scripting attack, it neutralizes the malicious script from executing. Similarly, Mozilla
Firefox has many useful add-ons to protect against cross-site scripting and other vulnerabilities.
NoScript is a useful add-on that prevents malicious scripts from being executed, thereby prevent-
ing a script injection or a cross-site scripting attack. Figure 3.4 and 3.5 demonstrate the protection
strategies provided by Mozilla Firefox extension “NoScript” and Internet Explorer 8's “XSS Filter”
protecting against Cross Site Scripting.