Tokens

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
Ree
Forum Regular
Posts: 592
Joined: Fri Jun 10, 2005 1:43 am
Location: LT

Tokens

Post 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.
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post 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.
User avatar
s.dot
Tranquility In Moderation
Posts: 5001
Joined: Sun Feb 06, 2005 7:18 pm
Location: Indiana

Post 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?
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.
Ree
Forum Regular
Posts: 592
Joined: Fri Jun 10, 2005 1:43 am
Location: LT

Post 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.
User avatar
Buddha443556
Forum Regular
Posts: 873
Joined: Fri Mar 19, 2004 1:51 pm

Post 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.
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post 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. :-)
mu-ziq
Forum Newbie
Posts: 11
Joined: Fri Jul 08, 2005 9:42 pm

Post 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
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post 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.
Post Reply