0

I joined a small project, I noticed that in the project uses something like a token associated with a user journey. So the URL looks something like: https://host.com/sell/:jurneyID.

All data entered during by the user in the journey are associated with the jurneyID including email, personal information and so on.

That means when I go to https://host.com/success/:jurneyID I can see user data related to that journey.

There is no concept of a session which means that anyone who knows jurneyID can access this data.

In theory jurneyID is long randomly unique string and expires after two weeks, however, I still don't like this solution because:

  • token string can be brute-forced
  • jurneyID is part of the URL therefore can be extracted from logs, browser history, etc.

I'd like to ask if you know any resources which can prove that this solution is a bad idea, and does such vulnerability has its name?

  • Is this url format also used for state-changing operations in POST requests (or even worse via GET requests)? That would make the application vulnerable to CSRF. – Martin Fürholz Jan 21 at 9:55
  • @MartinFürholz as far as I'm aware it's not used in a state-changing operations via GET but it's used in POST – LJ Wadowski Jan 21 at 13:13
  • How long exactly is jurneyID? – Conor Mancone Jan 21 at 16:14
  • @ConorMancone it's 32 characters long – LJ Wadowski Jan 22 at 10:11
3
+50

Token ids are a common tool. They originate into the 80's where the Kerberos protocol used a random token to identify a user for a period of time without requiring to give again a password.

The rationale is that only the legimate user should know the token, and that the duration of the token is short enough to have it to expire before it will be captured. It is generally seen as a very long password with a rather short duration (between one day and a few months). So what is assumed that it is harder to steal than a normal password because the latter has to be easily memorized by its user, so it requires less protection and can sent along with the URL.

For the weaknessess you asked about:

  • brute forcing the token string - it is a large random string and a brute force attack on it would certainly be noticed before it has a chance to success, and the livetime of the token should make it expire before the attacker could exhaust the possible strings. In addition, incorrect token should occur scarcely, because they are normally sent by a machine with no risk for typos. So token errors should soon blacklist the attacking address, even for a small period of time making brute force attacks impossible
  • the token can be extracted from logs and browser history. Hmm... one of the security laws says that if an attacker can control your system, it is no longer (only) your system. One recommended counter measure is to educate the users to change their token as soon as they think that someone could have used their browser. For the log part, it only means that logs become sensitive data and that they should require administrative priviledges to be read. And it is useless to try to protect a system against its admin...

TL/DR: you are true by saying that using tokens enlarges the attack surface and for that only reason lower the overall security. For that reason, they should not be used for highly sensitive systems. Nevertheless, they are still commonly used and are generally seen as compatible with standard security requirements.

| improve this answer | |
1

... you know any resources which can prove that this solution is a bad idea, and does such vulnerability has its name?

If the mentioned journeyID do not require authentication for the specific user which it's related to, then it's a vulnerability. Why? Well, if an attacker is able to perform a man-in-the-middle attack (and this is just one possibility, there are many others), only knowing the URLs is enough to get access to another user's data.

Similar vulnerabilities and attacks are described in the following OWASP pages:

However, as it's true for most scenarios (and I'll keep mentioning in my answers), for every scenario that a threat modelling assessment is created, some security risks can be accepted, and this is a choice of the application owner.

| improve this answer | |
0
  • So, if the ID is 32 alpha-numeric characters - it would take few millenia to crack. If 16 about quarter of millenia. You got the picture.

  • If someone have access to the logs\history - then anything can be extracted - cookies too - which means that is not the surface you would want to protect (unfeasible)

| improve this answer | |
  • In large datacenters, logs are ofter assumed to contain no sensitive data (passwords are commonly replaced by strings of stars (*)), so that they can be transmitted to a maintainer. With this use case, more care should be taken... – Serge Ballesta Jan 22 at 7:16
  • We're not talking here about cracking one password, it can happen that there are several thousands of tokens generated every day, which makes the chance of finding a combination that contains user data, much more likely. Also if the data were protected by i.e. password, then having access to log doesn't warranty access to user data. – LJ Wadowski Jan 22 at 10:19
  • LJ Wadowski Can you please elaborate the locations of logs that you stated are as a vulnerability? Cause judging by "browser history" I assumed that you were talking about local computer of a user. If that is the case, then again, that is not the responsibility of provider to harden. Regarding UniqueID - I've thought you are talking about dedicated attack. If you are talking about blanket type of attacks, then yes, it's vulnerable. A simple solutions is IMHO in tying sessionID to this UniqueID. Thanks for commenting btw. – Rashad Novruzov Jan 23 at 14:50
0

You should pass all parameters via POST so they won't appear in the url or browser history, you could hash the token then compare the two hashed just to prevent spoofing or MiTM attacks... and you couod also add a user id with the token so both values are compared... This way if an attacker has a token... He still needs to guess the user id it belongs to.

| improve this answer | |

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.