XSS (Cross-Site Scripting) – Methodology and Solutions
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.
Script Context Attack Methodology
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.
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.
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:
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.
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)
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
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.
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.
(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.