Как можно защитить ASP.NET или ASP.NET MVC от связанных атак домена cookie?

Ответ 1

Связанные с каналом файлы cookie

Следующий предлагаемый RFC поступает от сотрудника Google и описывает способ использования Клиентами самозаверяющего сертификата браузера (что не требует путать "всплывающее окно" для конечного пользователя), которое также может адресовать проблему безопасности cookie, известную как "Связанные файлы cookie домена"

Ниже следует выдержка из http://www.browserauth.net/, часть RFC, некоторые интересные комментарии и некоторые критические замечания по этому расширению.

Обзор связанных с каналами файлов cookie

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

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

Связывание каналов

До сервера нужно решить, следует ли привязывать файлы cookie к каналам TLS. Если клиент не поддерживает TLS-OBC, или если файл cookie, который он собирается установить, будет использоваться для разных origin, тогда сервер не будет привязывать канал к файлу cookie. Если он решит связать канал с файлом cookie, он должен связать файл cookie с открытым ключом клиента. Это похожее на RFC 5929,, но вместо клиента данные привязки к общедоступному ключу сервера, в этом случае сервер будет связывать данные (cookie) с открытым ключом клиента. Сервер может сделать это либо путем простого хранения в бэкэнд-базе данных факта, что определенный HTTP-сеанс должен быть аутентифицирован с помощью определенного открытого ключа клиента, либо он может использовать подходящую криптографию для кодирования в самом файле cookie, который является публичным клиентом TLS ключ, к которому прикреплен файл cookie.

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

Продолжение следует... http://www.browserauth.net/channel-bound-cookies

RFC Snip

TLS Origin-Bound Certificates RFC Draft

(Извлечение)

4.3. Укрепление Cookie

Один способ TLS-OBC можно использовать для усиления cookie-based аутентификация осуществляется путем "привязки" файлов cookie к привязке к началу сертификат. Сервер при выпуске файла cookie для HTTP сеанс будет связывать сертификат, связанный с исходным кодом клиента, с сеанс (либо путем кодирования информации о сертификате незаменимо в файле cookie или путем сопоставления сертификата с сеанс cookie с помощью других средств). Таким образом, если и когда cookie получает кражу у клиента, его нельзя использовать над TLS-соединение, инициированное другим клиентом - вором cookie также пришлось бы украсть секретный ключ, связанный с сертификат, связанный с исходным кодом клиента, задача значительно сложнее особенно когда мы предполагаем существование надежной платформы Модуль или другой безопасный элемент, который может хранить приватный ключ с привязкой к исходным ссылкам.

Дополнительный комментарий от [email protected]

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

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

Итак, скажем, приложение app.heroku.com устанавливает (cookie-bound) cookie в моем браузере для домена .heroku.com и что на сайте attacker.heroku.com есть атакующий. Одна атака, о которой мы можем беспокоиться, заключается в том, что злоумышленник просто собирает cookie.heroku.com из моего браузера, заманивая меня на атакующий .heroku.com. Однако они не смогут использовать cookie, потому что cookie привязан к каналу к моему сертификату клиента браузера, а не к сертификату клиента злоумышленника.

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

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

Критика от [email protected]

Существует ряд проблем, которые необходимо учитывать для TLS-OBC; Я расскажу вам пару, о которых я знаю.

• Некоторая логика установления связи SSL может потребоваться немного изменить; см. https://bugzilla.mozilla.org/show_bug.cgi?id=681839 для технического обсуждения.

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

• Можно предложить одно предложение о том, как № 2 можно найти здесь: http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts

• С SPDY происходят сложные взаимодействия. Для этого будут доступны обновления на browserauth.net.

Ответ 2

Основные моменты

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

Ответ на

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

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

<configuration>
    <system.web>
      <authorization>
        <deny users="*" />
      </authorization>
    </system.web>
</configuration>

relative: Я был взломан. Файл Evil aspx загружен под названием AspxSpy. Они все еще пытаются. Помогите мне поймать их!

Кража файлов cookie

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

• Cookie
• Идентификатор браузера
• Ip, включая прокси и forward ips.
• Браузер имеет разрешение javascript (или нет).
• Прямой запрос пароля.
• Другой файл, хранящийся на клиенте.

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

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

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

Итак, мы делаем то, что мы подключаем информацию cookie + ip + browser id + javascript для входа в систему, и если кто-либо из них изменится, мы больше не будем ему доверять, пока вы не войдете снова.

Cookies

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

Итак, если один из этих файлов cookie не существует или соединение не соответствует, то у пользователя снова нет разрешения и ему необходимо снова войти в систему (с предупреждением)

relative: Может ли какой-нибудь хакер украсть файл cookie у пользователя и войти в систему с этим именем на веб-сайте?

Идея объединить файлы cookie. С этой идеей я соединяю cookie сеанса с cookie аутентификации.

Если все сбой

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

• Создайте новую учетную запись администратора.
• Загрузите файл для запуска в качестве браузера и исполняемого файла.

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

Итак, для редких действий, таких как "Новый пользователь из backoffice", измените привилегию пользователей, удалите пользователя и т.д., нам нужно запрашивать второй пароль каждый раз, когда знает только администратор.

Итак, второй пароль - это окончательная проблема.

Одна заключительная идея

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

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

Я - кое-какие возможные места, но не испытал или не попробовал их в реальной жизни. Так что это некоторые помещены.

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

Итак, это мои идеи... любой критик, или решение (для того, как хранить небольшую информацию на клиенте, кроме cookie), приветствуется.

Реализация

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

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

Например, мы можем установить cookie с хешем (Ip + BrowserID) и проверить, много ли это или нет.

Оповещения - журнал

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

Пользователю

• Последние 10 входных данных (IP, DateTime, Успех или нет)
• Отправить электронное письмо от пользователя о некоторых действиях (для сайтов с высокой степенью защиты), таких как вход в систему, выход из системы, критические действия.

Администратору.

• Запишите и покажите какой-либо сбой соединения по четырем параметрам Cookie + IP + BroserID + Javascript Enable). Чем больше сбоев за короткое время, тем больше внимания требуется.
• Проверить наличие ошибки.
• Проверьте, что страница читается от пользователя с отключением (или сохранением) cookie, а javascript отключен, потому что это то, как сканер идентифицирован по моему опыту.

Ответ 3

Исправить RFC

Основная проблема здесь заключается в том, что любой хост может писать cookie, который может быть перезаписан любым другим хостом в том же домене. Что делать, если есть способ записать значение клиенту, которое абсолютно не может быть перезаписано каким-либо другим хостом? Я не нашел ничего подобного, также автоматически включается в заголовок HTTP (например, cookie).

Вот три решения, которые могут работать, хотя мне нравится решение 2 или # 3, если браузеры правильно его реализуют.

Решение 1: Добавить дополнительную информацию при загрузке файлов cookie на сервер

Когда клиент отправляет файлы cookie на сервер, также включается домен отправленного файла cookie. Затем сервер знает, какой домен и путь искать. Это означает, что клиент добавляет новый HTTP-заголовок Cookie-Details по каждому запросу:

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: name=value; name2=value2
Cookie-Details: name="value":"domain":"path":"IsSecure":"IsHTTPOnly"; name2="value2":"domain2":"path2":"IsSecure":"IsHTTPOnly"
Accept: */*

Затем сервер может игнорировать поле сведений или предпочитает его над тем, который не предоставляет подробностей. Причина, по которой я включил поле "значение" в разделе сведений, заключается в том, что сервер не сможет определить разницу между двумя файлами cookie, которые имеют домен, установленный в example.com и secure.example.com, если оба файла cookie имеют одинаковое имя. Большинство браузеров будут отправлять значения в произвольном порядке.

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

Решение 2: Расширение HTML5 LocalStorage, чтобы данные (необязательно) были автоматически вставлены в заголовок HTTP

Если мы могли бы расширить HTML5 LocalStorage, чтобы разрешить данные Secure/HTTPOnly, мы можем имитировать то, что сделано в решении № 1 выше, но имеют изменения, обусловленные рабочей группой HTML5 LocalStorage W3C

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

Решение 3 "Проверка файлов cookie"

• Пользователь посещает веб-приложение, в котором включен этот "специальный" режим проверки.
• В ответе HTTP некоторые файлы cookie отправляются в браузер. Файлы cookie могут быть только HTTP, Secure,... anything)
• Рядом с куки файлами cookie отправляется другой заголовок: Set-CookieValidationHash. Он содержит массив JSON из хешированных файлов cookie SHA-256 и значений и указывает истечение значения
• Затем браузер логически связывает этот заголовок с файлами cookie со следующим поведением
  • Этот заголовок помещается в "Cookie Validation Jar", который может быть написан только одним DNS-доменом и областью DNS
• Этот заголовок непрозрачен для клиента и возвращается на сервер при каждом запросе HTTP (например, в файле cookie).
• Сервер будет использовать это поле для проверки отправленных файлов cookie и выдает ошибку (или что-то еще), если сбой контрольной суммы.

Ответ 4

Источник: http://www.w2spconf.com/2011/papers/session-integrity.pdf

5.2. Целостность через пользовательские заголовки

Вместо защиты файлов cookie мы можем добиться целостности сеанса путем выбора нового метода хранения и передачи сеанса государство. Хотя это можно сделать с помощью специальных плагинов браузера как Flash, мы предпочли бы выбрать дизайн с наименьшим количеством зависимостей, поэтому мы сосредоточимся только на базовых инструментах HTTP. Основная форма HTTP-запроса имеет очень мало мест, которые подходят для отправки данных с целостностью. Данные в URL-адресе или тело объекта HTTP-запросов не имеет целостности, поскольку те части HTTP-запроса могут быть записаны в разных источниках и таким образом подделать атакующим. Cookies также слабы в этом отношении, поскольку они могут быть перезаписаны злоумышленником в нашем модель угрозы. Однако, используя JavaScript API называемый XMLHttpRequest (XHR), мы можем отправлять данные в обычном режиме заголовок.

Фон. XMLHttpRequest (XHR) позволяет HTTP запросы, содержащие пользовательские заголовки, и ответы читаются, но только к началу выполнения JavaScript. (См. Примечание5). В результате запросы, сделанные через XHR, могут быть отличающийся сервером как неизбежно возникающий из сайта.

Дизайн. Мы не будем использовать файлы cookie вообще, а вместо этого идентифицирующий токен в пользовательском HTTP-заголовке, который только написанный через XMLHttpRequest. Сервер должен обрабатывать все запросы, не имеющие этого настраиваемого заголовка, или содержащие недопустимый токен, принадлежащий к новой анонимной сессии. Чтобы сохраняйте этот сеанс, идентифицируя токен во всех перезапусках браузера и между разными страницами одного и того же приложения, токен может храниться в HTML5 localStorage с помощью JavaScript на успешная аутентификация.

Безопасность.. Обратите внимание, что в этой модели идентификатор сеанса идентификации будет отправлен только на исходный сервер и будет не включается в URL-адрес или тело объекта. Эти свойства обеспечивают конфиденциальность и целостность, соответственно. В отличие от cookie, токен не может быть перезаписан злоумышленником, поскольку localStorage полностью разделяет данные между источниками в большинство браузеров (см. примечание 6). Сайт, использующий HTTPS, может гарантировать, что токен отправляется только через HTTPS, обеспечивая тем самым секретность токена даже в присутствии активного сетевого злоумышленника. В Кроме того, поскольку этот токен не отправляется автоматически браузера, он также служит для защиты от атак CSRF.

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

(Примечание 5). Сайты могут выполнять межсайтовые запросы с использованием XHR, если они поддерживаются браузер и разрешен целевым сервером

(Примечание 6) Истина в Chrome, Firefox, Safari и Opera на OS X, несколько Linux дистрибутивами и Windows 7. Internet Explorer 8 не разделяет HTTP и HTTPS, но Internet Explorer 9. Делает это.

Ответ 5

Источник: Списки рассылки W3C

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

Если вы хотите эмулировать подход сертификата клиента TLS, вы можете использовать localStorage для хранения закрытого ключа и использовать JS crypto 1 заменить document.cookie на подписанную версию. Это немного неуклюже, но это может заставить работать. (Очевидно, было бы лучше с web crypto 2)

1 например: http://www.ohdave.com/rsa/

2 http://www.w3.org/community/webcryptoapi/

Ответ 6

Источник: Предложение о создании файлов cookie из Web 2.0 Конференция по безопасности и конфиденциальности

.

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

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

Дизайн.. Файлы cookie исходного кода - это файлы cookie, которые только отправляются и только модифицируются по запросам и ответам с точным происхождением. Они есть задавать в ответах HTTP так же, как существующие куки (используя Set-Cookie), но с новым атрибутом "Origin". В порядке чтобы веб-приложения могли отличать исходные файлы cookie от обычных файлы cookie, файлы cookie происхождения будут отправлены в HTTP-запросе в новом header 'OriginCookie, в то время как обычные файлы cookie будут продолжать отправляться в существующем заголовке 'Cookie.

HTTP/1.1 200 OK
...
Set-Cookie: foo=bar; Origin
...
Fig. 2. An HTTP response setting an origin cookie.
GET / HTTP/1.1
Host: www.example.com
...
Origin-Cookie: foo=bar
...

рис. 3. HTTP-запрос к URI, для которого источник cookie был установлен.

Например, если в ответ на запрос GET для http://www.example.com/, получен ответ, как на рисунке 2, затем исходный файл cookie будет установлен с помощью клавиши "foo и value" bar для источника http://www.example.com и будет отправлен на последующий запросы к этому происхождению. Последующий запрос GET для http://www.example.com/ будет выглядеть так, как показано на рисунке 3. Запросы, сделанные для любого другое происхождение, даже https://www.example.com и http://example.comбыло бы сделано так, как если бы исходный файл cookie для http://www.example.comникогда не был установлен. Атрибут Origin, расширяющий семантика самого Set-Cookie тонкая и подразумевает несколько семантические изменения на другие устанавливаемые атрибуты файлов cookie. Если Атрибут Origin установлен, атрибут Domain больше не является и поэтому их следует игнорировать. Аналогичным образом, Secure атрибут больше не подходит, поскольку он подразумевается схемой источника для файла cookie: если схема https, начало координат cookie эффективно имеет атрибут - поскольку он будет отправлен только безопасный канал - и если схема - это что-то еще, cookie делает не имеют атрибута. Потому что политика одного и того же происхождения различные пути, которые должны быть частью одного и того же происхождения, атрибут Path cookie не обеспечивает безопасность и также следует игнорировать. Семантика других атрибутов, таких как HttpOnly, Max-Age, Expires и т.д. остаются без изменений для файлов cookie. Обычные файлы cookie однозначно идентифицируются их ключ, значение атрибута "Домен" и значение Атрибут Path: это означает, что настройка cookie с ключом, Domain, и Path, который уже установлен, не добавляет новый файл cookie, но вместо этого заменяет существующий файл cookie. Файлы cookie происхождения должны занимать отдельное пространства имен и однозначно идентифицировать их ключ и полное происхождение которые его устанавливают. Это предотвращает случайное или злонамеренное использование сайтов удаление файлов cookie происхождения, в дополнение к другим чтения и изменения, а также делает использование файлов cookie на стороне сервера значительно легче.

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

Реализация. Интеграция файлов cookie исходного кода в существующие браузеры не потребует значительных модификаций. В качестве доказательства концепции мы реализованные файлы cookie в Chrome. Патч насчитывает всего 573 строки

Ответ 7

Из http://www.codeproject.com/Articles/16645/ASP-NET-machineKey-Generator

Всякий раз, когда вы используете аутентификацию ViewState, Session, Forms или другие зашифрованные и/или защищенные значения, ASP.NET использует набор ключей для шифрования и дешифрования. Обычно эти ключи скрыты и автоматически генерируются ASP.NET каждый раз, когда ваше приложение перерабатывает

Если два веб-сайта являются разными веб-приложениями, по умолчанию у них будут разные ключи, поэтому вы не сможете читать зашифрованные токены, созданные другим. Исключением является использование общих значений в глобальном web.config или machine.config.

От machineKey Element, decryptionKey: http://msdn.microsoft.com/en-us/library/w8h3skw9.aspx

AutoGenerate, IsolateApps Указывает, что ключ автоматически генерируется. Это значение по умолчанию. Модификатор AutoGenerate указывает, что ASP.NET генерирует случайный ключ и сохраняет его в Local Security Authority (LSA). Модификатор IsolateApps указывает, что ASP.NET генерирует уникальный зашифрованный ключ для каждого приложения, используя идентификатор приложения для каждого приложения.

Поэтому, если элемент machineKey не используется для установки decryptionKey на глобальном уровне, описанный вами метод не должен работать. Если он установлен, вы можете переопределить его на уровне приложения, используя файл web.config.

Ответ 8

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

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

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

Ответ 9

Вы можете установить уникальный machineKey в web.config для вашего приложения. Таким образом, могут быть дешифрованы только файлы cookie подлинности, испускаемые этим приложением. Если пользователь посещает вредоносный сайт в том же домене, этот другой сайт действительно может добавить cookie файл cookie с таким же именем, но с другим значением, но он не сможет зашифровать и подписать его с помощью того же машинного ключа, который используется вашим приложение, а когда пользователь перейдет назад, будет выбрано исключение.

Ответ 10

Ответ прост: всегда привязывайте сеансы к конкретному IP-адресу клиента (это должно быть сделано в любом современном веб-приложении) и не используйте файлы cookie для каких-либо других целей.

Объяснение: вы всегда отправляете один файл cookie SESSIONID обратно клиенту, который не содержит никакой информации - это просто очень длинная случайная строка. Вы сохраняете SESSIONID вместе с аутентифицированным IP-адресом пользователя в своей области webapps - например, например, в базе данных. Хотя связанная атака cookie может использоваться для обмена cookie SESSIONID между разными клиентами, ни один клиент не может маскироваться под другим пользователем или выполнять какие-либо действия, поскольку SESSIONID считается только действительным и привилегии предоставляются только в том случае, если его отправка из ассоциированного IP-адрес.

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