Archive for category Web Security

There is no single ideal system in the world, and this applies to Web application firewalls too (WAF’s).

While the advantages and positive features far outweigh the negative in WAF’s, one major problem is there are only a few action rules allowed. The white list is expanding, and requires more development efforts because it is very important to clearly establish allowed parameters.

The second major problem is that sometimes WAF vendors fail to update their signature definitions, or do not develop the required security rule on time, and this can put the web server at risk of attacks.

The first vulnerability is (http://www.security-database.com/detail.php?alert=CVE-2009-1593), which allows the inserting extra characters in the JavaScript close tag to bypass the XSS protection mechanisms. An example is shown below: http://testcases/phptest/xss.php?var=%3Cscript%3Ealert(document.cookie)%3C/script%20ByPass%3

Another example (http://www.security-database.com/detail.php?alert=CVE-2009-1594) also allows remote attackers to bypass certain protection mechanisms via a %0A (encoded newline), as demonstrated by a %0A in a cross-site scripting (XSS) attack URL.

HTTP Parameter Pollution (HPP)

HPP was first developed by two Italian network experts, Luca Carettoni and Stefano diPaola. HPP provides an attacker the ability to submit new HTTP-parameters (POST, GET) with multiple input parameters (query string, post data, cookies, etc.) with same name.

The application may react in unexpected ways and open up new avenues of server-side and client-side exploitation. The most outstanding example is a vulnerability in IIS + ModSecurity which allows SQL-injection based attacks on two features:

1. IIS HTTP parameters submit the same name. for Example:

POST /index.aspx?a=1&a=2 HTTP/1.0
Host: www.example.com
Cookie: a=5;a=6
Content-type: text/plain
Content-Length: 7
Connection: close

a=3&a=4

If such a request to IIS/ASP.NET setting a (Request.Params["a"]) is equal to 1,2,3,4,5,6.

2. ModSecurity analyzes the request after that it has been already processed by webserver. And reject it: http://testcases/index.aspx?id=1+UNION+SELECT+username,password+FROM+users

However the query submitted:

POST /index.aspx?a=-1%20union/*&a=*/select/* HTTP/1.0
Host: www.example.com
Cookie: a=*/from/*;a=*/users
Content?Length: 21

a=*/name&a=password/*

The database as a result will do the correct query:

SELECT b, c FROM t WHERE a =- 1 /*,*/ UNION /*,*/ SELECT /*,*/ username, password /*,*/ FROM /*,*/ users

XSS

Cross Site Scripting (XSS) is probably the best method for exploiting the Web application firewall (WAF). This is due to JavaScript’s flexibility. At the BlackHat conference, there were a large number of methods to trick filters. For example:

object data=”javascript:alert(0)”
isindex action=javascript:alert(1) type=image
img src=x:alert(alt) onerror=eval(src) alt=0
x:script xmlns:x=”http://www.w3.org/1999/xhtml” alert (‘xss’); x: script

More XSS information can be found on the following links:

– http://ha.ckers.org/xss.html

– http://sla.ckers.org/forum/list.php?24

– http://maliciousmarkup.blogspot.com/

New developments in Web Application Firewalls is forthcoming. However, sometimes it seems that everything has already been discovered, and that it makes no sense to search for something new, but there is always room for new research.

It is very important to look at all details of the WAF to ensure you have a clear vision of your security assets.

make sure you subscribe to my RSS feed!

When we hear the term firewall, most people think of the network filtering solution. But have you heard about the web application firewall (WAF)?

Web applications have some serious vulnerabilities, and WAF provides a very important extra protection layer to the web solution. Hackers can find access points through errors in code, and we find that having a WAF in front of our web application is very important for security.

WAF acts as a special mechanism governing the interaction between the server and client while processing the HTTP-packets. It also provides a way to monitor the data as it is received from the outside. The solution is based on a set of rules that exposes if there is an attack targeting the server. Usually, the web application firewall aims to protect large websites like banks, online retailers, social networks, large companies… But now anyone can use it now that we have some open-source solutions available.

WAF can be implemented in two ways, via hardware or software, and in three forms:

1. Implemented as a reverse proxy server.
2. Implemented in routing mode / bridge.
3. Integrated in the Web application.

The first form can be as mod_security , Barracuda , nevisProxy . These types of WAF Automatically block or redirect the request to the web server without any changes or editing data.

The second category consists mainly of hardware WAF. For example, Impreva SecureSphere (impervaguard.com). These solutions require additional configuration on the internal network, but eventually the option gains in productivity.

And finally, the third type implies the existence in the Web application like integrating the WAF in the CMS.
WAF rules contain a Blacklist (compared with a list of unacceptable actions) and Whitelist (accepted and permitted actions), for example we can find in the black list strings like: «UNION SELECT», «< script>», «/ etc / passwd» while whitelist rules may contain a number parameters value (from0 to 65535).

We will now look at how pentesting can detect the WAF server, and more importantly how to bypass it.
Each firewall has a special method in responding that helps in identifying the type of WAF implemented (fingerprint) for example:

• HTTP-response cookies parameters.
• Modifying HTTP-headers to mask the server
• The way of responding to a special data and queries
• The way in closing connection under not authorized actions.

For example, when we launch an attack on mod_security we get 501 error code; WebKnight – the code 999; Barracuda on cookie-parameter barra_counter_session.

This can certainly help in identifying the WAF, and there are some scanners that can automate the operation so you will be able to get the information like w3af a framework plug-in WAF_fingerprint and wafw00f. These tools are important for the pentesting operation.

Next part will be looking at different technics to bypass web application firewall and exploit most popular vulnerabilities.

make sure you subscribe to my RSS feed!