спокойный API .. безопасность сеанса

Предположим, приложение для заказа, пользователь «Бен» сможет перечислить конкретный заказ, выполнив

/заказ/1

теперь .. прежде чем сделать это, я аутентифицировал «Бена» (авторизация имени пользователя / пароля) и отправил имя пользователя в виде файла cookie (подписанного контрольной суммой sha1).

на каждый HTTP-запрос я получаю файл cookie, который говорит мне, что «Бент» все еще аутентифицирован, но кто может помешать ему выдать

/заказ/23

где заказ с id=23 не принадлежит "Бену".

поэтому я думаю, мне следует написать некоторую логику, чтобы убедиться, что заказ 23 действительно принадлежит «Бену» ... это лучшая практика или шаблон для такой ситуации?

Должен ли я использовать отдельный «функциональный первичный ключ» вместо последовательного идентификатора первичного ключа?


person Lance    schedule 12.08.2011    source источник
comment
ну .. я сам изучал это. это связано с повышением привилегий и описано в ссылка ... но я продолжаю исследовать   -  person Lance    schedule 13.08.2011
comment
также a4 в списке 10 лучших OWASP OWASP   -  person Lance    schedule 13.08.2011
comment
или ссылка   -  person Lance    schedule 13.08.2011


Ответы (1)


Я не вижу разумного естественного первичного ключа для порядка. Чтобы сделать его менее заметным, вы можете использовать UUID (довольно небольшой шанс случайно найти /orders/4886ed80-dd71-11e0-9572-0800200c9a66)...

НО это была бы безопасность по неизвестности. Даже если я не могу угадать UUID вашего заказа, я могу пронюхать ваш трафик и, если безопасность обеспечивается только непонятными URL-адресами, я смогу делать с ресурсом Order все, что захочу.

Это должно дать понять, что вы не можете пропустить аутентификацию в таком случае.

person aaimnr    schedule 12.09.2011