For example, an attacker can add their own cookie for the site using either a non-HTTPS request that they (as a man-in-the-middle) intercept and return a set-cookie header on (they can do this if the victim ever visits any non-HTTPS site, even if the target site doesn't even listen for plain HTTP!), or by gaining control of any subdomain that shares a root domain with the victim site and setting a cookie scoped to the root. Cookie security is kind of a mess for historical reasons, and while there are ways to protect cookies that have been bolted on over time, they're not yet in widespread use. The problem is that the assumption "attacker can't set cookies for the victim" isn't a very good one. With that said, the "double-submit cookie" pattern that you're describing here is weak, and should be avoided. As such, so long as each user gets a unique anti-CSRF token (it can be totally random, and if it's long enough there is still ~0 risk of collisions), an attacker can't use their own anti-CSRF token for a forged request, because it won't correspond to the victim's cookie (or match the anti-CSRF token expected for the victim using any other method either). The victim's browser sends its own cookies, not ones the attacker either knows about nor can control (at least, this is the assumption). In a CSRF attack, the attacker causes the victim to send a request (the Cross-Site Request that is being Forged) to the server.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |