Page 2 of 2
Posted: Thu Feb 22, 2007 3:02 am
by Tommy1402
The article makes it clear that by disabling javascript, a user is completely insecure.
Re: Security question.
Posted: Thu Feb 22, 2007 3:15 am
by Oren
Tommy1402 wrote:I also use token to make sure that all request come from my web forms.
It doesn't guarantee that the data come from your web forms.
It only guarantee that the user/hacker had been in your web page.
Re: Security question.
Posted: Thu Feb 22, 2007 3:30 am
by Tommy1402
Oren wrote:Tommy1402 wrote:I also use token to make sure that all request come from my web forms.
It doesn't guarantee that the data come from your web forms.
It only guarantee that the user/hacker had been in your web page.
The token is auto-changed in every page request...
I don't really understand what you're saying. Could you explain more detail? (thanks)
Posted: Thu Feb 22, 2007 4:29 am
by Oren
Ok, I'll explain, but first tell me how exactly you implement this mechanism in your code.
Posted: Thu Feb 22, 2007 8:06 pm
by Tommy1402
Oren wrote:Ok, I'll explain, but first tell me how exactly you implement this mechanism in your code.
First, a registered user logs-in. In success, $_SESSION['uid'] which contain the (user's id) and (new session id) are generated.
A random $ token and $_SESSION['token'] are also generated.
Then the current user's session id and IP is recorded in database.
if login succeed, the user will be redirected to the main page.
In every page, I put $User->Validate($_GET['token']) to make sure that the current user has same: User Id, Session Id, IP, and token. If validation success, a new $token is generated along with a new $_SESSION['token'].
Because I use GET to get the token value, I add ?token=$token in every link in my template(tpl) page.
Well, that's all. I'm still learning this concept so, please enlight me. Thanks!
Posted: Fri Feb 23, 2007 5:55 am
by Mordred
It is redundant to keep the info both in database and session.
Don't generate your own session id, let PHP do it (it will do it better than you)
Otherwise it seems okay in theory, will have to see the actual code for a true analysis.
P.S. for token-protected pages it might be good to disable caching (see the manual on header() for example).
Note that if you have a XSS vulnerability somewhere, the attacker may still be able to do CSRF by requesting a form and parsing it to get the token.
Read this:
http://shiflett.org/articles/cross-site ... -forgeries
Posted: Fri Feb 23, 2007 11:20 pm
by Tommy1402
Mordred wrote:
P.S. for token-protected pages it might be good to disable caching (see the manual on header() for example).
thanks for the above info...
one question regarding shiflett page: since shiflett uses session, post method and hidden form, what if i use cookie instead? is it safer?
Posted: Fri Feb 23, 2007 11:37 pm
by feyd
Cookies values are just as susceptible to manipulation as post and get submissions.