Follow us on Twitter!
The important thing is not to stop questioning. - Albert Einstein
Thursday, April 17, 2014
HellBoundHackers Main:
HellBoundHackers Find:
HellBoundHackers Information:
HellBoundHackers Exploit:
HellBoundHackers Programming:
HellBoundHackers Think:
HellBoundHackers Track:
HellBoundHackers Patch:
HellBoundHackers Other:
HellBoundHackers Need Help?
Members Online
Total Online: 25
Guests Online: 23
Members Online: 2

Registered Members: 82815
Newest Member: medjiking
Latest Articles

Intro to CSRF

Arrow Image An introduction to Cross-site request forgery. Description, explanation, examples, prevention

Introduction to
Cross Site Request Forgery

What is it?
Instead of just a definition, how about a situational breakdown first:
Cross-site: The action is being done by one user(on a site) and it affects one or more other users(on other sites).
Request: An HTTP request being made on a page
Forgery: Someone else sending a request your way and you making it
CSRF or XSRF for short
The two most fitting nicknames for it I think are Sea-Surf(made from pronouncing the acronym CSRF, you are surfing the internet taking advantage of their session) and session riding, since you are taking advantage of another user\'s session to perform certain tasks(riding it).

You may have noticed how the name is similar to XSS as far as the cross-site part goes. This is true because both attacks require more than one user to carry out. In an XSS example, you would need one person to
inject code into a guestbook, but then another user to view that page and get his cookies stolen. In a similar sense, in a CSRF attack one user would trick another into making a request. With CSRF though, a certain
script may be executed when they visit the page, but there is an action being performed just by them accessing the page. It\'s not something on the page that\'s being exploited, but just them going to the page unknowingly.

What is required?
Some form of authentication. Like I said, it is a two person job. The victim is logged in and when he \"signs\" these forged requests, he(or she) is actually doing the final step of the attack. It\'s required for the person
to have some kind of privilege on the site, whether it be admin, developer, or a plain and simple registered user. The reason is because a number of new pages are now available once you have some sort of further
access within the site. (Like when you are logged out of HBH, you can\'t use the shoutbox, post in the forums, do the challenges, submit code etc) Just like you couldn\'t make a new entry or add a friend unless logged
in on myspace or another blog/networking site. A person viewing your site that is not logged in would not be at risk.

Why it works
Because the (vulnerable) sites do not check to see if it\'s actually the real person making the request or not. There are simple solutions for this though, I\'ll get into those later.

Proof of concept
First, you have to know exactly what\'s going on before crafting links and getting fancy. Slick sends a link to Smooth in an IM window. He tells Smooth how he just uploaded some new pictures a few hours ago, and
wants someone\'s opinion on how they look. In reality, Slick hasn\'t been logged in since a week ago. That doesn\'t really matter though, because at the moment, Smooth is logged in. It\'s only because he saw pictures
of Smooth and his girlfriend last month that he\'s motivated for such an attack. If you didn\'t know what I meant by \"action\", it\'s just something being done on a page. One of the easiest ways to exploit CSRF is to exploit
URL\'s that use the GET method of requesting( Post is vulnerable too, more on that later.

Here would be the basic link to close Smooth\'s account:

Slick wants to make this a done deal though, he knows if Smooth sees that, he\'ll know something is fishy. He does a little crafting with hex encoding.

Smooth dismisses that as a bunch of mumbo jumbo to do with the site that Slick probably doesn\'t know anything about, so he clicks the link. doesn\'t know how the link came to be or how it\'s being
accessed, it just knows it\'s being accessed in Smooth\'s session. Once he is at closeAcct.php and the confirm variable is set to \"yes\", the account is wiped from the database.

Crafting Examples

Hex encoding is just one way to disguise a link. Here are a few ways to actually hide that a request will be made at all. One common and sneaky way to craft the link is to put it inside of an image tag. Unlike the case of
a hyperlink, you don\'t have to click it, because it automatically makes an HTTP request on the image when the page loads.
Here\'s what we could put in an html document.

<img src=\"\" width=\"0\" height=\"0\">

Notice the width and height are 0, for the reason we don\'t want anyone noticing the broken image. That might suggest something suspicious is going on.

Double click picture to enlarge
<img src=\"elusive_picture.jpg\" onmouse<em></em>over=\"window.location=\'\'\">

We trick the user into holding the cursor over the image, then they are redirected. (Unlikely that a person will view the source before going to the page)


<form method=\"post\" name=\"request\" action=\"http://site/vuln_page\">
<body on<em></em>load=\"request.submit()\">

We gave the name \"request\" to the form, then submitted it when the page loaded. Still vulnerable with $_POST!

The Misconception
Do you think that since GET variables are displayed in the URL and submitted once a link is clicked that POST variables are safe from CSRF? Well, you wouldn\'t be so lucky(depending on how you look at it). Attacks like phishing can easily work around using a GET page.
Javascript is also handy for submitting forms with post fields. Refer to the last example if you didn\'t already catch that.

On the user\'s end, they can log out of a site when they aren\'t using it, that way their session isn\'t open for attacks from other users. On the coder\'s end, it is solved by generating a unique key for an action the user could perform
and only follow through on it if they key equals the right value. On a side note, something that won\'t prevent but will do damage control if you are attacked is to not use the same password for multiple sites. This is a bad idea and
you could get completely screwed over this way.

$id = createUniqueHash();
if ( $_GET[\'action\'] == \'something\' )
if ( $_GET[\'token\'] == $id )
//do action;
die(\'Action failed: Incorrect key\');

instead of
a variable is sent and checked before carrying out the action

Real Life Connection
Is HBH vulnerable to CSRF? It might be. At least, it has been in the past. If you look in the hall of fame, you\'ll see 5 different cases(presently) where there have been CSRF vulnerabilities within this site. You hold your mouse
over the logout link and see there is a key that\'s being sent when you access the page, something that apparently wasn\'t always like that. The situations are sometime serious though. It may not (in fact, it won\'t) always be something
as elementary as logging another user out or redirecting them to a dirty picture. Important data could be deleted, money could be lost, and by their nature, one attack can easily lead to another. It\'s simple to prevent, so do it!

Surprisingly, I searched HBH and couldn\'t find an article on this, so that motivated me to write one. I know some people are already knowledgeable on this, but hopefully you enjoyed the read anyway. Comments welcome.



Mouzion June 05 2008 - 17:16:54
Hmm. I didn't understand what CSRF means until the Proof of Concept part : P (Although I've known this technique already, but didn't know the name). Other than that it was pretty good : )
mastergameron June 05 2008 - 20:37:21
Pretty good article, well laid out and presents the information clearly. Well done Smile
Uber0non June 05 2008 - 21:58:26
This article sure is a good introduction to CSRF, I'll top rate it Wink Just a note though; HBH is vulnerable to CSRF in many places but the admins haven't felt like fixing it (even though I reported it more than a year ago) ^^
system_meltdownon June 06 2008 - 00:03:09
Nice article, well presented, as others have said, and well structured, I like your writing style. P.S: Uber0n, PM me.
Uber0non June 07 2008 - 17:30:50
@system_meltdown: PM sent. I hope you'll fix it Wink
spywareon June 07 2008 - 17:40:04
Original content? On my HBH? That's awesome! Or, wait, nope, just very good :/.
root_opon June 07 2008 - 23:31:24
I love this article! I love the way that it's written! I'm waiting for more of this, Awesome work! Grin
ranmaon June 08 2008 - 18:15:18
Very nice.
korgon June 11 2008 - 07:55:33
Like it myself well written, Should help alot of people learning this stuff for the first time. 9/10!
crashbirdon June 13 2008 - 11:47:11
wonderfully written. excellent 10/10.
clone4on June 19 2008 - 16:08:19
Great introduction to CSFR,one of the better articles on HBH. Not only original content including topic, which hadn't been covered by any article on HBH, but also well structured, easy to read and understand. Well done, and Awesome! from me Wink
sharpskater80on June 27 2008 - 02:50:15
Thank you people for the feedback, glad you like it.
Post Comment


You must have completed the challenge Basic 1 and have 100 points or more, to be able to post.