Basic Web Functionality - Security Question

[dealTek]

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=<?php echo $record->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=<?php echo $record->getField('item_id'); ?>&random=<?php echo $record->getField('randomnum); ?>

ANY BETTER SUGGESTIONS to lock things down?


--
Thanks,
Dave - DealTek
***@gmail.com
[db-14]

[Aziz Saleh]

Post by dealTek
Hi all,
- 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=<?php echo $record->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=<?php echo
$record->getField('item_id'); ?>&random=<?php echo
$record->getField('randomnum); ?>
ANY BETTER SUGGESTIONS to lock things down?
--
Thanks,
Dave - DealTek
[db-14]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Are those Id's owned (each user has a set of Ids) or accessible by all?

[Ashley Sheridan]

Post by dealTek

Post by dealTek
Hi all,
- 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

Post by dealTek
is something like: editpage.php?id=<?php echo

$record->getField('item_id');

Post by dealTek
?>
- now when you click to the edit page - it will do another query to

get

Post by dealTek
all the item details and display an edit form - etc.
Problem: In this case - anyone can simply change the url id=xxx to

any

Post by dealTek
other number and it will make the page search for another item

record.

Post by dealTek
Q: HOW can we lock this down so as to prevent the above scenario and

it is

Post by dealTek
a more secure system?
BTW: One method that we can use is to have a second field such as a

random

Post by dealTek
number field in the table data - then search for both - which people

will

Post by dealTek
have a hard time guessing like this link: editpage.php?id=<?php echo
$record->getField('item_id'); ?>&random=<?php echo
$record->getField('randomnum); ?>
ANY BETTER SUGGESTIONS to lock things down?
--
Thanks,
Dave - DealTek
[db-14]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Are those Id's owned (each user has a set of Ids) or accessible by all?

A guid generated as an md5 of the auto id and another field?

Thanks,
Ash

[Stuart Dallas]

Post by dealTek
Hi all,
- 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=<?php echo $record->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=<?php echo
$record->getField('item_id'); ?>&random=<?php echo
$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

[Bastien Koert]

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

Post by dealTek
Hi all,
- 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

[Ged Quayle]

That's your classic case for rbac or uac isn't it? If they have the right
to browse records then they should be able to, if they don't then they
should be locked out. At its most granular would be general user, with the
right to browse their own record, up to your equivalent of root with the
right to browse all.

[Tony Marston]

Post by dealTek
Hi all,
- 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=<?php echo $record->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=<?php echo
$record->getField('item_id'); ?>&random=<?php echo
$record->getField('randomnum); ?>
ANY BETTER SUGGESTIONS to lock things down?
--
Thanks,
Dave - DealTek
[db-14]

My solution is not simple, but it's bulletproof.

(1) In the list/browse screen I store an array of primary keys which is
indexed by the row number in the current screen.
(2) This array is stored in the session data.
(3) The hyperlink contains the index number to the array, not the primary
key.
(4) When the hyperlink is used the scrip which is run accesses the array to
convert the index number to a primary key.

This means that I *NEVER* expose any primary key values in any URLs.