<summary><strong>Вивчайте хакінг AWS від нуля до героя з</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Якщо ви хочете побачити вашу **компанію в рекламі HackTricks**або**завантажити HackTricks у форматі PDF**, перевірте [**ПЛАНИ ПІДПИСКИ**](https://github.com/sponsors/carlospolop)!
* Відкрийте для себе [**Сім'ю 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.
**Cross-Site Request Forgery (CSRF)** - це тип уразливості безпеки, яку можна знайти в веб-додатках. Вона дозволяє зловмисникам виконувати дії від імені недопущених користувачів, використовуючи їх аутентифіковані сесії. Атака виконується, коли користувач, який увійшов до облікового запису жертви, відвідує зловмисний сайт. Цей сайт потім викликає запити до облікового запису жертви за допомогою методів, таких як виконання JavaScript, надсилання форм або отримання зображень.
1.**Визначення цінної дії**: Зловмиснику потрібно знайти дію, яку варто використовувати, наприклад, зміну пароля користувача, електронної пошти або підвищення привілеїв.
2.**Управління сесією**: Сесію користувача повинно керуватися виключно за допомогою куків або заголовка HTTP Basic Authentication, оскільки інші заголовки не можуть бути змінені для цієї мети.
3.**Відсутність непередбачуваних параметрів**: Запит не повинен містити непередбачувані параметри, оскільки вони можуть запобігти атаки.
Ви можете **захопити запит в Burp** та перевірити захист від CSRF, а також випробувати з браузера, натиснувши на **Копіювати як fetch** та перевірити запит:
* [**Куки з однаковим сайтом**](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-запиту з маркером CSRF**, проте вам слід **перевірити**, чи **дійсний GET**і чи при відправленні GET-запиту **маркер CSRF все ще перевіряється**.
Додатки можуть використовувати механізм для **перевірки маркерів**, коли вони присутні. Однак вразливість виникає, якщо перевірка пропускається, коли маркер відсутній. Зловмисники можуть використовувати це, **видаливши параметр**, який містить маркер, а не лише його значення. Це дозволяє їм обійти процес перевірки та ефективно виконати атаку Cross-Site Request Forgery (CSRF).
Додатки, які **не пов'язують маркери CSRF з сесіями користувачів**, створюють значний **ризик безпеки**. Ці системи перевіряють маркери проти **загального пулу**, а не забезпечують, що кожен маркер прив'язаний до початкової сесії.
Ця вразливість дозволяє зловмисникам робити несанкціоновані запити від імені жертви, використовуючи **недостатній механізм перевірки маркерів додатка**.
Якщо запит використовує "**дивний**" **метод**, перевірте, чи працює **функціональність перевизначення методу**. Наприклад, якщо він **використовує метод PUT**, ви можете спробувати **використати метод POST** та **відправити**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
Додатки можуть впроваджувати захист від CSRF, дублюючи маркер як у куці, так і в параметрі запиту або встановлюючи куку CSRF та перевіряючи, чи маркер, відправлений на сервер, відповідає значенню в куці. Додаток перевіряє запити, перевіряючи, чи маркер у параметрі запиту відповідає значенню в куці.
Однак цей метод вразливий до атак CSRF, якщо на веб-сайті є дефекти, які дозволяють зловмиснику встановити куку CSRF в браузері жертви, наприклад, вразливість CRLF. Зловмисник може використовувати це, завантажуючи обманливе зображення, яке встановлює куку, а потім ініціюючи атаку CSRF.
Зверніть увагу, що якщо **токен csrf пов'язаний з сесійним cookie**, цей атака не працюватиме, оскільки вам потрібно буде встановити жертві вашу сесію, і, отже, ви будете атакувати себе.
Згідно з [**цим**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), для **уникнення попередніх запитів** за допомогою методу **POST** дозволені наступні значення Content-Type:
Проте, слід зауважити, що **логіка сервера може відрізнятися** в залежності від використаного Content-Type, тому варто спробувати зазначені значення та інші, такі як **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
При спробі надіслати дані 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).
Додатки можуть перевіряти заголовок 'Referer' лише тоді, коли він присутній. Щоб запобігти відправці цього заголовка браузером, можна використовувати наступний HTML мета-тег:
Перша частина [**цього опису 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, але додаток просто видаляє тіло відповіді**.
Якщо використовується **CSRF-токен** як **захист**, ви можете спробувати **витягнути його** зловживаючи [**уразливістю XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) або [**вразливістю Dangling Markup**](dangling-markup-html-scriptless-injection/).
xh.setRequestHeader('Content-type', 'application/x-www-form-urlencoded'); //to send proper header info (optional, but good to have as it may sometimes not work without this)
Код може бути використаний для Brut Force форми входу за допомогою токена CSRF (Також використовує заголовок X-Forwarded-For для спроби обійти можливе чорніння IP):
<summary><strong>Вивчайте хакінг AWS від нуля до героя з</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Якщо ви хочете побачити вашу **компанію рекламовану на HackTricks**або**завантажити HackTricks у PDF-форматі**, перевірте [**ПЛАНИ ПІДПИСКИ**](https://github.com/sponsors/carlospolop)!
* Відкрийте для себе [**Сім'ю 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 репозиторіїв.