Как куки HttpOnly работают с AJAX-запросами?

Question

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 делает вас безопаснее, чем? Делать куки по сути только для чтения?

В вашем примере я не могу записать в ваш 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.
• Объекты XMLHttpObjects могут быть отправлены только в тот домен, из которого они были созданы, поэтому файлы cookie для междоменного размещения не допускаются.

edit: эта информация, вероятно, больше не актуальна.

Answer 1

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

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

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

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

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

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

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

Если вы не взломали 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-атаки, которые основаны на модификации куки-файлов клиента (не редкость).

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

Ajax строго не требует куки, но они могут быть полезны, как упоминали другие авторы. Маркировка куки HTTPOnly, чтобы скрыть его от сценариев, работает только частично, потому что не все браузеры поддерживают его, но также и потому, что существуют общие обходные пути.

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

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

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

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

Answer 5

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

Answer 6

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

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

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

Answer 7

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

Answer 8

Да, куки очень полезны для Ajax.

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

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

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

Answer 9

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

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