0

So the user gets an email with an order someone just placed, and he receives a link with 2 parameters to confirm the order without necessarily being logged in into the application. The url will contains the order ID and a confirmation key which is randomly and unique, created when the order has been placed. e.g

http://shop.com/confirm-order/12345/ksjdjJsjjJHDHHS2773mhhd

Is there any security concerns by passing the order id and the confirmation key, taking the fact the user will not be logged in so checking for permission is out of the question?

My main concern is if an attacker starts to recreate the parameters randomly could he possibly get a guess on an order that hasn't been confirmed yet and confirm it by mistake or will those parameters help him hacking the database?

Thank you

lesandru
  • 839
  • 2
  • 11
  • 27
  • 1
    Why not just simply check if the `order id` matches the id of the user that is logged in and if not, just die out. Leaving it this way is definitely vulnerable, no question about it. – Ohgodwhy Sep 08 '14 at 18:34
  • 1
    if someone guesses your hash, then your hash was obviously way too weak/simple. – Marc B Sep 08 '14 at 18:35
  • If there is a unique and long enough string being passed (and well-done), it's doubtful that a hacker or anyone else will be able to guess, unless that person's computer's being tracked by a keypress tracker/trojan, and/or the person's Email has been compromised. There are too many possible circumstances at stake. – Funk Forty Niner Sep 08 '14 at 18:35
  • Thank you guys. I'll go with the login route, I just wanted to cut some time of my users so they confirm the orders much more easier even if some of them weren't logged in... – lesandru Sep 08 '14 at 18:43
  • You can encrypt the URL & decrypt it. – Zo Has Sep 09 '14 at 06:24

1 Answers1

0

The threat is not due to the fact that you are giving away the Order ID and the randomly generated string via email. But the concern is how you are handling the job, when someone clicks / or better uses that URL to go back to your server.

So how your code handles a random product ID and a random string, which may exist or not is the problem. From the information you have provided, it seems that there isn't any real chance of getting hacked. As you are not giving away (output) any table name or database values, rather you are taking the URL (as an input) and processing it internally.

What you should check is -
 Make sure that the ID and Random Strings coming to your server (from the email click or elsewhere by a hacker) are truly an ID and a random string, and not some PHP or SQL codes. So sanitize that input or use htmlentities.

But still it doesn't solve the problem of someone else confirming an order. As by random guessing, known as "brute-forcing" someone can guess a combination of ID and random string, which might accidentally confirm an order.
So in order to solve that, I would recommend you the following solutions -

  • Ask the user to login. A simple login won't really annoy the buyer, that too if you use a facebook or google login, or if not, a "keep me logged in" feature.
  • If you are still keen on skipping any login, generate more than 1 random strings, which will exponentially reduce the chance of someone guessing. Like http://example.com/order/12345?random1=blahblahblah&random2=blah2blah2.
Community
  • 1
  • 1
Chique
  • 735
  • 3
  • 15