I don't understand how using a "challenge token" adds any kind of prevention: what value should be compared to what?
From OWASP:
Generally speaking, developers only need Generate this token once Current session. After initialization The generation of this token, whose value is stored in session and used For each subsequent request, until Session expired.
If I understand the process correctly, this is what will happen.
I log in to http://example.com and create a session/cookie containing this random token. Each form then contains a hidden input that also contains a random value from the session, which is compared to the session/cookie on form submission.
But what can be achieved? Don't you just get the session data, put it into the page, and compare it to the exact same session data? Seems like circular reasoning. These articles keep talking about following a "same origin policy" but that doesn't make any sense since all CSRF attacks originate with the user and just trick the user into doing something he/she doesn't intend.
Are there any alternatives to appending the token as a query string to each URL? Looks very ugly and impractical, and makes it harder for users to bookmark.
CSRF explained by analogy - Example:
The impostor took all your money and maybe played some Xbox on the way out...
Summary
CSRF basically relies on the fact that you open the door to your home and then leave it open so that someone else can simply walk in and pretend to be you.
how to solve this problem?
When you first open the door to your home, the doorman will give you a piece of paper with a long and very random number written on it:
Now, if you want to enter your house, you have to show that piece of paper to the doorman to get in.
SoNowWhen an impostor tries to enter your house, the doorman will ask:
"What is the random number written on the paper?"
If the impostor does not have the correct number, then he cannot enter. Either he has to guess the random number correctly - a very difficult task. To make matters worse, the random number is only valid for 20 minutes (for example). So know that the impersonator must guess correctly, and not only that, he only has 20 minutes to get the correct answer. This is so strenuous! So he gave up.
Of course, this analogy is a bit far-fetched, but I hope it helps.
**crud = (create, read, update delete)
The attacker cannot obtain the token. Therefore the request will not take effect.
I recommend this article by Gnucitizen. It has a pretty good explanation of CSRF: http://www.gnucitizen.org/blog/csrf-revealed/