I guess user specific implies authentication, but the authentication but makes sure that no random dude can retrieve a valid nonce. So, yes the current login does that.<br><br>By being page & form specific you gain alot. By tying the nonce that closely to the form/page then you are making sure that the only way to retrieve the correct nonce is through a valid request to that page/form. If the nonce is site-wide and valid on any form within the page, then all you need is a mistake in the way you validate the nonce and someone can retrieve a valid nonce. <br>
<br>I've seen this ALOT with login pages on sites using site-wide nonces, the first request to the login page will not have a nonce. Good you don't want to reveal it. But if you made that same request with invalid credentials then the nonce is exposed on the response asking you to try again.<br>
<br>A site-wide nonce does little more than a simple authentication does, there is generally a way to get a valid nonce. Think about it, your basically just adding a little extra information to the session in the get or post parameters... why not just force the session id into the url? Well then you leak the session id via the referrer. Same for nonces.<br>
<br>One of the more clever implementations of a site-wide crsf protection I have seen uses a state machine (with your current state in the session) to protect against out of band requests to random pages.<br><br><div class="gmail_quote">
On Tue, May 6, 2008 at 10:04 AM, Jon Daley <<a href="mailto:plogworld@jon.limedaley.com">plogworld@jon.limedaley.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What do you gain by being form or page specific? And what does "requires authentication" mean? something more than a regular login that we already have?<br>
I was thinking of a simple user and time token.<div><div></div><div class="Wj3C7c"><br>
<br>
On Tue, 6 May 2008, Matt Wood wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
It depends on how you implemented the nonce.<br>
<br>
I really haven't look into this specific vuln, I've just happened on the<br>
emails you guys were sending around... but assuming you have implemented a<br>
site-wide nonce implementation that is page specific, form specific, user<br>
specific, uses timed expiration, and requires authentication... it would be<br>
hard to utilize the reflection attack in any meaningful way other than<br>
attack yourself.<br>
<br>
I would never assume that it would be impossible, most of the time it is the<br>
conglomeration of vulnerabilities that allow an attack to do meaningful<br>
things.<br>
<br>
-Matt<br>
<br>
On Tue, May 6, 2008 at 3:17 AM, Reto Hugi <<a href="mailto:plog@hugi.to" target="_blank">plog@hugi.to</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Jon Daley wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I must really not be getting XSS then. If every post has to have a<br>
token on it, how would someone guess the token in order to have the<br>
javascript be accepted and displayed on the screen at all? I'd expect the<br>
token to be checked first, and simply die() if it doesn't match.<br>
I can't figure out a scenario where an attacker would be able to get<br>
javascript displayed on the screen to be executed within the context of that<br>
domain to steal a cookie, or do anything.<br>
<br>
<br>
</blockquote>
Jon, you're right on that very example. But I suppose we won't implement<br>
the CSRF Check (i.e. the nonce check) on every request, but only on the<br>
ones writing to the database (that's where CSRF is the most dangerous).<br>
And therefore we still need to make sure we are not vulnerable to xss.<br>
<br>
it was probably good to have this discussed once again. it's the only<br>
way we all get the same understanding of those attacks :)<br>
<br>
@matt: or do you see a possibility of exploiting our xss vuln. *if* we<br>
had implemented the nonce on every request (that's the scenario jon is<br>
thinking about...)<br>
<br>
<br>
_______________________________________________<br>
pLog-svn mailing list<br>
<a href="mailto:pLog-svn@devel.lifetype.net" target="_blank">pLog-svn@devel.lifetype.net</a><br>
<a href="http://limedaley.com/mailman/listinfo/plog-svn" target="_blank">http://limedaley.com/mailman/listinfo/plog-svn</a><br>
<br>
</blockquote>
<br>
</blockquote>
<br></div></div><div class="Ih2E3d">
-- <br>
Jon Daley<br>
<a href="http://jon.limedaley.com/" target="_blank">http://jon.limedaley.com/</a><br>
<br></div>
The only joy in the world is to begin.<br>
-- Cesare Pavese<div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
pLog-svn mailing list<br>
<a href="mailto:pLog-svn@devel.lifetype.net" target="_blank">pLog-svn@devel.lifetype.net</a><br>
<a href="http://limedaley.com/mailman/listinfo/plog-svn" target="_blank">http://limedaley.com/mailman/listinfo/plog-svn</a><br>
</div></div></blockquote></div><br>