Wednesday, 19 February 2014

DOM Based XSS Explained

In this post will talk about DOM Based XSS which is also known as type-0 XSS. DOM XSS is very difficult to find using scanner and most of the time scanner tend to give false positive. 

In DOM based XSS attacker modifies object of Document Object Model. Modifying DOM environment does not change response  but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

In the other form of XSS (stored and reflected) payload is executed in the response due to server side flow contrast to DOM based XSS. 

Let's see an example. 

As we can see in below screen shot website having parameter called "page". 


And value to this parameter appears on website as a marquee. This value can be modified by attacker. 


Now let's insert XSS payload <script>alert('XSS')</script> to the "page" parameter. And attacker can also craft URL with payload <script>alert(document.cookie)</script> and send it to victim to get session cookie. 



There are few guidelines for the developer to follow to avoid DOM based XSS. Any Untrusted data should not be rendered instead use encoding or sanitize input. Also avoid HTML rendering methods like document.write & element.innerHTML. 


Reference: https://code.google.com/p/domxsswiki/wiki/Introduction

SQL Injection Authentication Bypass - Request Method

In this post we will see variant of SQL injection to bypass authentication using request method. 

During my penetration assignment I was testing a login page to check presence of SQLi. I tried various payloads for error based and Boolean based injection but nothing worked. Then I bypassed login page by just manipulating request method. Simple :) 

Below is the Login page. And I tried simple payload with abc' OR '1'='1 -- in password field. 


And the response was invalid input. 


After trying several payloads I looked at the source code of the page. And I found the flow. 




As we can see in above screen shot application is using AJAX and it's validating the username and password field if submitted request is POST. so what if we send GET request with payloads as above. Let's see. 



I changed request method using burp inbuilt function and get through the next page with first user in database. Now if we want we can also enumerate users by changing payload and using LIMIT function. For example: in password field you may try abc' OR '1'='1' ORDER BY UserID ASC LIMIT 2, 1 --. This first gives error stating table UserID does not exist. 

Try and brute-force table names and then you can keep changing LIMIT 2,1 to login with other users. So it is advisable sensitive pages should be server only through POST method. 




Tuesday, 18 February 2014

Intro to W3af (Web Application Audit & Attack Framework) - Part 1

Introduction:
w3af (Web Application audit and attack framework) is a web applications framework for auditing and exploitation. In this article we will demonstrate how to scan application(s) using CLI, overview of various plugins and inter-communication among the plugins.
Features:
W3af plugins communicate with each other i.e. discovery plugin identify different application URLs and passes the result to the audit plugin, which further uses these URLs to find vulnerabilities. W3af has features like fuzzing and manual request generator and also be configured as man-in-the-middle proxy.
Plugins:

To open up the console type the following command.  It may ask you to update the W3af repository.



Figure 1: W3af Console

Now type command = ‘help to provide details of available features. 

Figure 2: W3af help

The command, ‘plugins’, can be used to list the available plugins in the framework. We can further explore available options within each plugin. keys command can be used to see list of short cut.

Figure 3: Keys command

Enter the plugin name followed by help (i.e. help PluginName) to find details about the plugin. Example:  help Discovery will fetch the details regarding Discovery plugin.  


Figure 4: Discovery plugin

There are 9 plugins in the w3f framework. A user can enable one or more plugin(s) as per their need. In this section, we will go over some of them.  

Discovery:  
Discovery plugin crawls and identifies URLs/forms with in the web application. This information is used detect web vulnerabilities. This plugin has features like spiderMan, hmap, webspider etc. We can type ‘discovery’ to check the options in this plugin.  


Figure 5: List of discovery plugins.

To get further information on the certain plugin, we can type discovery desc ‘pluginaname’. For example, discovery desc xssedDotCom, would retrieve us help on xssedDotCom plugin.


Figure 6: XSSedDotCom Description
Other commonly used commands are listed below:
       To enable more than one plugin: discovery plugin1, plugin2
             To enable all plugins: discovery all
              Removes all enabled plugins: discovery !all
       List enabled plugins: list discovery enabled


Figure 7: Some more commands

Audit: Audit plugin detects vulnerabilities on the URL’s identified by discovery plugin. This plugin injects various set of input strings and verifies the responses. It can identify vulnerabilities like SQL injection, XSS, CSRF etc. To retrieve the details about XSS feature in this plugin, we can type: audit desc xss


Figure 8: XSS Plugin description

The screen shot above shows that there are two configurable parameters available for XSS. We can set numberOfChecks by typing the below command.


Figure 9: Configure XSS parameters

Grep: The grep plugin works like passive scanning and finds issues by analysing request/response. It can look for information like credit card number, PII details and forms with file upload functionality etc. It is essential that we enable discovery plugin before using grep.


Figure 10: Grep Plugin for file upload

Output: The output plugin can help us produce results in different formats. Currently the supported formats are XML, Console, html, text etc. Users can also configure parameters like filename, verbosity level etc.  

In next post will see how to configure basic scan using some common plugin and identify vulnerability like XSS.