Безопасно ли помещать данные в файлы cookie?

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

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

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

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

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

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

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

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

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

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

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

Шифрование достаточно хорошее, это не слабое звено.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ОБНОВЛЕНИЕ: наличие сеанса подразумевает наличие файла cookie (или, по крайней мере, уродливого URL-адреса), что возвращает нас к той же самой проблеме: его можно перехватить. Единственный способ избежать этого — добавить сквозное шифрование: HTTP+SSL = HTTPS. И если кто-то скажет: «О, но файлов cookie/сеансов должно быть достаточно, чтобы отпугнуть большинство людей», проверьте Огненная овца.

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

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

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

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

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

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

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

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

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

Шифрование файла cookie также создает проблему управления ключами. Например, когда вы меняете ключ шифрования, вы должны быть уверены, что «живые» сеансы со старым ключом не будут немедленно прерваны. Вы думали об управлении ключом шифрования, верно? Что происходит, когда администраторы уходят? Он скомпрометирован? и Т. Д.

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

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

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

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

HttpCookie c;
c.Secure = true;

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

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

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

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

Состояние просмотра