Предисловие▸

С тех пор, как я присоединился к Byte Wuheng Labs в 2022.5, я занимался работой, связанной с SDLC. Одним из тупиков автоматизированных функций безопасности в SDLC является DAST (динамический тест безопасности приложений), который также является очень важным средством достижения сдвига безопасности влево. Я сам последние два месяца также занимался разработкой продуктов DAST, и моя цель, естественно, — внедрить их в коммерческое использование. Разработанный мной DAST не будет иметь открытый исходный код, но недавно у меня появилась возможность написать инструмент безопасности, поэтому я просто использовал Python для написания инструмента горизонтального несанкционированного обнаружения. Меня не волнует уровень ложных тревог и уровень утечек воды. В любом случае, я могу иметь код, который превратит PPT в ерунду.

Уязвимости переопределения полномочий всегда были болевой точкой в ​​бизнесе крупных компаний. Традиционные уязвимости, такие как SSRF, SQL-инъекция, XXE и другие уязвимости, уже могут быть успешно запущены в бизнесе под прикрытием плагинов безопасности IDE, разработки безопасности. комплекты, SAST, IAST, DAST, ручное тестирование и т. д. перед проверкой на этапах кодирования и тестирования. Однако, как логическая уязвимость, несанкционированный доступ имеет другие языковые характеристики и логику аутентификации. Если инструменты безопасности слишком сильно застряли, это не только увеличит количество ложных срабатываний, но и снизит уверенность НИОКР в безопасности, препятствуя внедрению SDLC. или DevSecOps; если инструменты безопасности слишком зависли, «слабые точки зависания» приведут к утечке большого количества уязвимостей в сеть, что представляет собой серьезную угрозу безопасности для бизнеса. Поэтому вопрос о том, как точно, эффективно и всесторонне обнаруживать логические уязвимости, является важным аспектом. инструменты безопасности производителей необходимо срочно улучшить.

Раскопки уязвимостей горизонтального переопределения▸

Выходные данные моей уязвимости▸

Обычно я создаю много несанкционированных уязвимостей в компании. Например, в месяц появляется около 10 уязвимостей высокого и серьезного риска, а также уязвимостей среднего и низкого риска. Кроме того, я обычно участвую в проверке поданных уязвимостей. от SRC, и я видел много отчетов белых шляп, поэтому я все еще имею право говорить.

Судя по данным, 95% трехзначных переопределений, которые я нашел, имеют общие характеристики, которые представляют собой как навыки поиска уязвимостей, так и характеристики обнаружения уязвимостей.

Навыки горного дела▸

Во-первых, давайте приведем два примера, а именно интерфейс для запроса списка заказов и запроса деталей заказа.

GET /order/list/get_order_list HTTP/1.2
<span class="hljs-attribute">Host</span><span class="hljs-punctuation">: </span>shop.y1ng.vip
<span class="hljs-attribute">Cookie</span><span class="hljs-punctuation">: </span>passport_session=JXJXXJXJXJXJXJX
<span class="hljs-attribute">Accept-Encoding</span><span class="hljs-punctuation">: </span>gzip, deflate
<span class="hljs-attribute">Connection</span><span class="hljs-punctuation">: </span>close

GET /order/detail/get_order_detail?order_id=83898379392 HTTP/1.2
<span class="hljs-attribute">Host</span><span class="hljs-punctuation">: </span>shop.y1ng.vip
<span class="hljs-attribute">Cookie</span><span class="hljs-punctuation">: </span>passport_session=JXJXXJXJXJXJXJX
<span class="hljs-attribute">Accept-Encoding</span><span class="hljs-punctuation">: </span>gzip, deflate
<span class="hljs-attribute">Connection</span><span class="hljs-punctuation">: </span>close

В двух вышеупомянутых интерфейсах,Очевидно, только второй мог превысить свои полномочия.,Первое невозможно. Причина тоже очень проста,Первый интерфейс запрашивает все списки заказов.,Просто определите вошедшего в систему пользователя на основе файла cookie, а затем получите список заказов пользователя.,Нет параметров, которые можно подделать, второй интерфейс другой;,Бэкэнд будет основан на входящихorder_idПроверьте детали заказа,если не сделаноorder_idПроверка с текущим вошедшим в систему пользователем,Есть горизонтальные ультравиры.

Для первого интерфейса вы можете внести «ненужные» изменения, чтобы сделать его уязвимым:

GET /order/list/get_order_list?user_id=1234567 HTTP/1.2
<span class="hljs-attribute">Host</span><span class="hljs-punctuation">: </span>shop.y1ng.vip
<span class="hljs-attribute">Cookie</span><span class="hljs-punctuation">: </span>passport_session=JXJXXJXJXJXJXJX
<span class="hljs-attribute">Accept-Encoding</span><span class="hljs-punctuation">: </span>gzip, deflate
<span class="hljs-attribute">Connection</span><span class="hljs-punctuation">: </span>close

Таким образом, с помощью приведенных выше примеров мы можем найти характеристику: уязвимость несанкционированного доступа в основном возникает в определенном параметре интерфейса. Изменяя этот параметр на идентификатор ресурса других пользователей и получая к нему доступ, мы можем определить, существует ли несанкционированный доступ. .

На самом деле при поиске уязвимостей существует не более двух методов:

1. Замените xxxId или xxxCode в пакете данных на чужой xxxId/xxxCode и воспроизведите его, чтобы проверить, успешен ли запрос.
2. Замените информацию аутентификации (например, cookie/jwt) в пакете данных на информацию учетной записи B, а затем воспроизведите ее. В это время параметр xxxId все еще принадлежит учетной записи A. Посмотрите, можете ли вы успешно получить доступ к данным A как учетная запись B. .

При обнаружении уязвимостей «черного ящика» сосредоточьтесь на поиске тех интерфейсов, которым необходимо передавать параметры, собирать различную информацию о параметрах и при необходимости проходить напрямую.

Майнинг уязвимостей с точки зрения стороны А▸

На самом деле внутри компании сообщается о гораздо большем количестве уязвимостей, чем во внешних SRC. По сути, около 95% уязвимостей обнаруживаются внутренними сотрудниками, а 100% высокорискованных и серьезных утечек являются целевыми. высокий риск и серьезные утечки наружу. Но реальная ситуация такова, что внешних «белых шляп» больше, чем внутренних сотрудников. Почему внутри обнаруживается больше уязвимостей?

Для ультравирусов существует два только что упомянутых метода обнаружения:

1. Замените xxxId или xxxCode в пакете данных на чужой xxxId/xxxCode и воспроизведите его, чтобы проверить, успешен ли запрос.
2. Замените информацию аутентификации (например, cookie/jwt) в пакете данных на информацию учетной записи B, а затем воспроизведите ее. В это время параметр xxxId все еще принадлежит учетной записи A. Посмотрите, можете ли вы успешно получить доступ к данным A как учетная запись B. .

Однако на самом деле у чисто черных ящиков есть много трудностей, которые сложнее и у белых шляп:

1. Я не знаком с системой и не имею прав на многие функции, поэтому многие API-интерфейсы недоступны.
2. Наконец-то я нашел интерфейс и мне нужно было заменить параметры на чужие параметры, но я не знал, что такое чужие параметры, а сами параметры не имели правил.
3. Сам сайт не позволяет зарегистрировать два аккаунта, либо за использование функций сайта взимается плата (требуется пополнение счета, чтобы пополнить счет на рытье ям).
4. Результаты поведения некоторых интерфейсов не возвращаются, поэтому невозможно определить, было ли переопределение успешным.
5. Некоторые функциональные точки не имеют данных. Без данных невозможно ими управлять и инициировать запросы. Прямой анализ js не может их проанализировать.

Но с точки зрения Стороны А все по-другому. Как Сторона А, у вас есть много преимуществ:

1. Вы можете увидеть исходный код, и функции понятны с первого взгляда.
2. Если вы чего-то не понимаете и не уверены, вы можете напрямую нанять однокурсников по исследованиям и разработкам/QA/PM.
3. Существует выделенная тестовая учетная запись, в которой можно использовать практически все функции, и вы можете использовать ее без подзарядки.
4. Если данных нет, просто попросите QA создать данные.
5. Вам необходимо запросить xxxId других людей. Нет необходимости собирать соответствующую информацию или просматривать ее. Вы можете искать непосредственно в журнале. Все данные запроса пользователя будут помещены на диск, или вы можете искать их непосредственно в базе данных. очень удобно (но будьте осторожны, чтобы не повлиять на онлайн-пользователей. Вы можете быть уверены в интерфейсе чтения, но интерфейс операции записи должен находиться в тестовой среде)
6. Опираясь на полную инфраструктуру, прямую удаленную неблокирующую отладку и отладку кода на месте.

кроме того,Белые шляпы постараются максимизировать свои риски, чтобы получить бонусы.,То же самое касается нападающего в наступательных и оборонительных упражнениях.,Поэтому обнаружение потенциальной проблемы требует как можно большей глубины. Но партия А другая,Для Стороны А это не что иное, как майнинг рисков.->управление рисками,Нажмите до тех пор,Если вы нашли лазейку, дайте R&D ее исправить, и все.,Нет необходимости в глубоком использовании,Потому что независимо от того, можно ли его использовать глубоко или нет, окончательное решение состоит в том, чтобы устранить лазейки. В результате, как только лазейки будут устранены, их невозможно будет использовать.,Это также делает Сторону А очень эффективной в самостоятельном рытье ям.,За один день можно изготовить несколько.

некоторые другие сцены▸

Конечно, не все переопределения соответствуют описанным выше характеристикам. Существуют также некоторые особые сценарии, которые могут быть вызваны комбинацией таких факторов, как инфраструктура, промежуточная платформа, логика сокрытия, понижение версии запроса и т. д.; вызвано проблемами с логикой самого кода. Например, используйте подстановочные знаки, специальные символы, а также компоненты с открытым исходным кодом, такие как shiro bypass.

Это довольно экстремальные вещи, но большая часть моей работы связана с инфраструктурой, и я часто с ними сталкиваюсь, поэтому не буду вдаваться в подробности, потому что они не универсальны.

Автоматическое обнаружение несанкционированных уязвимостей▸

Метод реализации▸

Продолжим рассматривать два вышеупомянутых метода обнаружения:

1. Замените xxxId или xxxCode в пакете данных на чужой xxxId/xxxCode и воспроизведите его, чтобы проверить, успешен ли запрос.
2. Замените информацию аутентификации (например, cookie/jwt) в пакете данных на информацию учетной записи B, а затем воспроизведите ее. В это время параметр xxxId все еще принадлежит учетной записи A. Посмотрите, можете ли вы успешно получить доступ к данным A как учетная запись B. .

Очевидно, вам следует выбрать второй вариант для сценариев автоматизации, потому что ваш инструмент не может знать xxxIds такого большого количества других людей. Различные интерфейсы имеют разные xxxIds, если только вы не можете напрямую имитировать или подключиться к серверной части RDS, которая является чисто черным. box. Это нецелесообразно для тестирования инструментов. А вот второй тип очень прост: при обнаружении инструменту нужно только заранее настроить файл cookie новой учетной записи, заменить новый файл cookie запросом, а затем воспроизвести его, а затем сравнить два ответа, если сравнение прошло успешно. считается, что имело место злоупотребление полномочиями.

В реальном процессе разработки,Разнообразие целевых систем должно быть полностью учтено.,Например, аутентификация может не полностью проходить через файлы cookie.,Некоторые параметры в заголовке или GET также участвуют в аутентификации.,Тогда простая замена куки не получится.,Инструменты должны предоставлять пользователям полные функции замены.,Разрешить пользователям самостоятельно создавать несанкционированные пакеты, если это возможно;,Инструменты также могут автоматически извлекать некоторые параметры функций из необработанного трафика.,Те, которые существуют и остаются неизменными в этих пакетах с множеством запросов, часто связаны с аутентификацией.,НапримерaccountId=xxxxxx

В Burp есть много готовых плагинов, например Auth Analyser/AuthMatrix/Authorize, все они используют одну и ту же идею.

логика принятия решения▸

После того, как мы воспроизведем пакет данных, остается сравнить исходный ответ и несанкционированный ответ, чтобы определить, является ли он несанкционированным. Вопрос о том, как определить, будет обсуждаться сейчас.

Предположим, что интерфейс существует и запрос возвращается успешно:

{
    <span class="hljs-attr">"code"</span> : <span class="hljs-number">200</span>,
    <span class="hljs-attr">"message"</span> : <span class="hljs-string">"success"</span>,
    <span class="hljs-attr">"data"</span> : [{
        <span class="hljs-attr">"name"</span> : <span class="hljs-string">"Y1ng"</span>,
        <span class="hljs-attr">"type"</span> : <span class="hljs-string">"shuaige"</span>
    }]
}

Запрос терпит неудачу и возвращает:

{
    <span class="hljs-attr">"code"</span> : <span class="hljs-number">100001</span>,
    <span class="hljs-attr">"message"</span> : <span class="hljs-string">"Нет доступа"</span>,
    <span class="hljs-attr">"data"</span> : []
}

Кажется, все, что вам нужно сделать, это определить, равны ли два ответа.,Это не тот случай,Потому что существует множество интерфейсов, которые могут каждый раз возвращать что-то другое.,Напримерlogid requestidждать。Чтобы решить эту проблему, вы можете использоватьСравнение сходства,Например, определите, превышает ли сходство между двумя запросами 90%.,В Python есть готовые пакеты:

<span class="hljs-keyword">import</span> difflib

<span class="hljs-function"><span class="hljs-keyword">def</span> <span class="hljs-title">__similarity</span>(<span class="hljs-params">str1, str2</span>) -&gt; <span class="hljs-built_in">float</span>:</span>
    <span class="hljs-keyword">return</span> difflib.SequenceMatcher(<span class="hljs-literal">None</span>, str1, str2).quick_ratio()

Но появились новые проблемы,Предположим, что интерфейс не возвращает действительные данные, а просто возвращает скелет json.,То же самое касается ответов на переопределение.,Тогда сходство между ними все еще очень велико; то же самое справедливо и для общедоступных интерфейсов и html-страниц.,В настоящее время требуется дальнейшее обследование。может пройтиДлина точки застреванияИсключить интерфейсы небольшой длины,Потому что часто очень короткий ответ может быть просто скелетом в формате JSON.

Длина может решить проблему ложных срабатываний на некоторых пустых интерфейсах.,但是对于一些共有的接口Например/api/user/get_role_listНе существует решения для такого типа интерфейса, который возвращает большую длину и не требует аутентификации.,На самом деле, это можно дополнительно очистить с помощью некоторых средств.,Это написано в моем DAST,Однако из-за сложной логики я не стал писать этот уровень функциональности в этой упрощенной версии.,Конкретные подробности пока не разглашаются.

когда мы проходимДлина точки застреванияИсключить интерфейсы небольшой длины时,Также возможно непреднамеренно исключить некоторые успешные интерфейсы, превышающие полномочия.,Особенно интерфейс операции записи,Например:

{
    <span class="hljs-attr">"code"</span> : <span class="hljs-number">200</span>,
    <span class="hljs-attr">"message"</span> : <span class="hljs-string">"ok"</span>
}

Поэтому в длине точки застревания Прежде чем добавить еще один слойРешение по ключевому слову,Конечно, было бы лучше, если бы можно было использовать НЛП.,Короче говоря, сначала определите, «успешный» ли это запрос.,Если да, сообщите об уязвимости напрямую.

Окончательный процесс принятия решения по этой упрощенной версии гаджета выглядит следующим образом:

Однако, если вы хотите добиться коммерческого использования, вам все равно необходимо сделать более точные логические суждения. В настоящее время есть некоторые решения, но большинство из них находятся в стадии разработки. Время запуска еще не известно.

Адрес инструмента▸

https://github.com/y1nglamore/IDOR_detect_tool

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

1. Поддержка HTTPS
2. Автоматически фильтровать статический контент, например страницы images/js/css/html.
3. Многопоточное обнаружение во избежание блокировки
4. Поддерживает выходные отчеты и полные URL-адреса, запросы и ответы.

Каждый раз, когда появляется новая уязвимость, она автоматически добавляется в report/result.html и открывается через браузер:

Нажмите на конкретную запись, чтобы развернуть/свернуть соответствующий запрос и ответ:

Всего здесь более 300 строк кода, чего мне должно хватить для создания PPT. .