Web application security scanner evaluation criteria v1.0 released

A very interesting document has been released by the Web application security consorsium yesterday. It's listing what a web application security scanner should be able to do in order to find and explain the more vulnerabilities possible. A document is also available for web application firewall.

WASSEC v1.0
WAFEC v1.0

What to spot when working on a positive model

A web application can be secured by a WAF, using a negative/positive security policy or a combinaison of the two.

A negative security policy is usually implemented using a static set of rules developed by a vendor. It can also contain some custom rules. Modifying a negative security policy requires expertise and good knowledge of applications. Adding a wrong rule can break an entire website or open access to secure content.

A positive security policy can be built manually by feeding the WAF with all resources definitions, but it becomes quickly hard to manage if the website is complex. The reality is this is often impossible to do this each time the application changes. Many WAF are using automated process to do this, proposing positive format for all resources of the website.

Here is a non exhaustive list of what to check when you're building a positive security policy.

• Define HTTP method used per scripts. Force scripts to be used only with method they are developed for, you don't need to allow more, specially if some people try to bypass some protection using POST instead of GET.
• Define only existing dynamic scripts. A web backdoor will use some dynamic script file extensions to be executed. Declaring only authorized scripts to run will deny access to unauthorized files. Declaring all static resources is not really helpful and it needs many changes when developers add more data. It's interesting here to declare some directories or some regular expression allowing path containing static content extensions (gif/jpeg/png etc.)
• Define only existing GET/POST parameters per scripts. The WAF should also be able to recognize order and number of parameters used. This definitions can block unauthorized parameters usages, like when doing HTTP parameters polutions.
• Define format on GET/POST parameters per scripts. You can quickly understand what your parameters are used for in the application. Your WAF should help you to do this. The more you will define format and the more precise they will be, the less your application will be vulnerable and the less an attacker will be able to exploit them.
  
• Define POST encoding per scripts. If a script receive a file through a file upload, it will use multipart. If it receive only parameters, it will mostly use x-urlencoded format. Forcing requests to use the good encoding can avoid some security policy bypass.
  
• Define redirect and specific answer headers per scripts. When a resource send back a redirect with a 302 and a location header, you can control values returned to avoid possible redirect to phishing website. Then it could also block a script trying to redirect even if it's not supposed to do it (header splitting attack).
• Define session cookies per scripts. Some scripts which always need a session informations, if they don't find it in the request, they can have bad behavior. Forcing request to use a valid cookie will block users trying to access unauthorized content. Using format on cookies values is also interesting to block possible attack if the application use cookie value to generate content.

Defining a positive security policy is a way to list possibilities on a web application. We spoke here about the request informations, but it can also be extended with some time based or QOS setup. Positive security policies need extensive setup that a WAF must automate to make this task possible in a production environment with many applications.

Look how your web application resist against strange traffic

I've released few week ago a web application security scanner i did few years ago. It's not up to date considering what is sent to the application, but it should be easy to upgrade with new pattern.

The goal of this scanner is to be modular. The core is providing HTTP(s) requests manipulation and processing, and a set of hooks that modules can use to insert and analyse requests done by the core.

Current available modules are:

1. Crawler (a Sax HTML parser)
2. Crawler2 (a DOM HTML parser)
3. Var Stress (insert and modify POST/GET/COOKIES variables data)
4. Form Auto Fill (automatically fill form to be able to continue crawling)
5. Form Authentication Bruteforce (bruteforce authentication form with different login/pass)
6. Hexa Encoder (encode in hexa all attacks that can be sent to the application)
7. Fuzzer (a classic fuzzer for POST/GET/COOKIES variables)
8. Tamper data import (use tamper data export of requests to replay traffic and insert attacks)

All these modules can be enabled/disabled in some setup template you can directly use with option -template. A default one is available in resource/template.xml in the project directory.

You can find sources and binary for mac os x here.
Documentation is available here.

How to use a Waf against HTTP Parameters Pollution

HTTP Parameters pollution is a way to use query string/POST/Cookies variables to attack an application. It has been presented during OWASP EU 2009 by Stephano di Paola and Luca Carettoni. You can find the presentation here

Two example of HTTP Parameters pollution:

First, you can use a variable more than one time and depending on the framework or language, the differents value of this variable will be concatenated.

index.asp?var1=val1&var2=val2&var1=val3 will result in index.asp?var1=val1+val3

Then you can also try to bruteforce some variables name to find ones used by the application but which is not exposed in a query string.

Example:

index.php?db_login=test&db_password=test will maybe gives an error of authentication failed on the database.

A Web application firewall is able to filter each part of an HTTP request. It can work on a positive model, to allow requests if they respect positive format, and it can block requests if they are matching a negative format.

In this case, to block HTTP Parameters pollution, you need to use a set of positive rules on your web application firewall. These two points will help you to be protected against HTTP Parameters pollution.

• Learn the different variables used by the different scripts. Your WAF should be able to do this and then limit usage to learnt variables. In this case, you will block variables used in code and which are tried to be accessed by query string, post'ed data or cookies. For example, a query string containing ?id=543&component=gallery&db_login=test will be blocked because "db_login" is a parameter never seen during the learning period, it's not the normal behavior of the application. If the url doesn't contain ONLY learnt parameters, it will be blocked.
  

• Enable request sanitization to block request containing two or more variables which the same name in the same request. Your waf should be able to do this and/or should be able to concatenate values to control what the application will use. For example, ?id=543&component=gallery&picture=1'%20O&picture=R%201=1 will be transformed by the WAF parsing into ?id=543&component=gallery&picture=1'%20OR%201=1 and the attack will be detected as SQL Injection
  

A WAF is able to work with positive security policies, which can be more or less strict, depending on how it's builing positive rules. Many automated processes can build for you this variables and parameters list. Depending on the WAF, this kind of setup can be more or less time consuming.

Why do you need a web application firewall

I'm a bit upset these last weeks when i heard that a WAF is not needed when there is a good SDL on web applications in a company. It could be the same to say that no more network firewall are needed because all applications and services are now safe. Network firewall are done to forbid access to some services and informations because they aren't trusted and can have potential security hole.

Maybe people don't know exactly what a WAF can do and they may think it's only blocking attacks.
A WAF can do many things on the HTTP traffic and is helpful in many situations like:

- Blocking known and unknown attacks
- Modifying traffic to have a more complex applicative infrastructure (ex. hostname mapping)
- Allow access only on specific informations
- Control authentication and autorizations
- Have another source of logged access and usage of the web application (forensic)
- etc. (i could spend the entire day giving good reason to have a waf :p)

A good list of possible WAF features is available on WAFEC project (web application firewall evaluation criteria).

http://www.webappsec.org/projects/wafec/

I will try to expose frequently on this blog some use case of what you can do with a WAF and how to have a good usage of this kind of security device.