Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
**Cross-Site Request Forgery (CSRF)** - це тип вразливості безпеки, що зустрічається у веб-додатках. Він дозволяє зловмисникам виконувати дії від імені нічого не підозрюючих користувачів, експлуатуючи їх автентифіковані сесії. Атака виконується, коли користувач, який увійшов до платформи жертви, відвідує шкідливий сайт. Цей сайт потім викликає запити до облікового запису жертви через методи, такі як виконання JavaScript, надсилання форм або отримання зображень.
1.**Визначити цінну дію**: Зловмисник повинен знайти дію, яку варто експлуатувати, наприклад, зміну пароля користувача, електронної пошти або підвищення привілеїв.
2.**Управління сесією**: Сесія користувача повинна управлятися виключно через куки або заголовок HTTP Basic Authentication, оскільки інші заголовки не можуть бути змінені для цієї мети.
3.**Відсутність непередбачуваних параметрів**: Запит не повинен містити непередбачуваних параметрів, оскільки вони можуть завадити атаці.
* [**SameSite cookies**](hacking-with-cookies/#samesite): Цей атрибут запобігає браузеру від надсилання куків разом із запитами з інших сайтів. [Більше про куки SameSite](hacking-with-cookies/#samesite).
* [**Cross-origin resource sharing**](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 Tokens**: Включення унікального токена 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 токен пов'язаний з сесійним кукі**, ця атака не спрацює, оскільки вам потрібно буде встановити жертві вашу сесію, і, отже, ви будете атакувати себе.
Згідно з [**цим**](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)
Код може бути використаний для брутфорсу форми входу, використовуючи CSRF токен (також використовується заголовок X-Forwarded-For, щоб спробувати обійти можливе блокування IP):
Приєднуйтесь до [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) сервера, щоб спілкуватися з досвідченими хакерами та шукачами вразливостей!
Вчіться та практикуйте хакінг AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Вчіться та практикуйте хакінг GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* **Приєднуйтесь до** 💬 [**групи Discord**](https://discord.gg/hRep4RUj7f) або [**групи в телеграмі**](https://t.me/peass) або**слідкуйте** за нами в **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Діліться хакерськими трюками, надсилаючи PR до** [**HackTricks**](https://github.com/carlospolop/hacktricks) та [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) репозиторіїв на github.