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

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

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

Изменить 2: Вопрос 2. Если целью HttpOnly является предотвращение доступа JavaScript к файлам 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>

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

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

Повторить все, что я узнал:

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

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

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

Там немного больше.

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

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

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

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

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

Ответ 5

Cookies автоматически обрабатываются браузером при вызове AJAX, поэтому вам не нужно, чтобы ваш Javascript работал с кукисами.

Ответ 6

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

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

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

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

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

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