[OWASP-wiki-editors] Page correction requested but authors/primary editors are unreachable
walterdolce at gmail.com
Fri Apr 29 23:53:38 UTC 2016
Hi all, does anyone have any update on this?
Thank you, Jim
I will continue on this thread unless you guys want me otherwise.
Pasting the original message below for brevity.
======= ORIGINAL MESSAGE =======
After trying to implement CSRF prevention components following the
encrypted token pattern and giving it some thought, I came to the
conclusion that this pattern does not protect you from replay attacks.
The page says
On successful Token-decryption, the server has access to parsed values,
ideally in the form of claims
<http://en.wikipedia.org/wiki/Claims-based_identity>. These claims are
processed by comparing the UserId claim to any potentially stored UserId
(in a Cookie or Session variable, if the site already contains a means of
authentication). The Timestamp is validated against the current time,
preventing replay attacks. Alternatively, in the case of a CSRF attack, the
server will be unable to decrypt the poisoned Token, and can block and log
The focus here is on "the timestamp is validated at the current time".
Imagine a scenario where a token with some time-based value embedded is
generated and then it's output in a hidden input field. The moment the
token is generated, it is already expired. If you think about a user who's
filling up a form, that would take her a few seconds. Once the user would
submit the form, she would then be blocked because time passed (>1sec)
since the token was generated. This makes form submissions almost
In a scenario where a "time threshold" is used instead (say 10 seconds max
until the token is considered as expired), the user experience would, *to
some extent*, benefit from the issue highlighted above. But here we open
ourselves to replay attacks, because if every request sent within the time
threshold would be considered valid. If someone tricks you to navigate a
fake page which under the hood sends i.e. payment POST request or things
like that, those requests would be considered valid and would pass...
Does this all make sense to you, or am I missing something?
What do you think?
If the answers are "yes, and no", then I think the page should be updated
accordingly as it creates false expectations.
======= END OF ORIGINAL MESSAGE =======
Please let me know what you all think.
On 24 April 2016 at 09:03, Jim Manico <jim.manico at owasp.org> wrote:
> Yes! Lets talk about fixing this cheat-sheet!
> Can you either submit comments here or perhaps send them to the cheatsheet
> email list?
> I look forward to reading your feedback!
> Aloha, Jim
> On 4/22/16 3:15 AM, Walter Dolce wrote:
> Hi all,
> I sent an email to the authors/primary editors few days ago as I believe
> the Cross Site Request Forgery Prevention Cheat Sheet page
> <https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet> needs
> correction but the email was sent back because of the subjects
> Is there anyone here I could discuss the changes with?
> Many thanks,
> walter dolce | senior full stack software engineer
> Zend Certified Engineer PHP5
> <http://www.zend.com/en/yellow-pages/ZEND026539> // Magento Certified
> Developer Plus
> twitter @walterdolce <https://twitter.com/WalterDolce>
> skype walter.dolce
> OWASP-wiki-editors mailing listOWASP-wiki-editors at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/owasp-wiki-editors
walter dolce | senior full stack software engineer
Zend Certified Engineer PHP5
<http://www.zend.com/en/yellow-pages/ZEND026539> // Magento Certified
twitter @walterdolce <https://twitter.com/WalterDolce>
tel +44 (or 0) 7873 527127
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-wiki-editors