Я намагаюся зрозуміти всю проблему з CSRF та відповідні способи її запобігання. (Ресурси, які я читав, розумію і погоджуюсь з: Ознайомлювальний лист OWASP CSRF , Запитання про КСРР .)

Як я розумію, вразливість навколо CSRF вводиться припущенням, що (з точки зору веб-сервера) дійсне cookie-сеанс у вхідному HTTP-запиті відображає побажання автентифікованого користувача. Але всі файли cookie для початкового домену магічно приєднуються до запиту браузером, тому дійсно весь сервер може зробити висновок про наявність дійсного файлу cookie сеансу у запиті, що запит надходить від браузера, який має аутентифікований сеанс; вона більше не може припускати нічого про кодпрацює в цьому веб-переглядачі, чи відображає це дійсно побажання користувача. Спосіб запобігти цьому - включити в запит додаткову інформацію про аутентифікацію ("маркер CSRF"), яку переносять іншими способами, крім автоматичної обробки файлів cookie браузера. Точно кажучи, файли cookie сеансу аутентифікують користувача / браузера, а маркер CSRF автентифікує код, що працює в браузері.

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

Що стосується мого запитання, що стосується конкретного способу транспорту, який використовується для цього маркера CSRF на цьому переході.

Здається, звичайно (наприклад, у AngularJS , Django , Rails ) надсилати маркер CSRF з сервера на клієнт у вигляді файлу cookie (тобто у заголовку Set-Cookie), а потім Javascript у клієнта викреслювати його з файлу cookie та приєднувати його як окремий заголовок XSRF-TOKEN для повернення на сервер.

(Альтернативний метод - це той, який рекомендується, наприклад, Express , де маркер CSRF, згенерований сервером, включається в тіло відповіді за допомогою розширення шаблону на стороні сервера, приєднаного безпосередньо до коду / розмітки, що надасть його назад на сервер, наприклад як прихований прийом форми. Цей приклад - це більш зручний для веб-способів ведення справ, але він узагальнить штраф для більш важкого для JS клієнта.)

Чому так часто використовується Set-Cookie як транспорт низхідного потоку для маркера CSRF / чому це гарна ідея? Я думаю, що автори всіх цих рамок уважно розглядали свої варіанти, і не зрозуміли це. Але, на перший погляд, використання файлів cookie для вирішення того, що по суті є обмеженням дизайну файлів cookie, здається непростим. Насправді, якщо ви використовували файли cookie як транспорт у зворотний бік (Set-Cookie: заголовок вниз за потоком для сервера, щоб повідомити браузеру токен CSRF, а Cookie: заголовок вгору для браузера, щоб повернути його на сервер), ви б знову ввели вразливість, яку ви намагаються виправити.

Я розумію, що вищевказані рамки не використовують файли cookie для цілого переходу для маркера CSRF; вони використовують Set-Cookie вниз за потоком, потім щось інше (наприклад, заголовок X-CSRF-Token) вгору за течією, і це повністю усуває вразливість. Але навіть використання Set-Cookie в якості транспорту нижче за течією потенційно вводить в оману та небезпечно; тепер браузер приєднає маркер CSRF до кожного запиту, включаючи справжні шкідливі запити XSRF; в кращому випадку, що робить запит більшим, ніж потрібно, а в гіршому - якийсь добронамерений, але неправильно керований фрагмент коду сервера може насправді спробувати його використати, що було б дуже погано. Крім того, оскільки фактичним призначеним одержувачем маркера CSRF є клієнтський Javascript, це означає, що цей файл cookie не може бути захищений лише http-адресою.

Вагомою причиною, яку ви начебто торкнулися, є те, що після отримання файлу cookie CSRF він стає доступним для використання у всій програмі в клієнтському скрипті для використання як у звичайних формах, так і в AJAX POST. Це матиме сенс у важкому додатку JavaScript, такому, як той, який використовується у AngularJS (для використання AngularJS не потрібно, щоб програма була додатком для однієї сторінки, тому було б корисно, коли держава повинна переходити між різними запитами на сторінки, де значення CSRF не може нормально зберігатись у браузері).

Розгляньте наступні сценарії та процеси в типовому додатку для деяких плюсів і мінусів кожного описаного підходу. Вони засновані на шаблоні токена синхронізатора .

Попросити підхід до органу

1. Користувач успішно входить у систему.
2. Сервер видає auth cookie.
3. Користувач клацає, щоб перейти до форми.
4. Якщо ще не створено для цього сеансу, сервер генерує маркер CSRF, зберігає його в сеанс користувача та виводить його в приховане поле.
5. Користувач подає форму.
6. Сервер перевіряє приховані поля відповідності сеансу, що зберігається.

Переваги:

• Простий у виконанні.
• Працює з AJAX.
• Працює з формами.
• Файл cookie насправді може бути лише HTTP .

Недоліки:

• Усі форми повинні виводити приховане поле в HTML.
• Будь-які порти AJAX також повинні містити значення.
• Сторінка повинна заздалегідь знати, що їй потрібен маркер CSRF, щоб вона могла включити її до вмісту сторінки, тому всі сторінки десь повинні містити значення токена, що може зайняти час для впровадження великого сайту.

Спеціальний заголовок HTTP (вниз)

1. Користувач успішно входить у систему.
2. Сервер видає auth cookie.
3. Користувач клацає, щоб перейти до форми.
4. Сторінка завантажується у браузері, тоді запит AJAX робиться для отримання маркера CSRF.
5. Сервер генерує токен CSRF (якщо він ще не створений для сеансу), зберігає його у сеансі користувача та виводить його в заголовок.
6. Користувач подає форму (маркер надсилається через приховане поле).
7. Сервер перевіряє приховані поля відповідності сеансу, що зберігається.

Переваги:

• Працює з AJAX.
• Файл cookie може бути лише HTTP .

Недоліки:

• Не працює без запиту AJAX, щоб отримати значення заголовка.
• Усі форми мають динамічно додавати значення до його HTML.
• Будь-які порти AJAX також повинні містити значення.
• Сторінка спочатку повинна зробити запит AJAX, щоб отримати маркер CSRF, тому це буде означати додаткову подорож у кожний раз.
• Можна також просто вивести маркер на сторінку, що дозволить зберегти зайвий запит.

Спеціальний HTTP-заголовок (вище)

1. Користувач успішно входить у систему.
2. Сервер видає auth cookie.
3. Користувач клацає, щоб перейти до форми.
4. Якщо ще не сформовано для цього сеансу, сервер генерує маркер CSRF, зберігає його у сеансі користувача та виводить його десь у вміст сторінки.
5. Користувач надсилає форму через AJAX (маркер надсилається через заголовок).
6. Сервер перевіряє спеціальний заголовок відповідності сеансу збереженого маркера.

Переваги:

• Працює з AJAX.
• Файл cookie може бути лише HTTP .

Недоліки:

• Не працює з формами.
• Усі порти AJAX повинні містити заголовок.

Спеціальні заголовки HTTP (вище та нижче)

1. Користувач успішно входить у систему.
2. Сервер видає auth cookie.
3. Користувач клацає, щоб перейти до форми.
4. Сторінка завантажується у браузері, тоді запит AJAX робиться для отримання маркера CSRF.
5. Сервер генерує токен CSRF (якщо він ще не створений для сеансу), зберігає його у сеансі користувача та виводить його в заголовок.
6. Користувач надсилає форму через AJAX (маркер надсилається через заголовок).
7. Сервер перевіряє спеціальний заголовок відповідності сеансу збереженого маркера.

Переваги:

• Працює з AJAX.
• Файл cookie може бути лише HTTP .

Недоліки:

• Не працює з формами.
• Усі порти AJAX також повинні містити значення.
• Сторінка повинна спочатку зробити запит AJAX, щоб отримати маркер CRSF, тому це буде означати додаткову поїздку в обидва рази.

Набір-Cookie

1. Користувач успішно входить у систему.
2. Сервер видає auth cookie.
3. Користувач клацає, щоб перейти до форми.
4. Сервер генерує токен CSRF, зберігає його проти користувальницького сеансу і виводить його на файл cookie.
5. Користувач надсилає форму через AJAX або через HTML-форму.
6. Сервер перевіряє власні заголовки (або приховане поле форми) на відповідність сеансу, що зберігається.
7. Файл cookie доступний у веб-переглядачі для використання в додаткових AJAX та формуванні запитів без додаткових запитів на сервер для отримання маркера CSRF.

Переваги:

• Простий у виконанні.
• Працює з AJAX.
• Працює з формами.
• Не обов'язково потрібен запит AJAX, щоб отримати значення файлу cookie. Будь-який HTTP-запит може отримати його, і він може бути доданий до всіх форм / запитів AJAX через JavaScript.
• Після того, як маркер CSRF буде отримано, оскільки він зберігається у файлі cookie, значення можна повторно використовувати без додаткових запитів.

Недоліки:

• Усі форми мають динамічно додавати значення до його HTML.
• Будь-які порти AJAX також повинні містити значення.
• Файл cookie буде подано для кожного запиту (тобто всіх GET для зображень, CSS, JS тощо), які не задіяні в процесі CSRF), збільшуючи розмір запиту.
• Файл cookie не може бути лише HTTP .

Таким чином, підхід до файлів cookie є досить динамічним, пропонує простий спосіб отримати значення файлу cookie (будь-який запит HTTP) та використовувати його (JS може додавати значення до будь-якої форми автоматично, і його можна використовувати в запитах AJAX або в якості заголовка, або як значення форми). Після того, як маркер CSRF отриманий для сеансу, не потрібно регенерувати його, оскільки зловмисник, що використовує експлуатацію CSRF, не має жодного способу отримання цього маркера. Якщо зловмисний користувач намагається прочитати токен CSRF користувача будь-яким із перерахованих вище способів, це запобіжить політиці того самого джерела . Якщо зловмисний користувач намагається отримати сторону сервера маркера CSRF (наприклад, черезcurl), то цей маркер не буде пов’язаний з тим самим обліковим записом користувача, оскільки файл cookie аутентивної сесії жертви буде відсутній у запиті (це було б зловмисником, тому він не буде пов'язаний на стороні сервера із сеансом жертви).

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

Використання файлу cookie для надання клієнту маркера CSRF не дозволяє успішну атаку, оскільки зловмисник не може прочитати значення файлу cookie та, отже, не може поставити його там, де потрібна перевірка CSRF на стороні сервера.

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

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

Моя найкраща здогадка щодо відповіді: Розгляньте ці 3 варіанти того, як знизити маркер CSRF з сервера до браузера.

1. В тілі запиту (не заголовку HTTP).
2. У користувацькому заголовку HTTP, а не Встановити cookie.
3. Як cookie, у заголовку Set-Cookie.

Я думаю, що перший, орган запиту (в той час як це демонструє експрес-підручником, з яким я пов’язаний у запитанні ), не є настільки переносним для широкого спектру ситуацій; не всі генерують кожну відповідь HTTP динамічно; там, де вам знадобиться ввести маркер в генеровану відповідь, може бути дуже різним (в прихованій формі введення; у фрагменті коду JS або змінної, доступній іншим кодом JS; можливо, навіть в URL-адресі, хоча це, як правило, погано ставити маркери CSRF). Тож, працюючи з деякими налаштуваннями, №1 - це важке місце для підходу, що відповідає одному розміру.

Другий, власний заголовок, привабливий, але насправді не працює, оскільки, хоча JS може отримати заголовки для XHR, на який він викликав, він не може отримати заголовки сторінки, з якої завантажується .

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

Окрім файлу cookie сеансу (який є типовим стандартом), я не хочу використовувати додаткові файли cookie.

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

Моє рішення без зайвих файлів cookie є простим:

Сторона клієнта

Зберігайте маркер CSRF, який повертається сервером після успішного входу в глобальну змінну (якщо ви, звичайно, хочете використовувати веб-сховище замість глобального, це добре). Попросіть JQuery поставити заголовок X-CSRF-TOKEN у кожному дзвінку AJAX.

Основна сторінка "індексу" містить цей фрагмент JavaScript:

// Intialize global variable CSRF_TOKEN to empty sting. 
// This variable is set after a succesful login
window.CSRF_TOKEN = '';

// the supplied callback to .ajaxSend() is called before an Ajax request is sent
$( document ).ajaxSend( function( event, jqXHR ) {
    jqXHR.setRequestHeader('X-CSRF-TOKEN', window.CSRF_TOKEN);
}); 

Сторона сервера

Після успішного входу в систему створіть випадковий (і досить довгий) маркер CSRF, збережіть його в сеансі на сервері та поверніть його клієнту. Фільтруйте певні (чутливі) вхідні запити, порівнюючи значення заголовка X-CSRF-TOKEN зі значенням, збереженим у сеансі: вони повинні відповідати.

Чутливі дзвінки AJAX (дані POST форми та GET JSON-дані) та фільтр на стороні сервера, що їх перехоплюють, знаходяться під шляхом / dataservice / *. Запити на вхід не повинні потрапляти до фільтра, тому вони знаходяться на іншому шляху. Запити на HTML, CSS, JS та ресурси зображення також не знаходяться на шляху / dataservice / *, тому не фільтруються. Вони не містять нічого секретного і не можуть завдати шкоди, тому це добре.

@WebFilter(urlPatterns = {"/dataservice/*"})
...
String sessionCSRFToken = req.getSession().getAttribute("CSRFToken") != null ? (String) req.getSession().getAttribute("CSRFToken") : null;
if (sessionCSRFToken == null || req.getHeader("X-CSRF-TOKEN") == null || !req.getHeader("X-CSRF-TOKEN").equals(sessionCSRFToken)) {
    resp.sendError(401);
} else
    chain.doFilter(request, response);
}