|
|
Posted by The Natural Philosopher on 09/28/45 12:01
Harris Kosmidhs wrote:
> Though I program in php for some years, I started thinking a lot about
> the security in my php scripts.
>
> When I add/insert/delete to a form I usually have a hidden input box
> with the (auto-increment id) of the record I want to update. So when I
> UPDATE I put where id=intval($id).
> This is quite a security risk but these forms are administration forms,
> assuming that the administrator won't edit hidden values and mess with
> it's data.
>
> But what happens if this is a public form? How can you avoid having the
> id in a hidden (and easily changed) form field? What techniques do
> exist? I have some in mind as a workaround (like puting id in $_SESSION)
> but I would like to hear other opinions.
>
> Thanks
well I dont see any real way around this. There isn't any mechanism that
couldn't be busted. The question is why anyone would want to.
Assuming they do, you could validate the data so that if it is an
update, at least *some* of it matches what it was...
Theres a few other things you might do, like storing in the database a
field that is 'last IP address that updated this' and at least flagging
an update from a different IP address..
But there might be many reasons why that would not be valid in perfectly
innocent cases.
The tendency with all databases is to avoid the updates altogether. Its
more usual to cancel a transaction and start a new one, than modify teh
existing data.
I have a more or less general rule.
Only the system admin under extreme duress ever deletes data.
Only the internal admins ever update it.
'Users' only add to it.
I.e. take a shopping cart. The users creates a new 'cart'
Then s/he creates order lines to add to that cart.
Then he closes the transaction, or abandons it. Thats is the OINLY
update to te master transaction record he can do. Typically HE dooesn't
do it either. Paypal etc will be giving the thumbs up to it.
Even if he modifies his numbers, you can do that by cancelling the
original orderlines and adding new ones. So the ONLY data update that
can be done by the user is to set a cancellation flag. Every other
amendment to e.g,. an order, is in fact a additional orderline
associated with it, or cancellation of an existing one. ONLY permitted
on 'open' transactions.
So there is a full audit trail. If he tries to add to someone else's
transaction, it won't work unless its 'open' and that means that someone
has to pay to close it, and they will probably notices if a million
quids worth of gold bars have been added to it. ;-)
This isn't about php or web or anything per se, its about a durable
approach to database design. You simply do not allow a low grade class
of users (data entry really) to do anything more than they have to via
the forms they get provided with. And even though it means you have a
load of redundant data on your disks, you will bless it if you ever need
to unpick an audit trail back to find out where a million gold bars went
missing.
The prisons are full of people who were given more tools than they
needed to do their jobs..and discovered what else they would do.
Don't give them the tools, because you were too lazy to code round the
need to.
You may decide that e.g. you will allow users to change their names and
addresses and passwords online. Fair enough. But thats ALL they should
be allowed to do. With a special form. And if that has implications of
malice or fraud that may result, I strongly suggest you create a NEW
customer record and flag the old as 'invalid' in case the original user
comes back and wants to know WTF is going on.
This implies that the user cannot magically update data that he hasn't
got acess to.
I.e. too simply load a whole record into hidden variables is bollocks.
You load the ID and what he is allowed to update, alone. If you are
really paaraanoid, nd your form needs to cter for higher lecvel ccess on
conditionl basis, you can read the record data out, and use that to
reinsert with except in the specific cases that user is allowed to have
access to. That is an implementation detail.
You COULD even use SQL usernames to have granular access to parts of te
data base. I do;t like that personally, as I prefer to write a form for
a specific single purpose, and let that be my control mechanism.
Navigation:
[Reply to this message]
|