Cross Site Request Forgery (CSRF or XSRF) is also known as session riding in which unauthorised user commands are sent to the server on the victim's behalf, victim himself being unaware of it. The website trusts the user because of the session cookie set up. This trust of the website towards the user is exploited through CSRF. A typical CSRF request inherits user's credentials to perform operations on their behalf, who are logged in to the target website.
Although not as popular and widespread as XSS or SQL Injection, there are quite a number of attacks and vulnerabilities that were reported last year. According to infosecurity magazine, almost one third of top banking websites are vulnerable to this type of attack. Youtube and The new york times were also once vulnerable to CSRF.
Basically, user's browser is tricked into making HTTP requests to a site where victim is logged in, to execute operations on user's behalf, like transferring money, changing the password, creating or deleting an account etc.
Here is an example...
Consider xyz bank which has online banking web app running on their website.
An attacker will craft a malicious URL as follows:
Now he can send this link to the victim in many ways like social engineering, guestbooks, online forums, emails, chats etc. However, he has to make sure that victim is logged into the bank when the HTTP request is being executed. Usually, the malicious link is included in the HTML img tag or a href tag in an email or webpage.
Usage of iframe can also be exploited to launch CSRF attack.
CSRF attacks are blind i.e. attacker is not able to see the page returned to victim. It is possible to forge login requests using CSRF. The attacker may log in the victim to the target website using his own credentials.
CSRF attacks are often executed in conjunction with XSS, where XSS can be used to bypass the CSRF preventive mechanisms. Sometimes, it is possible to store the CSRF attack URL on the target website itself, using guestbooks, comments, online forums etc. This can become more malicious since large number of users can be exploited.
Prevention of CSRF can sometimes become tricky since not all web application developers are aware of the mitigation techniques for this threat. Some people might believe that accepting only POST requests and setting up a secret cookie can stop CSRF attacks. These techniques do not offer prevention as mentioned on OWASP's CSRF article. Requiring a user specific token or the client credentials in any HTTP request that has security or financial implications is useful. Only checking the HTTP referrer is insufficient since it can be easily spoofed. Cookies stored at user's computers should have limited lifetime. Logging off the user after certain time of inactivity is also useful. OWASP CSRFGuard is a library that implements synchronizer tokens to prevent such attacks. There is very little individual end users can do to prevent CSRF attacks. Logging out of sites, avoiding 'remember me' feature, not loading external images in emails or spam can help. RequestPolicy and CsFire extensions are available for firefox to tackle CSRF attacks, however, these plugins may greatly hamper the regular browsing experience.
On a positive note, many websites that handle financial transaction require the user to manually enter a password (other than their login credentials) to authenticate a financial transaction.
Thanks for reading :)
Although not as popular and widespread as XSS or SQL Injection, there are quite a number of attacks and vulnerabilities that were reported last year. According to infosecurity magazine, almost one third of top banking websites are vulnerable to this type of attack. Youtube and The new york times were also once vulnerable to CSRF.
Basically, user's browser is tricked into making HTTP requests to a site where victim is logged in, to execute operations on user's behalf, like transferring money, changing the password, creating or deleting an account etc.
Here is an example...
Consider xyz bank which has online banking web app running on their website.
http://www.xyzbank.com/ibanking/And the users can transfer money from their account to another. An HTTP request for this transfer would look like this:
http://www.xyzbank.com/ibanking/transfer.php?amt=1000&toaccount=121232Where 1000 is the amount and 121232 is the account number where the money is to be transferred.
An attacker will craft a malicious URL as follows:
http://www.xyzbank.com/ibanking/transfer.php?amt=100000&toaccount=123434Where 123434 is attacker's own account number in xyz bank.
Now he can send this link to the victim in many ways like social engineering, guestbooks, online forums, emails, chats etc. However, he has to make sure that victim is logged into the bank when the HTTP request is being executed. Usually, the malicious link is included in the HTML img tag or a href tag in an email or webpage.
<img src="http://www.xyzbank.com/ibanking/transfer.php?amt=100000&toaccount=123434" width=0 height=0 />
<a href="http://www.xyzbank.com/ibanking/transfer.php?amt=100000&toaccount=123434">See the pictures!</a>Once the image is loaded and transfer request is made, the resulting webpage doesn't show up hence the victim is unaware of the transaction unless communication from the bank in this regard.
Usage of iframe can also be exploited to launch CSRF attack.
<iframe src="http://www.xyzbank.com/ibanking/transfer.php?amt=100000&toaccount=123434" />For CSRF, the attacker must choose a website which has no mechanism for checking referrer header. Also the attacker should know the correct values of all the form inputs, since failing to provide some of them (like IDs or codes) can result in unsuccessful attempt.
CSRF attacks are blind i.e. attacker is not able to see the page returned to victim. It is possible to forge login requests using CSRF. The attacker may log in the victim to the target website using his own credentials.
http://www.xyzbank.com/login.php?username=attacker&password=attacker123Then all the activity user makes on the website can be logged into the attacker's account.
CSRF attacks are often executed in conjunction with XSS, where XSS can be used to bypass the CSRF preventive mechanisms. Sometimes, it is possible to store the CSRF attack URL on the target website itself, using guestbooks, comments, online forums etc. This can become more malicious since large number of users can be exploited.
Prevention of CSRF can sometimes become tricky since not all web application developers are aware of the mitigation techniques for this threat. Some people might believe that accepting only POST requests and setting up a secret cookie can stop CSRF attacks. These techniques do not offer prevention as mentioned on OWASP's CSRF article. Requiring a user specific token or the client credentials in any HTTP request that has security or financial implications is useful. Only checking the HTTP referrer is insufficient since it can be easily spoofed. Cookies stored at user's computers should have limited lifetime. Logging off the user after certain time of inactivity is also useful. OWASP CSRFGuard is a library that implements synchronizer tokens to prevent such attacks. There is very little individual end users can do to prevent CSRF attacks. Logging out of sites, avoiding 'remember me' feature, not loading external images in emails or spam can help. RequestPolicy and CsFire extensions are available for firefox to tackle CSRF attacks, however, these plugins may greatly hamper the regular browsing experience.
On a positive note, many websites that handle financial transaction require the user to manually enter a password (other than their login credentials) to authenticate a financial transaction.
Thanks for reading :)
No comments:
Post a Comment