1

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://example.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.

To clarify, in the example, the address ID was randomaly generated, but once it exists, it never changes. The ID is not based on any specific user or address data.

Also, an address update is just one example, it doesn't really matter what the request actually does. It could be updating a phone number, or removing an email address. The key is that this alphanumeric is used to identify the entity and that no CSRF token is present.

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.

  • It might be more constructive to ask "is this CSRF exploitable?". Because this is not the standard CSRF defence, many practitioners would raise this as a potential issue. The key question is whether it's exploitable. – paj28 Nov 29 '14 at 17:34
2

There are CSRF prevention techniques that do not rely upon a session-bound CSRF token, after all there is more than on way to skin a cat. When considering a CSRF protection system, look for any shortcut that doesn't exist with the commonly used CSRF synchronization token pattern. There are three concerns with this proposed CSRF protection system.

Expiration - CSRF is also called "session riding", in some sense a CSRF token is a lot like a session id, most importantly they both must expire. The concern is that an attacker is permitted to guess the exact value of the CSRF token over an unlimited period of time.

Recovery from attack - XSS can be used to obtain any value on any page using an XMLHTTPRequest(), which includes CSRF tokens. Once the attacker has the CSRF token, they are permitted ride on the victim's session indefinitely, because it never expires.

Referer Information leakage - Sending the CSRF token in the URL is risky behavior. If at any point an attacker can control the href of an <a> tag or the src of an <img> tag, then an attacker can force browsers into loading content from a web server controlled by the attacker, thus allowing the attacker to log the HTTP referer, which will contain the CSRF token of the victim.

-1

If the adress ID could be generated from a specified adress (for example, if the adress ID is some binary representation of lat/long of the specified adress that is then Base64-encoded and then converted back and forth via a geolocation service), then you are at same risk of CSRF as originally.

But if the ID is random, then you are safe from CSRF.

You need to code your web application to reject any queries with a non-existing ID, or with a ID that does not belong to the user in question.

It does not matter if you encrypt a geolocated adress ID, because then the attacker just gets the old adress ID by simply inputting the victim's original adress into the attackers own account, and thus getting the ID to use to change the victims adress.

Thus you need to use a completely random ID to be secure.

  • Thanks for the answer. To clarify, the address ID is not derived from anything specific, just a random, but importantly never changes. You'd never generate an address ID based on its lat/long because two addresses can share the same lat/long. – ServerBloke Nov 29 '14 at 15:55
  • Then its safe. Note that if a attacker previously had access to a account, he could mount a targeted attack against the user in question. But such attacks is very uncommon, because if a malicious user would gain access to a victims account, he would propably hijack the account immediately. – sebastian nielsen Nov 29 '14 at 16:04
  • @sebastiannielsen do you have empirical evidence that it is uncommon, or is that just a guess? – atk Nov 29 '14 at 16:20
  • Looking at the Point of view from the attacker, there would be no gain for a attacker to gain access to a account, and then lose access, and then using CSRF to regain access. A attacker that would gain legitimate access to a account would rather keep access, by for example changing the password or something. This would indicate account lending is in the process which are a really bad thing to do in schemes that require a Little bit higher security. – sebastian nielsen Nov 29 '14 at 20:54
  • @sebastiannielsen (1) i am still interested in empirical evidence that supports your claim. (2) regarding your last post, csrf is a great way to frame other users for apparent misbehavior, since all logs point to the victim. It could also be used to have the other user perform an action on an object that you can see but not modify. There are probably other scenarios where csrf is still a useful attack, as long as the identifier is consistent across sessions. – atk Dec 1 '14 at 19:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.