Tokens
Moderator: General Moderators
Tokens
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.
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?
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
As I mentioned, I can read your token and submit it, but of course that's only easy if sessions aren't used.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?
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.
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
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.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.
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.If you generate a random token, and include it in your form, and store parameters (including the token) in a database ...
It's meant to prevent an attacker from crafting a fake request. Fake forms are a phishing sort of thing.... how could it NOT prevent someone from using fake forms?
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. :-)
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. :-)
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
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