Cross Site Scripting (XSS) FAQ

Document created by kb-author-1 Employee on May 19, 2010Last modified by eschamp on Jul 25, 2010
Version 5Show Document
  • View in full screen mode

Issue:

Cross Site Scripting is a serious vulnerability for a web application. To better understand what XSS is and how it works, this FAQ will answer certain questions.

 

Taken from:

 

http://www.secguru.com/param/commonly_asked_cross_site_scripting_questions

 

 

Question:

What role does the web application play in XSS attacks?

 

Cross site scripting vulnerabilities are categorized into two broad types:

 

    * Reflected

    * Stored

 

Web Application software may contain a vulnerability where it echoes the input provided by malicious attacker (Reflected) or it may store this input into a database that may later execute on other users (Stored).

 

To utilize Reflected XSS, a malicious attacker may trick a user of the web application into clicking a link which includes script tags. The web application presents the dynamically generated page to the user without removing the script tags, which then executes in the victim's browser. Cookies may be stolen in this attack, which could potentially be used to hijack the user's session.

 

However, to utilize Stored XSS no involvement is required from the client to get exploited. A malicious user stores script tags on the web page and it executes on every visitor's browser.

 

( An example of stored XSS would be a webpage which displays the last x number of refererals. A malicious attacker then sends a request to applications embedding script tags in the referrer tag. If not checked, they are stored and sent to each viewer\'s browser. )

 

 

Question:

How to stop Cross Site Script attacks? Is filtering a user input enough to stop XSS attacks?

 

A general rule of thumb is "Never trust user input and always filter meta-characters." In most cases, attempting to remove dangerous meta-characters from the input stream leaves a number of risks un-addressed. Developers should restrict variables used in the construction of pages to those characters that are explicitly allowed (similar to firewall rules where you put deny all and then open only certain ports). Looking for known, valid, and safe input is much easier than looking for known malicious or dangerous input.

 

Converting <and> to < and > is suggested and a popular approach among most developers. To add an extra layer of protection you may also translate them to ISO-8859-1 character set. Developers should explicitly set a character set to an appropriate value in all dynamically generated pages. For example, UTF-7 provides alternative encoding for "<" and " > ", and several popular browsers recognize these as the start and end of a tag.

 

 

Question:

Any real life example of an XSS attack through malicious URLs ?

 

An exploitable URL based XSS vulnerability when added to Phishing attacks is harder to spot even for the most alert users.

 

Phishing attacks so far have relied on spoofing techniques, where a malicious URL is made to appear identical to a trusted URL, through a variety of techniques. However, these exploits have a number of limitations, all related to the fact that the site the user is looking at is not really a trusted site. For example, they do not open a secure SSL session.

 

The main advantage of script-injection phishing attacks is that they are carried out on the trusted site itself. So even if the user is vigilant and verifies the identity of the site by examining the SSL certificate, the attacker is still able to steal information. This may also bypass the new anti-phishing browser plug-in for IE and Firefox.

 

 

Question :

What is a null character injection? Any examples?

 

Null character injection is a technique used to bypass sanity checking filters by adding URL encoded null-byte characters to user-supplied data.

 

With ASP.NET framework, Microsoft attempts to make it easier for application developers to write secure code. Microsoft added a new feature, named Request Validation to provide out of the box protection against cross site scripting and script injection attacks by automatically checking all parameters in the request and ensuring that their content does not include HTML tags.

 


Question:

How is XSS used to conduct account hijacking, cookie theft etc...?

 

With XSS, a malicious user can make a web server echo back any script of his choice. He can code a script which when runs in the client's browser and sends the live-cookie to the attacker\'s listener code. This code can then automatically send the same request as a victim along with the live cookie and conduct account hijacking.

 

It is suggested to keep low values of idle_session timeout and session_timeout values in order to safeguard critical applications against such attacks.

 

Stored Cross site scripting is more dangerous and it can run on the back-end of the web application, too. For example, a site with form fields to collect user information such as FirstName, LastName etc.. if not properly validated, an XSS on these fields would get stored in the database and may run when site administrators view the user_information page.

 

 

Question:

What are the recommendations to protect against XSS. What about large web sites that have no formal XSS security mechanism?

 

The Best Practice suggests to design centralized input validation code, which sanitizes the user input. In the meanwhile, administrators may also implement mod_security to defend their sites, because discovering all entry points and trust boundaries for variables is a time consuming process. Commonly used parameters for XSS are headers, cookies, query strings, form fields, and hidden fields.

 

The centralized input validation code should be modular and consistent across the web application. All user input should be validated for canonicalization, type, length, format, and range. Such design could also limit the scope of SQL injection.

 


Question:

Any recommendations on how and what to sanitize ?

 

The three basic checks for avoiding an XSS vulnerability are:

 

    * Constrain Input

    * Validate Input

    * Encode output

 

Developers can constrain input by validating it against a regular expression, which ensures that an input value matches a specified pattern. Developers should also validate the range to check that the user enters an input value that falls between two values.

 

User input should also be validated against predetermined types such as integers, strings, etc by converting it to the required data type and handling conversion errors.

 

Output Encoding should be used while displaying data from the user or database. Data Encoding functions like HTMLEncode would replace < with < , " with &quot; and prevent browsers from executing any malicious code. For encoding any dynamic output URLs use functions like UrlEncode.

 


Question:

What is this Apache mod_security and can it protect against XSS ?

 

ModSecurity is an open source intrusion detection and prevention engine for web applications. Operating as an Apache Web server module or standalone, the purpose of ModSecurity is to increase web application security, protecting web applications from known and unknown attacks. Mod Security comes along with a default configuration file with protection against XSS attacks (although limited).

 


Taken from: 

http://www.secguru.com/param/commonly_asked_cross_site_scripting_questions

 

 

Qualys Support KnowledgeBase

http://community.qualys.com/community/kb

 

ID: 0003.001.613.000

Attachments

    Outcomes