Обеспечивает ли безопасность данных в файлах cookie?

Ответ 1

Помимо шифрования файлов cookie, вы также должны использовать вращающийся токен для предотвращения повторных атак.

Идея состоит в том, что зашифрованный файл cookie содержит некоторое значение, которое можно сравнить с известным значением на сервере. Если данные совпадают, запрос выполняется успешно. Если данные не совпадают, вы испытываете повторную атаку и должны убивать сеанс.

UPDATE
Один из комментариев спросил, хочу ли я сохранить значение в файле cookie. Ответ - да. ENTIRE cookie должен быть зашифрован, что можно сделать автоматически с помощью HttpModule. Внутри зашифрованного файла cookie находится любая ваша нормальная информация + изменяющийся токен.

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

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

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

ОБНОВЛЕНИЕ 2
Я пытался выяснить, насколько это лучше или хуже, чем сохранение измененного значения, хранящегося в сеансе. Вывод, который я пришел, заключается в том, что сохранение вращающегося значения в сеансе на веб-сервере абсолютно не способствует предотвращению повторных атак и поэтому менее безопасно, чем помещение этого значения в файл cookie.

Рассмотрим этот сценарий. Браузер делает запрос. Сервер просматривает идентификатор сеанса и вытягивает объекты сеанса, затем выполняется работа, и ответ отправляется обратно в браузер. Тем временем BlackHat Bob записал транзакцию.

Затем Боб отправляет тот же запрос (включая идентификатор сеанса) на сервер. На этом этапе сервер не знает, что это запрос от злоумышленника. Вы не можете использовать IP-адрес, который может измениться из-за использования прокси-сервера, вы не можете использовать отпечаток пальца браузера, поскольку вся эта информация была бы записана в первоначальном обмене. Кроме того, учитывая, что сеансы обычно хороши как минимум 30 минут, а иногда и намного дольше, злоумышленник имеет довольно хорошее окно для работы.

Итак, что бы ни случилось, чтобы предотвратить повтор, вам нужно отправить изменяющийся токен в браузер после каждого запроса.

Теперь это оставляет нам вопрос о том, хранить ли такие значения, как идентификатор пользователя в зашифрованном файле cookie, или хранить его на стороне сервера в переменной сеанса. С сессией у вас есть проблемы, такие как более высокая память и использование процессора, а также потенциальные проблемы с балансировкой нагрузки и т.д. В файлах cookie у вас есть некоторый объем данных, размер которого меньше 4 КБ, и, соответственно, делается в диапазоне 1 кБ или меньше, который добавляется для каждого запроса. Я думаю, это будет сводиться к тому, что вы предпочтете добавить больше/больше серверов и внутреннее сетевое оборудование для обработки запросов (сеансов) или заплатить за чуть больший интернет-канал (cookie).

Ответ 2

Шифрование достаточно хорошее, что не слабая ссылка.

Слабая связь заключается в том, что значение cookie может быть перехвачено, а кто-то другой может олицетворять пользователя.

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

Ответ 3

Название вашего вопроса действительно не соответствует тому, что вы просите. Здесь вы можете задать две разные вещи.

1. Есть ли безопасный способ хранения данных в файле cookie?

Ответ: да. Чтобы безопасно хранить данные в файле cookie, вам необходимо зашифровать данные, которые вы хотите сохранить, и подписать зашифрованные данные. Шифрование не позволяет злоумышленникам читать данные, а подписание не позволяет злоумышленникам изменять данные. Это обеспечит целостность данных. Вы можете использовать этот метод для хранения данных о пользователе, которого хотите сохранить в сети (их адрес электронной почты, дата рождения и т.д.). Примечание. Безопасное хранение данных в файле cookie не является безопасным способом аутентификации пользователя! Если вы сохранили идентификатор пользователя в подписанном и зашифрованном файле cookie, ничто не мешает злоумышленнику украсть весь файл cookie и отправить его обратно на сервер. Нет никакого способа узнать, был ли cookie аутентификации из того же браузера, где пользователь вводил свое имя пользователя и пароль. Это приводит нас к второму вопросу (тот, который вы действительно спрашивали)...

2. Есть ли безопасный способ аутентификации пользователя с файлом cookie?

Да. Чтобы обеспечить надежную аутентификацию пользователя, вы должны объединить методы из вопроса 1 с SSL (https). SSL гарантирует, что только браузер сможет получить доступ к файлу cookie аутентификации (подписанный зашифрованный файл cookie с идентификатором пользователя в нем). Это означает, что ваш процесс регистрации (принятие имени пользователя и пароля, а также настройка файла cookie аутентификации) должен происходить через SSL. Вы также должны установить для свойства HttpCookie.Secure значение true, когда вы устанавливаете cookie аутентификации на сервере. Это говорит браузеру включать этот файл cookie только при обращении к вашему сайту через SSL. Вы также должны указать время истечения срока действия в зашифрованном файле cookie auth, чтобы защитить кого-то, забывшего выйти из вашего сайта, находясь в библиотеке. Побочным эффектом этого подхода является то, что только страницы вашего сайта, которые являются SSL, смогут аутентифицировать пользователя. Что вызывает третий вопрос...

3. Как вы безопасно аутентифицируете пользователя без использования SSL?

Нет. Но у вас есть варианты. Одна из стратегий состоит в том, чтобы создать два файла cookie авторизации при входе в систему, один обычный файл cookie и один ssl-only (оба зашифрованы и подписаны, хотя). При выполнении конфиденциальных операций с именем пользователя требуется, чтобы страница была в SSL и использовала только cookie с поддержкой SSL. При выполнении нечувствительных операций (например, просмотр магазина, настроенного на основе страны, в которой находится их учетная запись), вы можете использовать обычный файл cookie. Другой вариант состоит в том, чтобы разделить страницу так, чтобы информация, требующая знать, кто является пользователем, получает асинхронный доступ через AJAX или json. Например: вы возвращаете всю страницу блога по http, а затем выполняете запрос SSL AJAX, чтобы получить имя текущего пользователя, адрес электронной почты, профиль pic и т.д. Мы используем оба этих метода на веб-сайте, над которым я работаю.

Я знаю, что этот вопрос задавали почти год назад. Я пишу это ради потомков.: -)

Ответ 4

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

В примере хранения идентификатора пользователя выберите то, что вряд ли будет использоваться против вашей системы. Для идентификатора пользователя используйте указатель, а не вероятное числовое значение, которое PK в таблице базы данных. Руководство не будет легко изменено, чтобы успешно угадать другого пользователя во время атаки на вашу систему.

Как только пользователь будет идентифицирован или аутентифицирован, перейдите и сохраните объект пользователя или ключевые свойства в Session.

Ответ 5

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

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

edit: Шифрование файлов cookie привело к атаке атак ASP.NET для атак. Этого следует избегать вместе, используя криптографический Nonce. Как я уже сказал, это грубое злоупотребление криптографией.

Ответ 6

Для вашего конкретного сценария (идентификатор пользователя) короткий ответ НЕТ!

Для длинного ответа представьте этот гипотетический сценарий:

• Перейдите к stackoverflow.com;
• Заполните свое имя пользователя/пароль и отправьте форму;
• Сервер отправляет вам файл cookie, содержащий ваш идентификатор пользователя, который будет использоваться для идентификации вас при следующих запросах;
• Поскольку ваше соединение не было безопасным (HTTPS), плохой парень понюхал его и захватил куки.
• Плохой парень получает доступ к вашей учетной записи, потому что сервер не хранит, скажем, ваш IP-адрес и, следовательно, не может отличить вашу машину от плохого парня.

Все еще в этом сценарии, представьте, что сервер сохранил ваш IP-адрес, но вы находитесь в корпоративной локальной сети, а ваш внешний IP-адрес аналогичен другим 100 машинам. Представьте, что кто-то, у кого есть доступ к одной из этих машин, скопировал ваш файл cookie. У тебя это уже есть, верно?: -)

Мой совет: разместить конфиденциальную информацию о сеансе HTTP.

UPDATE:, имеющий сеанс, подразумевает файл cookie (или, по крайней мере, уродливый URL), что возвращает нас к той же самой проблеме: его можно захватить. Единственный способ избежать этого - добавить сквозное шифрование: HTTP + SSL = HTTPS. И если кто-то говорит "о, но cookie/сеансов должно быть достаточно, чтобы отбить большинство людей", проверьте Firesheep.

Ответ 7

Это хорошо (не здорово, но не так) с точки зрения безопасности. С точки зрения производительности, однако, это то, чего вы хотите избежать.

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

Лучший (общий) подход состоит в том, чтобы просто сохранить отдельный токен в cookie, который вы используете в качестве ключа для поиска базы данных для информации. Запросы к базе данных также относительно медленны (по сравнению с информацией, уже имеющейся в памяти или в запросе), но поиск в основном ключе, как это, неплохо, и это все же лучше, чем отправка данных, возможно, четверть пути по всему миру на каждом запрос. Это также лучше для обеспечения безопасности, поскольку оно позволяет хранить данные с пользовательской машины и от провода как можно больше. Этот токен не должен быть чем-то вроде userid из вашего вопроса, а скорее чем-то более недолговечным — ключ, используемый для индексации и скрытия больших блоков данных, одним из которых является ваш идентификатор пользователя.

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

Ответ 8

Использование, которое вы ищете, - это точная цель для хранения информации в билете Forms Auth.

Ответ 9

Нет. Было показано, что Атака оскорбления атак, что получение данных шифрования (CBC) может быть опасным из-за утечки ошибок.

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

Ответ 10

Шифрование значения userid в файле cookie только не позволяет пользователю узнать, что это за значение. Это не

• предотвратить воспроизведение cookie (используйте SSL для предотвращать перехват злоумышленника файл cookie-жертвы)
• предотвратить вмешательство (злоумышленник может все еще слепо перевернуть бит в кодированном файле cookie с вероятность того, что он будет декодироваться до действительного userid, используйте HMAC для предотвращения этого)
• полностью запрещает пользователю получать дешифрованное значение (пользователь может перетащить значение вне линии, использовать сильный ключ шифрования, чтобы сделать успех менее вероятным)

Шифрование файла cookie также вводит проблему управления ключами. Например, когда вы вращаете ключ шифрования, вы должны убедиться, что "живые" сеансы со старым ключом не будут немедленно терпеть неудачу. Вы думали об управлении ключом шифрования, правильно? Что происходит, когда администраторы уходят? Это скомпрометировано? и др.

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

Объект сеанса, вероятно, будет намного проще и безопаснее для вашей заявленной проблемы.

Ответ 11

Чтобы обеспечить надлежащую защиту файлов cookie, вы должны убедиться, что вы указали схему безопасного шифрования/хэширования (обычно в файле web.config), установив свойство machineKey validation = "SHA1" (I используйте SHA1, но при необходимости вы можете заменить его другим поставщиком). Затем убедитесь, что у ваших форм auth есть атрибут защита = "Все" , чтобы файл cookie был хэширован и зашифрован. Неотказание и защита данных, все в одном:)

ASP.NET будет обрабатывать шифрование/дешифрование [EDIT: только файл cookie cookie!] cookie для вас, хотя для пользовательских куки файлов вы можете использовать метод FormsAuthentication.Encrypt(...) поэтому просто убедитесь, что вы не отправляете UserId через другой файл cleartext, например, запрос.

Ответ 12

HttpCookie c;
c.Secure = true;

Очевидно, что это работает только при передаче через SSL, но этот параметр указывает браузеру не отправлять cookie, если соединение не является SSL, таким образом предотвращая перехват с помощью атак типа "человек в середине". Если вы не используете безопасное соединение, данные в файле cookie полностью видны любому, кто пассивно обнюхивает соединение. Это, кстати, не так маловероятно, как вы думаете, учитывая популярность публичного Wi-Fi.

Ответ 13

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

Файл cookie может быть ответственным, если он находится на клиентской машине. Просмотрите кражу печенья, подделку подпроса, просьбу о замешательстве.

Ответ 14

Ограничения для файлов cookie: размер, может быть отключен и угроза безопасности (фальсификация). Конечно, если вы зашифруете файл cookie, может быть удар по производительности. Сессия и Viewstate были бы хорошей альтернативой. Если вы хотите, чтобы он был сохранен на стороне клиента, viewstate было бы лучше. Вы можете зашифровать строку userid и сохранить в viewstate. Сессия будет лучшим вариантом. Если ваши вызовы базы данных неактивны, рассмотрите кеширование

Viewstate