Cross-site scripting (XSS) – Security Testing Handbook for Banking Applications

2: Basic Tests and Techniques
29
Cross-site scripting (XSS)
When a user logs into an application by entering their
credentials, the application uses a cookie to store their
session information. This cookie is saved on the user’s
system for the duration of the session. The user is
considered an authentic user if they possess the cookie
assigned by the application to them. Hence, if someone can
steal this cookie they can trick the application into believing
that they are the user. This is precisely the aim of XSS:
stealing someone’s identity.
We have already talked about applications validating the
input entered by users. When you are entering data in input
fields, you would have noticed pop-ups that either prompt
you to fill mandatory fields or specify the format a field
expects. These pop-ups are generated by JavaScripts. When
a page is loaded, it may have some code written in
JavaScript that is loaded along with the HTML content.
These scripts are executed by the browser. An XSS attack
uses JavaScripts to steal a user’s session cookie.
XSS is primarily of two types – self-reflecting and cross-
reflecting:
In self-reflecting XSS, an attacker crafts a link with a
script attached to it; this is usually obfuscated so that the
user can’t make it out. The user then clicks on the
malicious link on which the script executes and sends the
user’s identity information to the attacker. The user
however needs to be tricked to click on that link.
Cross-reflecting XSS employs the same principle, only
in this case the attacker uses pages which everybody can
view (like feedback forms) and writes a feedback entry
with a script embedded in it. Anyone who clicks on that
feedback message will be vulnerable to whatever the