Cross Site Scripting - XSS

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.

OWASPTop 10

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

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

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.

Scenario

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

• Result: Payload executed on the client side.

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

OWASP rules on how to PreventA. 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).