Cross Site Scripting (XSS)

Cross Site Scripting (XSS) is one of the most common types of attacks on web applications. In fact, the programming error that leads to Cross Site Scripting Attacks (XSS) is considered to be the top most dangerous programming error.  This clearly demonstrates the devastating effects of Cross Site Scripting attacks. Cross Site Scripting attacks typically occurs on web applications which accepts the input data and echo backs the data to the user. In simple words, web application that accepts the input from the user and displays it back without proper validation. A common example of this sort of web applications could be of the websites that allows users to post their feedback, reviews or comments and the other users could actually see the submitted reviews or comments. Cross Site Scripting (XSS) attacks occurs when an attacker injects the malicious code in such web applications and later that code affect other users. Using malicious scripts, the attacker could access lot of sensitive information like cookies, session information and other important information stored on user’s browser. The users can even be re-directed to an authentic looking web application that accepts user’s credentials but is actually controlled by the attacker.

Types of Cross Site Scripting Attacks (XSS):

Generally, Cross Site Scripting (XSS) attacks are of 2 types: Stored/Persistent and Reflected/Non persistent.

a. Stored/Persistent Cross Site Scripting Attacks:

 In Stored Cross Site Scripting attacks, the attacker injects the malicious code in the application that would be permanently saved in the database. As the malicious code is being saved in the database, the script will run for all the users who will try to access that page. The most common examples where Stored/Persistent types of attacks takes place are the web applications that allows users to post their comments, feedback’s  etc which are stored in database so that it can be rendered back on page. Some of the examples of the malicious code that an attacker can inject are as follows:

1. location = “http://www.sitename.com/ “
Effect: This piece of malicious code when injected to a web form can redirect the users to other web pages that are controlled by the attacker. The destination page could look similar to the original web site and ask users to enter their login credentials.

2. alert(document.cookie);
Effect: This test piece of code exposes the cookie information stored on user’s browser. An attacker could modify this code to steal the cookie and other important information.

b. Reflected/Non Persistent Cross Site Scripting Attacks: 

The Reflected XSS attacks are very much similar to Stored XSS attacks, except that the malicious code used in the attack is not stored anywhere. In Non Persistent Cross Site Scripting attacks, instead of storing the malicious code on the server, the attacker appends the script to the query parameters or to the form submissions. For Reflected Cross Site Scripting attacks to occur, the attacker must first convince the user to visit the malicious URL or to submit some sort of form. Once the user visits the URL or submits the form, the attacker could install spying software on user’s computer or steal sensitive information.

Out of the two types of XSS attacks discussed, the Reflected/Non Persistent attacks are more prevalent. However, for Reflected/Non Persistent attacks to occur, the users must be convinced to visit a malicious URL or to submit a form. That is, it is targeted on individual users. On the other hand, for Stored/Persistent attacks to occur there is no need to target individual users because the scripts stored on the server executes automatically for every user accessing the infected page. Therefore, the Stored/Persistent XSS attacks are more destructive then Reflected/Non persistent attacks. [1]

Preventing Cross Site Scripting Attacks:

As discussed above, Cross Site Scripting Attacks occurs when an attacker is able to inject malicious code in a web application that enables the attacker to access sensitive information of other users. The Cross Site Scripting attacks can be very dangerous and both the user and the developer should take steps to prevent this kind of attacks. One method of preventing these attacks on end user side could be to disable scripts on the user’s browsers. However, disabling scripts would mean reduced functionality and therefore, this is not the ideal way of dealing with these types of attacks. Moreover, disabling scripts could prevent individual users from these attacks but would do nothing to completely eliminate Cross Site Scripting attacks. Hence, it is the responsibility of web developers to full proof their applications against these types of attacks. Developers should properly filter the user input and encode the output content to deal with these types of attacks.

a. Filtering:

 To prevent Cross Site Scripting attacks, web developers should never trust the user input. Web developers should filter both the input content and the output content. It is not a good practice to filter only the input content submitted by the users. This is because of the fact that there is lot more ways to enter data into database other than HTTP. Therefore, it is highly required for the web developers that they also filter the output content before it is rendered on the web page. The filtering mechanism can be as simple as looking for specific tags and replacing them with a space or anything else that does not cause any damage to the application. [4][5]
Example:

String maliciousCharacters=”[();/]“;
String FilteredStr = content.replaceAll(maliciousCharacters,” “);

The above lines of code will first look for special characters that are mainly used in scripting languages. Then it will simply replace those characters with a space and thus, making malicious code unable to execute.

b. Encoding: 

Encoding is a method where all the dynamic content before being rendered on the web page is properly encoded so that no malicious scripts can run on the end user side. Encoding is nothing but replacement of all the special characters to the specific codes for any encoding mechanism. For an efficient encoding mechanism, web developers should first identify if their output data contains anything from the user input. If this is the case, then all the output data must be properly encoded. [4][5]

References:

1. Cross-site scripting – Wikipedia, the free encyclopedia. (n.d.). Wikipedia, the free encyclopedia. Retrieved April 27, 2010, from http://en.wikipedia.org/wiki/Cross-site_scripting

2. Cross-site Scripting (XSS) – OWASP. (n.d.). OWASP. Retrieved April 29, 2010, from

3. Cross site scripting / XSS – How to find & fix it with a web scanner. Website Security – Acunetix Web Security Scanner. Retrieved April 29, 2010, fromhttp://www.acunetix.com/websitesecurity/cross-site-scripting.htm

4. Lee, P. (2002, September 1). Cross-site scripting. IBM – United States. Retrieved April 29, 2010, from http://www.ibm.com/developerworks/tivoli/library/s-csscript/

5. How to prevent cross-site scripting security issues. (n.d.). Microsoft Support. Retrieved April 29, 2010, from 

6. Meier, J., Mackman, A., Wastell, B., Bansode, P., & Wigley, A. (n.d.). How To: Prevent Cross-Site Scripting in ASP.NET. MSDN: Microsoft Development, MSDN Subscriptions, Resources, and More. Retrieved April 29, 2010, from http://msdn.microsoft.com/en-us/library/ms998274.aspx

7. Beaver, K. (2008, January 15). Cross-site scripting 101: XSS attacks plague Web browsers :: SearchSecurity.com.au . Information Security: Covering todays security topics . Retrieved April 29, 2010, from http://searchsecurity.techtarget.com.au/articles/22257-Cross-site-scripting-1-1-XSS-attacks-plague-Web-browsers

8. Testing for Reflected Cross site scripting (OWASP-DV-001) – OWASP. (n.d.). OWASP. Retrieved April 29, 2010, fromhttp://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OWASP-DV-001)