XSS (Cross-Site Scripting) - Methodology and Solutions

[Former Member]

Well this is a continuation of my previous blog on XSS (Cross-Site Scripting) - Overview and Contexts and this time I will continue with attack methodology and solutions. Actually if we think closely we can realize that each attack should have a methodology through which an attacker try to bypass a context or any filter. If we can follow this below methodology we can be at least sure that whether there is an XSS or no XSS in the particular Injection Point.

Though the examples shown here are from PHP but are applicable to any sever side languages. And using the help of this methodology we can later able to achieve a secure solution or XSS sanitizer. Let's proceed it on the basis each contexts showing simple examples.

Attack Methodology:

Script Context Attack Methodology

We would use simple scripting to bypass the context and here it has been consider as 3 step process. So here the Injection point has been reflected back as a part of variable of a script tag and there could be two possibilities as from server wither use single or double quotes. Semicolon in the beginning is statement terminator here and terminate the variable value (variable declaration has been closed), any event handler can be use like  alert, confirm or prompt but in real life scenario the attacker never use such simple, so this is only a proof-of-concept for JavaScript execution. The last semicolon in the injection point will take care of the end of variable declaration.

If the first two injection point fails then we can also prematurely closing the script tag as the variable value  and execute JavaScript of our choice like in the third step. If any of the steps could not bypass the context then there is no bypass possible for this context. All these steps here are browser independent but we need to consider as well that chrome has a XSS Filter and not good for the testing.

So just by looking into the source code we can find out the context and based on the context we can apply the respective attack methodology to find whether there is a XSS bypass. For a example we can check Edit fiddle - JSFiddle

Attribute Context Attack Methodology

In a very similar way we can check the Attribute Context which is again a 3 step process. Here we use a Div tag and class as an attribute. Injection point is reflected back in the value of the class attribute the injection will land here. We can use any event handler, here it has been use onmouseover just to show the proof of concept. The first two steps are browser independent but not the last one as back tick works on old Internet Explorer only.

For a example we can check Edit fiddle - JSFiddle

Style Context Attack Methodology

Modern browsers does not allowed you to execute via style so in spite of 3 step process it is more specific to old Internet Explorer. The injection point has been reflected back as the value to the attribute style. This is actually a dynamic CSS. First step is simple calling of event handler where in the next step multi line comment has been use as an old trick. The 3rd and 4th steps steps are only use case of encoding, 3rd step encoded in hex or decimal form as both start with & sign while last step is CSS escaping.

URL Context Attack Methodology

Injection point here has been reflected back as a value of href or as a URL. Here to make it better we use different encoding options.

First step is plain JavaScript based URI, second is bit complicate JavaScript based URI with small and lower cases and encoded the parenthesis as URL encoded form. Html5 encoding has been used in the third step inside the word JavaScript. Fourth one is database URI and last one a vbscript.

By using all these steps it can be find out that whether the context is XSS by-passable or not. All of the steps are browser friendly except the last one.

Encoding is also need to get consider when there is a explicit decoding from server die response otherwise it doesn't make sense. There are huge numbers of ways to encode and this it itself a different interesting topic to discuss.

Solutions:

Custom XSS Solutions:

They are very common and use by many applications around these days as they are widely and easily available specially on Github.

Let's check how strong are these solutions:

RemoveXSS:

Can be found in the Github, first array consist of blacklisted words, second list consist of event handler for explicitly mentioned these keywords. The main purpose is to filter these keywords from the input. Are also popular as  filterXSS or noXSS.

But if we use the exemption then it could be bypassed easily which we have seen also in the attack methodology as there are number of ways to change this keywords.

width: ex/**/pression(alert(1))

ja	vasc&NewLine:ript:alert(1)

cleanInput:

Very popular on the Github. It consist of array of 4 elements, first look for script tag, second for <> tag, while third looking for style tag and the fourth one for multi line comment and whenever this filter found these elements then it just remove it. This filter works on the basis of the understanding the input would contain any of these elements for XSS.

But this could be again bypassed by using a half open tag as below.

<img src=x id=confirm(1) onerror=eval(id)

sanitizeCSS:

This filter can only use in the style block and this state, the first regular expression look for URL and second try to capture the small left parenthesis.

To understand the code we use the tool regexpert, so when we input the regular expression then we can visualize the regular expression as well.

Bypass is possible for this filter as well as per the below example

width:expression(alert(1))

detectXSS:

In this filter the first array looks for event handler while the second looks for the keyword with it's own way. Bypass is possible here as well as given below.

Summary of Bypasses:

As we can see from the last examples, not only these the most used best 10 customized solutions currently by the web applications are by passable.

If you see the above summary you can even noticed which context is valid. So one should carefully consider these solutions and these are not fool proof. It is always better to test as per the attack methodology shown above and develop our own solution based on these custom solutions then our filter will be more stronger. We should also keep in mind that filters and solutions should be in layers starting from WAF, client side validation, server side validation and sanitization.

Based on the attack methodology and contexts if we can add the below solutions with the customs one our filter would definitely become stronger. Some of them are shown below:

Like attributeContextCleaner where the filter just replace 3 elements to prevent the XSS in attribute context.

Another one with styleContextCleaner where the filter just replace 6 elements to prevent the XSS in style context. Id we just follow the attack methodology we will able to understand how we could restrict the XSS.

Similarly we can have urlContextCleaner, which is little different from the other contexts. In order to protect JavaScript execution we are going to use regular expression which will force us to use http or https or even ftp in way where we can’t execute JavaScript.

Currently there are others injection points as well like files, images, video, other things to upload it has been clear that more injection points means more chances to XSS. So we have to carefully provide option in out web applications. for example WISIWYG (What You See Is What You Get) editor are more close to vulnerability.

Further model to prevent XSS can find in  XSS (Cross Site Scripting) Prevention Cheat Sheet from OWASP

The attack methodology and solutions shown here may not work with HTML5 as it has various new options but as a whole still iit has not been used in huge number of web applications yet. you may see the HTML5 Security Clean Sheet  and  HTML5 Security Cheat Sheet from OWASP for the further options.

Happy XSSing!

(Most of these details, screenshots and explanation has been shared from Ashar's Talks) If you want to know more over the XSS I would definitely recommend to visit the slides from the Ashar's Talks (Presentations by Ashar Javed)  and the blogs(on XSS) where he nicely explains over his works, findings and his bypasses.