8

I'm auditing my website with w3af.

It says it found several issues on my site, but I doubt that's really the case.

One of the issues is:

The URL: http://localhost/en/login is vulnerable to cross site request forgery. It allows the attacker to exchange the method from POST to GET when sending data to the server.

I'm pretty sure it isn't vulnerable to a csrf attack since I have used crsf protection in my forms (field with token which gets checked).

So I am wondering what this message is about:

It allows the attacker to exchange the method from POST to GET when sending data to the server.

I don't care if an attacker would be able to switch from POST to GET or do I?

And if I do can you please explain why I do? How can it be exploited?

PeeHaa
  • 71,436
  • 58
  • 190
  • 262
  • Are you using $_REQUEST in that form, instead of _POST? – Marc B Nov 22 '11 at 21:46
  • @MarcB: Yup I am. But I don't see how that would be exploitable (considering the csrf prevention field). – PeeHaa Nov 22 '11 at 21:48
  • @Macmade: can you please explain why I do care about it? – PeeHaa Nov 22 '11 at 21:49
  • 3
    @peehaa: it'd be far easier to attack a login form that allows GET inputs. consider someone putting up a malicious FB app that promises the meme-du-jour and puts in `` You'd have the entire FB bandwagon banging on your front door. – Marc B Nov 22 '11 at 21:56
  • @MarcB: No can't do since the csrf protection field with the 'random' token. The malicious FB app cannot know the token. – PeeHaa Nov 22 '11 at 21:58
  • Also saying that GET is easier to use than POST is really not the case. – PeeHaa Nov 22 '11 at 21:59
  • True enough, just a random sample. But still... get is much easier to forge than post. – Marc B Nov 22 '11 at 22:00
  • @MarcB: ok by better looking at your comment :) you have a tiny point when for example using it in an image src. tiny point but still a point :) – PeeHaa Nov 22 '11 at 22:04
  • +1, didn't know about w3af so thanks for asking! If you use POST->Redirect->GET pattern, you would probably be checking the request method before pulling out the form submission information, so that would probably be enough to silence w3af regardless. Also, just having a dedicated URL for your login page can be seen as a vulnerability or at least just not RESTful. A website can be organised so that any unauthenticated request responds with the login page for any protected URL. – Lee Kowalkowski Nov 22 '11 at 22:08
  • @LeeKowalkowski: You're welcome. I was just trying out some testers. You could also check out http://sectools.org/ which contains a list. What if I return the correct status code wouldn't that make it 'RESTful'? – PeeHaa Nov 22 '11 at 22:29
  • 1
    To be perfect, you can return 403 Forbidden for your CSRF detection or 401 Unauthorised for a login challenge response. The response body can still be user friendly too. E.g. the CSRF response can explain that the request looked unsolicited (the CSRF response for our systems is a form-field validation component so all form fields are persisted for the user to review), and the 401 response should be the login form. Using clear status codes and well-structured, meaningful URLs helps a lot when inspecting HTTP log files. – Lee Kowalkowski Nov 22 '11 at 22:49

1 Answers1

3

Coming from a point of view of no experience with w3af, I would assume that it has some pretty basic rules written into it and it checks those rules and reports back on them.

In this case it will probably check whether you have used $_REQUEST instead of $_POST or $_GET and then report an error if it finds it, regardless of the efforts you have made to secure this.

Everyone will code differently so getting software to understand the context of your code would be an amazing achievement and probably be beyond the intelligence of this one. This is not meant as an attack on the software, but to be honest if I came up with some program that could understand the context and intent of someone else's code, I wouldn't be giving it away on sourceforge :p

Does it matter? Maybe depending on how well you have secured the site (see Marc B's (+1) comment above).

-- EDIT --

By using $_REQUEST instead of specifying $_POST or $_GET you have left yourself open to an area of attack that is easily closed. Not only this but $_REQUEST also includes $_COOKIE. This has been covered here rather than me duplicating someone else's answer.

Community
  • 1
  • 1
Matt Asbury
  • 5,644
  • 2
  • 21
  • 29
  • Tell me why the +1 since I have csrf protection build in... I don't get it. Also see my comment on Marc B's comment. How can it ever be exploited when csrf protection is in place. Or am I missing something huge here (can also bee the case. it happens sometimes :) ) – PeeHaa Nov 22 '11 at 22:01
  • Oh @PeeHaa by the way +1 for w3af. Just had a look and it looks pretty awesome. – Matt Asbury Nov 22 '11 at 22:34
  • I think that would make sense. It tests it to see if the variables also could be send using `GET`. But I've came to the conclusion that i doesný matter for me since I have csrf protection in place. Nice edit about the `$_COOKIE` variable for others to read. Although I always change the sequence of the GPC and make sure I have a nice prefix for my cookies just in case. I've ran into that problem once and it's a nice addition for others to read. – PeeHaa Nov 22 '11 at 22:35
  • 1
    also see my comment at @ LeeKowalkowski for a nice list of pentesters – PeeHaa Nov 22 '11 at 22:38
  • 1
    This thread is why I like this site so much; everyone learns something :D – Matt Asbury Nov 22 '11 at 22:47