• One of the most common application-layer web attacks.
• Commonly targets scripts embedded in a page which are
executed on the client-side rather than on the server-side.
• As you can see from the image below XSS has been in the
OWASP Top 10 for both 2010 and 2013 version.
What is Cross Site Scripting?
• Injection problem in which malicious scripts are injected
into the otherwise benign and trusted web sites.
• XSS tries to manipulate client-side scripts of a web
application to execute in the manner desired by the
• Such a manipulation can embed a script in a page which
can be executed every time the page is loaded, or
whenever an associated event is performed.
• User sends password to the server to requests access to the
• Granted access and given a session cookie.
• Sends data to the Website with session cookie but there is an
XSS in the Site that the attacker has taken advantage off.
• XSS triggers and sends the session cookie back to the attacker.
• Attacker can then use the cookie to log into the Site and the
Types of XSS
• Stored attacks are those where the injected code is permanently stored on the target
servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim
then retrieves the malicious script from the server when it requests the stored information.
• Injected code is reflected off the web server, such as in an error message, search result, or
any other response that includes some or all of the input sent to the server as part of the
• Delivered to victims via in an e-mail messages, or on some other web server. When a user is
tricked into clicking on a malicious link or submitting a specially crafted form, the injected
code travels to the vulnerable web server, which reflects the attack back to the user’s
browser. The browser then executes the code because it came from a "trusted" server.
• XSS attack wherein the attack payload is executed as a result of modifying the DOM
“environment” in the victim’s browser used by the original client side script, so that the client
side code runs in an “unexpected” manner.
• The page itself (the HTTP response that is) does not change, but the client side code
contained in the page executes differently due to the malicious modifications that have
occurred in the DOM environment.
• Vulnerable Parameter : Search Field
• Attacker captured the Users traffic (WireShark) and changed
the original request to a malicious attack on the User.
• As you can see the test value was changed to a malicious XSS
• Or obtain the Users cookie.
• With this session hijacking may be possible
OWASP rules on how to Prevent
A. Use regular expressions on the server side to filter out all hazardous input when
possible. If any or all of this characters is needed by the application, properly
escaping is enough. A non comprehensive list of characters likely to be part of an
attack vector is:
• <> (triangular parenthesis) • () (parenthesis)
• " (quotation mark) • & (ampersand sign)
• ' (single apostrophe) • + (plus sign)
• % (percent sign) • = (equals sign)
• : (colon) • ` (forward tick)
• ; (semicolon) • ´ (back tick)
B. Escape all the untrusted output before presenting to the UI. Follow the rules
detailed in the next link to ensure proper escaping for every context and location:
C. When possible, it is recommended to enforce a specific charset encoding (using
'Content-Type' header or <meta> tag).