Good security methods depend on understanding
(a) What you're protecting
(b) The threat
/then/ you can judge which tools to use.
(A really excellent general book on this subject is
Security Engineering by Ross Anderson. Pub. Wiley)
Here are two bad things:
1 : customer number 45 looks at customer number 46's data
2 : customer 45 bookmarks or has sent to them a URL in an email or
passes a URL to somebody else which can be used out of the intended
context. (Eg an email: "this is your order reference number to view
progress click go to http:....?orderref=12345")
These are slightly different things.
If the only 'way in' to our web site is via URL line (ie not using
cookies) then this means any hacker will have to fiddle with the URL
request. So bad thing 1 can now be re-cast as "How can we make it
difficult for a hacker to misuse the command line to make false
requests" and bad thing 2 can be re-cast as "how can we detect and
manage the context of URL requests".
Are random numbers (difficult to guess) for customer IDs enough?
No. A page might list say employees with a link for details:
<a href="publicdetails.php?empno=1423527365">Fred Smith</a>
<a href="publicdetails.php?empno=5276928065">Sally Jones</a>
So we MUST at the /very least/ disguise the numbers so they can't be
re-used in privatedetails.php. (You will understand that in a situation
where people can look at their own record they may be able to change the
URL to one of the other numbers quite legitimately used for public
purposes.)
A /simple/ way is to have a _reversible_ obfuscation function which
obfuscates differently according to (say) the page on which it is used.
This can be used to prevent casual hacking but is more security by
obscurity than proper lock-outs. (But you can detect experimental
efforts to fiddle as when the de-obfuscation fails to produce a valid
result you can be alerted to some fiddling. This might be acceptable in
a closed user community context.)
A more robust and more complex[1] method is to generate a big random
number every time you want a URL response and use that as a key to the
real response kept in a database or session.
The HTML looks the same
<a href="publicdetails.php?resp=1423527365">Fred Smith</a>
but now you have done (simplifying) something like
$responsearray['1423527365']='empno=66&action=payrise';
What you can do with this depends firstly on the persistence of
$responsearray and secondly on the persistence of each record. For
example here are some things you can do if you're passing URLs in emails
* expire after a given time
* class the user as 'logged in' or take them to their own login with
user name and other details already present just waiting for password
* if one response from a multiple choice email (eg click on this link to
confirm or this one to cancel) then not only remove the one chosen but
also its sibling.
Of course in the above I've only covered one aspect of user input issues
and even then only at a top level but I hope it gives you something to
think about.
[1] It was tricky to write a class to do the job in detail but of
course those details are hidden in normal use. I could share it if
people are interested but (because I've never actually used it in anger,
and because it is tailored to my ways of working) it would be 100%
unsupported and not much use to those that want instant gratification.
--
PETER FOX Not the same since the deckchair business folded
pe******@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>