Cross-site scripting (XSS) is one of the most common web application attacks, where malicious scripts are injected into otherwise benign websites. There are three main types of XSS attacks - stored, reflected, and DOM-based. To prevent XSS, developers should sanitize user input by removing hazardous characters, properly escape untrusted output before displaying it, and enforce a specific character encoding.

1. Cross Site Scripting - XSS

2. Overview
• 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.

3. OWASPTop 10
• As you can see from the image below XSS has been in the
OWASP Top 10 for both 2010 and 2013 version.

4. 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
malicious user.
• 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.

5. • User sends password to the server to requests access to the
Website.
• 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
Victim.

6. Types of XSS
Stored
• 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.
Reflected
• 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
request.
• 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.
DOM
• 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.

7. Scenario
• Altoromutual.com
• Vulnerable Parameter : Search Field

8. • 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
payload. <script>alert(123)</script>

9. • Result: Payload executed on the client side.

10. • Or obtain the Users cookie.
• With this session hijacking may be possible

11. 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:
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_
Cheat_Sheet
C. When possible, it is recommended to enforce a specific charset encoding (using
'Content-Type' header or <meta> tag).