Web Application Scanners benchmark - 2014

The *NEW* 2013/2014 WAVSEP benchmark was published: *63* web application scanners competing in 12 categories - by Shay Chen.

For more info: http://sectooladdict.blogspot.co.il/2014/02/wavsep-web-application-scanner.html

Web Application Scanners benchmark

As a security expert i was looking for web application security scanners benchmark. One day, during beer night with my friend Shay Chen(another security expert :-)), i asked him if he knows about such research and he told me that he is planning to publish such kind of benchmark very soon.
It was worthwhile to wait for his comprehensive benchmark of web application scanners that can be found here http://www.sectoolmarket.com

The following comparisons are covered in this benchmark:

List of Tested Scanners

General Features Comparison

Audit Features Comparison

Complimentary Features Comparison

Input Vector Support

Coverage Features Comparison

Authentication Features Comparison

SQLi Detection Accuracy

RXSS Detection Accuracy

It is obvious that such benchmark that indicates the advantages/disadvantages of each scanner, can help the security community to choose the appropriate scanner according to their needs.
Good work Shay!

How to bypass token protection against CSRF in HTML 5

This article would explain how it is possible to bypass token based protection against CSRF attacks as a result of improper usage of HTML 5 XDR/COR mechanism.

As we all know, today popular browsers implement the SOP (Same Origin Policy) mechanism in order to prevent from sites to access and get other sites' content via Javascript. However, there are sometimes business needs which require such cross domain access and technologies such as flash and silverlight already have implemented the well known crossdomain.xml file which defines a list of allowed sites that can access a site.

HTML5 brings us a similar mechanism the XDR (Cross Domain Request) also known as COR (Cross Origin Request). This mechanism allows a website to be accessible by foreign websites via Ajax calls. In contrary to flash/silverlight, XDR works on a per-page access control model. Every page that is supposed to be accessed by foreign sites, should respond with the ‘Access-Control-Allow-Origin' header in the HTTP Response header and specify a white list of websites that are allowed to access its content.

The big security concern is that programmers would set the Access-Control-Allow-Origin with the wildcard '*', which means that all websites are allowed to access the pages which contains such definition via ajax calls.
Example: Response.AddHeader("Access-Control-Allow-Origin", "*");

Such bad coding practice will allow every website on the internet to access and get the content of the page that contains such definition via javascript (ajax call).
But there is another big security issue: well known token based protection against CSRF attacks could be easily bypassed. In case of page that inserts/updates/deletes data in the database and implements the famous token based protection against CSRF attacks and also allows access to foreign sites, the attacker can steal the csrf protection token by sending two ajax requests as described in the following steps:

1. The victim is logged-in to application A and simultaniously accesses attacker's siteB.
2. Attacker's page B sends and ajax request to the page on site A (which contains Access-Control-Allow-Origin:* definition and by that allows cross domain access) and gets the csrf token from the response!
3. Finally, attacker's page B sends a request to the page from site A with the token that the server of site A expects to get.
In such way the attacker will bypass the protection against CSRF attack and send a valid request with a valid token to the server of site A which will process the request as it was sent by the victim.

The solution is quite simple: Pages should define a white list of sites that are allowed to get the content in the "Access-Control-Allow-Origin" header.
Wildcard '*', shouldn't be used in pages with insert/update/delete and even view functionality.

Google Docs - a great hosting for Phishing forms

Google docs is a powerful service for creating and sharing online documents such as documents, spreadsheets, presentations and forms which are stored in the cloud. Creating forms that are stored and presented in google's domain, makes this service useful for Phishers that can create phishing forms in order to steal user credentials, credit card numbers, etc. Innocent victims would trust the form due to theact that these forms are stored and presented in google's domain.

In the following images it is possible to see a POC of such attack: Step 1: The attacker creates a phishing form, using google forms in order to steal vitctims' sensitive information such as user credentials, credit card numbers etc. It is possible to see that this form is running under google's domain.This form will submit victims' credentials to google docs server.

Step 2: In the following image it is possible to see that the attacker now is able to see victim's credentials.

HTML 5 - XSSQL attack

Html 5 brings a lot of new features to the web. One of its features is SQLite - a client side database engine which allows storage of data on the client side. Databases can be created and queried by the JavaScript.

It is pretty clear that many developers would use the opportunity to store information on the client side. The risk will be high if they use this repository and store their sensitive information such us user passwords, session ids, credit card numbers etc.
In case of XSS vulnerability in such website it would be possible to query these databases via JavaScript.
I even have a name for this attack - XSSQL :-) funny as well as concerning ...

Eventually, XSS attacks still remain common and even more powerful with the ability to query client side databases and steal sensitive information.

HTML 5 - SQLite Example

function db1()
{

if (window.openDatabase)
var db = openDatabase('yossidb', '1.0', 'attack this db', 2 * 1024 * 1024);

db.transaction(function (tx) {
tx.executeSql('CREATE TABLE IF NOT EXISTS users (id unique, username, password)');
tx.executeSql('INSERT INTO users (id, username, password) VALUES (1, "user1","bbbbb")');
tx.executeSql('INSERT INTO users (id, username, password) VALUES (2, "user2","password")');
tx.executeSql('INSERT INTO users (id, username, password) VALUES (3, "user3","username")');
tx.executeSql('INSERT INTO users (id, username, password) VALUES (4, "user4","another")');
tx.executeSql('INSERT INTO users (id, username, password) VALUES (5, "user5","fighter")');
//tx.executeSql('DROP TABLE users');//SELECT * FROM users
});
db.transaction(function (tx) {
tx.executeSql(sql.value, [], function (tx, results){

var len = results.rows.length, i, resultsOutputUsers="",resultsOutputPasswords="";
for (i = 0; i < len; i++) { if (results.rows.item(i).username!=null) { resultsOutputUsers = resultsOutputUsers + results.rows.item(i).username + " " resultsOutputPasswords = resultsOutputPasswords + results.rows.item(i).password + " " } document.getElementById("div1").innerHTML = resultsOutputUsers; document.getElementById("div2").innerHTML = resultsOutputPasswords; } } )}); }

Session Puzzling

Session Puzzling is a new type of application-level vulnerabilities that could enable attackers to perform a variety of malicious actions not limited to:

Bypass authentication and authorization enforcement mechanisms

Elevate privileges

Impersonate legitimate users

Avoid flow enforcement restrictions

Execute “traditional attacks” (such as injections) in locations that were previously considered safe

Affect content delivery destination

Cause unexpected application behaviors

Shay Chen, a friend and known security specialist presented this new kind of attack at Israeli local OWASP chapter meeting.

More information could be found here

Web security scanner - Software as service

ZeroDyaScan revolutionize web security by offering an online security scanning service running from the cloud. This service is suitable for any pocket. ZeroDayScan service utilizes a network of servers connected to the backbone to perform security assessments of the websites. Basically a private cloud is used to perform website security assesment.

On every website ZeroDayScan performs thousands of security tests. The system looks for most complicated security vulnerabilities as well as web server misconfiguration. When combined together these security tests give good and accurate results with almost zero false positives.

Zerodayscan - web security scanner - SaaS