Как файлы cookie HttpOnly работают с запросами AJAX?

JavaScript необходим доступ к файлам cookie, если AJAX используется на сайте с ограничениями доступа на основе файлов cookie. Будут ли файлы cookie HttpOnly работать на сайте AJAX?

Изменить: Microsoft создала способ предотвратить атаки XSS, запретив доступ JavaScript к файлам cookie, если указан HttpOnly. Позже FireFox принял это. Итак, мой вопрос: если вы используете AJAX на сайте, например StackOverflow, можно ли использовать файлы cookie только Http?

Редактировать 2: Вопрос 2. Если целью HttpOnly является предотвращение доступа JavaScript к файлам cookie, и вы по-прежнему можете получать файлы cookie через JavaScript через объект XmlHttpRequest, в чем смысл HttpOnly < / сильный>?

Редактировать 3: Вот цитата из Википедии:

Когда браузер получает такой файл cookie, он должен использовать его как обычно в следующих HTTP-обменах, но не для того, чтобы сделать его видимым для клиентских скриптов. [32] Флаг HttpOnly не является частью какого-либо стандарта и реализован не во всех браузерах. Обратите внимание, что в настоящее время нет предотвращения чтения или записи файла cookie сеанса через XMLHTTPRequest. [33].

Я так понимаю, что document.cookie блокируется при использовании HttpOnly. Но кажется, что вы все еще можете читать значения cookie в объекте XMLHttpRequest, что позволяет использовать XSS. Как HttpOnly делает вас безопаснее? Делая файлы cookie только для чтения?

В вашем примере я не могу писать на ваш document.cookie, но я все равно могу украсть ваш файл cookie и опубликовать его в своем домене с помощью объекта XMLHttpRequest.

<script type="text/javascript">
    var req = null;
    try { req = new XMLHttpRequest(); } catch(e) {}
    if (!req) try { req = new ActiveXObject("Msxml2.XMLHTTP"); } catch(e) {}
    if (!req) try { req = new ActiveXObject("Microsoft.XMLHTTP"); } catch(e) {}
    req.open('GET', 'http://stackoverflow.com/', false);
    req.send(null);
    alert(req.getAllResponseHeaders());
</script>

Редактировать 4: Извините, я имел в виду, что вы можете отправить XMLHttpRequest в домен StackOverflow, а затем сохранить результат getAllResponseHeaders () в строку, вывести файл cookie с помощью регулярного выражения и затем опубликовать его во внешнем домен. Похоже, что Википедия и хакеры согласны со мной в этом, но я бы хотел перевоспитаться ...

Окончательное редактирование: А, очевидно, оба сайта ошибочны, на самом деле это ошибка в FireFox. IE6 и 7 - фактически единственные браузеры, которые в настоящее время полностью поддерживают HttpOnly.

Чтобы повторить все, что я узнал:

  • HttpOnly ограничивает весь доступ к document.cookie в IE7 и FireFox (не уверен в других браузерах)
  • HttpOnly удаляет информацию cookie из заголовков ответов в XMLHttpObject.getAllResponseHeaders () в IE7.
  • Объекты XMLHttpObject могут быть отправлены только в домен, из которого они произошли, поэтому междоменная отправка файлов cookie не производится.

изменить: эта информация, скорее всего, устарела.


person Shawn    schedule 26.08.2008    source источник
comment
Я добавил ваш пример в сценарий greasemonkey, и похоже, что FF больше не отображает файлы cookie. Отличное исследование и пример.   -  person    schedule 15.07.2010
comment
Возможно, с той же политикой происхождения вы не можете сделать http-запрос к домену, который не совпадает с тем, в котором запущен скрипт; однако я считаю, что вы можете легко передать файлы cookie, перенаправив пользователя на страницу с помощью window.location и передав всю информацию через параметры строки запроса.   -  person Luca Marzi    schedule 09.06.2016
comment
@LucaMarzi вы не можете сделать http-запрос к домену, который не совпадает с тем, в котором запущен скрипт Вы говорите, что сайт X не может включать изображение с хоста Y? (функция, которая поддерживается всеми браузерами, начиная с Mosaic?)   -  person curiousguy    schedule 23.11.2018


Ответы (9)


Да, файлы cookie только для HTTP подходят для этой функции. Им по-прежнему будет предоставлен запрос XmlHttpRequest к серверу.

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

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

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

В вашем примере я не могу писать в ваш document.cookie, но я все еще могу украсть ваш файл cookie и опубликовать его в своем домене с помощью объекта XMLHttpRequest.

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

Обычно вы можете внедрить скрипт для отправки cookie в свой домен с помощью удаленного взаимодействия iframe или JSONP, но тогда HTTP-Only снова защищает cookie, поскольку он недоступен.

Если вы не взломали StackOverflow.com на стороне сервера, вы не сможете украсть мой файл cookie.

Изменить 2: Вопрос 2. Если целью Http-Only является предотвращение доступа JavaScript к файлам cookie, и вы по-прежнему можете получать файлы cookie через JavaScript через объект XmlHttpRequest, в чем смысл Http-Only?

Рассмотрим этот сценарий:

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

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

Изменить 4: Извините, я имел в виду, что вы можете отправить XMLHttpRequest в домен StackOverflow, а затем сохранить результат getAllResponseHeaders () в строку, вывести файл cookie с помощью регулярного выражения и затем отправить его во внешний домен. Похоже, что Википедия и хакеры согласны со мной в этом, но я бы хотел перевоспитаться ...

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

Однако, если вы вернетесь к моему примеру сценария, вы увидите, где HTTP-Only действительно успешно отсекает XSS-атаки, которые полагаются на изменение файлов cookie клиента (не редкость).

Все сводится к тому, что а) ни одно улучшение не устранит все уязвимости и б) ни одна система не будет когда-либо полностью защищенной. Только HTTP - полезный инструмент защиты от XSS.

Точно так же, даже если междоменное ограничение на XmlHttpRequest не на 100% успешно предотвращает все эксплойты XSS, вы все равно никогда не мечтаете об удалении ограничения.

person Dave Ward    schedule 26.08.2008
comment
Многие платформы помещают csrf токен в файлы cookie. Я полагаю, что вызов AJAX, требующий проверки csrf, не будет работать, если вы не поместите токен csrf в скрытый элемент HTML, чтобы JS извлек его. - person user; 05.02.2015

Да, это приемлемый вариант для сайта на основе Ajax. Куки-файлы аутентификации не предназначены для манипуляции сценариями, они просто включаются браузером во все HTTP-запросы, отправляемые на сервер.

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

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

Мне очень нравятся файлы cookie только для HTTP - это одно из тех проприетарных расширений браузера, которое было действительно отличной идеей.

person thomasrutter    schedule 26.02.2009

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

person Glenn Slaven    schedule 26.08.2008

Есть еще кое-что.

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

Странно, что заголовки XMLHTTPresponse предоставляют cookie, технически серверу не нужно возвращать cookie с ответом. После того, как он установлен на клиенте, он остается установленным до истечения срока его действия. Хотя существуют схемы, в которых cookie изменяется при каждом запросе, чтобы предотвратить повторное использование. Таким образом, вы можете избежать этого обходного пути, изменив сервер, чтобы он не предоставлял cookie в ответах XMLHTTP.

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

Если вы хотите быть уверены, что запрос AJAX аутентифицирован, сам запрос И заголовки HTTP должны содержать cookie. Например, с помощью скриптов или уникальных скрытых входов. HTTPOnly может этому помешать.

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

person davenpcj    schedule 10.06.2009
comment
Я должен упомянуть, что в настоящее время передовой практикой является проверка полезной нагрузки и запроса, как я упоминал выше, но с использованием HTTPOnly secure cookie для проверки запроса и другого токена с полезной нагрузкой, поэтому HTTPOnly isn ' т помеха. - person davenpcj; 28.05.2021

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

person pkchukiss    schedule 26.08.2008

Поэтому я предполагаю, что JavaScript требуется доступ к вашим файлам cookie.

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

Официальный ответ на ваш вопрос в формулировке - «Нужен ли JavaScript доступ к файлам cookie, если используется AJAX?» - поэтому "нет". Подумайте, например, о полях расширенного поиска, которые используют запросы Ajax для предоставления параметров автоматического предложения. В этом случае информация о файлах cookie не требуется.

person Polsonby    schedule 26.08.2008
comment
XmlHttpRequest нужны файлы cookie. Упомянутый вами расширенный поиск может находиться за страницей входа. Но нужно ли Javascript иметь возможность предоставлять значение cookie для виртуальной машины - это другой вопрос. - person Mr. Shiny and New 安宇; 23.03.2009

В качестве пояснения - с точки зрения сервера страница, запрашиваемая запросом AJAX, по существу не отличается от стандартного HTTP-запроса на получение, выполняемого пользователем, нажимающим на ссылку. На сервер передаются все обычные свойства запроса: user-agent, ip, session, cookies и т. Д.

person Glenn Slaven    schedule 26.08.2008
comment
Сеанс - это не концепция HTTP. Это концепция высокого уровня, построенная на основе концепций HTTP фреймворком. - person curiousguy; 23.11.2018

Нет, страница, которую запрашивает вызов AJAX, также имеет доступ к файлам cookie, и это то, что проверяет, вошли ли вы в систему.

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

person Glenn Slaven    schedule 26.08.2008

Да, файлы cookie очень полезны для Ajax.

Помещение аутентификации в URL-адрес запроса - плохая практика. На прошлой неделе была новость о получении токенов аутентификации в URL-адресах из кеша Google.

Нет, предотвратить атаки невозможно. Старые браузеры по-прежнему разрешают простой доступ к файлам cookie через javascript. Вы можете обойти только http и т. Д. Все, что вы придумали, можно обойти, приложив достаточно усилий. Уловка состоит в том, чтобы приложить слишком много усилий, чтобы оно того стоило.

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

person Jay    schedule 23.03.2009