Application security encompasses measures taken throughout the application's life-cycle to prevent exceptions in the security policy of an application or the underlying system (vulnerabilities) through flaws in the design, development, deployment, upgrade, or maintenance of the application.

Sunday, June 20, 2010


Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications that enables malicious attackers to inject client-side script into web pages viewed by other users.

There is a simple positive model for preventing XSS using output escaping/encoding properly. While there are a huge number of XSS attack vectors, following a few simple rules can completely defend against this serious attack. These rules apply to all the different varieties of XSS. Both reflected and stored XSS can be addressed by performing the appropriate escaping on the server-side.

While input validation is important and should always be performed, it 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.

Escaping (aka Output Encoding)

"Escaping" is a technique used to ensure that characters are treated as data, not as characters that are relevant to the interpreter's parser. There are lots of different types of escaping, sometimes confusingly called output "encoding." Some of these techniques define a special "escape" character, and other techniques have a more sophisticated syntax that involves several characters.

Escaping is the primary means to make sure that untrusted data can't be used to convey an injection attack. There is no harm in escaping data properly - it will still render in the browser properly. Escaping simply lets the interpreter know that the data is not intended to be executed, and therefore prevents attacks from working.

Untrusted data is most often data that comes from the HTTP request, in the form of URL parameters, form fields, headers, or cookies.

XSS Prevention Rules

RULE #0 - Never Insert untrusted Data Except in Allowed Locations

The first rule is to deny all - don't put untrusted data into your HTML document unless it is within one of the slots defined in Rule #1 through Rule #5. The reason for Rule #0 is that there are so many strange contexts within HTML that the list of escaping rules gets very complicated. We can't think of any good reason to put untrusted data in these contexts.

RULE #1 - HTML Escape Before Inserting Untrusted Data into HTML Element Content

RULE #2 - Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes


RULE #3 - JavaScript Escape Before Inserting Untrusted Data into HTML JavaScript Data Values


RULE #4 - CSS Escape Before Inserting Untrusted Data into HTML Style Property Values


RULE #5 - URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values


RULE #6 - Use an HTML Policy engine to validate or clean user-driven HTML in an outbound way


RULE #7 - Prevent DOM-based XSS

Referance: OWASP

PL post your queries.......
and any other suggestion to remediate XSS.

No comments:

Post a Comment