9. Лазейки в логике приложения

Автор: Питер Yaworski 译者：летающий дракон протокол：CC BY-NC-SA 4.0

Уязвимости логики приложений отличаются от других типов, которые мы обсуждали. В то время как внедрение HTML, загрязнение параметров HTML и XSS предполагают отправку потенциально вредоносных входных данных определенного типа, реализация и уязвимость приложения фактически включают в себя манипулирование сценой и использование ошибок в коде веб-приложения.

Ярким примером атаки такого типа является проникновение Егора Хомакова на Github, написанное с использованием RoR. Если вы не знакомы с Rails, это очень популярный веб-фреймворк, который выполняет большую часть тяжелой работы при разработке веб-сайтов.

существовать 2012 Год 3 луна, Егор Уведомлено Rails Сообщество, в целом, Rails примет все переданные ему аргументы и будет использовать эти значения для обновления записи базы данных (в зависимости от реализации разработчика. Rails Идея разработчиков ядра заключается в использовании Rails из Web Ответственность за заполнение пробелов и определение того, какие значения может предоставить пользователь для обновления записи, лежит на разработчике. Такое поведение уже известно всем в сообществе, но Github начальствоиз Темы показывают очень малоиз Люди могут определить, что это приноситизриск（https://github.com/rails/rails/issues/5228）。

Когда основные разработчики с ним не согласились, Егор продолжать использовать Github Из-за уязвимости аутентификации, если вы угадаете и отправите значение параметра, оно будет содержать дату создания (если вы знакомы с Rails А зная, что большинство записей базы данных содержат столбцы с датами создания и обновления, это не так уж и сложно). Поэтому оно существует Github На товаре есть чек, а дата в будущем. Он также успевает обновлять SHH ключ доступа, который даст ему доступ к Github Официальный из репозитория кода.

Как упоминалось ранее, это проникновение происходит через Github Реализация внутреннего кода, она не проверяет должным образом Egor Что будет сделано, это существование затем можно будет использовать для обновления записи базы данных. Вот, Егор Была обнаружена так называемая уязвимость массового назначения.

Уязвимость логики приложения,То есть я обнаружил, что этот тип атаки обсуждался ранее.,более умелый,Потому что они полагаются на кодекс суждений, созданный Дин Сивэем.,И дело не только в отправке потенциально вредоносного кода.,Разработчики не избежали этого. (Не пытайтесь существовать здесь, чтобы упростить другие типы уязвимостей.,Некоторый XSS Атака также очень сложна! )

использовать Github из Пример, Егор Знайте, что система основана на Rails а также Rails Как обрабатывать ввод пользователя. существуют Другие примеры включают в себя прямые программные призывы к API Чтобы протестировать поведение приложения, например Shopify из Обход прав администратор такой. Альтернативно, это предполагает повторение использования из проверки API Вызов возвращаемого значения для последующего изAPI Колл, тебе нельзя этого позволять.

Пример

1. Обход разрешений администратора Shopify

Сложность: низкая

URL：shop.myshopify.com/admin/mobile_devices.json

Ссылка на отчет：https://hackerone.com/reports/100938

Дата отчета: 2015.11.22

Приз: 500 долларов.

описывать:

Shopify это большая и надежная платформа, содержащая Web UI а такжеподдерживаетсяиз API. В этом примере API Некоторые разрешения не проверяются, пока Web UI Очевидно, так и будет. Таким образом, администраторы магазина, которым не разрешено получать напоминания по электронной почте, могут сделать это, запустив API Терминал для обхода этих настроек безопасности существует, их Apple На устройство поступают оповещения.

Согласно отчету, хакерам нужно только:

• Использовать Полный доступ из входа в учетную запись Shopify мобильное приложение
• перехватыватьPOST /admin/mobile_devices.jsonизпросить
• Удалить все разрешения из этой учетной записи
• Удалить и добавить мобильное напоминание
• переигратьPOST /admin/mobile_devices.jsonизпросить

после этого,Пользователи могут получать мобильные напоминания обо всех заказах в магазине.,Поэтому настройка магазина «Из Безопасность» игнорируется.

Важные выводы Здесь два Важных выводы. Во-первых, не все связано с внедрением кода. Всегда помните код использования, следите за тем, какая информация передается на сайт, и экспериментируйте с ней, чтобы увидеть, что произойдет. Здесь происходит только удаление POST параметры для обхода проверок безопасности. Во-вторых, и опять же, не все атаки основаны на HTML страница. API Терминалы всегда являются областью потенциальных уязвимостей, поэтому обязательно учтите и протестируйте их.

2. Условия конкурса Starbucks

Сложность: Средняя

URL：Starbucks.com

Ссылка на отчет：http://sakurity.com/blog/2015/05/21/starbucks.html

Дата отчета: 21 мая 2015 г.

Бонус: Нет

описывать:

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

Вот пример:

1. Вы вошли на сайт своего банка со своего мобильного телефона и запросили

500 со счета переведено на другой счет.

1. Этот запрос занимает много времени (но все еще обрабатывается),Итак, вы существуете с помощью входа в систему с ноутбука.,и снова выполнил тот же запрос.
2. Запрос на ноутбук был выполнен почти сразу, то же самое касается и вашего мобильного телефона.
3. Вы обновили свой банковский счет,И обнаружил, что в вашем аккаунте что-то есть

500。

хотя это очень элементарно,Концепция та же самая,В начале запроса существуют некоторые условия,существоватьзавершенный,Больше нет существования.

Итак, вернемся к этому примеру, Егор Протестировал перевод денег с карты Starbucks и обнаружил, что состояние успешно сработало гонки。проситьиспользовать CURL Программы создаются практически одновременно.

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

3. Повышение привилегий Binary.com

Сложность: низкая

URL：binary.com

Ссылка на отчет：https://hackerone.com/reports/98247

Дата отчета: 2015.11.14

Приз: 300 долларов.

описывать:

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

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

существовать до того, как ты проникнешь,Если вы вошли в системуBinary.com/cashier,и просмотрел страницу в формате HTML,Вы заметите, что есть<iframe>标签包含 PIN параметр. Этот параметр на самом деле является вашим аккаунтом ID。

Ниже, если вы редактировали HTML, и вставляется еще один PIN,Сайт автоматически выполнит операции с новой учетной записью.,без проверки пароля или каких-либо других учетных данных. другими словами,Сайт будет считать вас владельцем предоставленной вами учетной записи.

такой же,необходимыйизвсе дело в том, чтобы знать кого-тоиз Номер счета。ты можешь дажесуществовать Появлятьсясуществоватьiframeсерединаиз Время изменено наPAYOUT,для инициирования платежных операций на другом счете. но,Bianry.comвыражать,Все снятие средств требует ручной проверки.,Но это не значит,Это обязательно будет обнаружено.

Важные выводы Если вы ищете возможности для использования уязвимостей в аутентификации, знайте, откуда на сайт передаются учетные данные. Хотя эта уязвимость достигается за счет просмотра исходного кода страницы, вы также можете обратить внимание на передачу сообщения при использовании прокси-перехватчика. Если вы обнаружите, что какие-то учетные данные передаются, но они кажутся незашифрованными, имейте в виду и попробуйте поиграть с ними. Вот ПИН 是CRXXXXXXИ пароль0e552ae717a1d08cb134f132。显然 PIN Нет расшифровки,Но пароль зашифрован. Незашифрованное значение — очень хорошее место.,Вы можете начать здесь.