Java Reference
In-Depth Information
attacks on the Web application against other users in the application. he most common route
they take for this is to use applications that don't validate input, and they do so by entering arbi-
trary inputs to successfully perform attacks such as cross-site scripting (XSS) and SQL injection.
For instance, if an Internet forum application allows users to enter arbitrary input without data
validation, then an attacker may post in the forum with malicious JavaScript and anyone who
clicks on the post may be redirected to a site containing malware. he Gumblar worm, an infa-
mous Internet worm, worked this way, where when a user accessed an afected site (Web applica-
tion), the worm's malicious JavaScript would kick in and the user would be maliciously redirected
to the attacker's page where malware was downloaded onto the user's machine, thereby infecting
and making it a part of the larger Gumblar botnet.
Lack of input validation can also lead to malicious ile execution—for instance, if a Web appli-
cation accepts uploaded iles from the user and the user uploads iles containing code that may be
used to execute certain privileged actions on the server, thereby giving the attacker access to the
entire server. File inputs also need to be validated to ensure that only certain ile types that need to
be uploaded are in fact uploaded and any other iles are rejected by the system.
Developers need to ensure that applications are inherently capable of validating input to pro-
tect against these multifarious Web application attacks.
10.2.1.3 Output Encoding
Proper encoding of Web pages and output is due to the consistency of encoding that is present
for the Web pages and their content. In the world of Web applications, there is no such thing as
plaintext. When there is a string that needs to be read or interpreted, it is imperative that there be
an appropriate encoding present to ensure that it is available to be read or interpreted. Although
this is the reason for the need for encoding from a functionality standpoint, security is also an
important consideration for encoding. In the case of attacks like XSS, the user's crafted input is
interpreted by the browser as HTML and the JavaScript is executed, thereby leading to a cross-
site scripting attack. For instance, let us consider an Internet forum Web site, where users can
post their queries and an attacker posts his query along with the malicious JavaScript designed to
transmit the user's session ID to the attacker's site. If the Web site does not force output encoding
for all its strings rendered through user input, then the JavaScript is executed and the user's session
credentials are passed to the attacker; however, if output encoding is forced for all the user-based
input in the page, then the malicious JavaScript is encoded in a certain format ensuring that the
JavaScript, while displayed as a part of the message, is not executed, thereby mitigating the efect
of the cross-site scripting attack. he attack has been indicated in Figure 10.1.
he malicious JavaScript in the Internet post is executed because of the lack of output encod-
ing (and input validation). his part of the attack has been exempliied in Figure 10.2.
If output encoding is forced by the application, the JavaScript payload present in the Internet
post is encoded in an encoding format, rendering it harmless. he same has been illustrated in
Figure 10.3.
Figure 10.1
entry of the JavaScript input <script>alert('this is Cross Site Scripting')</script>.
Search WWH ::
Custom Search