2008-08-26 1 views
172

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

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

Edit 2: Вопрос 2. Если цель HttpOnly, чтобы предотвратить доступ к JavaScript куки, и вы все еще можете получить куки через JavaScript через XmlHttpRequest Object, , что точка HttpOnly?

Edit 3: Вот цитата из Википедии:

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

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

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

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

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

+0

Я бросил ваш пример в сценарий greasemonkey, и похоже, что FF больше не отображает файлы cookie. Отличные исследования и примеры. – 2010-07-14 22:09:03

+0

Возможно, с той же самой политикой происхождения вы не можете сделать http-запрос для домена, который не является тем же самым скриптом; однако я считаю, что вы можете легко передать файлы cookie, перенаправив пользователя на страницу с помощью window.location и передав информацию через параметры строки запроса. – 2016-06-09 08:38:29

ответ

3

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

0

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

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

1

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

1

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

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

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

+0

XmlHttpRequest нуждается в куки. Упомянутый расширенный поиск может заходить за страницу входа. Но нужен ли Javascript для отображения значения cookie для виртуальной машины - это другой вопрос. – 2009-03-23 15:54:28

1

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

55

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

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

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

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

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

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

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

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

Edit 2: Вопрос 2. Если цель Http-только, чтобы предотвратить доступ к JavaScript куки, и вы все еще можете получить куки через JavaScript через XmlHttpRequest объект, какова точка Http-только?

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

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

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

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

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

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

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

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

2

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

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

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

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

0

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

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

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

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

2

Это немного больше.

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

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

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

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

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