Ebay - Advertisement

Wednesday, September 14, 2011

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.

Tuesday, July 5, 2011

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.

Sunday, July 3, 2011

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; } } )}); }

Sunday, June 5, 2011

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

    Sunday, May 22, 2011

    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

    Sunday, March 27, 2011

    Need a good reference for Microsoft SQL Server 2005/2008 hardening?

    This paper contains administrative and operational tasks that should be taken in account from security perspective when using Mircosoft SQL Server. The article covers operative instructions and example of code snippets needed for DBA's and Server administrators.
    http://www.greensql.com/content/sql-server-security-best-practices

    Sunday, March 13, 2011

    ExternalInterface.call() in ActionScript - can expose Flash applications to XSS attacks

    The ExternalInterface class is the External API, an application programming interface that enables straightforward communication between ActionScript and the Flash Player container– for example, an HTML page with JavaScript.
    TheExternalInterface.call("functionNameInJavaScript",inputFromUser) function in ActionScript - allows making calls from ActionScript to JavaScript functions.
    The first parameter is the name of the function in javascript, and the second one can be one or more parameters that this function receives.

    Call to such method would be translated on the embedding page to a javascript code which would look as follows:

    try {
        __flash__toXML(functionNameInJavaScript, "the value from inputFromUser"));
      } catch (e) {
        //Do something useful;
      }
    

    If the inputFromUser parameter's value is Hey"people, backslash escaping character will be added automatically and the value will become to be Hey\"people .
    However, the function does not escape any stray backslash characters. So input like Hello world!\"+alert('XSS')); } catch(e) {} // can lead to Cross Site Scripting attacks.

    This vulnerability was found by lcamtuf and was first posted on his blog.

    Thursday, January 20, 2011

    It is easy to find adobe flash security vulnerabilities

    Meet the HP SWFScan - a free tool developed by HP Web Security Research Group, will automatically find security vulnerabilities in applications built on the Flash platform.

    • Decompiles applications built on the Adobe Flash platform to extract the ActionScript code and statically analyzes it to identify security issues such as information disclosure.
    • Automatic Code Review - Identifies and reports insecure programming and deployment practices and suggests solutions.
    • Enables you to audit third party applications without requiring access to the source code.
    Download from here