XSS (Cross-site scripting)

It's only fair to share...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInDigg thisShare on RedditPin on PinterestPrint this pageEmail this to someone

Cross-site scripting is a vulnerability that exists in many web applications. It is rated as a top threat for web application developers and also rated as one of the famous types of exploits among web application hackers. Before moving ahead, I’d like to point out few examples that prove how common cross-site scripting is, even in nowadays, after 11 years from February 2, 2000 when the first advisory about Cross-Site Scripting (XSS) was published, namely Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests.

Drupal is a famous open source content management system. Shown below is a screenshot of Drupal, Security Mailing list (2011 February).

Click to enlarge

In 2011 February Drupal security team has found 8 security vulnerabilities and 5 out of 8 of those are XSS (Cross-site scripting) related vulnerabilities. In March 2011 it is 3 out of 5. In January 2011 it is 2 out of 3. All together, in year 2011 Drupal team found 16 vulnerabilities and 10 of those are directly related to XSS, making 62.5% of vulnerabilities found in Drupal in year 2011, XSS related.

Not only Drupal, but most of other famous web application that highly interact with end users contained this type of attacks. Some examples are Twitter, Facebook, and even President of US,Barack Obama’s official web site.

What is XSS?

As discussed before Twitter, Facebook, or such web application can be identified as applications trusted by community. XSS or cross-site scripting is a situation where an attacker could possibly inject a malicious code into otherwise trusted web application.This could happen due to many reasons including poor input validation and fail to use encodings in vulnerable data. Once XSS attempt was successful an attacker will gain the abilities such as changing content of your web application, extracting information about user session and even completely disabling the web application.

I thought of using, using a simple web application, to demonstrate few basic examples of XSS and how to fix these vulnerabilities.

Below code is used in “errorPage.jsp” which will be displayed if a user tries to access a non existing resource.

As you may see it is directly printing “errorURL” HTTP GET parameter into the body of response. Original expected result of this page is shown below:

Request URL : http://localhost:8080/errorPage.jsp?error=notfound&errorURL=TestPage.jsp

Click to enlarge

Let’s change “errorURL” request parameter to a JavaScript (<script>alert(‘XSS’);</script>) to check if this page is vulnerable to XSS attacks.

Click to enlarge

As you may see browser has executed the JavaScript we placed in URL. Now as we or some hacker knows that this “errorURL” makes the application vulnerable to XSS, he/she can simply use this to malicious abuse the application to do many things. Next section of this discussion is dedicated to understand what these “Many Things” are.

Effects of XSS

Let’s consider previous example to identify what could be the effects of XSS.

Changing content of a web application

It is possible to change content of a web application by exploiting XSS vulnerability. Such situation is demonstrated below:

Request URL – http://localhost:8080/errorPage.jsp?error=notfound&errorURL=<script>document.getElementById(‘name-text’).innerHTML=%22Hacked%20by%20Ayoma</script>

As you may see request URL clearly shows that we are modifying the content of web application to others. This is not a good sign when it comes to XSS, because victim will now that they are following a URL which is used in XSS. So that we can encode the GET parameter using related HEX values as shown below. This HEX encoding can be used to prevent some browsers such as Firefox and Chrome from automatically preventing XSS attempts.

Encoded Request URL – http://localhost:8080/errorPage.jsp?error=notfound&errorURL=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65%6E%74%2E%67%65%74%45%6C%65%6D%65%6E%74%42%79%49%64%28%27%6E%61%6D%65%2D%74%65%78%74%27%29%2E%69%6E%6E%65%72%48%54%4D%4C%3D%22%48%61%63%6B%65%64%20%62%79%20%41%79%6F%6D%61%22%3C%2F%73%63%72%69%70%74%3E

Response –

Click to enlarge

Thought above situation is bit harmless, think of a situation where some data entered by user is stored in a database and printed on another user’s browser. Let’s simulate such situation by the hackable version of User Profiles section. User’s full name is set to “Test User<script>document.getElementById(‘name-text’).innerHTML=”Hacked By Ayoma”</script>” and this value is saved to the database.

Click to enlarge

As this malicious code is stored in database and loaded each time user’s full name is displayed harm of this is more than just changing a URL.

Result :-

Click to enlarge

This ability of changing content can be used to promote other web applications or tasks, inject various advertisements, harm reputation of web applications, increasing search engine ranking by adding forward links, mislead users and even in phishing attacks by showing or changing authentication forms maliciously.

Extract Session information

This section is bit related to Devaka’s post about evil session IDs. However we’ll be focusing more on extraction session information using XSS vulnerabilities. JavaScripts are allowed to read Cookies from web browser where session details are maintained. However JavaScripts from a particular domain cannot access cookies stored by another domain. In order to extract session information of a web application it is required to make related JavaScript calls from a page that is located within the domain which created the cookies. This is where XSS become important. It is possible to prevent JavaScripts from reading a cookie by making it HTTP ONLY, but some web developers disable this feature even from Session IDs to allow providing more interactivity and client side validations.

Let’s consider an example. We have included below line to the home page of our hackable web application:

In above code, we set HttpOnly to “false” for the cookie that store “JSESSIONID”. Then we add another regular cookie that contains “secret client information”. As demonstrated before, User Profile is vulnerable to XSS. Let’s try to grab these session information using XSS. A simple cookie stealer is coded using PHP as shown below and hosted at http://127.0.0.1/xss.php.

Now, let’s modify the address field of the user profile as shown below:

Click to enlarge

This JavaScript will secretly call “http://127.0.0.1/xss.php” and pass data stored in cookies to the “cookie” HTTP GET parameter. If anyone try to view the user profile which contains the malicious code, session information stored under that user’s profile will be extracted by “xss.php” and will get stored in a text file. No suspicious code or information will be displayed under user profile which makes the identification of attack hard.

Click to enlarge

Disabling a web application

Setting a script like (<script>document.location=”http://lms.codl.lk”</script>) in the name field of user profile will redirect users to “http://lms.codl.lk”, every time they render the name of that user. All the pages that show data stored in this field will be disabled and such redirect can be used in a phishing attack to redirect users to a different authentication page.

Many Other Possibilities

It is not possible to state that these are the possibilities an attacker might gain by using XSS vulnerabilities, because they have control over a certain area of the web application. They are allowed to use JavaScripts to do various things. DOM manipulation abilities of JavaScript open up lot more possibilities. Actually, the level or risk depends upon the design and development practices followed in developing the web application.

How an application can be vulnerable to XSS and how to prevent XSS?

Input validation

When considering the example scenarios we discussed profile fields or error descriptors were not validated against invalid characters. Strongly validating input parameters is important in preventing XSS. Someone’s name can not possibly contain symbols like ” < > ‘ \ / =. It is possible to show an error message if such symbols were used. However an attacker might use encoding to fool such validations. It is important to check for encodings such as URL Encoding and complete HEX encoding of strings when validation input fields.

Use of proper encoding

As demonstrated before Persistent XSS attacks are dangerous than non Persistent XSS attacks. Before persisting data to a database or a data file, encoding information peoperly can prevent many persistent XSS attacks. As an example, we use below code to encode profile fields into HTML strings.

StringEscapeUtils class is a part of Apache Commons project.

If any user tried to use a HTML tags within a profile field these HTML tags will be converted into their equaling escaped format. Because of this if <script> tag was used, it will be converted into &lt;script&gt; before getting stored in the database. This will make it just a block of text but not a HTML tag. Now if we try using a malicious JavaScript like “<script>document.getElementById(‘name-text’).innerHTML=”Hacked By Ayoma”</script>” as a profile field, it will not act as HTML tags. Instead of that application will print HTML code in text, as shown below:

Click to enlarge

Secure session management

Secure session management is not a way to prevent XSS, but it is possible to reduce the risk of a XSS by using such practices. Managing user session information is a secure manner is important. Session IDs shouldn’t be exposed to Scripts. This can be done by setting them to HTTP ONLY. Also, if any other cookie contains sensitive information, keeping it away from Scripts is better. It is possible to use this to secure the session information previously exposed, by using below code.

“JSESSIONID” is already HTTP ONLY, so that it is not necessary to explicitly set that. Now if we try out the Cookie Staler we created output will look like what is shown below. (Please note that above mentioned encoding is disabled again to simulate this attempt).

Click to enlarge

·Other solutions –

oDisabling script support of browser

oUsing frameworks that are developed to prevent XSS

oUsing web application proxies to filter incoming and outgoing data

XSS (Cross Site Scripting) Cheat SheetEsp: for filter evasion By RSnake can be identified as a good source that can be used to learn various possible XSS attacking methods and prevention methods. Feel free to post your related questions below.

It's only fair to share...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInDigg thisShare on RedditPin on PinterestPrint this pageEmail this to someone

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">