3 weeks ago
So I make a form that Posts to the .php (I’ve also tried to the page itself, because… why not.), enter the password (sometimes just have it already entered), hit enter (or use a snazzy submit button), and get an error saying Invalid CSRF Token. I’ve been banging my head on this for two work days now.
Am I doing something wrong here? I checked to make sure I have cookies enabled. That’s fine. Normally the site is more explicit when you make an error, so I’m curious if it could be something to do with my company’s firewall blocking the post method.
Any assistance would be appreciated.
Not sure what you are trying to do (login or submit solutions). Anyways, the forms on the web site have a CSRF token included that gets transmitted with the form request. If you want to mimic the form submission of the web site, you have to include that CSRF token in your request. Just search for the parameter “token” in the web site source.
If you’re curious why there is such a token at all, I’m sure Google has plenty of answers for Cross Site Request Forgery and how to prevent it. ;)
3 weeks ago
Actually, speaking of the CSRF protection of DTW, I don’t think a token contained within a hidden input is a good idea. You can always retrieve it on the first request and then use it to submit a follow-up request.
I think it would be better to have the CSRF token as an HTTP request header instead as well as to have it removed from playground pages.
At least for now you do indeed need a CSRF token to solve it, but luckily the CSRF token is given in the page, just not in a form. Have a look if you can find it. (I’m not saying more here in case it is intentionally part of the challenge.)
@Keeper: Isn’t the idea of a CRSF token to provide protection exactly against those attackers that cannot do that first request (or at least get the result of that request)?
Sure, but most applications that store the CSRF token in the HTML associate it with the user’s session. That token then becomes valid up for the entirety of the session until it’s terminated. So in the event of an XSS vulnerability the attacker can obtain the token and then reuse it through the entire lifespan of the session (which if users opt for the remember me can be additionally extended).
As opposed to that, not having to handle the CSRF protection using a stateful token comes with its advantages. For example, checking the
Origin header would disallow external hosts from sending requests on behalf of the end-user. Using a double submit cookie can also be considered better than just a single token in the DOM.
Anyhow, in the end, an XSS vulnerability would render any CSRF protection useless but my point is that one can still aim to limit the attack vectors/impact.
@Keeper: Aim sure, but you already indicate that it doesn’t really solve anything, so… (and DtW’s tokens already seem to be unique per form per request). Anyway, off-topic.
@tehron: Pretty sure; have a closer look. Although there is also at least one in a form, I didn’t try that one because I expect it shouldn’t work.
2 weeks ago
Thank you for the replies and information.
I’m still beating my head on this. I’ve used different formats that I have found but I still get invalid CSRF and, occasionally, invalid log in comes up with it.
This is the latest code I’ve used:
The value for the token changes each time, obviously,, but from what I can tell this should work. I’ve also tried including the token on the url, instead (https://defendtheweb.net/playground/http-method?_csrf=<8887efaf3bcb9579fd53f59d0650c408ed117fabca6b8aeb8ed96b6003d8118a>, with and without <> on the value). Adding it as meta (which isn’t where it goes, but at this point why not?). There must be something that I am outright not understanding. I am a complete novice and was pretty happy with my progress this far. Any further insight would be very much appreciated.
@dloser : I cannot view the ticket you linked. What was the content?
2 weeks ago
Yes, this level should be looked at by @flabbyrabbit .
@niroth: You can use the CSRF token in the meta tag.
I suggest that you read up on HTML. A useful link for heads up in this challenge: https://www.w3schools.com/html/html_forms.asp
Also look at how the CSRF protection at DtW works and combined with the above link you’ll be able to solve the challenge.
2 weeks ago
a week ago | edited a week ago
I opened up Google Chrome Dev Tools to inpect the page, then injected this code into one of the div:
<form id="myform" action="https://defendtheweb.net/playground/http-method" method="POST"> <input type="hidden" name="password" value="8f1990c83a"/> </form> <script> document.getElementById("myform").submit(); </script>
Since the page itself already has a csrf-token in its meta-tag, so I did not need to edit that.
After refreshing the page, there was no CSRF error, but it just reloads the same page showing the same
original instructions. Apparently nothing happened. Can anyone point me in the right direction - what am I missing here, please?
a week ago
2 days ago
22 hours ago | edited 15 hours ago