Monday, March 28, 2016

Understanding Cross-Site Request Forgery (CSRF)

This is just a quick guide to Understanding Cross-Site Request Forgery and how it works and how can it be prevented.  So without wasting any more time lets get to it :).


So What is Cross-Site Request Forgery  RARRRRRRRRRR

Cross-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 Forgery

  • Malicious 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 Attack

In 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 into) the target site. For instance, let’s say 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:"

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 into the router interface. So they had the CSRF attack set up 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) Vulnerabilities

The 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 a source other than the user.

Finding and Remediating Cross-Site Request Forgery (CSRF) Vulnerabilities

The 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.




No comments:

Post a Comment

Cracking Kerberos Service Tickets (TGS) Using Kerberoasting

As of late I've been spending a lot of time researching and learning different techniques when it comes to attacking Active Directory En...