Page 1 of 1
Tokens
Posted: Sat Apr 01, 2006 8:04 am
by Ree
I'm reading Shiflett's book on PHP security right now, and I wonder what's so great about including a unique token in your forms? It can easily be read, for example, by using CURL, and included in form submition. I don't see how it forces anyone to use the forms on the actual site.
Posted: Sat Apr 01, 2006 4:26 pm
by timvw
If i'm not mistaken the use of a token tries not to prevent automated posting, it tries to make CSRF attacks more difficult.
Posted: Sat Apr 01, 2006 9:15 pm
by s.dot
If you generate a random token, and include it in your form, and store parameters (including the token) in a database, and then check them on submission of the form, how could it NOT prevent someone from using fake forms?
Posted: Sun Apr 02, 2006 3:38 am
by Ree
scottayy wrote:If you generate a random token, and include it in your form, and store parameters (including the token) in a database, and then check them on submission of the form, how could it NOT prevent someone from using fake forms?
As I mentioned, I can read your token and submit it, but of course that's only easy if sessions aren't used.
However, if the token is purely session-based, that would make things more difficult for the attacker. Without session mechanism, tokens are pretty much useless, I guess.
Does anyone know a way to read the token in the form while the user is loggged in? That is, you would need to pass the user's cookies with GET as well.
Posted: Sun Apr 02, 2006 9:01 am
by Buddha443556
Ree wrote:As I mentioned, I can read your token and submit it, but of course that's only easy if sessions aren't used.
The point of a cross-site request forgery (
CSRF) is to get another user to make the request for you with their IP and thier session info.
If you generate a random token, and include it in your form, and store parameters (including the token) in a database ...
Usually a hash(secret value + session id) is enough - no database required. However, a value that changes on every request would be stronger - but also require more resources.
... how could it NOT prevent someone from using fake forms?
It's meant to prevent an attacker from crafting a fake request. Fake forms are a phishing sort of thing.
Posted: Sun Apr 02, 2006 9:54 pm
by shiflett
This question has been answered pretty well, but I want to elaborate on two important points:
1. What is a fake form? Lots of developers worry too much about what form someone uses to submit a request. Focus on the request - as long as it plays by the rules, does it matter? Cross-site request forgeries (CSRF) are the only concern related to this topic, in my opinion. They are requests that do in fact play by your rules, but the sender has been tricked into sending the request. You want to prevent that. Most web sites don't.
2. When you add a unique, one-time token to a form, many people understandably question the usefulness of the technique. On the surface, it seems trivial to view source or write a script that reads the HTML to find the token, but keep in mind point one above. This isn't meant to prevent people from submitting a request that plays by your rules - it's meant to prevent CSRF. If I am an attacker, and I want to forge a request from timvw, I need his token, so discovering my own is useless. In fact, I have nothing to gain from "forging" a request from myself that plays by your rules, because I can already use the form you provide to do that.
Hope that offers some clarification. If not, read Buddha443556's post again. :-)
Posted: Fri Jun 30, 2006 1:02 pm
by mu-ziq
Sorry to have to bump this old thread but I have a question
Would the following bypass any sort of token-protected submission forms:
- User is tricked into going to a
http://www.evilwebsite.com/form.php which is exact replica of your
http://www.yourwebsite.com/form.php
- The above fake form using javascript (similar to MySpace worm) sends a get request to
http://www.yourwebsite.com/form.php
and extracts the generated token from the hidden input field
- Fake form is submitted with the extracted token
am I missing something or would above work
Posted: Sat Jul 01, 2006 7:25 pm
by shiflett
mu-ziq wrote:am I missing something or would above work
Your description is valid when evilwebsite.com == yourwebsite.com. This was the case with Myspace, because they had a cross-site scripting (XSS) vulnerability that allowed the attacker to embed the JavaScript into the myspace.com domain.