Hi Everyone,
I want to talk about some advanced attacks and potential security flaws especially when using JSON Applications that can lead to Data Injection/Session Hijacking issues.
In this 1st part i’ll talk about a particular kind of vulnerabilities in web applications that are vulnerable more and more to XSS vulnerabilities that are reflected in non HTML responses, For example : JSON. Before I go further, i want to define JSON : JavaScript Object Notation (JSON) is a simple, text-based data transfer format that is used to transmit data between a server and web applications, it’s widely used as a transport mechanism in AJAX applications. I’ll not give some JSON code samples you can find it over the net. In general, every expression that is valid in JavaScript is also valid in JSON.
So in order to apply our tests we have to know that JSON data objects can be evaluated. So, this feature helps to overcome the security restrictions applied by the SOP (same origin policy). However, we can use scripts to communicate and transmit data by the nature of AJAX applications.
Hacking JSON consist on the following typical Fuzzing techniques :
– Array overwrite.
-Large/negative numbers.
-Symbols like <@’_”%/–.
-Additional serialized objects.
As i mentioned before i’ll demonstrate an example of exploiting an XSS vulnerability. But exploiting XSS vectors against Internet Explorer is more than an “alert(‘XSS’)” and as we all know it’s a little bit hard in this situation because browsers pop up the file download instead of rendering the response when the returned content-type is application/json or application/javascript or application/json-rpc.
Thus, the only solution is to bypass JSON parsing mechanism to indirectly exploit this issue, before we move to the trick that will allow us to attack the vulnerable application (IE versions below 10), I want to explain how Microsoft Internet Explorer Filters works. Recently i had a chance to explore how this filters prevent such attacks :
Microsoft Internet Explorer’s XSS Filters : ===============================
Filters within Internet Explorer (IE) 8/9 have the capability to deal with and to detect reflected XSS attacks by applying regular expressions to response data. If this data were reflected within the response, IE would handle the payload to prevent it from actually triggering.
The following command show some Filters :
C:\>findstr /C:”sc{r}” \WINDOWS\SYSWOW64\mshtml.dll|find “< C:\>findstr /C:”script” \WINDOWS\SYSWOW64\mshtml.dll|find “{”
Here are a some of the extracted regular expressions including Unicode characters, common URI attributes and event handler names…etc :
After converting the resulting regular expressions, then creating SecRules to prevent XSS attacks against a web application, any
user can apply blacklist-filtering secrules against incoming request data. Some of the converted IE XSS filters:
It was just a quick look into IE Cross-site Scripting filters, Now we pass to the method we’ll use to overcome the problem we encounter previously. This problem is linked to IE content sniffing heuristics, any file can be interpreted as executable Javascript under many circumstances. It’s actually a security weakness even if the data is sent with the appropriate JSON content type and well configured, this concept remains true even if JSON is not embedded in HTML. However this way is based on rendering JSON responses in IE by direct browsing. First we should know how IE defines file types and what content-type will be set for each response :
- IE search for the response data content-type in the windows registry for the specific CLSID key (know more about CLSID i.e: “CLSID”=6650f4a1-E8B5-A1CF-BB82-012500DDCE0B ), to find the correct handler for that response.
-
If the content-type is found, IE will consider that to be the valid content-type otherwise IE will attempt to identify the content-type from the file extension or another way.
In our situation the default mime-type list of Internet Explorer does not include any JSON data mime-type. Besides when visiting a link with JSON data included, IE directly prompts the file download dialog because the specific content-type to consider for the requested file is not found when IE attempts to search in the windows registry (HKCR\MIME\Database\Content Type\CLSID).
In order to force IE to recognize JSON responses and render them, the file extension must be considered by IE as text/html (.htm or .html) within the URL. In addition regarding the manner that most web servers use to parse the path, most server side languages (PHP, Python, Perl CGI…) accepts “path-info” parameter that uses the slash sign (/) as delimiter to be passed from the URL (i.e : HTTP://[domain_name]/[path-info]?[GET params]). Then when an web application is vulnerable to a reflected XSS, the attacker simply adds “.html” as path-info, consequently the server returns a page with XSS content and the same JSON file type and finally IE matches .html path-info to be text/html and directly triggers XSS.
This way we are now able to exploit XSS using a combination of path-info parameter and IE’s content-type designation weakness.
That’s all for this 1st part guys stay in touch … 🙂
You can check my previous research about a kind of JSON attacks : http://www.marw0rm.com/handling-session-actions-web-application-authorization-bypass-youtube-as-example/
Follow me on twitter : https://twitter.com/r007hunt
r00thun7 