My<cod/>.net
Как HttpOnly cookies работают с AJAX запросами?
JavaScript необходим доступ к файлам cookie, если AJAX используется на сайте с ограничениями доступа на основе файлов cookie. Будут ли файлы cookie HttpOnly работать на сайте AJAX?
Изменить: Microsoft создала способ предотвращения атак XSS, запретив JavaScript доступ к файлам cookie, если указано HttpOnly. FireFox позже принял это. Итак, мой вопрос: если вы используете AJAX на сайте, как StackOverflow, являются ли Http-только файлы cookie опцией?
Правка 2: Вопрос 2. Если целью HttpOnly является предотвращение доступа JavaScript к cookies, и вы все еще можете получить cookies через JavaScript через объект XmlHttpRequest, то в чем смысл HttpOnly ?
Правка 3: Вот цитата из Википедии:
Когда браузер получает такой файл cookie, он должен использовать его как обычно в следующих обменах HTTP, но не делать его видимым для клиентской стороны scripts.[32] флаг
HttpOnlyне является частью какого-либо стандарта и не реализован во всех браузерах. Обратите внимание, что в настоящее время нет никакой возможности предотвратить чтение или запись сессионного куки через 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() в строку, regex из файла cookie, а затем отправить его во внешний домен. Похоже, что Википедия и ha.ckers согласны со мной в этом, но я хотел бы быть перевоспитанным...
Окончательное редактирование: Ах, очевидно, оба сайта ошибочны, на самом деле это ошибка в FireFox . IE6 & 7 на самом деле являются единственными браузерами, которые в настоящее время полностью поддерживают HttpOnly.
Чтобы повторить все, что я узнал:
- HttpOnly ограничивает весь доступ к document.cookie в IE7 & и FireFox (не уверен в других браузерах)
- HttpOnly удаляет информацию о файлах cookie из заголовков ответов в XMLHttpObject.getAllResponseHeaders() в IE7.
- XMLHttpObjects могут быть отправлены только в домен, из которого они исходят, поэтому нет никакой междоменной публикации файлов cookie.
правка: эта информация, скорее всего, больше не актуальна.
Да, HTTP-только куки-файлы были бы хороши для этой функциональности. Они все равно будут предоставлены с запросом XmlHttpRequest к серверу.
В случае переполнения стека файлы cookie автоматически предоставляются как часть запроса XmlHttpRequest. Я не знаю подробностей реализации поставщика проверки подлинности переполнения стека, но эти данные cookie, вероятно, автоматически используются для проверки вашей личности на более низком уровне, чем метод контроллера "vote".
В более общем случае файлы cookie не требуются для AJAX. Поддержка XmlHttpRequest (или даже iframe remoting, в старых браузерах) - это все, что технически требуется.
Однако если вы хотите обеспечить безопасность для функций с поддержкой AJAX, то применяются те же правила, что и для традиционных сайтов. Вам нужен какой-то метод для идентификации пользователя, стоящего за каждым запросом, и куки-файлы почти всегда являются средством для достижения этой цели.
В вашем примере я не могу написать на ваш document.cookie, но я все еще могу украсть ваш файл cookie и отправить его в свой домен, используя объект XMLHttpRequest.
XmlHttpRequest не будет выполнять междоменные запросы (именно по тем причинам, которые вы затронули).
Обычно вы можете ввести скрипт для отправки файла cookie в ваш домен с помощью iframe remoting или JSONP, но тогда HTTP-только защищает файл cookie снова, так как он недоступен.
Если бы вы не взломали StackOverflow.com на стороне сервера, вы не смогли бы украсть мой файл cookie.
Правка 2: Вопрос 2. Если цель Http-Only состоит в том, чтобы предотвратить доступ JavaScript к cookies, и вы все еще можете получить cookies через JavaScript через объект XmlHttpRequest, то в чем смысл Http-Only?
Рассмотрим этот сценарий:
- Я нахожу способ ввести на страницу код JavaScript.
- Джефф загружает страницу, и мой злонамеренный JavaScript изменяет свой файл cookie, чтобы он соответствовал моему.
- Джефф дает блестящий ответ на ваш вопрос.
- Поскольку он отправляет его с моими данными cookie вместо своих, ответ станет моим.
- Голосовать " за " звездных "my" ответа.
- Моя реальная учетная запись получает точку.
С печеньем HTTP-Only второй шаг был бы невозможен, тем самым победив мою попытку XSS.
Правка 4: Извините, я имел в виду, что вы можете отправить XMLHttpRequest в домен StackOverflow, а затем сохранить результат getAllResponseHeaders() в строку, regex из файла cookie, а затем отправить его во внешний домен. Похоже, что Википедия и ha.ckers согласны со мной в этом вопросе, но я хотел бы быть перевоспитанным...
И это правильно. Вы все еще можете захватить сеанс таким образом. Это значительно уменьшает стадо людей, которые могут успешно выполнить даже этот XSS Хак против вас, хотя.
Однако, если вы вернетесь к моему примеру сценария, вы можете увидеть, где HTTP-Only успешно отсекает атаки XSS, которые полагаются на изменение cookies клиента (не редкость).
Это сводится к тому, что а) ни одно улучшение не решит всех уязвимостей и б) ни одна система никогда не будет полностью защищена. HTTP-только является полезным инструментом в деле против XSS.
Аналогично, даже если кросс-доменное ограничение на XmlHttpRequest не является 100% успешным в предотвращении всех эксплойтов XSS, вы все равно никогда не мечтали бы об удалении этого ограничения.
Не обязательно, это зависит от того, что вы хотите сделать. Не могли бы вы немного уточнить? AJAX не нуждается в доступе к файлам cookie для работы, он может самостоятельно делать запросы для извлечения информации, запрос страницы, который делает вызов AJAX, может получить доступ к данным cookie & передать их обратно в вызывающий скрипт без Javascript прямого доступа к файлам cookie
Да, они являются жизнеспособным вариантом для сайта на базе Ajax. Аутентификационные файлы cookie не предназначены для манипулирования сценариями, а просто включаются браузером во все запросы HTTP, поступающие на сервер.
Скрипты не должны беспокоиться о том, что говорит куки сеанса - пока вы аутентифицированы, то любые запросы к серверу, инициированные пользователем или скриптом, будут включать соответствующие куки. Тот факт, что сами скрипты не могут знать содержание файлов cookie, не имеет значения.
Для любых файлов cookie, которые используются для целей, отличных от аутентификации, они могут быть установлены без флага HTTP only, если вы хотите, чтобы скрипт мог изменять или читать их. Вы можете выбрать, какие файлы cookie должны быть только HTTP, поэтому, например, все нечувствительные параметры, такие как UI (порядок сортировки, свернуть левую панель или нет), могут быть совместно использованы в файлах cookie со сценариями.
Мне очень нравится HTTP only cookies - это одно из тех фирменных расширений браузера, которые были действительно хорошей идеей.
Тут есть еще кое-что.
Ajax не требует строго куки, но они могут быть полезны, как упоминалось в других плакатах. Маркировка файла cookie HTTPOnly для скрытия его от скриптов работает только частично, поскольку не все браузеры поддерживают его, но также и потому, что существуют общие обходные пути.
Странно, что заголовки XMLHTTPresponse дают куки, технически сервер не должен возвращать куки с ответом. Как только он установлен на клиенте, он остается установленным до истечения срока его действия. Хотя существуют схемы, в которых куки-файлы изменяются при каждом запросе, чтобы предотвратить повторное использование. Таким образом, вы можете избежать этого обходного пути, изменив сервер, чтобы он не предоставлял файлы cookie для ответов XMLHTTP.
В целом, однако, я думаю, что HTTPOnly следует использовать с некоторой осторожностью. Существуют атаки с использованием межсайтовых сценариев, когда злоумышленник организует для пользователя отправку ajax-подобного запроса, исходящего с другого сайта, используя простые формы сообщений, без использования XMLHTTP, и все еще активный файл cookie Вашего браузера будет аутентифицировать запрос.
Если вы хотите быть уверены, что запрос AJAX аутентифицирован, сам запрос AND заголовки HTTP должны содержать файл cookie. Например, через использование скриптов или уникальных скрытых входов. HTTPOnly будет препятствовать этому.
Обычно интересной причиной для получения HTTPOnly является предотвращение кражи файлов cookie сторонним контентом, размещенным на вашей веб-странице. Но есть много интересных причин для того, чтобы быть очень осторожными в отношении включения стороннего контента и агрессивно фильтровать его.
Поэтому я предполагаю, что JavaScript нуждается в доступе к вашим файлам cookie.
Поэтому я предполагаю, что JavaScript нуждается в доступе к вашим файлам cookie.
Все запросы HTTP от Вашего браузера передают вашу информацию о файлах cookie для данного сайта. JavaScript может как устанавливать, так и считывать файлы cookie. Файлы cookie по определению не требуются для Ajax приложений, но они необходимы для большинства веб-приложений для поддержания состояния пользователя.
Формальный ответ на ваш вопрос в такой формулировке-"Does JavaScript need access to cookies if AJAX is used?"-это, следовательно, "no". Подумайте о расширенных полях поиска, которые используют запросы Ajax для предоставления опций автоматического предложения, например. В этом случае информация о файлах cookie не требуется.
Как пояснение-с точки зрения сервера, страница, которая запрашивается запросом AJAX, по существу ничем не отличается от стандартного запроса HTTP get, выполняемого пользователем, щелкнувшим по ссылке. Все нормальные свойства запроса: пользователь-агент, айпи, сессии, куки и т. д. передаются на сервер.
Да, куки-файлы очень полезны для Ajax.
Помещать аутентификацию в запрос URL-плохая практика. На прошлой неделе появилась новость о получении токенов аутентификации в URL из кэша google.
Нет, нет никакого способа предотвратить нападения. Старые браузеры по-прежнему разрешают тривиальный доступ к cookies через javascript. Вы можете обойти только http и т. д. Все, что вы придумаете, можно обойти, приложив достаточно усилий. Фокус в том, чтобы сделать это слишком много усилий, чтобы быть стоящим.
Если вы хотите сделать свой сайт более безопасным (идеальной безопасности не существует), вы можете использовать файл cookie аутентификации, срок действия которого истекает. Затем, если файл cookie украден, злоумышленник должен использовать его до истечения срока действия. Если они этого не делают, то у вас есть хороший признак того, что на этом счету есть подозрительная активность. Чем короче временное окно, тем лучше для безопасности, но тем большую нагрузку оно накладывает на ваш сервер, генерирующий и поддерживающий ключи.