Notice: file_put_contents(): Write of 3459 bytes failed with errno=28 No space left on device in /var/www/tg-me/post.php on line 50

Warning: file_put_contents(): Only 8192 of 11651 bytes written, possibly out of free disk space in /var/www/tg-me/post.php on line 50
PythonSec | Telegram Webview: hackedbypython/300 -
Telegram Group & Telegram Channel
Boo🧨

Асап, так получилось, что я отсутствовал полтора года. Но вроде как, теперь есть вариант писать сюда. Пробуем новый, тестовый формат, где я описываю обезличенные случаи из своей практики AppSec.

В рамках такого формата, хотелось бы поговорить про самую частую уязвимость, которую я находил в своих проектах. Это broken access control.

Стоит отметить, что понятие уязвимости, которое может вписываться в эту категорию всегда будет разным. Так например одна уязвимость, которую можно "занести" на Bug Bounty и уяза, которую можно зарепортить во время тестирования безопасности сервиса - может иметь разную оценку по критичности.

Теперь когда с этим разобрались можно приступать к основной части.

По идее нарушенный контроль доступа или же B.A.C. (почти как ACAB) это уязвимость в веб-приложении которая позволяет злоумышленнику получить доступ к функциональности, для эксплуатации которой у него нет прав. Для этого очевидно, в приложении должна быть реализована ролевая модель. Или нет? Давайте разберем два случая. Когда она есть и когда ее нет.

В рамках тестирования сервиса X на Bug Bounty, удалось использовать уязвимость нарушенного контроля доступа чтобы запостить новость в афише от имени администратора, прикрепив туда изображение в формате svg, которое содержит в себе полезную нагрузку для триггера XSS уязвимости. Получается, что тут 2 проблемы. Это небезопасная загрузка файлов и IDOR. Если первая уяза совершенно не по теме, давайте разберемся с нашим контролем доступа.

В моем случае сервис посылал POST запрос на создание новости в афише. Изучив api, я смог посмотреть какие параметры передются в JSON через этот POST запрос и подметил для себя тот факт, что в запросе передаётся user id и другой параметр, который проверял прошла ли новость модерацию. Изменив user id на id администратора и исправив другой параметр с false на true, я получил IDOR на стероидах, который из-за отсутствия корректной валидации данных параметров со стороны обычного пользователя, без привилегий позволяет нам создать фейковую новость с кликбейтным названием, плюс ко всему еще и тригерит наш Stored XSS.

Если ролевая модель толком не реализована и сервис не позволяет нам работать через POST, PUT и PATCH запросы - имеет смысл провести разведку API для выявления "подозрительных ручек". Например сервис X не позволяет пользователям вносить изменения на стороне сервера, однако это еще не значит, что вектор нарушенного контроля доступа надо вычеркивать из флоу тестирования. В рамках тестирования, уязвимостью нарушенного контроля доступа может считаться страница, где производиться вход в админку, получаются данные дургих пользователей сервиса (критичность уязы в таком случае зависит от контекста приватности информации) или даже доступ в /metrics, где будут разглашены внутренние хосты и весь api.



tg-me.com/hackedbypython/300
Create:
Last Update:

Boo🧨

Асап, так получилось, что я отсутствовал полтора года. Но вроде как, теперь есть вариант писать сюда. Пробуем новый, тестовый формат, где я описываю обезличенные случаи из своей практики AppSec.

В рамках такого формата, хотелось бы поговорить про самую частую уязвимость, которую я находил в своих проектах. Это broken access control.

Стоит отметить, что понятие уязвимости, которое может вписываться в эту категорию всегда будет разным. Так например одна уязвимость, которую можно "занести" на Bug Bounty и уяза, которую можно зарепортить во время тестирования безопасности сервиса - может иметь разную оценку по критичности.

Теперь когда с этим разобрались можно приступать к основной части.

По идее нарушенный контроль доступа или же B.A.C. (почти как ACAB) это уязвимость в веб-приложении которая позволяет злоумышленнику получить доступ к функциональности, для эксплуатации которой у него нет прав. Для этого очевидно, в приложении должна быть реализована ролевая модель. Или нет? Давайте разберем два случая. Когда она есть и когда ее нет.

В рамках тестирования сервиса X на Bug Bounty, удалось использовать уязвимость нарушенного контроля доступа чтобы запостить новость в афише от имени администратора, прикрепив туда изображение в формате svg, которое содержит в себе полезную нагрузку для триггера XSS уязвимости. Получается, что тут 2 проблемы. Это небезопасная загрузка файлов и IDOR. Если первая уяза совершенно не по теме, давайте разберемся с нашим контролем доступа.

В моем случае сервис посылал POST запрос на создание новости в афише. Изучив api, я смог посмотреть какие параметры передются в JSON через этот POST запрос и подметил для себя тот факт, что в запросе передаётся user id и другой параметр, который проверял прошла ли новость модерацию. Изменив user id на id администратора и исправив другой параметр с false на true, я получил IDOR на стероидах, который из-за отсутствия корректной валидации данных параметров со стороны обычного пользователя, без привилегий позволяет нам создать фейковую новость с кликбейтным названием, плюс ко всему еще и тригерит наш Stored XSS.

Если ролевая модель толком не реализована и сервис не позволяет нам работать через POST, PUT и PATCH запросы - имеет смысл провести разведку API для выявления "подозрительных ручек". Например сервис X не позволяет пользователям вносить изменения на стороне сервера, однако это еще не значит, что вектор нарушенного контроля доступа надо вычеркивать из флоу тестирования. В рамках тестирования, уязвимостью нарушенного контроля доступа может считаться страница, где производиться вход в админку, получаются данные дургих пользователей сервиса (критичность уязы в таком случае зависит от контекста приватности информации) или даже доступ в /metrics, где будут разглашены внутренние хосты и весь api.

BY PythonSec


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/hackedbypython/300

View MORE
Open in Telegram


PythonSec Telegram | DID YOU KNOW?

Date: |

Telegram today rolling out an update which brings with it several new features.The update also adds interactive emoji. When you send one of the select animated emoji in chat, you can now tap on it to initiate a full screen animation. The update also adds interactive emoji. When you send one of the select animated emoji in chat, you can now tap on it to initiate a full screen animation. This is then visible to you or anyone else who's also present in chat at the moment. The animations are also accompanied by vibrations. This is then visible to you or anyone else who's also present in chat at the moment. The animations are also accompanied by vibrations.

That growth environment will include rising inflation and interest rates. Those upward shifts naturally accompany healthy growth periods as the demand for resources, products and services rise. Importantly, the Federal Reserve has laid out the rationale for not interfering with that natural growth transition.It's not exactly a fad, but there is a widespread willingness to pay up for a growth story. Classic fundamental analysis takes a back seat. Even negative earnings are ignored. In fact, positive earnings seem to be a limiting measure, producing the question, "Is that all you've got?" The preference is a vision of untold riches when the exciting story plays out as expected.

PythonSec from ua


Telegram PythonSec
FROM USA