Как создать cookie, который защищен от кражи и не может быть изменен пользователем / клиентом?

Question

Защита от кражи означает, что я могу обнаружить, что это происходит с другого IP-адреса клиента или по другому маршруту (например, когда клиент находится за прокси-сервером или чем-то еще).

Защита от несанкционированного доступа означает, что я могу обнаружить, что файл cookie недействителен и не отправлен сервером.

Answer 1

Cookie всегда должен быть криптографически безопасным псевдослучайным числом (CSPRNG) , которое также является криптографическим одноразовым номером или значением, которое используется только один раз.Это значение используется для доступа к информации о состоянии на стороне сервера.

Почему?Не имеет значения, если злоумышленник изменит значение, он все равно не сможет изменить состояние сеанса.

Как насчет шифрования куки?В области безопасности лучше всего избегать этой проблемы.Это неправильное использование криптографии, поскольку оно открывает дверь для атак, таких как недавняя атака ASP.NET Oracle CBC Padding .

Некоторые другие функции, которые нужно добавить:

«Безопасные куки» - ужасное имя, но это флаг, который заставляет куки всегда передаваться по HTTPS.Это гарантирует, что вы никогда не нарушите OWASP A9 .

«HTTPOnly Cookies» - это делает так, что JavaScript не может получить доступ к document.cookie, и делает куки более сложными для кражи.

Обязательно исправьте Session Riding aka CSRF .

Обязательно протестируйте свое приложение на XSS, используя Sitewatch Free Edition или Wapiti .Даже с файлами cookie HTTP только XSS можно использовать для обхода защиты CSRF на основе токенов и Referer.

Answer 2

Чтобы ответить на ваш вопрос: Вы не можете определить, был ли ваш файл cookie украден или скопирован. После того, как он покидает ваш сервер, вы не представляете, что с ним произошло - как вы могли?

Однако вы можете определить, не были ли изменены исходные данные cookie, которые вы использовали, с помощью алгоритма безопасного хеширования, например SHA-1 .

Алгоритм SHA-1 генерирует хэш-сигнатуру, которая изменяется (или статистически с большой вероятностью изменится), если изменяются данные, к которым он применяется. Поскольку вы генерируете хэш, используя не только данные, но и секрет Соль , , только вы можете сгенерировать правильную сигнатуру хеша для данного фрагмента данных. Если кто-то изменит ваши данные, он не сможет внести соответствующее изменение в хэш без значения Salt. Конечно, вы проверите все данные, которые возвращаются, чтобы убедиться, что хэш-подпись, которая идет с ней, является правильной. Это требует, чтобы вы добавили хеш-подпись в конец данных или какой-то аналогичный механизм для сохранения данных и хеш-подписи вместе.

Имейте в виду, что значение Соли необходимо держать в секрете.

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

Стоило бы взглянуть на ресурсы, доступные по адресу OWSAP . OWASP имеет ряд Top 10 приоритетных списков наиболее распространенных уязвимостей безопасности веб-приложений. Убедитесь, что вы знакомы с ними, чтобы не допускать ошибок, которые делали тысячи других.

Answer 3

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

1. Генерирует большое случайное число (ish) фиксированной длины.
2. Хеш число с солью.
3. Добавьте соленый хеш в конец случайного числа (от 1) и отправьте его клиенту.
4. Использовать SSL.
5. Чтобы проверить целостность, разделите поля, добавьте соль в первую часть, повторите хэш. Если хеш не совпадает со вторым полем, он был подделан.

Как я уже говорил, я не эксперт, но это кажется возможным.