Wednesday, January 11, 2012

DVWA Cross Site Request Forgery

Cross Site Request Forgery is very dangerous, and also quite common. OWASP describes Cross Site Request Forgery as:
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.

For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.

In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.

In other words, this is one reason why people tell you not to click on links (or open e-mails) from people you do not trust. Just by clicking a link they can steal your information or change your password without you knowing about it.

Preparation:

To follow this guide you will need a copy of Samurai. If you do not have one, or do not know how to set it up, please see this post.

1. Open Firefox by clicking the Firefox Icon or going to Applications > Internet > Firefox Web Browser and browse to http://dvwa/.


2. Go to the DVWA Security page and change the Script Security level to low.


3. Open Burp Suite by going to Applications > Samurai > Recon & Mapping > BurpSuite and set Firefox to use the Burp Local Proxy by clicking Tools > FoxyProxy Standard > Use proxy "Burp Local" for all URLs.



Now we are ready to get started.

The Attack:

We are going to use Burp Suite to capture the HTTP request when we try to change a password, and from that we will create a "hidden" link to send to a victim (via e-mail, IM, etc.) that will change their password to whatever we want so we can access their account.

1. Go to the CSRF page in DVWA and Change your admin password by entering a password in the New password and Confirm new password fields and clicking the Change button.





Notice that the page is loading, but not complete. That is because we need to tell Burp Suite to forward the packet and let it finish it's process.

2. Go to Burp Suite, click the Proxy tab, and view the password change http request and forward it after and you will see that your Password Changed on the DVWA site.



Now the part we are interested in is the begenning of the http request which looks something like:

GET /dvwa/vulnerabilities/csrf/?password_new=newpwd&password_conf=newpwd&Change=Change HTTP/1.1

Now all we have to do is construct a link that will perform the same function and hide it in some html so our victim doesn't know it is happening.

Example Text Link:

<a href="http://dvwa/vulnerabilities/csrf/?password_new=admin&password_conf=admin&Change=Change">Click Here</a>

Looks like: Click Here

Now, obviously, we can be more creative than a "Click Here" link but I'll leave that part up to you.

When someone clicks on the "Click Here" link it will change their password to "admin" without them knowing about it. Feel free to try it out and see for yourself. Now imagine this on a bank website, where all you needed to do was get someone to click a link that would deposit X amount of money in Y account, or on Facebook where you could change peoples passwords and get into all the hidden stuff they locked you out of.

6 comments:

  1. This one looks more manageable to me. Hurray for testing :V

    ReplyDelete
  2. If you run into any problems or have any questions, just ask.

    ReplyDelete
  3. Wouldn't we need to send the session cookies as well? Or are we assuming that the victim is logged in for the attack to be "successful"?

    ReplyDelete
    Replies
    1. You are correct, we are assuming the victim is logged in and using their session rather than sending our own session cookies.

      Delete
  4. This comment has been removed by the author.

    ReplyDelete
  5. This is nice blog for cross pen in delhi.We have Best cross pen in delhi along with different cross pens of various colors buy latest cross pen.Want to luxury best cross pen available visit website www.crosspenn.com for corporate gifting to get order online.

    ReplyDelete