Cross-Site Request Forgery AttacksCross-Site Request Forgery (CSRF) is an attack outlined in the OWASP Top 10 whereby a malicious website will send a request to a web application that a user is already authenticated against from a different website. This way an attacker can access functionality in a target web application via the victim's already authenticated browser. Targets include web applications like social media, in browser email clients, online banking, and web interfaces for network devices.
Key Concepts of Cross-Site Request ForgeryMalicious requests are sent from a site that a user visits to another site that the attacker believes the victim is validated against.The malicious requests are routed to the target site via the victim’s browser, which is authenticated against the target site.The vulnerability lies in the affected web application, not the victim’s browser or the site hosting the CSRF.Executing a CSRF AttackIn a Cross Site Request Forgery attack, the attacker is exploiting how the target web application manages authentication. For CSRF to be exploited the victim must be authenticated against (logged in) to the target site. For instance let’s say examplebank.com has online banking that is vulnerable to CSRF. If I visit a page containing a CSRF attack on examplebank.com but am not currently logged in, nothing happens. I am logged in however, the requests in the attack will be executed as if they were actions that I had intended to do.
Let’s look at how the attack described above would work in a bit more detail. First let’s assume that I’m logged in to my account on examplebank.com which allows for standard online banking features, including transferring funds to another account.
Now let’s say I happen to visit somemalicioussite.com. It just so happens that this site is trying to attack people who bank with examplebank.com and have setup a CSRF attack on their site. The attack will transfer $1500.00 to their account, which is account number 123456789. Somewhere on somemalicioussite.com attackers have added this line of code:
<iframe src="http://examplebank.com/app/transferFunds?amount=1500&destinationAccount=123456789" mce_src="http://examplebank.com/app/transferFunds?amount=1500&destinationAccount=123456789" >
Upon loading that iframe, my browser will send that request to examplebank.com which my browser has already logged in as me. The request will be processed and send $1500.00 to account 123456789.
Find CSRF vulnerabilities in your code. Click here to view the demo of Veracode's Static Code Analysis ToolView Another Example of Cross-Site Request Forgery I just bought a new home wireless router. Like most wifi routers it’s configured through a web interface. The router was shipped to me with an internal IP address of 192.168.1.1. I’m having trouble configuring the router though, and fortunately the folks over at somemalicioussite.com have published a guide that shows me exactly what buttons to click in the router interface to get everything set up securely. The attackers have also set up a proxy server at 123.45.67.89 that will log all traffic that goes through it and look for things like passwords and session tokens.
As I clicked through the configuration guide I missed the 1x1 pixel image that failed to load:
<img src=”http://192.168.1.1/admin/config/outsideInterface?nexthop=123.45.67.89”; alt=”pwned” height=”1” width=”1”/>
The attackers knew that when I was reading their tutorial I would be logged in to the router interface. So they had the CSRF attack setup in the tutorial. With that request my router would be reconfigured so that my traffic will be routed to their proxy server where they can do all manner of bad things with it.
Preventing Cross-Site Request Forgery (CSRF) VulnerabilitiesThe most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append unpredictable challenge tokens to each request and associate them with the user’s session. Such tokens should at a minimum be unique per user session, but can also be unique per request. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user.
Finding and Remediating Cross-Site Request Forgery (CSRF) VulnerabilitiesThe easiest way to check whether an application is vulnerable is to see if each link and form contains an unpredictable token for each user. Without such an unpredictable token, attackers can forge malicious requests. Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets.
0 comments:
Post a Comment