# CSRF (Cross Site Request Forgery)
Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)! Інші способи підтримки HackTricks: * Якщо ви хочете побачити вашу **компанію в рекламі HackTricks** або **завантажити HackTricks у форматі PDF**, перевірте [**ПЛАНИ ПІДПИСКИ**](https://github.com/sponsors/carlospolop)! * Отримайте [**офіційний PEASS & HackTricks мерч**](https://peass.creator-spring.com) * Відкрийте для себе [**Сім'ю PEASS**](https://opensea.io/collection/the-peass-family), нашу колекцію ексклюзивних [**NFT**](https://opensea.io/collection/the-peass-family) * **Приєднуйтесь до** 💬 [**групи Discord**](https://discord.gg/hRep4RUj7f) або [**групи telegram**](https://t.me/peass) або **слідкуйте** за нами на **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Поділіться своїми хакерськими трюками, надсилайте PR до** [**HackTricks**](https://github.com/carlospolop/hacktricks) та [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) репозиторіїв GitHub.
Приєднуйтесь до [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy), щоб спілкуватися з досвідченими хакерами та мисливцями за багами! **Інсайти щодо хакінгу**\ Взаємодійте з контентом, який досліджує захоплення та виклики хакінгу **Новини про хакінг у реальному часі**\ Будьте в курсі швидкозмінного світу хакінгу завдяки новинам та інсайтам у реальному часі **Останні оголошення**\ Будьте в курсі нових баг-баунті, які запускаються, та важливих оновлень платформи **Приєднуйтесь до нас на** [**Discord**](https://discord.com/invite/N3FrSbmwdy) та почніть співпрацювати з найкращими хакерами вже сьогодні! ## Пояснення Cross-Site Request Forgery (CSRF) **Cross-Site Request Forgery (CSRF)** - це тип уразливості безпеки, яку можна знайти в веб-додатках. Вона дозволяє зловмисникам виконувати дії від імені недопущених користувачів, використовуючи їх аутентифіковані сесії. Атака виконується, коли користувач, який увійшов до облікового запису жертви, відвідує зловмисний сайт. Цей сайт потім викликає запити до облікового запису жертви за допомогою методів, таких як виконання JavaScript, надсилання форм або отримання зображень. ### Передумови для атаки CSRF Для використання уразливості CSRF необхідно виконати кілька умов: 1. **Визначення цінної дії**: Зловмиснику потрібно знайти дію, яку варто використовувати, наприклад, зміну пароля користувача, електронної пошти або підвищення привілеїв. 2. **Управління сесією**: Сесію користувача повинно керуватися виключно за допомогою куків або заголовка HTTP Basic Authentication, оскільки інші заголовки не можуть бути змінені для цієї мети. 3. **Відсутність непередбачуваних параметрів**: Запит не повинен містити непередбачувані параметри, оскільки вони можуть запобігти атаки. ### Швидка перевірка Ви можете **захопити запит в Burp** та перевірити захист від CSRF, а також випробувати з браузера, натиснувши на **Копіювати як fetch** та перевірити запит:
### Захист від CSRF Для захисту від атак CSRF можна впровадити кілька протиправних заходів: * [**Куки з однаковим сайтом**](hacking-with-cookies/#samesite): Ця атрибут запобігає браузеру відправляти куки разом із запитами з інших сайтів. [Докладніше про куки з однаковим сайтом](hacking-with-cookies/#samesite). * [**Спільний доступ до ресурсів між джерелами**](cors-bypass.md): Політика CORS на сайті жертви може впливати на можливість атаки, особливо якщо для атаки потрібно прочитати відповідь від сайту жертви. [Дізнайтеся про обхід CORS](cors-bypass.md). * **Перевірка користувача**: Запит на введення пароля користувача або вирішення капчі може підтвердити намір користувача. * **Перевірка заголовків Referrer або Origin**: Перевірка цих заголовків може допомогти забезпечити, що запити надходять з надійних джерел. Однак ретельне створення URL-адрес може обійти погано реалізовані перевірки, наприклад: * Використання `http://mal.net?orig=http://example.com` (URL закінчується на довірений URL) * Використання `http://example.com.mal.net` (URL починається з довіреного URL) * **Зміна назв параметрів**: Зміна назв параметрів у запитах POST або GET може допомогти у запобіганні автоматизованих атак. * **Маркери CSRF**: Включення унікального маркера CSRF в кожну сесію та вимога цього маркера у наступних запитах може значно зменшити ризик CSRF. Ефективність маркера можна підвищити, вимагаючи CORS. Розуміння та впровадження цих захистів є важливим для забезпечення безпеки та цілісності веб-додатків. ## Обхід захисту ### Від POST до GET Можливо, форма, яку ви хочете використовувати, підготовлена для відправлення **POST-запиту з маркером CSRF**, проте вам слід **перевірити**, чи **дійсний GET** і чи при відправленні GET-запиту **маркер CSRF все ще перевіряється**. ### Відсутність маркера Додатки можуть використовувати механізм для **перевірки маркерів**, коли вони присутні. Однак вразливість виникає, якщо перевірка пропускається, коли маркер відсутній. Зловмисники можуть використовувати це, **видаливши параметр**, який містить маркер, а не лише його значення. Це дозволяє їм обійти процес перевірки та ефективно виконати атаку Cross-Site Request Forgery (CSRF). ### Маркер CSRF не пов'язаний з сесією користувача Додатки, які **не пов'язують маркери CSRF з сесіями користувачів**, створюють значний **ризик безпеки**. Ці системи перевіряють маркери проти **загального пулу**, а не забезпечують, що кожен маркер прив'язаний до початкової сесії. Ось як зловмисники використовують це: 1. **Аутентифікуйтеся** за допомогою власного облікового запису. 2. **Отримайте дійсний маркер CSRF** з загального пулу. 3. **Використовуйте цей маркер** у атаку CSRF проти жертви. Ця вразливість дозволяє зловмисникам робити несанкціоновані запити від імені жертви, використовуючи **недостатній механізм перевірки маркерів додатка**. ### Обхід методу Якщо запит використовує "**дивний**" **метод**, перевірте, чи працює **функціональність перевизначення методу**. Наприклад, якщо він **використовує метод PUT**, ви можете спробувати **використати метод POST** та **відправити**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_ Це також може працювати, відправляючи **параметр \_method всередині POST-запиту** або використовуючи **заголовки**: * _X-HTTP-Method_ * _X-HTTP-Method-Override_ * _X-Method-Override_ ### Обхід маркера власного заголовка Якщо запит додає **власний заголовок** з **маркером** до запиту як **захист від CSRF**, тоді: * Протестируйте запит без **власного маркера та також заголовка**. * Протестируйте запит з точно **такою ж довжиною, але іншим маркером**. ### Перевірка маркера CSRF за допомогою куки Додатки можуть впроваджувати захист від CSRF, дублюючи маркер як у куці, так і в параметрі запиту або встановлюючи куку CSRF та перевіряючи, чи маркер, відправлений на сервер, відповідає значенню в куці. Додаток перевіряє запити, перевіряючи, чи маркер у параметрі запиту відповідає значенню в куці. Однак цей метод вразливий до атак CSRF, якщо на веб-сайті є дефекти, які дозволяють зловмиснику встановити куку CSRF в браузері жертви, наприклад, вразливість CRLF. Зловмисник може використовувати це, завантажуючи обманливе зображення, яке встановлює куку, а потім ініціюючи атаку CSRF. Нижче наведено приклад того, як може бути структурована атака: ```html
``` {% hint style="info" %} Зверніть увагу, що якщо **токен csrf пов'язаний з сесійним cookie**, цей атака не працюватиме, оскільки вам потрібно буде встановити жертві вашу сесію, і, отже, ви будете атакувати себе. {% endhint %} ### Зміна Content-Type Згідно з [**цим**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), для **уникнення попередніх запитів** за допомогою методу **POST** дозволені наступні значення Content-Type: * **`application/x-www-form-urlencoded`** * **`multipart/form-data`** * **`text/plain`** Проте, слід зауважити, що **логіка сервера може відрізнятися** в залежності від використаного Content-Type, тому варто спробувати зазначені значення та інші, такі як **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ Приклад (з [тут](https://brycec.me/posts/corctf\_2021\_challenges)) відправлення даних JSON як text/plain: ```html
``` ### Обхід запитів на попередню перевірку для даних JSON При спробі надіслати дані JSON через запит POST, використання `Content-Type: application/json` в HTML-формі не є безпосередньо можливим. Так само, використання `XMLHttpRequest` для надсилання цього типу вмісту ініціює запит на попередню перевірку. Тем не менш, існують стратегії, які потенційно дозволяють обійти це обмеження та перевірити, чи обробляє сервер дані JSON незалежно від Content-Type: 1. **Використання альтернативних типів вмісту**: Використовуйте `Content-Type: text/plain` або `Content-Type: application/x-www-form-urlencoded`, встановивши `enctype="text/plain"` у формі. Цей підхід перевіряє, чи використовує сервер дані незалежно від Content-Type. 2. **Зміна типу вмісту**: Щоб уникнути запиту на попередню перевірку, забезпечуючи визнання сервером вмісту як JSON, ви можете надіслати дані з `Content-Type: text/plain; application/json`. Це не викликає запит на попередню перевірку, але може бути правильно оброблено сервером, якщо він налаштований на прийом `application/json`. 3. **Використання файлу SWF Flash**: Менш поширений, але можливий метод включає використання файлу SWF Flash для обходу таких обмежень. Для глибшого розуміння цієї техніки див. [цей пост](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937). ### Обхід перевірки Referrer / Origin **Уникайте заголовка Referrer** Додатки можуть перевіряти заголовок 'Referer' лише тоді, коли він присутній. Щоб запобігти відправці цього заголовка браузером, можна використовувати наступний HTML мета-тег: ```xml ``` Це забезпечує відсутність заголовка 'Referer', що потенційно дозволяє обійти перевірку в деяких додатках. **Обхід регулярних виразів** {% content-ref url="ssrf-server-side-request-forgery/url-format-bypass.md" %} [url-format-bypass.md](ssrf-server-side-request-forgery/url-format-bypass.md) {% endcontent-ref %} Для встановлення доменного імені сервера в URL, який Referrer буде відправляти в параметрах, можна використовувати: ```html
``` ### **Обхід методу HEAD** Перша частина [**цього опису CTF**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) пояснює, що [вихідний код Oak](https://github.com/oakserver/oak/blob/main/router.ts#L281), маршрутизатор встановлений для **обробки запитів HEAD як запитів GET** без тіла відповіді - загальний обхід, який не є унікальним для Oak. Замість конкретного обробника, який працює з HEAD-запитами, вони просто **передаються обробнику GET, але додаток просто видаляє тіло відповіді**. Отже, якщо запит GET обмежений, ви можете просто **надіслати запит HEAD, який буде оброблений як запит GET**. ## **Приклади використання** ### **Витік CSRF-токену** Якщо використовується **CSRF-токен** як **захист**, ви можете спробувати **витягнути його** зловживаючи [**уразливістю XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) або [**вразливістю Dangling Markup**](dangling-markup-html-scriptless-injection/). ### **GET за допомогою HTML-тегів** ```xml

404 - Page not found

The URL you are requesting is no longer available ``` Інші теги HTML5, які можна використовувати для автоматичного відправлення GET-запиту: ```html