Hey guys,
I've used both the hash of something as a unique id and a generated number ( this approach suffered badly from race conditions ).
But I do have to agree with Stuart about the need for it if the users can edit all the records. If they can't , then add in a check for the record owner when displaying the link.
Bastien
Sent from Acompli
On Mon, Aug 11, 2014 at 3:24 PM -0700, "Stuart Dallas" <stuart@xxxxxxxx> wrote:
On 11 August 2014 21:02, dealTek wrote:
> Hi all,
>
> Assuming the following:
>
>
> - in your database you are using serial numeric ID's
> - with php you do a search query to get a number of items - then you
> display the results in a loop on a web page list view.
> - then on each row you have an edit button for that item. Here, the link
> is something like: editpage.php?id=getField('item_id');
> ?>
> - now when you click to the edit page - it will do another query to get
> all the item details and display an edit form - etc.
>
>
> Problem: In this case - anyone can simply change the url id=xxx to any
> other number and it will make the page search for another item record.
>
>
> Q: HOW can we lock this down so as to prevent the above scenario and it is
> a more secure system?
>
> BTW: One method that we can use is to have a second field such as a random
> number field in the table data - then search for both - which people will
> have a hard time guessing like this link: editpage.php?id= $record->getField('item_id'); ?>&random= $record->getField('randomnum); ?>
>
> ANY BETTER SUGGESTIONS to lock things down?
>
Is there a reason users can't edit other items? How is that access
controlled? Why doesn't the edit page check that they have access to edit
the item before showing th edit form? If access is restricted, said access
should be checked whenever a user attempts to access data. Security should
be enforced whenever data is accessed, not just when it is listed.
If that's not the case and any user can edit any item, why the need to stop
them from editing the URL to display the edit form for other items?
If you still need to prevent it via the URL (tho I can't see a reason why
you'd need to) you could either add a random string field to the table and
also pass that in the URL, or a better solution is to not use simple
ascending numbers as IDs. In the past I've use uniqid() to generate IDs
which will generate an ascending alphanumeric ID (be careful in a
multi-server environment), or an md5()/sha1() of uniqid().gethostname()
(note that gethostname() is v5.3+ only).
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
