samedi 29 novembre 2014

Is it a considered a CSRF if it requires a unique identifier which is not a CSRF token - not tied to the user session?



Consider an end point such as below. Let's imagine that this endpoint updates an address of the signed in user, changing the zip code. The address to update is identified by the address ID (kUj3Nkg10).


http://foo.com/address-update/kUj3Nkg10/?zipCode=1234


Importantly, the identifier is an alphanumeric string, not an incremental integer. If it was an incremental integer, then it feasibly could be predicted. The alphanumeric can't reasonably be predicted or guessed.


Argument for considering it a CSRF


A CRSF token only lives and remains valid for the current session (or possibly even shorter). The unique ID in question remains the same (probably forever). Therefore a CSRF token should be used. It's possible that the identifier could be used elsewhere in the app, and made available for another user to see.


Argument for not considering it a CSRF


The attacker is unlikely to ever obtain the unique ID. It could be close to being as difficult to obtaining an actual CSRF token itself.


OWASP defines a CSRF as:



Any application that accepts HTTP requests from an authenticated user without having some control to verify that the HTTP request is unique to the user's session.



I think the above example satisfies the OWASP definition, because the address ID is not unique to the user's session.






Aucun commentaire:

Enregistrer un commentaire