|
|
Posted by Peter Fox on 11/19/48 11:45
Following on from Gordon Burditt's message. . .
>>I use a number of approaches
>>(1) Instead of auto-incrementing ID use a 32 bit random number.
>>(Obviously you have the creation overhead of making sure you can't
>>retrieve the record before creating it to catch. the theoretical 1 in
>>24billion chance of a clash)
>>
>>This DOESNT solve your problem if any other IDs are available for
>>inspection. eg a selection table with click on button to delete
>>functionality because the other IDs can be harvested. AND WORSE if you
>>use this ID anywhere at all eg a table of click on button to _edit_
>>functionality the same thing applies.
>
>All of this is a very poor substitute for validating that the user
>in question has the authority to delete the record *AT THE TIME OF
>THE FORM SUBMISSION*. If the user with administrator authority
>always has the authority to delete *any* record, and a user without
>administrator authority cannot delete any record (even his own),
>there's nothing wrong with just using trivially-guessable record
>numbers. But you need to re-check his administrator status at the
>time of the form submission. He might have been fired between the
>form being sent (and possibly cached in a browser for a year) and
>submitting it.
>
>If the user can only delete *his own* records, then check, when he
>submits the form, that he still has the authority to delete it: he
>still owns it, his membership hasn't expired, he's still logged in
>as the same user, etc.
Sorry Gordon, I should have made it clear that each page checks the user
as a matter of course. It didn't occur to me that some people don't do
this.
By the way : It _is_ a good idea to use big random unguessable numbers
for IDs because (a) it *obviously* makes the cracking job harder and (b)
even if you hit a valid number you have no idea whose it would be. Thus
it is a deterrent. Also (probably with more bits in the random number)
it is _essential_ where the user cannot be validated. For example
"Thank you for your custom...To view the progress of your order go to
www..../orders.php?OID=123454345434544"
>>(2) Keep track of page visiting history in the session and boot out
>>people coming back via bookmarks without going through the right path.
>>Here's the outline:
>> In page 1
>> $_SESSION['LastPage']='Page1';
>> At top of page 2 :
>> if($_SESSION['LastPage']!='Page1'){...
>Unless you store which records the last page offered him the chance
>to delete, and that it would still offer him the chance to delete
>the record that he is trying to delete, this check is ineffective
>and spoofable.
There are sometimes cases where persistent state in the database isn't
comprehensive enough. To take a simple example: Your delete page might
be preceded by a warning page about the dangers of deleting "Are you
sure" etc. In which case you code :
$_SESSION['DeleteWarningDone']=1;
in the warning page then at the top of the delete page
if($_SESSION['DeleteWarningDone']==1){...
(But why bother with specific code like this when you have standard page
tracking functions.)
Instead of delete, think of add (or submit order). Checking somebody's
authority is fine, but you need an idempotent method so that duplicate
orders aren't created by mistake.
--
PETER FOX Not the same since the submarine business went under
peterfox@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>
Navigation:
[Reply to this message]
|