Interested in learning

more about security?

SANS Institute
InfoSec Reading Room
This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express written permission.

Using Web Application Firewall to detect and block

common web application attacks
A web application firewall is not as common as a network firewall is, but it has been catching our eyes in
recent security news, security articles and conferences. Enterprise has been adopting this technology because
it enhances web application security significantly. But configuring, implementing and maintaining this new
technology is not trivial. To be successful in using it, you must understand application s behavior thoroughly
and carefully configure the firewall rules. Also, since commercial versions of this techn...

Copyright SANS Institute

Author Retains Full Rights
AD
 Using Web Application Firewall to detect and
block common web application attacks

s.
t
GIAC GCIA Gold Certification

igh
Author:  Issac  Museong  Kim,  iamissac@gmail.com  

lr
Advisor:  Antonios  Atlasis  

ul
 

f
Accepted:  November  17,  2011  

ns
 

ai
et
Abstract  

rr
A  web  application  firewall  is  not  as  common  as  a  network  firewall  is,  but  it  has  been  
catching  our  eyes  in  recent  security  news,  security  articles  and  conferences.  Enterprise  has  
ho
been  adopting  this  technology  because  it  enhances  web  application  security  significantly.  
But  configuring,  implementing  and  maintaining  this  new  technology  is  not  trivial.  To  be  
t
successful  in  using  it,  you  must  understand  application’s  behavior  thoroughly  and  carefully  
Au

configure  the  firewall  rules.  Also,  since  commercial  versions  of  this  technology  are  
e,

expensive  to  purchase,  implement  and  maintain,  it  is  recommended  to  start  with  an  open  
source  product,  such  as  Modsecurity,  so  you  can  determine  if  this  solution  is  appropriate  
ut

for  your  budget  and  environment.  This  paper  will  show  how  to  analyze  common  web  
t

attacks  by  using  WAF’s  detection  and  logging  ability  along  with  Apache  server’s  logging  
i
t

ability.  Finally,  its  effectiveness  against  some  simple  and  some  more  advanced  web  attacks  
ns

will  be  examined.  

I
NS
SA
11
20
©

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 2
 

1. Introduction
Over the last few years, vulnerabilities in web applications have been the biggest threat in
information technology (IT) environment (Modsecurity, 2011). According to the open source

s.
vulnerability database (OSVDB), web application threats become almost fifty percent of all

t
gh
vulnerabilities in 2010 (HP DVlabs, 2010). You don’t have to be an expert in IT field to figure

i
lr
out that web applications are being used widely in our everyday life as well as in the business

ul
sector. Therefore, securing web applications is becoming one of the most important things you

f
need to pay attention as an end-user or as a business user (HP DVlabs, 2010).

ns
A web application firewall (WAF) is a type of firewall that filters HTTP traffic based on

ai
a rule set. It inspects the application layer so it usually comes as an appliance type or as a server

et
module. It generally identifies and blocks common web attacks such as cross-site scripting (XSS)

rr
and SQL Injection by customizing the rules. Therefore, the customization of its rules is very
ho
significant and requires high maintenance (Owasp, 2011).
t
There are many ways to protect a web application, such as implementing a secure coding
Au

practice, managing secure configuration, performing vulnerability assessment and deploying a

e,

web application firewall, but there is no silver bullet that it will protect the application entirely.
ut

Using a web application firewall is just one method that helps to protect such an application.
t
i

This technology is relatively new comparing with other technologies, but it can become a
t
ns

powerful solution when you configure and use it properly (Mischel, 2009).
I

In this paper, Modsecurity is going to be used to demonstrate how to secure a web

NS

application using a WAF. Modsecurity protects web applications from a range of web attacks
and allows monitoring of HTTP traffic with not many interference in the existing infrastructure
SA

(Modsecurity, 2011). It is an open source WAF module for the Apache web server and it has
11

been maintained by SpiderLabs, Trustwave. Since this is an open source product, it comes with
20

free license and many users contribute to the community to improve and maintain the product
(Trustwave, 2011).
©

A WAF is not a tool that just blocks the malicious activity on the application layer. It can
also be used to analyze and detect malicious traffic that attacks your critical application.
Therefore, this paper will also show how to analyze common web attacks by using WAF’s
detection and logging ability along with the Apache server’s logging ability.

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 3
 

2. Setting up and Configuring Modsecurity

2.1. System Setup

s.
This section describes the configuration of the testing lab. Figure 1 below shows the

t
Modsecurity architecture in a diagram. First, Fedora Linux 15 is used to host the application. It

gh
requires some libraries such as libapr, libapr-util, libpcre, libxml2 and liblua (Modsecurity, 2011).

i
lr
If the Apache server is not installed, the latest version of Apache is recommended. In this lab, the

ul
Apache version 2.2.19 is used. After installing the Apache server, the damn vulnerable web

f
application (DVWA) is installed to illustrate the use of a WAF. DVWA is a framework of a

ns
deliberately vulnerable web application to help the security testers to learn and test their security

ai
skills regarding the protection of a web application (Ivey, 2010). Finally, Modsecurity 2.5.13 is

et
used to wrap the DVWA application in this lab. In order to use Modsecurity, it first needs to be

rr
compiled. The compilation creates a file called mod_security2.so which is the Modsecurity plug-
ho
in module for the Apache web server. The following line needs to be added to the Apache
t
configuration file http.conf, as shown below, to enable the Modsecurity module:
Au

LoadModule security2_module modules/mod_security2.so

e,

After this line has been added, the Apache server needs to be restarted so as the Modsecurity
ut

module to run within the Apache web server.

t
i
t
ns

Fedora  Linux  15z  

I

Apache  2.2.19  web  server  

NS

Modsecurity  2.5.13  
DVWA  1.0.7  
SA
11
20

Figure 1: Modsecurity Architecture.

©

2.2. Basic Configuration

Modsecurity has a configuration file called “modsec.conf”. It is recommended to put the
file into the directory /etc/httpd/conf.d/ so it gets loaded automatically whenever the Apache

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 4
 

server is restarted. This configuration file contains startup rule sets with auditing settings. The
startup configuration is shown below.
<IfModule security2_module>

s.
# Turn rule engine on and set default action

t
SecRuleEngine On

gh
SecDefaultAction "phase:2,deny,log,status:403"

i
lr
#Turn Audit on

ul
SecAuditEngine On

f
SecAuditLog logs/modsec_audit.log

ns
</IfModule>

ai
et
Figure 2: Modsecurity startup configuration file.

rr
It is important to understand what each line means. First of all, all rules and configuration
ho
statements must be written between the tags <IfModule> and </IfModule>. Otherwise, it is going
t
to break the configuration or the rule can be ignored. “#” sign is used to put a comment.
Au

“SecRuleEngine On” line turns the rule engine on which enables the rule processing.
e,

“SecDefault Action” line takes actions when there is a matching rule in place. In this example, it
ut

is going to deny the request with 403 HTTP error code and to write the result to the Apache error
t
i
t

log and Modsecurity audit log when there is any matching rule. However, since there is no
ns

SecRule in the current configuration, it will allow any requests. “SecAuditEngine On” line turns
I

audit logging on for any transactions (Mischel, 2009). “SecAuditLog logs/modsec_audit.log”

NS

line enables logs to be written to a modsec_audit.log file. In order to apply the configuration
SA

changes, the Apache daemon must be restarted.

11

2.3. Basics of Rules and CRS (Core Rule Set)

20

Modsecurity needs rules to operate. In Modsecurity, each one of these rules is called
SecRule. SecRule has many features and functions. The basic syntax of a rule, which will be
©

briefly explained later, is shown below:

SecRule Target Operation [Actions]
The ‘Target’ variable is a part of the request or the response that is going to be examined.
The ‘Operation’ is a part of the rule that is going to be compared with a matching variable. By
default, it uses regular expressions if nothing is specified. The ‘Actions’ are optional variables
Issac Museong Kim, iamissac@gmail.com
 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 5
 

that perform specific actions when there is a matching variable. For example, it can either allow
or deny the web traffic by also returning the corresponding status codes. If no actions are
specified, it will take the settings from the SecDefaultAction statement (Mischel, 2009).

s.
Modsecurity does not provide general protection against normal web attacks by default, unless

t
you install the appropriate rules. Writing such rules can be a complex and a time consuming

igh
process. Therefore, Trustwave’s SpiderLabs founded the OWASP Modsecurity core rule set

lr
(CRS) project. While intrusion detection systems depend on vulnerability signatures, CRS helps

ul
Modsecurity to protect web applications from unknown vulnerabilities. The CRS rule set is very

f
ns
easy to follow and deploy since it provides excellent comments; the most updated rule sets can

ai
be downloaded from the OWASP Modsecurity CRS Project Site (Modsecurity, 2011).

et
rr
3. Analyzing and blocking common web application attacks
ho
t In this section, the most common vulnerabilities such as XSS and SQL injection are
exploited against DVWA. First, the attacks run without the Modsecurity blocking rules in place
Au

and the results are analyzed by correlating Wireshark traffic captures, Apache access/error logs
e,

and Modsecurity audit logs. Then, the appropriate blocking rule is placed in the Modsecurity
ut

configuration file based on the analysis. Lastly, the attack runs again to verify the rule by
t
i

observing the response as well as by analyzing the logs to check if the attack is stopped.
t
ns

3.1. Analyzing XSS attacks

I

“XSS vulnerability enables an attacker to target other users of the application, potentially
NS

gaining access to their data, performing unauthorized actions on their behalf, or carrying out
SA

other attacks against them” (Stuttard & Pinto, 2007). In this study, the XSS injection string,
“%3C%2FTITLE%3E%3CSCRIPT%3Ealert%28%22XSS%22%29%3B%3C%2FSCRIPT%3E
11

#” is injected into the “name” parameter, as shown below:

20

http://127.0.0.1/dvwa/vulnerabilities/xss_r/?name=%3C%2FTITLE%3E%3CSCRIPT%3
Ealert%28%22XSS%22%29%3B%3C%2FSCRIPT%3E#
©

Then the browser responds with a popup window displaying the message “XSS”, as
shown in Figure 3.

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 6
 

s.
t
igh
lr
ul
f
ns
ai
et
rr
ho
t
Figure 3: Browser screenshot of the XSS attack without an XSS blocking rule.
Au

Figure 4 shows the Wireshark capture during the attack. It shows a GET request with an
e,

XSS injection script in the packet #4. Then, the packet #6 shows that it accepted the request and
ut

runs the XSS script.

t
i
t
ns
I
NS
SA
11
20
©

Figure 4: Wireshark screenshot of the XSS attack without an XSS blocking rule.

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 7
 

Figure 5 is from the Apache access log, which is located at “/etc/httpd/logs/access_log”

and it shows that it accepted the request to the web server.
127.0.0.1 - - [27/Sep/2011:21:31:47 -0700] "GET

s.
/dvwa/vulnerabilities/xss_r/?name=%3C%2FTITLE%3E%3CSCRIPT%3Ealert(%22X

t
SS%22)%3B%3C%2FSCRIPT%3E HTTP/1.1" 200 4372 "-" "Mozilla/5.0 (X11;

gh
Linux i686; rv:6.0.2) Gecko/20100101 Firefox/6.0.2"

i
lr
ul
Figure 5: Apache access log without an XSS blocking rule.

f
ns
Figure 6 is from the Modsecurity audit log, which is located at

ai
“/etc/httpd/logs/modsec_audit.log. The Modsecurity audit log has certain formats. First, it starts

et
with a unique identifying string such as “cb5e7204” to group the rest of the log entry. After this

rr
string, it has a capital letter, such as “A”, which represents the audit log part. For example, “A”
ho
represents an audit log header, “B” represents a request header, “F” represents a response header,
t
“H” represents an audit log trailer and “Z” represents the end of an audit log entry. There are
Au

additional parts you can add by adding “SecAuditLogParts” line, but A, B, F, H and Z are the
e,

default settings. As shown in Figure 6, Modsecurity allowed the request because by default, it
ut

allows any requests that do not match with any SecRule.

t
i

--cb5e7204-A--
t
ns

[27/Sep/2011:21:31:47 --0700] ToKjM38AAAEAAAvEEjAAAAAH 127.0.0.1 37879

I

127.0.0.1 80
NS

--cb5e7204-B--
GET
SA

/dvwa/vulnerabilities/xss_r/?name=%3C%2FTITLE%3E%3CSCRIPT%3Ealert(%22X
SS%22)%3B%3C%2FSCRIPT%3E HTTP/1.1
11

Host: 127.0.0.1
20

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20100101

Firefox/6.0.2
©

Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 8
 
Connection: keep-alive
Cookie: security=low; PHPSESSID=ikat12q2sh3l43gnrqoqt4huf4
Cache-Control: max-age=0

s.
--cb5e7204-F--

t
HTTP/1.1 200 OK

gh
X-Powered-By: PHP/5.3.8

i
lr
Expires: Tue, 23 Jun 2009 12:00:00 GMT

ul
Cache-Control: no-cache, must-revalidate

f
Pragma: no-cache

ns
Content-Length: 4372

ai
Connection: close

et
Content-Type: text/html;charset=utf-8

rr
--cb5e7204-H--
Apache-Handler: php5-script
ho
Stopwatch: 1317184307086553 8511 (263 266 -)
t
Producer: ModSecurity for Apache/2.5.13 (http://www.modsecurity.org/).
Au

Server: Apache/2.2.21 (Fedora)

e,

--cb5e7204-Z--
t
iut

Figure 6: Modsecurity Audit Log without an XSS blocking rule.

t
ns
I

3.2. Blocking XSS attacks

NS

From the various logs in the above section, it is found that this XSS attack uses keywords
such as “SCRIPT” and “alert” in the uniform resource identifier (URI). The easy and quick way
SA

to block this type of XSS attack is using a Target variable called “REQUEST_URI” which
11

examines a text in URI. For example, the following line is added to the configuration:
20

SecRule REQUEST_URI "SCRIPT"|”alert”

This rule denies any requests that include the words “SCRIPT” or “alert” in their URI.
©

Though this rule does not have a “deny” variable, it denies such requests because the
“SecDefaultAction” is set to “deny” in Figure 2. However, this is a very simple rule that can
block only simple XSS attacks. An attacker can bypass this type of filtering by encoding or by
injecting the script into other places, such as a cookie field. To block more advanced XSS attacks,

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 9
 

you can add common attack strings to the existing rules, such as the ones presented in Table1, or
to include the corresponding XSS base rules from the CRS rule set.
Jscript onsubmit copyparentfolder document javascript meta onchange onmove

s.
onerror onselect onmouseover onfocus javascript: alert background onunload

t
gh
iframe lowsrc onmousemove vbscript livescript: script @import onresize

i
lr
Table1: Common XSS attack strings.

ul
When the same request was sent after placing the rule, the browser responded with a

f
“Forbidden” error code, as shown in Figure 7.

ns
ai
et
rr
ho
t
Au

Figure 7: Browser response with the XSS blocking rule

e,
ut

Figure 8 shows the Wireshark capture during the attack. It shows the GET request that it
t
i
t

was sent with the aforementioned XSS injection script in the packet #4. Then, the packet #6
ns

shows that it forbids the request.

I
NS
SA
11
20
©

Figure 8: Wireshark screenshot of the XSS attack with the XSS blocking rule.

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 10
 

Figure 9 is from the Apache error log which shows that it denied the request to the web
server.
[Thu Sep 29 19:28:28 2011] [error] [client 127.0.0.1] ModSecurity:

s.
Access denied with code 403 (phase 2). Pattern match "(SCRIPT|alert)"

t
at REQUEST_URI. [file "/etc/httpd/conf.d/modsec.conf"] [line "15"]

gh
[hostname "127.0.0.1"] [uri "/dvwa/vulnerabilities/xss_r/"] [unique_id

i
lr
ToUpTH8AAAEAAEgDDEYAAAAB"]

ul
f
Figure 9: Apache error log with the XSS blocking rule.

ns
As shown in Figure 10, the Modsecurity denied the request because it found the pattern in

ai
the rule.

et
--22a47b2f-A--

rr
[29/Sep/2011:19:28:28 --0700] ToUpTH8AAAEAAEgDDEYAAAAB 127.0.0.1 43415
ho
127.0.0.1 80
t
--22a47b2f-B—
Au

GET
e,

/dvwa/vulnerabilities/xss_r/?name=%3C%2FTITLE%3E%3CSCRIPT%3Ealert%28%2
ut

2XSS%22%29%3B%3C%2FSCRIPT%3E HTTP/1.1
t

Host: 127.0.0.1
i
t

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20100101

ns

Firefox/6.0.2
I

Accept:
NS

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
SA

Accept-Encoding: gzip, deflate

11

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
20

Referer: http://127.0.0.1/dvwa/vulnerabilities/xss_r/
©

Cookie: security=low; PHPSESSID=ikat12q2sh3l43gnrqoqt4huf4

--22a47b2f-F—
HTTP/1.1 403 Forbidden
Content-Length: 304
Connection: close

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 11
 
Content-Type: text/html; charset=iso-8859-1
--22a47b2f-H—
Message: Access denied with code 403 (phase 2). Pattern match

s.
"(SCRIPT|alert)" at REQUEST_URI. [file

t
"/etc/httpd/conf.d/modsec.conf"] [line "15"]

gh
Action: Intercepted (phase 2)

i
lr
Stopwatch: 1317349708697236 5950 (1302 1605 -)

ul
Producer: ModSecurity for Apache/2.5.13 (http://www.modsecurity.org/).

f
Server: Apache/2.2.21 (Fedora)

ns
--22a47b2f-Z--

ai
et
Figure 10: Modsecurity Audit Log with the XSS blocking rule.

rr
3.3. Analyzing SQL Injection Attacks
ho
t SQL Injection is another common web application attack method. This vulnerability
allows attackers to inject malicious SQL statements to interact with the backend database. From
Au

this injection, the attacker may be able to obtain data as well as to execute malicious commands
e,

to the database (Stuttard & Pinto, 2007). In this study, the SQL injection string (' union all select
ut

user, password from dvwa.users#) was injected into the “id” parameter, as shown below:
t
i
t

http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=%27+union+all+select+user%2C+passwor
ns

d+from+dvwa.users%23&Submit=Submit#
I
NS
SA
11
20
©

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 12
 

Then, the browser responded with a list of users and the corresponding password hashes,
as shown in Figure 11.

s.
t
igh
lr
ul
f
ns
ai
et
rr
ho
t
Au
e,
t
iut
t

Figure 11: Browser screenshot of the SQL Injection attack without a blocking rule.
ns
I

Figure 12 shows the Wireshark capture during the attack. It shows a GET request which
NS

was sent with an SQL Injection script in the packet #4. Then, the packet #6 shows that it
SA

accepted the request and displays the user ID as well as the hash.
11
20
©

Figure 12: Wireshark screenshot of SQL Injection attack without a blocking rule.

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 13
 

Figure 13 displays the Apache access log, which shows that it accepted the request to the
web server.

s.
127.0.0.1 - - [30/Sep/2011:18:53:21 -0700] "GET

t
/dvwa/vulnerabilities/sqli/?id=%27+union+all+select+user%

gh
2C+password+from+dvwa.users%23&Submit=Submit HTTP/1.1" 200 4990

i
lr
"http://127.0.0.1/dvwa/vulnerabilities/sqli/" "Mozilla/5.0 (X11; Linux

ul
i686; rv:6.0.2) Gecko/20100101 Firefox/6.0.2"

f
ns
Figure 13: Apache access log without an SQL Injection blocking rule.

ai
et
As shown in Figure 14, the Modsecurity allowed the request because it did not find any

rr
matching SecRule.
ho
--a396eb61-A--
t
Au
[30/Sep/2011:18:53:21 --0700] ToZykX8AAAEAAEgEC-oAAAAC 127.0.0.1 34717
127.0.0.1 80
e,

--a396eb61-B--
ut

GET
t
i

/dvwa/vulnerabilities/sqli/?id=%27+union+all+select+user%2C+password+f
t
ns

rom+dvwa.users%23&Submit=Submit HTTP/1.1
I

Host: 127.0.0.1
NS

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20100101

Firefox/6.0.2
SA

Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
11

Accept-Language: en-us,en;q=0.5
20

Accept-Encoding: gzip, deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
©

Connection: keep-alive
Referer: http://127.0.0.1/dvwa/vulnerabilities/sqli/
Cookie: security=low; PHPSESSID=ikat12q2sh3l43gnrqoqt4huf4
--a396eb61-F--
HTTP/1.1 200 OK

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 14
 
X-Powered-By: PHP/5.3.8
Expires: Tue, 23 Jun 2009 12:00:00 GMT
Cache-Control: no-cache, must-revalidate

s.
Pragma: no-cache

t
Content-Length: 4990

gh
Connection: close

i
lr
Content-Type: text/html;charset=utf-8

ul
--a396eb61-H--

f
Apache-Handler: php5-script

ns
Stopwatch: 1317434001221137 169753 (20956 20986 -)

ai
Producer: ModSecurity for Apache/2.5.13 (http://www.modsecurity.org/).

et
Server: Apache/2.2.21 (Fedora)

rr
--a396eb61-Z--

ho
t Figure 14: Modsecurity Audit Log without an SQL Injection blocking rule.
Au

3.4. Blocking SQL Injection attack

e,

From the various logs in the above section, it is found that this SQL Injection attack uses
ut

a keyword “union” in the argument. Similarly to the prevention of the XSS attack, you can add
t
i
t

the following SecRule line to the configuration to block the SQL Injection attack. In this
ns

example, “msg” argument is added to the rule so it writes the log message that explains why it is
I

blocked:
NS

SecRule ARGS "union” “msg: ‘SQL Injection’”

SA

This rule denies any requests that include the keyword “union” as an argument. Again
this is a very simple type of SQL injection attacks. To block more advanced SQL Injection
11

attacks, you can add more common attack strings to the existing rule, such as the ones presented
20

in Table 2, or the corresponding SQL Injection base rules from the CRS rule set should be
included.
©

xor rlike -- and # union All ;

‘ drop delete having 1=1 admin Select

Table 2: Common SQL Injection attack strings.

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 15
 

When the same request was sent after placing the rule, the browser responded with
“Forbidden” error code, as shown in Figure 15.

s.
t
igh
lr
ul
f
ns
ai
et
rr
Figure 15: Browser response with the SQL Injection blocking rule.
ho
t
Figure 16 shows the Wireshark capture during the attack. It shows the GET request
Au

which was sent with the aforementioned SQL injection script in the packet #4. Then, the packet
e,

#6 shows that it forbids the request.

t
iut
t
ns
I
NS
SA
11
20
©

Figure 16: Wireshark screenshot of the SQL Injection attack with the SQL Injection blocking
rule.

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 16
 

Figure 17 displays the Apache error log that shows it denied the request to the web server.
[Fri Sep 30 20:35:11 2011] [error] [client 127.0.0.1] ModSecurity:
Access denied with code 403 (phase 2).

s.
Pattern match "union" at ARGS:id. [file

t
"/etc/httpd/conf.d/modsec.conf"] [line "16"] [msg "SQL Injection"]

gh
[hostname "127.0.0.1"] [uri "/dvwa/vulnerabilities/sqli/"] [unique_id

i
lr
"ToaKb38AAAEAAGXcEtcAAAAG"]

ul
f
Figure 17: Apache error log with the SQL Injection blocking rule.

ns
As shown in Figure 18, the Modsecurity denied the request, because it found the pattern

ai
in the rule.

et
--2ef14200-A--

rr
[30/Sep/2011:20:35:11 --0700] ToaKb38AAAEAAGXcEtcAAAAG 127.0.0.1 60564
ho
t 127.0.0.1 80
--2ef14200-B--
Au

GET
e,

/dvwa/vulnerabilities/sqli/?id=%27+union+all+select+user%2C+passw
ut

ord+from+dvwa.users%23&Submit=Submit HTTP/1.1
t

Host: 127.0.0.1
i
t

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20100101

ns

Firefox/6.0.2
I

Accept:
NS

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
SA

Accept-Encoding: gzip, deflate

11

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
20

Referer: http://127.0.0.1/dvwa/vulnerabilities/sqli/
©

Cookie: security=low; PHPSESSID=ikat12q2sh3l43gnrqoqt4huf4

--2ef14200-F--
HTTP/1.1 403 Forbidden
Content-Length: 303
Connection: close
Content-Type: text/html; charset=iso-8859-1

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 17
 
--2ef14200-H--
Message: Access denied with code 403 (phase 2). Pattern match "union"
at ARGS:id. [file "/etc/httpd/conf.

s.
d/modsec.conf"] [line "16"] [msg "SQL Injection"]

t
Action: Intercepted (phase 2)

gh
Stopwatch: 1317440111243660 80417 (793 79882 -)

i
lr
Producer: ModSecurity for Apache/2.5.13 (http://www.modsecurity.org/).

ul
Server: Apache/2.2.21 (Fedora)

f
--2ef14200-Z--

ns
Figure 18: Modsecurity Audit Log with the SQL Injection blocking rule.

ai
et
rr
4. Attacking the application using automated tools
ho
t
In this section, automated testing tools such as XSS Me and Sqlmap are used to test for
Au

XSS and SQL injection vulnerabilities. These automatic testing tools perform more complex and
a wider range of attacks to make sure the SecRule is safe enough to block such attacks. The use
e,

of these tools will be explained briefly. Also, when the existing rules are not good enough to
ut

block an attack, more comprehensive rules will be added after the appropriate analysis.
t
i
t
ns

4.1. XSS attacks using XSS Me

I
NS

XSS Me is a Firefox plug-in created by Security Compass. This tool helps testers to run
XSS attacks against a target website instantly while browsing (Security Compass, 2010). XSS
SA

Me performs 154 different types of XSS test by default. To make the test more comprehensive,
the attack strings from XSS cheat sheet by RSnake were added to the existing strings of XSS Me
11

(Hansen, 2008). So, 328 XSS tests were totally performed against the web application. To run
20

XSS Me, you first have to get to the URL that needs to be tested and then open the XSS Me side
©

bar. Figure 19 shows the interface of XSS Me. The “name” parameter was selected, then “run all
tests” was selected to run the attack. XSS Me runs against the same URL that was tested in
section 3.1 with the existing SecRule.

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 18
 

s.
t
igh
lr
ul
f
ns
ai
et
Figure 19: XSS Me interface.

rr
ho
Figure 20 shows that there were 6 Failures meaning that 6 XSS tests were successful
t
while there are 162 Warnings meaning that 162 XSS tests were not successful but it may were
Au

vulnerable in other environment, and 160 XSS tests were passed meaning that 160 XSS tests
e,

were not successful.

t
iut
t
ns
I
NS
SA
11
20
©

Figure 20: XSS testing with the existing SecRule using the XSS Me tool

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 19
 

To block these 6 XSS attacks, the strings in Table1 are added to the existing SecRule that
was used to block the XSS attack, as shown below:
SecRule REQUEST_URI

s.
"(Jscript|onsubmit|copyparentfolder|document|javascript|meta|Onchange|onmove|onerro

t
r|onselect|onmouseover|onfocus|javascript:|alert|background|onunload|iframe|lowsrc|on

igh
mousemove|vbscript|livescript:|script|@import|onresize)"

lr
SecRule ARGS

ul
"(Jscript|onsubmit|copyparentfolder|document|javascript|meta|Onchange|onmove|onerro

f
ns
r|onselect|onmouseover|onfocus|javascript:|alert|background|onunload|iframe|lowsrc|on

ai
mousemove|vbscript|livescript:|script|@import|onresize)"

et
Figure 21 shows the test results with the updated SecRule in place. Out of 328 tests, there

rr
were 0 failures meaning that all XSS tests were not successful and that they were blocked by
ho
Modsecurity.
t
Au
e,
t
iut
t
ns

Figure 21: XSS testing with the updated SecRule using the XSS Me tool.
I
NS

Lastly, the application was tested by using some of the XSS obfuscated strings that were
presented in the Black Hat USA 2009 by Eduardo Vela and David Linsay, as shown below (Vela
SA

& Lindsay, 2009):

11

<img src="x:alert" onerror="eval(src%2b'(0)')">

20

<img src="x:gif" onerror="eval('al'%2b'lert(0)')">

<img src="x:gif" onerror="window['al\u0065rt'](0)"></img>
©

Figure 22 from the Modsecurity audit logs shows that these obfuscated attacks are
blocked by Modsecurity. However, this does not mean that the web application is safe against
any future obfuscated attack; hence, it is recommended to include the CRS rule set and update
them periodically.

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 20
 
GET
/dvwa/vulnerabilities/xss_r/?name=%3Cimg+src%3D%22x%3Aalert%22+onerro
r%3D%22eval%28src%252b%27%280%29%27%29%22%3E HTTP/1.1

s.
--cf6ca670-H--

t
Message: Access denied with code 403 (phase 2). Pattern match

gh
"(Jscript|onsubmit|copyparentfolder|document|javascript|meta|On

i
lr
change|onmove|onerror|onselect|onmouseover|onfocus|javascript:|alert|

ul
background|onunload|iframe|lowsrc|onmousemove|vbscript|livescript:|sc

f
ript|@import|onresize)" at REQUEST_URI. [file

ns
"/etc/httpd/conf.d/modsec.conf"] [line "20"] [msg "XSS attack"]

ai
--cf6ca670-B--

et
GET

rr
/dvwa/vulnerabilities/xss_r/?name=%3Cimg+src%3D%22x%3Agif%22+onerror%
3D%22eval%28%27al%27%252b%27lert%280%29%27%29%22%3E
ho HTTP/1.1
--cf6ca670-H--
t
Message: Access denied with code 403 (phase 2). Pattern match
Au

"(Jscript|onsubmit|copyparentfolder|document|javascript|meta|On
e,

change|onmove|onerror|onselect|onmouseover|onfocus|javascript:|alert|
ut

background|onunload|iframe|lowsrc|onmousemove|vbscript|livescript:|sc
t
i

ript|@import|onresize)" at REQUEST_URI. [file

t
ns

"/etc/httpd/conf.d/modsec.conf"] [line "20"] [msg "XSS attack"]

I

--cf6ca670-B--
NS

GET
/dvwa/vulnerabilities/xss_r/?name=%3Cimg+src%3D%22x%3Agif%22+onerror%
SA

3D%22window%5B%27al%5Cu0065rt%27%5D+%280%29%22%3E%3C%2Fimg%3E
HTTP/1.1
11

--cf6ca670-H--
20

Message: Access denied with code 403 (phase 2). Pattern match
"(Jscript|onsubmit|copyparentfolder|document|javascript|meta|On
©

change|onmove|onerror|onselect|onmouseover|onfocus|javascript:|alert|
background|onunload|iframe|lowsrc|onmousemove|vbscript|livescript:|sc
ript|@import|onresize)" at REQUEST_URI. [file
"/etc/httpd/conf.d/modsec.conf"] [line "20"] [msg "XSS attack"]

Figure 22: Modsecurity audit log of obfuscated XSS attacks with the updated SecRule

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 21
 

4.2. SQL injection attacks using Sqlmap

The Sqlmap is “an open source penetration testing tool that automates the process of
detecting and exploiting SQL injection flaws and taking over of database servers” (Damele &

s.
Stampar 2011). Python interpreter version 2 or newer is required to run this tool. In this study,

t
gh
the following command was run to identify SQL injection vulnerabilities:

i
./sqlmap.py -u

lr
ul
'http://127.0.0.1/dvwa/vulnerabilities/sqli/index.php?id=1&Submit=Submit#' --

f
cookie='security=low; PHPSESSID=ikat12q2sh3l43gnrqoqt4huf4' --dbms=MySQL --

ns
tamper='tamper/randomcase.py, tamper/charencode.py' --level=5 --risk=3

ai
Understanding the command above is important. First, “-u” switch sets the target URL

et
and “-- cookie” sets the cookie value. DVWA application uses a cookie value to authenticate the

rr
users, so this value is required whenever the request is sent to the application. “--dbms” sets the
ho
type of the database of the target application so it only injects the attack strings that works for the
t
specific database. In this experiment, it is already known that it uses a MySQL database from the
Au

DVWA documentation (Ivey, 2011). “--tamper” option allows the obfuscation of the attack
e,

strings in order to bypass the detection. “randomcase.py” script randomizes the attack strings and
ut

“charencode.py” script encodes the characters. “--level” option sets the level of test to perform
t
i

meaning that level 1 uses limited number of tests whereas level 5 uses much larger amount of
t
ns

tests. “--risk” option sets the risk of the tests to perform, meaning that risk 1 uses a limited
I

number of injection points whereas risk 3 uses a much larger amount of injection points (Damele
NS

& Stampar 2011). Figure 23 shows the output of the testing against the SecRule that was created
in Section 3.4. The highlighted lines show that the tool injected 211 tests and the parameter “id”
SA

is vulnerable.
11

sqlmap/1.0-dev (r4397) - automatic SQL injection and database takeover

tool
20

[18:10:54] [INFO] loading tamper script 'randomcase'

©

[18:10:54] [INFO] loading tamper script 'charencode'

[18:10:54] [INFO] testing connection to the target url
[18:10:55] [INFO] testing if the url is stable, wait a few seconds
[18:10:56] [INFO] url is stable
[18:10:56] [INFO] testing if GET parameter 'id' is dynamic

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 22
 
[18:10:56] [WARNING] GET parameter 'id' appears to be not dynamic
[18:10:56] [INFO] heuristic test shows that GET parameter 'id' might
be injectable (possible DBMS: MySQL)

s.
[18:10:56] [INFO] testing sql injection on GET parameter 'id'

t
[18:10:56] [INFO] testing 'AND boolean-based blind - WHERE or HAVING

gh
clause'

i
lr
[18:10:58] [INFO] testing 'AND boolean-based blind - WHERE or HAVING

ul
clause (Generic comment)'

f
[18:10:59] [INFO] testing 'OR boolean-based blind - WHERE or HAVING

ns
clause'

ai
[18:11:00] [INFO] GET parameter 'id' is 'OR boolean-based blind -

et
WHERE or HAVING clause' injectable

rr
[18:11:00] [INFO] testing 'MySQL >= 5.0 AND error-based - WHERE or
HAVING clause'
ho
[18:11:00] [INFO] GET parameter 'id' is 'MySQL >= 5.0 AND error-based
t
- WHERE or HAVING clause' injectable
Au

[18:11:00] [INFO] testing 'MySQL > 5.0.11 stacked queries'

e,

[18:11:00] [INFO] testing 'MySQL < 5.0.12 stacked queries (heavy

ut

query)'
t
i

[18:11:00] [INFO] testing 'MySQL > 5.0.11 AND time-based blind'

t
ns

[18:11:10] [INFO] GET parameter 'id' is 'MySQL > 5.0.11 AND time-based
I

blind' injectable
NS

[18:11:10] [INFO] testing 'MySQL UNION query (NULL) - 1 to 10 columns'

[18:11:10] [INFO] target url appears to be UNION injectable with 2
SA

columns
[18:11:10] [INFO] GET parameter 'id' is 'MySQL UNION query (NULL) - 1
11

to 10 columns' injectable
20

[18:11:10] [WARNING] in OR boolean-based injections, please consider

usage of switch --drop-set-cookie if you experience any problems
©

during data retrieval

GET parameter 'id' is vulnerable. Do you want to keep testing the
others? [y/N] N
sqlmap identified the following injection points with a total of 211
HTTP(s) requests:

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 23
 
---
Place: GET
Parameter: id

s.
Type: boolean-based blind

t
Title: OR boolean-based blind - WHERE or HAVING clause

gh
Payload: id=-2213' OR NOT (7100=7100) AND 'VBXM'='VBXM&Submit=Submit

i
lr
ul
Type: error-based

f
Title: MySQL >= 5.0 AND error-based - WHERE or HAVING clause

ns
Payload: id=1' AND (SELECT 3198 FROM(SELECT

ai
COUNT(*),CONCAT(CHAR(58,100,104,110,58),(SELECT (CASE WHEN (3198=3198)

et
THEN 1 ELSE 0 END)),CHAR(58,103,120,117,58),FLOOR(RAND(0)*2))x FROM

rr
INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a) AND
'Ezsb'='Ezsb&Submit=Submit
ho
t
Type: UNION query
Au

Title: MySQL UNION query (NULL) - 2 columns

e,

Payload: id=1' UNION ALL SELECT

ut

CONCAT(CHAR(58,100,104,110,58),IFNULL(CAST(CHAR(121,104,70,108,121,115
t
i

,88,113,67,112) AS CHAR),CHAR(32)),CHAR(58,103,120,117,58)), NULL# AND

t
ns

'diwU'='diwU&Submit=Submit
I
NS

Type: AND/OR time-based blind

Title: MySQL > 5.0.11 AND time-based blind
SA

Payload: id=1' AND SLEEP(5) AND 'AFme'='AFme&Submit=Submit

---
11

[18:11:18] [INFO] changes made by tampering scripts are not included

20

in shown payload content(s)

[18:11:18] [INFO] the back-end DBMS is MySQL
©

web server operating system: Linux Fedora

web application technology: Apache 2.2.21, PHP 5.3.8
back-end DBMS: MySQL 5.0

Figure 23: SQL Injection testing with the existing SecRule using the Sqlmap tool.

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 24
 

To block this type of SQL injection attack, the strings in Table2 are added to the existing
SecRule, as shown below:
SecRule ARGS "(union|xor|rlike|--|#|union

s.
all|;|‘|drop|delete|having|1=1|admin|select|and)" “msg: ‘SQL Injection’”

t
Figure 24 shows the test results with the SecRule above in place. The highlighted line

igh
shows that the SQL injection is not successful and the request was forbidden 8425 times. Even

lr
though the attack strings are obfuscated by using the “--tamper” option, it is still blocked by

ul
Modsecurity. However, this does not mean that it is safe against any future obfuscated attacks, so

f
ns
it is recommended to include the CRS rule set and update them periodically.

ai
[21:19:50] [INFO] loading tamper script 'randomcase'

et
[21:19:50] [INFO] loading tamper script 'charencode'

rr
[21:19:50] [INFO] using '/home/sqlmap/output/127.0.0.1/session' as
session file
ho
[21:19:50] [INFO] testing connection to the target url
t
[21:19:50] [INFO] testing if the provided string is within the target
Au

URL page content

e,

[21:19:50] [INFO] testing if GET parameter 'id' is dynamic

ut

[21:19:50] [INFO] confirming that GET parameter 'id' is dynamic

t
i

[21:19:50] [INFO] GET parameter 'id' is dynamic

t
ns

[21:19:50] [WARNING] heuristic test shows that GET parameter 'id'

I

might not be injectable

NS

[21:19:50] [INFO] testing sql injection on GET parameter 'id'

[21:21:15] [WARNING] GET parameter 'id' is not injectable
SA

[21:21:15] [INFO] testing if GET parameter 'Submit' is dynamic

[21:21:15] [WARNING] GET parameter 'Submit' appears to be not dynamic
11

[21:21:15] [WARNING] heuristic test shows that GET parameter 'Submit'

20

might not be injectable

[21:21:15] [INFO] testing sql injection on GET parameter 'Submit'
©

[21:21:15] [INFO] testing 'AND boolean-based blind - WHERE or HAVING

clause'
[21:21:15] [INFO] GET parameter 'Submit' is 'AND boolean-based blind -
WHERE or HAVING clause' injectable
[21:21:21] [WARNING] GET parameter 'Submit' is not injectable

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 25
 
[21:21:21] [INFO] testing if Referer parameter 'Referer' is dynamic
[21:21:21] [WARNING] Referer parameter 'Referer' appears to be not
dynamic

s.
[21:21:21] [WARNING] heuristic test shows that Referer parameter

t
'Referer' might not be injectable

gh
[21:21:21] [INFO] testing sql injection on Referer parameter 'Referer'

i
lr
[21:23:59] [WARNING] Referer parameter 'Referer' is not injectable

ul
[21:23:59] [INFO] testing if User-Agent parameter 'User-Agent' is

f
dynamic

ns
[21:26:48] [WARNING] User-Agent parameter 'User-Agent' is not

ai
injectable

et
[21:26:48] [INFO] testing if Cookie parameter 'security' is dynamic

rr
[21:26:48] [WARNING] Cookie parameter 'security' appears to be not
dynamic ho
[21:26:48] [WARNING] heuristic test shows that Cookie parameter
t
'security' might not be injectable
Au

[21:26:48] [INFO] testing sql injection on Cookie parameter 'security'

e,

[21:29:53] [WARNING] Cookie parameter 'security' is not injectable

ut

[21:29:53] [INFO] testing if Cookie parameter 'PHPSESSID' is dynamic

t
i

sqlmap got a 302 redirect to 'http://127.0.0.1:80/dvwa/login.php'. Do

t
ns

you want to follow redirects from now on (or stay on the original
I

page)? [Y/n] n
NS

[21:30:03] [INFO] confirming that Cookie parameter 'PHPSESSID' is

dynamic
SA

[21:30:03] [INFO] Cookie parameter 'PHPSESSID' is dynamic

[21:30:03] [WARNING] heuristic test shows that Cookie parameter
11

'PHPSESSID' might not be injectable

20

[21:30:03] [INFO] testing sql injection on Cookie parameter

'PHPSESSID'
©

[21:35:05] [WARNING] Cookie parameter 'PHPSESSID' is not injectable

[21:35:05] [CRITICAL] all parameters appear to be not injectable.
[21:35:05] [WARNING] HTTP error codes detected during testing:
403 (Forbidden) - 8425 times

Figure 24: SQL Injection testing with the updated SecRule using the Sqlmap tool.

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 26
 

Lastly, the application was tested with one of the latest obfuscated SQL injection
techniques that were presented by the CWH Underground team (Phongthiproek, 2011). This
technique uses a MySQL server’s comment feature which is the “/*” character sequence to the

s.
following “*/” character sequence with a new line character such as “%0D%0A”. Combining

t
these two methods, it allows the attack strings to extend over multiple lines so Modsecurity fails

igh
to detect the pattern (Phongthiproek, 2011). The attack string “' union all select user, password

lr
from dvwa.users#” from the section 3.3 was obfuscated as following:

ul
‘union%23foo%2F*bar%0D%0Aall%20select%23foo%0D%0Auser%2Cpassword%20fr

f
ns
om%20from%20dvwa.users%23

ai
The above stings are equivalent to the following SQL payload:

et
' union#foo*/*bar

rr
all select#foo
ho
user, password from dvwa.users#
t
But when these strings are passed to the MySQL database, they are interpreted as following:
Au

' union all select user, password from dvwa.users#

e,

Figure 25 from the Modsecurity audit log shows that the attack was not successful and that it was
ut

blocked by Modsecurity. However, this may work against different types of SecRule or
t

applications so it is worth to try it. The CWH Underground team proved that the attack was
i
t
ns

successful against the application that utilizes the CRS SQL injection rule version 2.2.1. As of
I

this writing, the latest version of CRS SQL injection rule is 2.2.2 so, it is recommended to update
NS

the rules frequently if the CRS rule set is used.

--aa2d3934-A--
SA

[29/Oct/2011:18:01:14 --0700] Tqyh2n8AAAEAAAjUCgoAAAAD 192.168.63.1

46195 192.16
11

8.63.157 80
20

--aa2d3934-B--
GET
©

/dvwa/vulnerabilities/sqli/?id=%E2%80%98union%2523foo%252F*bar%25
0D%250Aall%2520select%2523foo%250D%250Auser%252Cpassword%2520from
%2520from%2520dvwa.users%2523&Submit=Submit HTTP/1.1
Host: 192.168.63.157
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 27
 
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5

s.
Accept-Encoding: gzip,deflate

t
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

gh
Keep-Alive: 115

i
lr
Connection: keep-alive

ul
Referer: http://192.168.63.157/dvwa/vulnerabilities/sqli/

f
Cookie: security=low; PHPSESSID=osqeourqqjacdph85t9oi58ji3

ns
--aa2d3934-F--

ai
HTTP/1.1 403 Forbidden

et
Content-Length: 308

rr
Connection: close
Content-Type: text/html; charset=iso-8859-1
ho
--aa2d3934-H--
t
Message: Access denied with code 403 (phase 2). Pattern match
Au

"(union|xor|or|rli
e,

ke|--|#|all|'|drop|delete|having|select|and)" at ARGS:id. [file

ut

"/etc/httpd/conf
t
i

.d/modsec.conf"] [line "24"]

t
ns

Action: Intercepted (phase 2)

I

Stopwatch: 1319936474504182 9305 (1552 8952 -)

NS

Producer: ModSecurity for Apache/2.5.13 (http://www.modsecurity.org/).

Server: Apache/2.2.21 (Fedora)
SA

--aa2d3934-Z--
11

Figure 25: Example of an advanced obfuscating SQL Injection attack.

20

5. Successful implementation of Modsecurity

©

In the above section, the deny rule was added to block the attacks right after the
corresponding analysis, but in real world this is a very dangerous approach, because, it may
break some legitimate application functions. For example, one of the demonstrated XSS attacks
was blocked by restricting the use of the “SCRIPT” string in the URI. This method worked in the

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 28
 

above example, but if a critical function of the application has the word “script” in the URI, this
will break the application. As a security professional, it is important to consider availability as
well as confidentiality and integrity of the application server. In this section, it is going to be

s.
discussed how to implement Modsecurity successfully for your application.

t
igh
5.1. Whitelisting model vs. Blacklisting model

lr
ul
When implementing a WAF for an application, it is very important to choose either the

f
whitelisting or the blacklisting model. With the whitelisting model, exact actions of the

ns
application needs to be defined in the rule set and the WAF will only allow the requests that were

ai
specified in the rule set. Any other requests will be denied. Therefore, the whitelisting method

et
provides high security and protection against new types of attacks, but it is really difficult to

rr
implement because you need a detailed knowledge of the application; any misinterpretation of
ho
the application behavior causes the failure of the application (Mischel, 2009).
t
On the other hand, with the blacklisting model, you only have to specify the requests you
Au

want to block and all other request will be allowed. So, it is much easier to implement it than the
e,

whitelisting approach and it is less likely that the application will fail. However, it is weak
ut

against attacks that were not defined in the rule set.

t
i

5.2. Log Mode

t
ns

In the previous section, both the whitelisting and the blacklisting model were discussed,
I

but the last one will be examined further for the rest of the section. In the above testing, the
NS

“SecDefaultAction” was set to a deny mode so it only denies every request that is matched by
SecRule, while any other request is allowed. Again, this is a very dangerous approach to start
SA

with; instead, it is recommended to use the log mode which allows the requests that are matched
11

by a SecRule to create a log entry. To enable the log mode, you need to change the “deny”
20

variable to “pass” from the “SetDefaultAction” line of configuration file, as shown below. If you
have used any deny action for individual rules which supersede the default action, you need to
©

change it to “pass, log” as well.

SecDefaultAction "phase: 2, pass, log”
When you use the log mode, it does not affect the functionality of the web application
because it does not block any request. You need to carefully examine the logs and find out what
requests have been logged by the Modsecurity audit log. If a valid request is caught by any

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 29
 

SecRule and appears in the log, you need to modify your SecRule accordingly. But going
through the tons of log entries is a difficult task. To help with log auditing, it is a good idea to
use the “msg” option, as shown in Section 3.4. Using this “msg” option, you can specify why the

s.
traffic is logged and you can find out easily which rule you need to fix. Also, it is a good idea to

t
setup a log monitoring system that can parse the large amount of logs easily.

igh
5.3. Deny Mode

lr
ul
You can’t stay in the log mode forever. When you are not seeing any more legitimate

f
traffic getting logged by the SecRule during the log mode for a reasonable amount of time, you

ns
have to make a decision to go to the deny mode, which denies the requests that are matched by

ai
SecRule. To enable the deny mode, you need to change the “pass” variable to “deny” from the

et
SetDefaultAction” line of the configuration file, as shown below. Again, if you have used any

rr
pass action for an individual rule which supersedes the default action, you need to change it to
ho
“deny, log, redirect:127.0.0.1/dvwa/” as well.
t
SecDefaultAction "phase: 2, deny, log, redirect:127.0.0.1/dvwa/”
Au

When the request gets denied, it is wise to redirect the traffic to the default website
e,

instead of displaying error messages, because it is not appropriate to show to the customers an
ut

error message or to provide any clue to the attackers. As shown above, the “redirect” action is
t
i

used to redirect the traffic to the homepage of the DVWA web application when the request gets
t
ns

denied. Even though you have spent reasonable amount time in the log mode, there is always a
I

chance of misconfiguration or a new type of traffic to be denied. For example, there can be a
NS

critical process that only runs once a year, but it happens to include a string that gets denied by
the existing SecRule. Therefore, it is important to prepare a system that monitors the denied
SA

requests and alerts the administrator immediately so he or she can check the logs to investigate
11

the case.
20

6. Conclusions
©

Web applications have been evolving so fast and they have become one of the most
important things that we can’t live without, such as electricity and water. The use of web
applications will not stop increasing but, on the other hand, attackers will not stop trying to
penetrate your applications to. Implementing a web application firewall is a great method to
protect your application from web attacks. However, the cost and the complexity of

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 30
 

implementing a WAF are huge. If you are new to the WAF technology, you should start with an
open source technology, such as Modsecurity, to learn the technology. Then, as a next step, you
can test your small application. Once you are confident with the technology, you can start

s.
implementing it for your main application in order to protect it.

t
igh
lr
ul
f
ns
ai
et
rr
ho
t
Au
e,
t
iut
t
ns
I
NS
SA
11
20
©

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Using Web Application Firewall to detect and block common web application attacks | 31
 

7. References
Damele, B., & Stampar, M. (2011). Sqlmaps's user manual. Retrieved from
http://sqlmap.sourceforge.net/doc/README.pdf

s.
Hansen, R. (2008). Xss cheat sheet. Retrieved from

t
gh
http://ha.ckers.org/xss.html

i
lr
HP DVlabs, (2010). 2010 full year top cyber security risks report.
Retrieved from http://dvlabs.tippingpoint.com/img/FullYear2010

ul
Risk Report.pdf

f
I v e y , T . ( 2 0 1 0 ) . D a m n v u l n e r a b l e w e b a p p l i c a t i o n o f f i c i a l d o c u m e n t a t i o n.

ns
Retrieved from

ai
https://dvwa.svn.sourceforge.net/svnroot/dvwa/docs/DVWA_v1.3.
pdf

et
rr
Mischel, M(2009). Modsecurity 2.5. (1st ed.). Birmingham, UK: Packt
Publishing Ltd.
ho
Modsecurity, (2011). Modsecurity reference manual. Trustwave Holdings,
t
Inc.Retrieved from http://sourceforge.net/apps/mediawiki/mod-
Au

security/index.php?title=Reference_Manual
e,

Owasp, (2011). Web application firewall. Retrieved from

h t t p s : / / w w w . o w a s p . o r g / i n d e x . p h p / W e b _ A p p l i c a t i o n _ F i r e w a l l  
t
iut

Phongthiproek, P. (2011). Beyond sqli: Obfuscate and bypass. Retrieved

t

from http://www.exploit-db.com/papers/17934/
ns
I

Stuttard, D, & Pinto, M(2007). The web application hacker's handbook. (1

NS

ed.). Indianapolis, IN: Wiley& Sons Publishing.

Security Compass. (2010). Retrieved from https://addons.mozilla.org/en-

SA

US/firefox/addon/xss-me/
11

Trustwave, (2011). New modsecurity release includes key data protection

advancements. Retrieved from
20

https://www.trustwave.com/pressReleases.php?n=new-
m o d s e c u r i t y - r e l e a s e - i n c l u d e s - k e y - d a t a - p r o t e c t i o n - a d v a n c e m e n t s  
©

Vela, E., & Lindsay, D. (2009). Our favorite xss filters/ids. Retrieved from
http://www.blackhat.com/presentations/bh-usa-
09/VELANAVA/BHUSA09-VelaNava-FavoriteXSS-SLIDES.pdf

Issac Museong Kim, iamissac@gmail.com

 

©2011TheSANSI
nst
it
ute Aspar
toft
heI
nfor
mat
ionSecur
it
yReadi
ngRoom Aut
horr
etai
nsf
ull
right
s.
 Last Updated: November 22nd, 2017

Upcoming SANS Training

Click Here for a full list of all Upcoming SANS Events by Location

SANS San Francisco Winter 2017 San Francisco, CAUS Nov 27, 2017 - Dec 02, 2017 Live Event

SIEM & Tactical Analytics Summit & Training Scottsdale, AZUS Nov 28, 2017 - Dec 05, 2017 Live Event

SANS Khobar 2017 Khobar, SA Dec 02, 2017 - Dec 07, 2017 Live Event

SANS Munich December 2017 Munich, DE Dec 04, 2017 - Dec 09, 2017 Live Event

European Security Awareness Summit & Training 2017 London, GB Dec 04, 2017 - Dec 07, 2017 Live Event

SANS Austin Winter 2017 Austin, TXUS Dec 04, 2017 - Dec 09, 2017 Live Event

SANS Frankfurt 2017 Frankfurt, DE Dec 11, 2017 - Dec 16, 2017 Live Event

SANS Bangalore 2017 Bangalore, IN Dec 11, 2017 - Dec 16, 2017 Live Event

SANS Cyber Defense Initiative 2017 Washington, DCUS Dec 12, 2017 - Dec 19, 2017 Live Event

SANS Security East 2018 New Orleans, LAUS Jan 08, 2018 - Jan 13, 2018 Live Event

SANS SEC460: Enterprise Threat Beta San Diego, CAUS Jan 08, 2018 - Jan 13, 2018 Live Event

SEC599: Defeat Advanced Adversaries San Francisco, CAUS Jan 15, 2018 - Jan 20, 2018 Live Event

SANS Amsterdam January 2018 Amsterdam, NL Jan 15, 2018 - Jan 20, 2018 Live Event

Northern VA Winter - Reston 2018 Reston, VAUS Jan 15, 2018 - Jan 20, 2018 Live Event

SANS Dubai 2018 Dubai, AE Jan 27, 2018 - Feb 01, 2018 Live Event

SANS Las Vegas 2018 Las Vegas, NVUS Jan 28, 2018 - Feb 02, 2018 Live Event

Cyber Threat Intelligence Summit & Training 2018 Bethesda, MDUS Jan 29, 2018 - Feb 05, 2018 Live Event

SANS Miami 2018 Miami, FLUS Jan 29, 2018 - Feb 03, 2018 Live Event

SANS London February 2018 London, GB Feb 05, 2018 - Feb 10, 2018 Live Event

SANS Scottsdale 2018 Scottsdale, AZUS Feb 05, 2018 - Feb 10, 2018 Live Event

SANS Secure India 2018 Bangalore, IN Feb 12, 2018 - Feb 17, 2018 Live Event

SANS Southern California- Anaheim 2018 Anaheim, CAUS Feb 12, 2018 - Feb 17, 2018 Live Event

SANS Dallas 2018 Dallas, TXUS Feb 19, 2018 - Feb 24, 2018 Live Event

SANS Secure Japan 2018 Tokyo, JP Feb 19, 2018 - Mar 03, 2018 Live Event

Cloud Security Summit & Training 2018 San Diego, CAUS Feb 19, 2018 - Feb 26, 2018 Live Event

SANS Brussels February 2018 Brussels, BE Feb 19, 2018 - Feb 24, 2018 Live Event

SANS London November 2017 OnlineGB Nov 27, 2017 - Dec 02, 2017 Live Event

SANS OnDemand Books & MP3s OnlyUS Anytime Self Paced