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

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

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

Редактирование 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 отсутствует.

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

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

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

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

Однако если вы хотите обеспечить безопасность для функциональности с поддержкой 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-только делает успешно отрезаны от XSS атак , которые полагаются на изменения куков клиента (не редкость).

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

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

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

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

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

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

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

Есть немного больше к этому.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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