Кратко:

Сервер доверяет данным, которые приходят от клиента, и использует их для проверки роли пользователя

Эксплуатация:
1. Ищем панель администратора при помощи dirb

2. Переходим на найденную панель администратора и ловим запрос через BurpSuite, меняем значение
admin=false на admin=true

3. Отправляем изменённый запрос дальше

4. Мы в панеле администратора, удаляем пользователя carlos

5. Решено✅

P.s в посте выше можно прочитать подробнее

Перепрошёл Лабу: User-ID-Controlled-by-Request-Parameter-with-Unpredictable-User-IDs

В данной лабораторной присутствует уязвимость типа IDOR (Insecure Direct Object Reference).
Приложение использует идентификатор пользователя в параметре запроса и передаёт страницу аккаунта без проверки владельца ресурса

Из-за этого можно заменить свой ID на чужой и получить доступ к данным другого пользователя.

Эксплуатация:
1. Авторизуемся в аккаунт с выданными данными лаборатории.

2. Напрямую подобрать чужой ID не получится, так как используются непредсказуемые значения, поэтому переходим в пост пользователя carlos и замечаем его идентификатор в ссылке профиля

3. Копируем найденный ID, затем открываем страницу My account и заменяем свой идентификатор на ID пользователя carlos

4. После перехода открывается аккаунт carlos, откуда получаем его API Key.

5. Отправляем найденный API Key для завершения лабораторной.

Перепрошёл лабу User ID controlled by request parameter with password disclosure

Уязвимость IDOR в параметре User ID с раскрытием пароля

В этой лаборатории присутствует уязвимость типа IDOR. Существует незащищённый аккаунт, в который можно войти, просто подставив его ID в запрос. Для решения задачи нужно узнать пароль администратора, войти в его аккаунт и удалить пользователя carlos.

1. Входим в наш аккаунт с предоставленными данными: wiener:peter.

2. Ищем уязвимость. Перехватываю запрос с параметром my-account?id=wiener и меняю ID. В ходе исследования мне удалось зайти в аккаунты carlos и administrator, но пароль не отображается. Хотя я в аккаунте администратора, админ-панель недоступна. Чтобы войти корректно, сначала нужно узнать пароль.

3. Переходим в BurpSuite. После входа в аккаунт administrator включаем перехват (Intercept), обновляем страницу и ловим запрос с my-account?id=administrator. Отправляем его в Repeater, нажимаем Send и изучаем ответ сервера. В ответе раскрывается исходный код страницы, где виден пароль пользователя administrator.

4. Заходим в аккаунт administrator с найденным паролем и удаляем пользователя carlos.

И так, снова пополнил свой запас врайтапов, перепрошёл лабораторию:
Lab: Username enumeration via different responses

Lab: Username enumeration via different responses

Суть уязвимости в этой лаборатории была в том что при регистрации, сайт отвечает incorrect password если вы подобрали правильный username то будет писать incorrect password, а должно incorrect password or username, так злоумышленникам труднее будет брутфорсить чужие данные

Приступим как обычно к решению:
1. Перехватываем запрос регистрации аккаунта с методом POST

2. Нажимаем по запросу и отправляем в Intruder, нажимаем add §§ и перебираем для начала username так же не забудьте добавить список имён пользователей, его даёт Portswigger копируете и вставляете в intuder, запускаете брутфорс и ждёте пока intuder найдет правильный username, как вы поймёте что он правильный? всё просто в строке Length все запросы будут одинаковый длины — Lenght, а правильный юзернейм будет отличаться длиной, так же вы можете это подтвердить если нажмёте на этот юзернейм и посмотрите ответ от сервера там будет Incorrect password

3. Брутфорс пароля, всё тоже самое только теперь с строкой password, только здесь когда вы уже найдете правильный пароль код статуса будет не 200 а 302 — редирект, и так же длина запроса будет маленькой и отличаться от всех, будьте внимательны

4. Когда вы нашли правильный юзернейм и пароль, просто вводите их и заходите на аккаунт, лаборатория будет защитана.

брутф0рс username через intruder

брутфорс password

Перепрошёл Лабу: 2FA-Simple-Bypass

Lab: 2FA Simple Bypass

Уязвимость заключается в том, что сайт не проверяет завершение 2FA и сразу создаёт сессию пользователя. Доступ к аккаунту можно получить, просто изменив ссылку и обойдя 2FA.

Решение:
1. Авторизуемся в аккаунт carlos:montoya.
2. Нам предлагают ввести код 2FA. Не вводя его, сразу переходим по ссылке /my-account?id=carlos.
3. Всё, после входа в аккаунт лаборатория считается решённой.

SSRF — когда сервер ходит туда, куда скажешь ты

SSRF (Server-Side Request Forgery) — это уязвимость, при которой приложение принимает URL от пользователя и делает запрос от имени сервера

Пример:

stockApi=http://example.com

Сервер идёт на этот адрес и скидывает ответ, доверяя пользователю, но атакующий может подсунуть в url:

http://localhost

или даже:

http://127.0.0.1

И тогда сервер начнет обращаться к внутренним ресурсам, которые обычному пользователю недоступны.

Что можно сделать через SSRF?
• попасть во внутренние админ-панели
• сканировать внутреннюю сеть
• обращаться к "localhost"
• получать cloud metadata ("169.254.169.254")
• иногда приводить к RCE

Lab: Basic SSRF against the local server

В данной лаборатории присутствует уязвимость типа SSRF
Цель лаборатории — получить доступ к админке и удалить пользователя carlos

1. Анализируем сайт, заходим на любой пост, скроллим вниз и видим кнопку check stock, которая обращается к API

2. Перехватываем запрос в BurpSuite:

POST /product/stock HTTP/1.1
Host: TARGET-LAB.web-security-academy.net

stockApi=http://stock.weliketoshop.net:8080/product/stock/check?productId=1&storeId=1

3. Изменяем URL и отправляем в Repeater:

POST /product/stock HTTP/1.1
Host: TARGET-LAB.web-security-academy.net

stockApi=http://localhost/admin

Мы получили доступ к внутренней админке, но заметьте, если мы нажмём на сайте кнопку admin panel, или попытаемся на прямую удалить пользователя carlos, у нас ничего не выйдет, т.к доступ к админке обычному пользователю ограничен, анализируем ответ от сервера и видим ссылку на удаление пользователя carlos, копируем и вставляем в новый изменённый запрос:

POST /product/stock HTTP/1.1
Host: TARGET-LAB.web-security-academy.net

stockApi=http://localhost/admin/delete?username=carlos

4. Отправляем запрос, и лаборатория засчитывается как решенная после удаления пользователя carlos

Посмотреть решенную лабу на моем GitHub (Кликабельно)

Lab: Basic SSRF against another back-end system

В данной лаборатории присутствует уязвимость типа SSRF
Цель лаборатории — найти внутренний бэкенд-сервер с админ панелью, и удалить пользователя carlos

Решение:
1. Открываем любой товар, и ищем кнопку check stock которая обращается к API, перехватыем ее запрос в BurpSuite

2. Из описания лаборатории нам известно, что внутренний айпи находится в диапазоне 192.168.0.Х

3. В BurpSuite Intruder перебираем диапазон от нуля до 255, такой payload должен у вас получится:
http://192.168.0.§X§:8080/admin

4. Находим нужный IP, большинство адресов вернут код статуса 500 или 400, нам нужем ответ с кодом статуса 200

5. Удаляем пользователя, вот такой примерно у нас должен быть SSRF:

POST /product/stock HTTP/1.1
Host: TARGET-LAB.web-security-academy.net

stockApi=http://192.168.0.157:8080/admin/delete?username=carlos

Посмотреть write-up по этой лабе:
GitHub(Aspyd0x) <------ Click