0

assume an ordering application, user "Ben" would be able to list a specific order by issuing

/order/1

now .. before doing that i've authenticated "Ben" (username/password auth) and sent the username as a cookie (signed with a sha1 checksum).

on each http request i receive the cookie that tells me "Bent" is still authenticated, but who can stop him from issuing

/order/23

where order with id=23 does not belong to "Ben".

so i guess i should write some logic to make sure that order 23 actually belongs to "Ben" ... is that a best practice or pattern for this kind of situation ?

should i use a separate "functional primary key", instead of a serial primary key id ?

Lance
  • 1
  • 2
  • well .. i've been looking into it myself. it has to do with privilege escalation and is covered at [link](http://www.lulu.com/product/download/owasp-ruby-on-rails-security-guide/4489819) ... but i keep researching – Lance Aug 12 '11 at 23:53
  • also a4 in owasp top 10 list [OWASP](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) – Lance Aug 13 '11 at 00:29
  • or [link](http://stackoverflow.com/questions/6382900/playframework-owasp-top-10) – Lance Aug 13 '11 at 01:45

1 Answers1

0

I don't see any reasonable natural primary key for order. To make it less discoverable you could use UUID (pretty small chance to accidentally find /orders/4886ed80-dd71-11e0-9572-0800200c9a66 )...

BUT it would be security by obscurity. Even if it's impossible for me to guess the UUID of your order, I can sniff your traffic and, if the security is only provided through obscure URLs, I will be able to do whatever I want with the Order resource.

That should make it clear that you cannot skip authentication in such case.

aaimnr
  • 1,646
  • 1
  • 17
  • 31