I have performed a large number of Web Application Security Assessments over the years, and as a result, I have encountered a fairly large number of Web Application Firewalls.

It never ceases to amaze me how poorly many of these firewalls are configured. In many cases, I find that the web application firewall does very little to protect the client from anything, except the most basic of attacks.

One of my favorite web application vulnerabilities is Cross Site Scripting (XSS). For some strange reason, I still get a kick when a pop-up box appears in my web browser that says “XSS”.

Unfortunately, that is all XSS has become to many web application developers and network engineers… nothing more than a pop-up. This notion is due in part to the security community’s inability to communicate a vulnerability’s business impact to non-technical personnel.

Security Personnel's Inability to Speak to Non-Technical Personnel - (The Widget Breaks the Blurp and Crashes the Gloop! You Need to Invest Lots of Money Quickly!)

Many times, companies hire a security consultant to perform a Web Application Security Assessment on one of their main sites. The consultant runs a web application scanner, which finds XSS vulnerabilities.

In order to test for the vulnerability, the web application scanner uses a XSS payload that is easy to reproduce and normally results in some sort of pop-up in the web browser. This pop-up normally says something like “XSS” or “Hello World”.

The consultant provides the client with a list of parameters that are vulnerable to XSS along with the proof of concept code that the scanner used to identify the XSS vulnerability.

The client throws the vulnerable link in their browser, and as a result (horror of horrors), a pop-up that says “XSS” appears in the browser. The consultant never explains that this is just basic proof of concept code and that real world XSS attacks could result in logging keystrokes, stealing session cookies, or even the possibility of remote code execution on machines connecting to the vulnerable site (when linked with other vulnerabilities).

As a result, many companies that configure web application firewalls do not truly understand the web application attacks they are trying to prevent. Thus, in many cases, we have poorly coded web applications with poorly configured web application firewalls "protecting" them.

The ability to competently explain the findings from a Web Application Security Assessment is one of the many reasons it is important to have a reputable security consulting company perform Web Application Security Assessments.

This is true whether the Assessment is a White Box, Grey Box, or Black Box Web Application Security Assessment.

Blocking the Word "Script" (We are all Actors on the Stage of Life... Sorry, Wrong Script)

The first web application firewall misconception that drives me crazy is the belief that filtering out keywords that are commonly used in XSS attacks (or even worse XSS proof of concept code) will somehow stop XSS attacks.

Many times, the web application firewall has been configured to block requests containing the words “script” and/or “alert”. The word “script” is blocked due to the fact that the idea behind XSS is to get a hacker controlled script to execute in the victim’s web browser within the context of the vulnerable web application.

One way the attacker can do this is to insert script tags containing a script of the attacker’s choice into the underlying HTML markup when a user connects to the vulnerable site.

An example script the attacker could use is as follows:

< s c r i p t > a l e r t ( ‘ X S S ’ ) < / s c r i p t >

One of the problems with flagging on the word “script” in order to prevent XSS attacks is the fact that the attacker does not need to insert script tags into the underlying HTML, in order to successfully execute an XSS attack.

The attacker can use tags other than SCRIPT, such as IFRAME, BODY, or DIV tags, in order to embed a script into the underlying HTML. For example, an attacker could use any of the following tags to generate a pop-up that says “XSS”:

This will help those responsible for configuring web application firewalls to configure them correctly. So if blocking keywords is not the answer to an effective web application firewall configuration, could it be that blocking or encoding special characters like <, >, or “ is the answer?

Lawrence Munro
A good post, and good common sense. The only think I would add is that the emphasis should not be on configuring a WAF, but on engineering the application and teaching coders how to write secure JS. WAFs just add a layer of complexity and should not be relied upon or a substitute for inherent application security. Server-side sanitation is the best way to prevent such injection attacks (in addition to secure coding practices) as client-side manipulation is trivial. Most compliance guys could do with reading an understanding this concept!

Gary McCully
I completely agree with you. In my follow-up blog I will be talking about additional ways that WAFs fail to protect web applications and quickly summarize some recommendations for really securing the web applications. Correctly configured WAFs should be used in the context of defense in depth and not as the primary means of protecting a web application. A combination of white listing, secure coding practices, and a good software development lifecycle are needed to prevent these sort of attacks.

1328112359

The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.