Як файли cookie HttpOnly працюють із запитами AJAX?


195

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 робить вас будь-якими безпечнішими? Створюючи файли 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 () у рядок, повторно виправити файл cookie та опублікувати його на зовнішній домен. Здається, що Вікіпедія та хакери погоджуються зі мною на цьому, але я хотів би перевчитись ...

Остаточне редагування: Ага, мабуть, обидва сайти помиляються, це насправді помилка у FireFox . IE6 & 7 - це єдині браузери, які на сьогодні повністю підтримують HttpOnly.

Щоб повторити все, що я дізнався:

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

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


Я кинув ваш приклад у сценарій жирної клавіші, і схоже, що FF більше не відображає файли cookie. Відмінне дослідження та приклад.

Можливо, за допомогою політики політики оригінального походження ви не можете робити запит http до домену, який не є тим самим, у якому працює сценарій; однак я вважаю, що ви можете легко передати файли cookie, перенаправляючи користувача на сторінку за допомогою window.location і передаючи інформацію через параметри рядка запиту.
Лука Марці

@LucaMarzi " ви не можете зробити запит http до домену, який не є тим самим, у якому працює сценарій ". Ви говорите, що сайт X не може містити зображення від хоста Y? (функція, яку підтримують усі браузери з часів Mosaic?)
цікаво

Відповіді:


64

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

У разі переповнення стека файли cookie автоматично надаються як частина запиту XmlHttpRequest. Я не знаю деталей реалізації постачальника аутентифікації Stack Overflow, але ці файли cookie, ймовірно, автоматично використовуються для перевірки вашої особи на нижчому рівні, ніж метод контролера "голосування".

Більш загально, файли cookie не потрібні для AJAX. Підтримка XmlHttpRequest (або навіть видалення iframe у старих браузерах) - це все, що технічно потрібно.

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

У вашому прикладі я не можу записатись у ваш document.cookie, але я все одно можу вкрасти ваше cookie та опублікувати його на своєму домені за допомогою об’єкта XMLHttpRequest.

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

Зазвичай ви можете ввести сценарій для надсилання файлу cookie у ваш домен за допомогою видалення iframe або JSONP, але тоді HTTP-лише знову захищає файл cookie, оскільки він недоступний.

Якщо б ви не зламали StackOverflow.com на стороні сервера, ви не змогли вкрасти моє cookie.

Редагуйте 2: Запитання 2. Якщо метою Http-Only є запобігання доступу JavaScript до файлів cookie, і ви все ще можете отримати файли cookie через JavaScript через об’єкт XmlHttpRequest, у чому сенс лише Http?

Розглянемо цей сценарій:

  • Я знаходжу проспект для введення коду JavaScript на сторінку.
  • Jeff завантажує сторінку, і мій шкідливий JavaScript змінює його cookie на мій.
  • Джефф подає зоряну відповідь на ваше запитання.
  • Оскільки він подає його разом із моїми даними cookie замість своїх, відповідь стане моєю.
  • Ви проголосуєте "мою" зоряну відповідь.
  • Мій реальний рахунок отримує бал.

З кукі-файлами HTTP-другого кроку було б неможливо, тим самим переможивши мою спробу XSS.

Редагування 4: Вибачте, я мав на увазі, що ви можете надіслати XMLHttpRequest до домену StackOverflow, а потім зберегти результат getAllResponseHeaders () у рядок, повторно виправити файл cookie та опублікувати його на зовнішній домен. Здається, що Вікіпедія та хакери погоджуються зі мною на цьому, але я хотів би перевчитись ...

Це правильно. Ви все ще можете сеанс викрадення таким чином. Це значно зменшує стадо людей, які можуть успішно виконати навіть той злом XSS проти вас.

Тим НЕ менше, якщо повернутися до мого прикладу, ви можете побачити , де HTTP-тільки робить успішно відрізані від XSS атак , які покладаються на зміни куків клієнта (не рідкість).

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

Так само, хоча обмеження між доменом на XmlHttpRequest не є на 100% успішним у запобіганні всіх подвигів XSS, ви все одно ніколи не мрієте про видалення обмеження.


Багато фреймворків ставлять csrf маркер у файлах cookie . Я вважаю, що виклик AJAX, для якого потрібна csrfперевірка, не спрацює, якщо ви не помістите маркер csrf у прихований HTML-елемент для отримання JS.
користувач

4

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


4

Так, вони є життєздатним варіантом для сайту на базі Ajax. Файли cookie аутентифікації не призначені для маніпулювання сценаріями, а просто включаються браузером у всіх HTTP-запитах, зроблених на сервер.

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

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

Мені дуже подобаються лише файли cookie HTTP - це одне з тих власних розширень браузера, які були дійсно охайною ідеєю.


3

У цьому є трохи більше.

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

Як не дивно, що заголовки відповіді XMLHTTPвіддають файли cookie, технічно сервер не повинен повертати файли cookie з відповіддю. Після того, як він встановлений на клієнті, він залишається встановленим, поки його термін дії не закінчиться. Хоча існують схеми, в яких cookie змінюється з кожним запитом, щоб запобігти його повторному використанню. Таким чином, ви можете уникнути цього вирішення, змінивши сервер, щоб не надавати файли cookie у відповідях XMLHTTP.

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

Якщо ви хочете бути впевнені, що запит AJAX є автентифікованим, сам запит ТА заголовки HTTP повинні містити файли cookie. Наприклад, за допомогою скриптів або унікальних прихованих входів. HTTPOnly перешкоджатиме цьому.

Зазвичай цікавою причиною бажати HTTPOnly є те, щоб запобігти крадіжкам файлів cookie сторонніх сторінок, що містяться на вашій веб-сторінці. Але є багато цікавих причин, щоб бути дуже обережними щодо включення сторонніх вмістів і фільтрувати їх агресивно.


1

Браузер автоматично обробляє браузер, коли ви здійснюєте AJAX-дзвінок, тому немає необхідності, щоб ваш Javascript псувався з cookie-файлами.


1

Тому я припускаю, що JavaScript потребує доступу до ваших файлів cookie.

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

Офіційна відповідь на ваше запитання у формі фрази - "Чи потрібен JavaScript доступ до файлів cookie, якщо використовується AJAX?" - тому "ні". Подумайте про розширені поля пошуку, які використовують запити Ajax, наприклад, для надання опцій автоматичного підказу. У цьому випадку інформація про файли cookie не потрібна.


XmlHttpRequest потребує файлів cookie. Розширений пошук, який ви згадуєте, може бути за сторінкою входу. Але чи потрібно Javascript вміти піддавати значення файлу cookie VM - це інше питання.
Містер Блискучий та Новий 安 宇

1

Як уточнення - з точки зору сервера, сторінка, яка запитується запитом AJAX, по суті не відрізняється від стандартного HTTP-запиту на отримання, зробленого користувачем, натиснувши на посилання. Усі звичайні властивості запиту: користувальницький агент, ip, сесія, файли cookie тощо передаються серверу.


"Сеанс" не є концепцією HTTP. Це концепція високого рівня, побудована на основі концепцій HTTP рамкою.
допитливо

0

Ні, сторінка, на яку вимагає дзвінок AJAX, також має доступ до файлів cookie. Це те, що перевіряє, чи ви ввійшли в систему.

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


0

Так, файли cookie дуже корисні для Ajax.

Встановлення автентифікації в URL-адресу запиту є поганою практикою. Минулого тижня з’явилася новина про отримання маркерів аутентифікації в URL-адресах з кешу Google.

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.