Уязвимость с помощью шифрования файлов cookie для аутентификации (подкаст переполнения стека) - PullRequest
3 голосов
/ 25 мая 2009

Я слушал подкаст stackoverflow (я думаю, что это был эпизод 52). Джефф говорил о том, как они придумали какой-то механизм авторизации, где они шифровали учетные данные в куки-файле, который они отправляли клиенту. Видимо, кто-то, кого знает Джефф, смог найти дыру в этом и смог войти с любым идентификатором, который он хотел.

Он не вдавался в подробности подкаста, но это вызвало у меня интерес. Я один из тех людей, которые предположили бы, что если вы зашифруете свою информацию cookie, то они не смогут быть уязвимыми. Кто-нибудь слушал этот эпизод и / или знал, какую возможную дыру вы бы открыли этим решением?

спасибо NCAGE

Ответы [ 3 ]

2 голосов
/ 13 июня 2009

В моей реализации я использую случайную строку (16 байт), за которой следует важная информация. Все это затем шифруется с помощью AES с использованием циклического объединения блоков.

Это позволяет избежать необходимости хранить информацию в состоянии сеанса или получать ее из базы данных. В любом случае, это не сайт с очень высоким уровнем безопасности, но я думаю, что добавление случайной строки и CBC немного улучшит безопасность.

1 голос
/ 13 июня 2009

Может быть, вы можете проверить это сообщение в блоге , оно объясняет многое, о чем вы даже не подумали, и почему шифрование не является аутентификацией. На самом деле, вам не следует приходить с собственным решением, а пытаться использовать проверенное.

1 голос
/ 11 июня 2009

Если вы передаете зашифрованную информацию клиенту, то всегда есть вероятность, что он сможет ее расшифровать (возможно, из-за недостатков в используемом алгоритме шифрования или из-за недостатка соли, приводящей к атакам анализа или различным другим возможные проблемы).

Таким образом, вы не должны отправлять клиенту информацию, которую вы можете избежать .

В идеале вы просто посылаете им случайный идентификатор, который вы используете для поиска в таблице сеансов, и сохраняете все данные на стороне сервера . Тогда «единственный» способ, которым пользователь может стать другим, - угадать (очень длинный и случайный) идентификатор сеанса.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...