Другие способы защиты куки - PullRequest
2 голосов
/ 24 августа 2009

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

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

Какими хитроумными способами вы использовали для защиты ваших файлов cookie?

Ответы [ 4 ]

2 голосов
/ 24 августа 2009

Э-э, вы храните идентификатор пользователя в файле cookie и предоставляете пользователю доступ на основе этого значения? Вы просите неприятностей. Реализации данных на основе сеансов сервера существуют по уважительной причине: сохраните идентификатор сеанса в файле cookie и получите доступ к идентификатору пользователя из записи на сервере, где клиент не может изменить его.

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

1 голос
/ 24 августа 2009

Подписание файла cookie с помощью HMAC - вполне разумный способ сделать это. По сути, HMAC сворачивает в хэш секретный ключ, известный только вашему серверу, поэтому даже тот, кто знает алгоритм, не может сгенерировать HMAC, который будет признан действительным, не зная ключа. Простое использование простого старого хэша тривиально обходится, потому что злоумышленник может генерировать действительные хэши своих собственных данных, и вся «соль» в океане не сможет это исправить.

Даже если вы использовали идентификатор сеанса вместо хранения значимых значений, вам все равно нужно быть осторожным, чтобы злоумышленник не мог предсказать другой действительный идентификатор сеанса, и вместо этого отправил его вам, таким образом угоняя сеанс другого пользователя. Я полагаю, что на Hotmail действовал настоящий эксплойт, который сработал таким образом.

Шифрование cookie помогает вам только в том случае, если там есть что-то, что вы не хотите, чтобы пользователь видел. Хуже того, шифрование без HMAC дает ложное чувство безопасности, потому что файл cookie, который просто зашифрован, все еще уязвим для манипуляций с зашифрованным текстом для изменения частей открытого текста.

Итак, не просто хэшируйте, используйте HMAC!

1 голос
/ 24 августа 2009

При хешировании вы должны быть очень осторожны, если вы добавили соль, в противном случае определение подходящего хеша может быть тривиальным.

Таким образом, для защиты от несчастных случаев часто целесообразно также зашифровать cookie.

- редактировать

Вы также можете узнать о файлах cookie «HTTPOnly»: http://www.owasp.org/index.php/HTTPOnly

0 голосов
/ 24 августа 2009

На подкасте Security Now (я забыл, какой эпизод) Стив Гибсон говорит о том, чтобы сделать что-то подобное, и я думаю, что система, которую он рекомендовал, состояла в том, чтобы сделать содержимое cookie хорошим хешем, а затем сделать этот хеш ключом в вашем локальная база данных, где значение (я) - это вся информация, которую нужно хранить.

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