Основы этичного веб-хакинга (перевод)

Уязвимости в логике приложений

Описание 
Уязвимости в логике приложений отличаются от тех, что мы 
обсуждали до этого момента. В то время, как HTML-инъекции, 
HTML Parameter Pollution и XSS включают отправку какого- 
либо вида потенциально вредоносных данных, уязвимости, 
основанные на аутентификации, включают манипулятивные 
сценарии и использование багов в коде приложения. 
Хорошим примером этого типа атак можно назвать атаку, 
осуществленную Егором Хомяковым в отношении GitHub, ко- 
торый использует Ruby on Rails. Если вы незнакомы с Rails, 
это очень популярный веб-фреймворк, который по умолчанию 
заботится о множестве вещей при разработке сайтов. 
В марте 2012 Егор указал сообществу Rails, что по умолчанию, 
Rails принимает все отправляемые ему параметры и исполь- 
зует эти значения для обновления записей в базе данных (в 
зависимости от реализации разработчиками). Идея разработ- 
чиков ядра Rails состояла в том, что веб-разработчики, ис- 
пользующие Rails, должны нести ответственность за закрытие 
этой бреши в безопасности приложения и определять, какие 
значения могут быть отправлены пользователем для обновле- 
ния записей в БД. Это поведение уже было хорошо извест- 
но в сообществе, но тема на GitHub показывает, насколько 
малое их число оценило риски, которые нес такой подход

Когда разработчики ядра выразили несогласие с ним, Егор 
использовал уязвимость в системе авторизации GitHub, сде- 
лав предположение и отправив значения параметров, которые 
включали дату создания (не очень сложно, если вы работали 
с Rails и знаете, что большинство записей содержат колонки 
с датами создания и обновления в базе данных). В результате, 
он создал тикет на GitHub с датой на несколько лет в будущем. 
Он также сумел обновить ключи доступа к SSH, что дало ему 
доступ к официальному репозиторию проекта на GitHub. 
Как я уже сказал, взлом стал возможен через бэкенд-код GitHub, 
который не аутентифицировал корректным образом действия 
Егора, который не должен был иметь возможность отправить 
значения с датой создания, используемые впоследствии для 
обновления записей в БД. В этом случае, Егор обнаружил то, 
что называется уязвимостью mass assignment 
Это тип уязвимостей несколько сложнее найти по сравнению 
с типами атак, описанными ранее, поскольку они сильнее 
полагаются на креативные идеи о том, какие решения были 
приняты при разработке, и чтобы их обнаружить, недостаточ- 
но просто отправить потенциально вредоносный код, который 
разработчики не экранировали должным образом (я не пыта- 
юсь преуменьшить значение других уязвимостей, некоторые 
XSS-атаки чрезвычайно сложны!). 
В примере с GitHub, Егор знал, что система работает на основе 
Rails и знал, как Rails обрабатывает пользовательский ввод. В 
других примерах, это может быть создание прямых программ- 
ных запросов к API для проверки реакции, как будет показано 
в примере с администраторскими привилегиями на Shopify 
ниже. Или, это может потребовать повторного использования 
возвращенных значений от аутентифицированных запросов к 
API для создания последующих запросов, которые вам совер- 
шать не позволено.