Уязвимость открытого перенаправления возникает, когда жертва посещает определённый URL-адрес некоторого сайта, а тот предписывает браузеру жертвы перейти по совершенно другому URL-адресу в отдельном домене. Предположим, например, что Google использовал для перенаправления пользователей в Gmail следующий URL-адрес:

При посещении этого URL-адреса Google получал бы HTTP-запрос GET и по значению параметра redirect_to определял, куда следует перенаправить браузер посетителя. Затем Google возвращал бы HTTP-ответ с кодом 302, предписывая браузеру пользователя выполнить GET-запрос к https://www.gmail.com, то есть к адресу из параметра redirect_to. Теперь предположим, что мы изменили исходный URL-адрес:

Если бы Google не проверял, что параметр redirect_to указывает на один из принадлежащих компании допустимых сайтов, куда она намерена отправлять посетителей - в нашем примере это https://www.gmail.com, - сайт мог бы оказаться уязвимым для открытого перенаправления. Он возвращал бы HTTP-ответ, предписывающий браузеру посетителя выполнить GET-запрос к https://www.attacker.com.

Открытый проект безопасности веб-приложений (Open Web Application Security Project, OWASP) - сообщество, занимающееся безопасностью приложений и составляющее перечень самых критических изъянов безопасности веб-приложений, - включил эту уязвимость в десятку важнейших уязвимостей 2013 года. Открытые перенаправления используют доверие к определённому домену - в нашем примере https://www.google.com/, - чтобы заманить жертву на вредоносный сайт. В ходе фишинговых атак таким способом заставляют пользователей поверить, будто они отправляют сведения доверенному сайту, хотя ценные данные в действительности попадают на сайт злоумышленника. Кроме того, злоумышленник может распространять с вредоносного сайта программы или похищать токены OAuth - эту тему мы рассмотрим в одной из следующих глав.

При поиске уязвимостей такого типа следует обращать внимание на GET-запрос к проверяемому сайту с параметром, который задаёт URL-адрес перенаправления.

Открытые перенаправления позволяют злоумышленнику незаметно направлять людей на вредоносный сайт. Как видно из примеров, для их обнаружения часто требуется наблюдательность. Иногда параметры перенаправления легко заметить по названиям redirect_to=, domain_name=, checkout_url= и подобным. В других случаях они носят менее очевидные имена: r=, u= и так далее.

Загрязнение параметров HTTP (HTTP Parameter Pollution, HPP) - это манипулирование тем, как веб-сайт обрабатывает параметры, получаемые в HTTP-запросах. Уязвимость возникает, когда параметры внедряются и принимаются уязвимым сайтом как доверенные, что приводит к неожиданному поведению. Это может происходить на серверной стороне, где серверы посещаемого сайта обрабатывают невидимые для вас сведения, или на клиентской стороне, где результат виден в клиенте - обычно в браузере.

Когда вы обращаетесь к веб-сайту, его серверы обрабатывают запрос и возвращают ответ, как рассказывалось в главе 1. Иногда серверы не просто возвращают веб-страницу, но и выполняют код на основании сведений из переданного им URL-адреса. Этот код работает только на серверах и, по существу, невидим для вас: вы видите отправленные сведения и полученный результат, но всё происходящее между ними остаётся чёрным ящиком. При серверном HPP вы отправляете серверам неожиданные данные, пытаясь заставить серверный код вернуть неожиданный результат. Поскольку работу серверного кода увидеть нельзя, для обнаружения серверного HPP приходится выявлять потенциально уязвимые параметры и экспериментировать с ними.

Серверное HPP могло бы возникнуть, например, если ваш банк выполнял бы переводы через веб-сайт, а сервер обрабатывал бы их, принимая параметры URL. Допустим, для перевода денег необходимо заполнить три параметра URL: from, to и amount. Они по порядку задают номер счёта списания, счёт зачисления и сумму перевода. URL-адрес для перевода 5000 долларов со счёта 12345 на счёт 67890 мог бы выглядеть так:

Банк может предполагать, что получит только один параметр from. Но что произойдёт, если отправить два таких параметра?

Начало этого URL устроено так же, как в первом примере, но в конце добавлен ещё один параметр from, задающий другой счёт списания - ABCDEF. Как вы, вероятно, уже догадались, если приложение уязвимо для HPP и банк доверяет последнему полученному параметру from, злоумышленник может выполнить перевод с чужого счёта.

Вместо перевода 5000 долларов со счёта 12345 на счёт 67890 серверный код воспользуется вторым параметром и отправит деньги со счёта ABCDEF на счёт 67890.

Как серверные, так и клиентские уязвимости HPP зависят от поведения сервера при получении нескольких одноимённых параметров. Например, PHP/Apache использует последнее вхождение, Apache Tomcat - первое, ASP/IIS - все вхождения и так далее. Следовательно, единого гарантированного способа обработки нескольких одноимённых параметров не существует, а при поиске HPP необходимо экспериментально выяснить, как работает проверяемый сайт.

До сих пор в примере использовались очевидные параметры, но иногда уязвимости HPP возникают из-за скрытого поведения серверного кода, которое непосредственно увидеть нельзя. Допустим, банк решил изменить обработку переводов: исключил параметр from из URL-адреса в серверном коде и вместо этого стал принимать массив, содержащий несколько значений.

Теперь банк принимает два параметра: счёт зачисления и сумму перевода. Счёт списания считается заранее известным. Пример ссылки может выглядеть так:

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

Этот код создаёт две функции: prepare_transfer и transfer_money. Функция prepare_transfer принимает массив params, содержащий параметры to и amount из URL-адреса. Массив имеет вид [67890,5000]: его значения заключены в квадратные скобки и разделены запятыми. Первая строка функции добавляет в конец массива сведения об учётной записи пользователя, определённые ранее в коде. В результате в params получается массив [67890,5000,12345], после чего params передаётся функции transfer_money.

Обратите внимание: в отличие от параметров, значения массивов Ruby не имеют связанных с ними имён. Поэтому код рассчитывает, что значения всегда следуют в массиве в одном порядке: сначала счёт зачисления, затем сумма и, наконец, счёт списания. В функции transfer_money это становится очевидным: каждому значению массива присваивается переменная. Позиции в массиве нумеруются с нуля, поэтому params[0] обращается к первой позиции - в данном случае к значению 67890 - и присваивает её переменной to. В двух следующих строках другим значениям также назначаются переменные, а затем их имена передаются функции transfer. Эта функция во фрагменте кода не показана; она принимает значения и фактически переводит деньги.

В идеале параметры URL всегда будут оформлены так, как ожидает код. Однако злоумышленник может изменить результат этой логики, передав в params значение from, например с помощью следующего URL-адреса:

В этом случае параметр from тоже попадёт в массив params, переданный функции prepare_transfer, поэтому значения массива примут вид [67890,5000,ABCDEF]. После добавления учётной записи пользователя получится [67890,5000,ABCDEF,12345]. В результате в функции transfer_money, вызываемой из prepare_transfer, переменная from получит третий параметр. Код ожидает, что это будет значение user.account, равное 12345, но фактически обратится к переданному злоумышленником значению ABCDEF.

Клиентские уязвимости HPP, напротив, позволяют внедрить параметры в URL-адрес, который затем отражается на странице, возвращаемой пользователю.

Два исследователя, Лука Кареттони и Стефано ди Паола, в докладе об этом типе уязвимостей, представленном в 2009 году, привели пример такого поведения с условным URL-адресом http://host/page.php?par=123%26action=edit и следующим серверным кодом:

Здесь код создаёт новый URL-адрес на основании адреса, введённого пользователем. Сформированный URL содержит параметры action и par, причём второй определяется URL-адресом пользователя. В условном URL злоумышленник передаёт значение 123%26action=edit в параметре par. Последовательность %26 - это URL-код символа &, поэтому при разборе URL она интерпретируется как &. Благодаря этому в созданную ссылку href добавляется ещё один параметр, хотя явный параметр action не указывается.

Если бы вместо этого использовалось 123&action=edit, строка была бы воспринята как два отдельных параметра: par со значением 123 и action со значением edit. Но сайт ищет и применяет в своём коде только параметр par, чтобы создать новый URL, поэтому параметр action был бы отброшен. Обойти это ограничение позволяет %26: первоначально action не распознаётся как отдельный параметр, а значение par становится равным 123%26action=edit.

Затем par, где символ & закодирован как %26, передаётся функции htmlspecialchars. Эта функция преобразует специальные символы, в том числе %26, в значения, закодированные для HTML; в результате %26 становится &. Преобразованное значение сохраняется в $val. После этого новая ссылка создаётся добавлением $val к значению href, и получается:

Таким способом злоумышленнику удаётся добавить в URL из href дополнительный параметр action=edit. В зависимости от того, как сервер обрабатывает два параметра action, это может привести к уязвимости.

Опасность загрязнения параметров HTTP в действительности зависит от действий, выполняемых серверной частью сайта, и от того, где используются загрязнённые параметры.

Атака межсайтовой подделки запросов (cross-site request forgery, CSRF) происходит, когда злоумышленник с помощью HTTP-запроса получает доступ к сведениям пользователя на другом веб-сайте и использует их, чтобы действовать от имени пользователя. Обычно для этого жертва должна быть заранее аутентифицирована на целевом сайте, куда отправляется действие, причём сама жертва не знает, что подверглась атаке. Рассмотрим простой пример:

1. Боб входит на сайт своего банка, чтобы проверить баланс.

2. Закончив, он открывает учётную запись Gmail, перейдя на https://gmail.com/.

3. Боб видит письмо со ссылкой на незнакомый сайт и нажимает её, желая узнать, куда она ведёт.

4. После загрузки незнакомый сайт предписывает браузеру Боба отправить HTTP-запрос банковскому сайту, который переводит деньги со счёта Боба на счёт злоумышленника.

5. Банковский сайт Боба получает HTTP-запрос от незнакомого и вредоносного сайта, не имеет защиты от CSRF и поэтому выполняет перевод.

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

Cookie применяются для разных целей, в том числе для хранения пользовательских настроек и истории посещения веб-сайта. Для хранения таких сведений у cookie могут быть атрибуты - стандартизированные элементы данных, которые сообщают браузеру о файле и о порядке обращения с ним. Среди возможных атрибутов есть домен, срок действия, secure и httponly.

Помимо атрибутов cookie могут содержать пары «имя - значение», состоящие из идентификатора и связанного значения, которое передаётся веб-сайту. Сайт назначения этих сведений определяется атрибутом домена cookie. Один сайт может установить любое число файлов cookie, каждый со своим назначением. Например, cookie session_id позволяет сайту запомнить пользователя, чтобы тому не приходилось вводить имя и пароль на каждой посещаемой странице и при каждом действии. Помните, что HTTP считается протоколом без сохранения состояния: при каждом HTTP-запросе веб-сайт не знает, кто перед ним, и поэтому должен снова аутентифицировать пользователя.

Например, пара «имя - значение» в cookie может иметь вид sessionId:123456789, а домен cookie - .site.com. Это означает, что cookie user_id следует отправлять каждому посещаемому пользователем сайту в домене .site.com: foo.site.com, bar.site.com, www.site.com и так далее.

Атрибуты secure и httponly сообщают браузерам, когда и каким образом разрешается отправлять и читать cookie. Значений у этих атрибутов нет: это флаги, которые либо присутствуют в cookie, либо отсутствуют. Если у cookie установлен атрибут secure, браузер отправляет его только при посещении сайтов по HTTPS. Если вы откроете http://www.site.com/ с защищённым cookie, браузер не передаст cookie сайту. Так обеспечивается конфиденциальность, поскольку соединения HTTPS зашифрованы, а HTTP - нет. Атрибут httponly сообщает браузеру, что cookie разрешено читать лишь посредством запросов HTTP и HTTPS. Это станет важно в следующей главе о межсайтовом скриптинге, а пока достаточно знать: если cookie имеет атрибут httponly, браузер не позволит языкам сценариев, например JavaScript, прочесть его значение. Cookie без атрибута secure можно передать сайту, не использующему HTTPS; аналогично cookie без установленного httponly можно прочитать через соединение, отличное от HTTP.

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

Вернёмся к Бобу. Когда он посещает банковский сайт и входит в систему, банк отвечает на его HTTP-запрос HTTP-ответом с cookie, идентифицирующим Боба. После этого браузер Боба автоматически отправляет cookie со всеми остальными HTTP-запросами к банковскому сайту.

Закончив банковские операции, Боб не выходит из системы и решает посетить https://www.gmail.com/. Это важно: когда вы выходите с сайта, тот обычно отправляет HTTP-ответ, прекращающий действие cookie. Поэтому при следующем посещении сайта придётся войти снова.

Открывая неизвестный сайт, Боб невольно посещает вредоносную веб-страницу, предназначенную для атаки на его банковский сайт. Способ эксплуатации банка зависит от того, принимает ли он запросы GET или POST.

Если банковский сайт принимает запросы GET, вредоносный сайт отправит HTTP-запрос с помощью скрытой формы или тега <img>. Скрытые формы подходят и для POST-запросов, поэтому в этом разделе мы рассмотрим тег <img>, а к формам вернёмся далее, в разделе «CSRF с запросами POST».

Когда браузер отображает тег <img>, он выполняет HTTP-запрос GET к адресу из атрибута src. Допустим, на вредоносном сайте применяется URL для перевода 500 долларов от Боба Джо:

Тогда вредоносный тег изображения использует этот URL как значение источника:

Когда Боб посещает сайт злоумышленника, тот включает тег <img> в HTTP-ответ, после чего браузер выполняет HTTP-запрос GET к банку. Браузер отправляет аутентификационные cookie Боба, пытаясь получить то, что считает изображением, но банк в действительности принимает запрос, обрабатывает URL из атрибута src тега и выполняет перевод.

Именно поэтому согласно общему принципу веб-программирования HTTP-запросы GET никогда не должны изменять данные на серверной стороне, например переводить деньги.

Если банк принимает запросы POST, необходимо учитывать несколько обстоятельств. Содержимое POST-запроса способно усложнить CSRF-атаку, поэтому для успеха применяются иные приёмы.

Простейший случай - POST-запрос с типом содержимого application/x-www-form-urlencoded или text/plain. Тип содержимого - заголовок, который браузер может включить в отправляемый HTTP-запрос. Он сообщает получателю, как закодировано тело HTTP-запроса. Вот пример запроса с типом содержимого text/plain:

Тип содержимого указан вместе с кодировкой символов запроса. Он важен, поскольку браузеры по-разному обращаются с разными типами - к этому мы скоро вернёмся. В рассматриваемой ситуации вредоносный сайт может создать скрытую HTML-форму и незаметно для жертвы отправить её целевому сайту. Форма способна отправить POST- или GET-запрос к URL-адресу и даже передать значения параметров. Вот пример вредоносного кода:

Здесь мы с помощью формы отправляем банку Боба HTTP-запрос POST; на это указывает атрибут target тега <form>. Злоумышленник не хочет, чтобы Боб увидел форму, поэтому каждому элементу <input> присвоен тип hidden, делающий его невидимым на веб-странице. Наконец, злоумышленник помещает в тег <script> код JavaScript, который автоматически отправляет форму при загрузке страницы.

Код JavaScript вызывает у HTML-документа метод getElementByID(), передавая идентификатор формы csrf-form, установленный в <form>. Как и с GET-запросом, после отправки формы браузер выполняет HTTP-запрос POST и передаёт cookie Боба банковскому сайту, который осуществляет перевод. Поскольку в ответ на POST-запрос приходит HTTP-ответ для браузера, злоумышленник скрывает его в элементе <iframe> с атрибутом display:none, чтобы Боб ничего не увидел и не понял, что произошло.

В других случаях сайт может ожидать POST-запрос с типом содержимого application/json. Иногда у такого запроса имеется токен CSRF - значение, которое передаётся вместе с HTTP-запросом и позволяет целевому сайту проверить, что запрос поступил от него самого, а не с другого вредоносного сайта. Токен может находиться в теле POST-запроса, а иногда передаётся в заголовке, подобном заголовку типа содержимого.

Особенность отправки POST-запросов с типом application/json заключается в том, что браузер сначала выполняет HTTP-запрос OPTIONS и лишь затем отправляет POST. Сайт отвечает на вызов OPTIONS, перечисляя принимаемые типы HTTP-запросов. Браузер читает ответ и выполняет настоящий HTTP-запрос POST - в нашем примере перевод. Такой порядок защищает от некоторых CSRF-уязвимостей: вредоносному сайту не разрешается прочитать HTTP-ответ OPTIONS целевого сайта, чтобы узнать, можно ли отправлять вредоносный POST-запрос. Этот механизм называется совместным использованием ресурсов между источниками (cross-origin resource sharing, CORS).

CORS ограничивает доступ к ресурсам, включая ответы JSON, из домена, отличного от того, который предоставил файл, если только целевой сайт явно не разрешил такой доступ. Иными словами, когда сайт защищён CORS, нельзя отправить запрос application/json целевому приложению, прочитать ответ и выполнить следующий вызов, если целевой сайт этого не разрешает. В некоторых ситуациях CORS можно обойти и провести CSRF-атаку, что мы увидим далее в этой главе.

Как уже говорилось, от уязвимостей CSRF защищаются несколькими способами, поэтому перед отправкой отчёта важно подготовить надёжное доказательство возможности атаки.

Вероятно, самая распространённая защита от CSRF - токен CSRF, который защищённый сайт требует при отправке запросов, способных изменить данные, то есть запросов POST. Веб-приложение, например банк Боба, создаёт токен из двух частей: одну получает Боб, а другая остаётся у приложения. При попытке выполнить перевод Боб должен передать свою часть токена, которую банк затем проверяет с помощью хранящейся у него части.

Названия токенов не всегда очевидны; среди возможных вариантов встречаются X-CSRF-TOKEN, lia-token, rt и form-id. Без действительного токена злоумышленник не сможет успешно отправить POST-запрос и провести CSRF-атаку. Однако наличие токенов CSRF не всегда означает тупик при поиске уязвимостей.

Другой очевидный способ защиты - CORS. Но он не безупречен, поскольку полагается на безопасность браузеров и правильную настройку доступа сайтов к ответам; кроме того, в прошлом обнаруживались уязвимости обхода CORS. Иногда CORS можно обойти, заменив тип содержимого application/json на application/x-www-form-urlencoded или отправив GET вместо POST. Возможность каждого из этих обходов зависит от настройки целевого сайта.

Наконец, уязвимости CSRF можно предотвратить, если сайт проверяет заголовок origin, отправляемый с HTTP-запросом. Злоумышленник не может управлять источником, который указывает место возникновения запроса.

Уязвимости CSRF создают ещё один вектор атаки, причём эксплуатация может произойти без ведома жертвы и без активных действий с её стороны. Для обнаружения CSRF требуются изобретательность и, опять же, желание проверять всё подряд.

Инъекцию языка гипертекстовой разметки (HTML) иногда называют также виртуальной подменой содержимого. Такая атака становится возможной, когда сайт неправильно обрабатывает пользовательский ввод и позволяет злоумышленнику внедрять HTML в свои веб-страницы. Иными словами, уязвимость HTML-инъекции возникает, когда сайт получает HTML, обычно через какое-либо поле формы, а затем отображает его на веб-странице именно как разметку. Эта уязвимость отличается от внедрения JavaScript, VBScript и других языков, которое способно привести к атакам межсайтового скриптинга.

HTML определяет структуру веб-страницы, поэтому, если злоумышленник может внедрить HTML, он фактически способен изменить результат отображения браузером и внешний вид страницы. Иногда удаётся полностью изменить оформление страницы, а иногда - создать HTML-формы и обманом убедить пользователей передать через них конфиденциальные сведения; это называется фишингом. Например, имея возможность внедрять HTML, вы могли бы добавить на страницу тег <form>, предлагающий пользователю снова ввести имя и пароль:

Однако при отправке формы сведения через атрибут action фактически уходят на http://attacker.com, то есть на веб-страницу злоумышленника.

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

Уязвимость инъекции возврата каретки и перевода строки (Carriage Return Line Feed, CRLF) возникает, когда приложение неправильно очищает пользовательский ввод и позволяет вставлять символы возврата каретки и перевода строки. Во многих интернет-протоколах, включая HTML, эти символы обозначают разрывы строк и имеют особое значение.

Сложность: высокая

URL: https://twitter.com/i/safety/report_story

Ссылка на отчёт: https://hackerone.com/reports/52042^[1]

Дата сообщения: 21 апреля 2015 года

Вознаграждение: 3500 долларов

Описание:

В апреле 2015 года @filedescriptor сообщил Twitter об уязвимости, которая позволяла хакерам задавать произвольный cookie, дописывая дополнительные сведения в HTTP-запрос.

В сущности, HTTP-запрос к https://twitter.com/i/safety/report_story - устаревшей странице Twitter для жалоб пользователей на неприемлемую рекламу - включал параметр reported_tweet_id. В ответ Twitter также возвращал cookie, куда входил тот же параметр, который передавался в HTTP-запросе. Во время проверки @filedescriptor заметил, что символы CR и LF очищаются: LF заменяется пробелом, а CR приводит к ответу HTTP 400 - ошибке неверного запроса.

Однако благодаря своим энциклопедическим знаниям он помнил о прежней ошибке кодирования в Firefox: при установке cookie браузер отбрасывал полученные недопустимые символы вместо того, чтобы их кодировать. Причиной было то, что Firefox принимал лишь определённый диапазон допустимых значений. Проверяя похожий подход с Twitter, @filedescriptor использовал символ Unicode U+560A, код которого оканчивается на %0A, то есть перевод строки. Но это ещё не решало задачу. Параметр передавался в URL, а значит, кодировался в UTF-8 для URL. В результате символ U+560A превращался в %E5%98%8A.

Отправив это значение, @filedescriptor обнаружил, что Twitter не выявляет вредоносных символов. Сервер декодирует значение обратно в код Unicode 56 0A и удаляет недопустимый символ 56. Остаётся символ перевода строки 0A, как показано на схеме процесса:

Процесс декодирования CRLF

Аналогичным образом исследователь передал %E5%98%8A%E5%98%8DSet-Cookie:%20test. В результате в заголовок cookie попали %0A и %0D, а Twitter вернул Set-Cookie:test.

Атаки CRLF могут быть ещё опаснее, когда позволяют провести XSS-атаку; подробнее см. главу о межсайтовом скриптинге. В данном случае благодаря обходу фильтров Twitter @filedescriptor мог разделить ответ и выполнить XSS, чтобы похитить сеанс и токен пользователя. Ниже URL разбит на несколько строк только ради форматирования:

Обратите внимание на разбросанные по адресу трёхбайтовые значения %E5%98%8A, %E5%98%8D, %E5%98%BC и %E5%98%BE. Все они декодируются следующим образом:

Если заменить все символы и действительно добавить разрывы строк, заголовок выглядит так:

Как видите, разрывы строк позволяют создать новый возвращаемый заголовок с исполняемым кодом JavaScript: svg/onload=alert(innerHTML). В качестве доказательства концепции для Twitter функция alert открывает всплывающее окно с содержимым веб-страницы. С помощью такого кода злоумышленник мог похитить сведения о сеансе ничего не подозревающей жертвы в Twitter, поскольку конфиденциальные данные находились в заголовке после места инъекции, которое эксплуатировал @filedescriptor.

Выводы. Хороший хакинг сочетает наблюдательность и мастерство. В этом случае @filedescriptor знал о прежней ошибке кодирования Firefox, который неправильно обрабатывал символы. Эти знания подтолкнули его проверить аналогичное кодирование в Twitter и добиться вставки вредоносных символов.

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

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

URL: v.shopify.com/last_shop?x.myshopify.com

Ссылка на отчёт: https://hackerone.com/reports/106427^[2]

Дата сообщения: 22 декабря 2015 года

Вознаграждение: 500 долларов

Описание:

Для администраторов магазинов Shopify предоставляет серверную функцию, которая устанавливает в браузере cookie с последним магазином, куда входил пользователь. Предположительно, это удобный способ при входе и выходе перенаправлять пользователя в его поддомен, поскольку URL-адреса соответствуют шаблону STORENAME.myshopify.com. Cookie устанавливается GET-запросом к /last_shop?SITENAME.shopify.com.

В декабре 2015 года хакер сообщил, что Shopify не проверяет параметр shop, передаваемый в вызове. С помощью Burp Suite исследователь изменил запрос, добавив %0d%0a, чтобы серверы Shopify вернули новые заголовки. Вот снимок экрана:

Разделение HTTP-ответа Shopify

Вредоносный код выглядел так:

Здесь %20 обозначает пробел, а %0d%0a - CRLF. В итоге браузер получал два действительных HTTP-ответа и отображал второй, что могло привести к разным уязвимостям, включая XSS и фишинг.

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

Хороший хакинг сочетает наблюдательность и мастерство, а умение использовать закодированные символы для эксплуатации уязвимостей чрезвычайно полезно. Особенно важны символы %0D%0A, поскольку они способны приводить к CRLF-инъекциям. При поиске уязвимостей обращайте внимание на параметры, которые потенциально контролирует злоумышленник, но которые отражаются в HTTP-заголовке. Обнаружив такие параметры, проверяйте обработку сайтом закодированных символов, прежде всего %0D%0A. В случае успеха постарайтесь пойти дальше и объединить уязвимость с XSS-инъекцией, чтобы получить убедительное доказательство концепции.

Один из самых известных примеров уязвимости межсайтового скриптинга (cross-site scripting, XSS) - червь Myspace Samy, созданный Сэми Камкаром. В октябре 2005 года Сэми воспользовался XSS-уязвимостью Myspace, позволявшей сохранить полезную нагрузку JavaScript в его профиле. Когда вошедший в систему пользователь посещал профиль Сэми в Myspace, код полезной нагрузки выполнялся, добавлял Сэми в друзья посетителя и изменял профиль последнего, показывая текст «но важнее всего то, что Сэми - мой герой». Затем код копировал себя в профиль посетителя и продолжал заражать страницы других пользователей Myspace.

Хотя Сэми создал червя без злого умысла, Myspace отнеслась к случившемуся совсем не благосклонно, а власти провели обыск в доме Сэми. За распространение червя его арестовали, и он признал себя виновным в совершении тяжкого преступления.

Червь Сэми - крайний случай, но его действие показывает, насколько далеко может распространяться влияние XSS-уязвимости на веб-сайт. Как и рассмотренные ранее изъяны, XSS возникает, когда веб-сайт отображает определённые символы без очистки, заставляя браузер выполнить непредусмотренный JavaScript. К таким символам относятся двойные кавычки ("), одинарные кавычки (') и угловые скобки (< >). Они имеют особое значение, поскольку определяют структуру веб-страницы в HTML и JavaScript. Например, если сайт не очищает угловые скобки, можно вставить <script></script>:

Если отправить эту полезную нагрузку сайту и тот отобразит её без очистки, теги <script></script> предписывают браузеру выполнить находящийся между ними JavaScript. В данном случае полезная нагрузка вызывает функцию alert, создающую всплывающее диалоговое окно с переданными ей сведениями. Указанный в скобках объект document относится к DOM и здесь возвращает доменное имя сайта. Если полезная нагрузка выполнится на https://www.example.com/foo/bar, во всплывающем окне появится www.example.com.

Если сайт правильно очищает символы, они отображаются как сущности HTML. В исходном тексте веб-страницы " будет записана как " или ", ' - как ' или &39;, < - как < или <, а > - как > или >.

Обнаружив XSS-уязвимость, необходимо подтвердить её последствия, потому что не все XSS одинаковы. Если в описании вы подтвердите и укажете влияние ошибки, это улучшит отчёт, поможет специалистам программы проверить находку и может увеличить вознаграждение.

Например, XSS-уязвимость сайта, где у конфиденциальных cookie отсутствует флаг httpOnly, отличается от XSS на сайте с таким флагом. Если httpOnly нет, XSS может читать значения cookie. Когда среди них есть cookie, идентифицирующие сеанс, появляется возможность похитить сеанс жертвы и получить доступ к её учётной записи. Чтобы это проверить, можно вывести document.cookie с помощью alert; выяснять, какие cookie сайт считает конфиденциальными, приходится методом проб и ошибок отдельно для каждого сайта. Даже без доступа к конфиденциальным cookie можно вывести document.domain и проверить, позволяет ли DOM получить секретные сведения пользователя и выполнять действия от его имени. Если отображается неправильный домен, XSS может не представлять для сайта уязвимости.

Например, при выводе document.domain из изолированного iframe код JavaScript может оказаться безвредным, поскольку не способен обратиться к cookie, выполнить действия с учётной записью пользователя или получить конфиденциальные сведения из DOM. Причина в том, что браузеры в качестве механизма безопасности реализуют политику одного источника (Same Origin Policy, SOP).

SOP ограничивает взаимодействие документов - буква D в DOM - с ресурсами, загруженными из другого источника. Она защищает невиновные веб-сайты от вредоносных сайтов, которые пытаются атаковать их через пользователя. Например, если вы посетили www.malicious.com, а этот сайт вызвал в браузере GET-запрос к www.example.com/profile, SOP не позволила бы www.malicious.com прочитать ответ www.example.com/profile. Впрочем, www.example.com может разрешить другим сайтам межсайтовое взаимодействие с собой, но обычно разрешение ограничивается конкретными сайтами, а широкий неограниченный доступ чаще всего является ошибкой.

Источник сайта определяется протоколом, например HTTP или HTTPS, узлом, например www.example.com, и портом веб-сайта. Исключение - Internet Explorer, который не считает порт частью источника. Ниже приведены примеры источников и указано, считаются ли они одинаковыми с http://www.example.com.

В некоторых ситуациях URL не соответствует источнику. Браузеры особым образом обрабатывают контекст двух схем с точки зрения SOP: about:blank и javascript:. Эти схемы наследуют источник открывшего их документа. Контекст about:blank относится к схеме URL about, которая служит для получения сведений из самого браузера и взаимодействия с ним. Схема URL JavaScript используется для выполнения JavaScript. Поскольку URL не содержит сведений о своём источнике, эти две схемы обрабатываются особым образом.

При обнаружении XSS полезно применять в доказательстве концепции alert(document.domain): так подтверждается источник, в котором выполняется XSS. Это особенно важно, когда URL в адресной строке браузера отличается от источника, против которого работает XSS. Именно это происходит, когда веб-сайт открывает URL вида javascript:. Если бы www.example.com открыл URL javascript:alert(document.domain), в адресной строке браузера появился бы javascript:alert(document.domain), но окно предупреждения показало бы www.example.com, поскольку наследует источник предыдущего документа.

До сих пор мы рассматривали лишь пример с тегом HTML <script>, но при потенциальной инъекции отправить теги HTML удаётся не всегда. В таком случае полезную нагрузку XSS всё ещё можно внедрить с помощью одинарных или двойных кавычек. Значимость зависит от места инъекции. Предположим, вы управляете атрибутом value следующего кода:

Внедрив двойную кавычку в атрибут value, можно закрыть существующую кавычку и поместить в тег вредоносную полезную нагрузку XSS. Например, значение атрибута меняется на hacker" onfocus=alert(document.cookie) autofocus", и получается:

Атрибут autofocus предписывает браузеру сразу после загрузки страницы поместить фокус курсора в текстовое поле ввода, а атрибут JavaScript onfocus - выполнить JavaScript, когда поле получает фокус. Без autofocus событие onfocus обычно возникло бы после щелчка пользователя в поле. У приёма есть ограничения: фокус нельзя автоматически установить на скрытом поле, а если атрибут autofocus имеется у нескольких полей страницы, в зависимости от проверяемого браузера фокус получит первый или последний элемент. После запуска полезная нагрузка выводит document.cookie.

Аналогично предположим, что вы управляете переменной внутри тега script. Если в следующем коде удаётся внедрять одинарные кавычки в значение переменной name, можно закрыть переменную и выполнить собственный JavaScript:

Мы управляем значением hacker, поэтому после замены переменной name на hacker';alert(document.cookie);' получится:

Внедрение одинарной кавычки и точки с запятой закрывает переменную name. Поскольку мы находимся внутри тега <script>, внедрённая функция JavaScript alert(document.cookie) будет выполнена. В конце вызова функции мы добавляем ещё одну последовательность ;', чтобы JavaScript оставался синтаксически правильным: сайт сам дописывает '; для закрытия переменной name. Без '; в конце осталась бы висящая одинарная кавычка, способная нарушить синтаксис страницы.

При проверке XSS важно понимать, что существует два основных типа уязвимости: отражённая и хранимая. При отражённой XSS полезная нагрузка доставляется и выполняется в рамках одного HTTP-запроса и нигде на сайте не сохраняется. Поскольку она не хранится, выполнить её повторно без ещё одного HTTP-запроса с полезной нагрузкой невозможно. Браузеры Chrome, Internet Explorer, Edge и Safari пытались предотвращать такие уязвимости с помощью XSS Auditor. Это встроенная функция браузеров, которая старается защитить пользователей от вредоносных ссылок, выполняющих JavaScript. При её срабатывании браузер обычно показывает повреждённую страницу и сообщение, что она заблокирована ради защиты пользователя.

Несмотря на усилия разработчиков браузеров, XSS Auditor часто удаётся обойти из-за множества сложных способов выполнения JavaScript на сайте. Методы обхода постоянно меняются и потому выходят за рамки книги, но есть два прекрасных источника: запись FileDescriptor о заголовке x-xss-protection^[1] и памятка Масато Кинугавы по обходу фильтров^[2].

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

XSS также делится на три подтипа: основанная на DOM, слепая и направленная на самого себя. XSS на основе DOM возникает при манипулировании существующим JavaScript-кодом веб-сайта, которое приводит к выполнению вредоносного JavaScript; такая XSS может быть хранимой или отражённой. Например, если веб-сайт с помощью следующего HTML заменяет содержимое значением из URL и не проверяет его на вредоносный ввод, появляется возможность выполнить XSS:

На этой примерной веб-странице тег script вызывает у объекта document метод getElementById, чтобы найти HTML-элемент с идентификатором name. В результате возвращается ссылка на элемент span внутри тега <h1>. Затем тег script методом innerHTML изменяет текст между <span id="name"></span>. Код устанавливает в <span></span> значение из location.hash, то есть всё, что находится после символа # в URL. location - ещё один API браузера, подобный DOM; он предоставляет доступ к сведениям о текущем URL.

Если страница доступна по адресу www.example.com/hi, то посещение www.example.com/hi#Peter динамически изменит HTML на <h1>Hi Peter</h1>. Однако страница не очищает значение после # перед обновлением элемента span. Поэтому, если пользователь посетит www.example.com/h1#<img src=x onerror=alert(document.domain)>, появится окно JavaScript с текстом www.example.com, если браузеру не удалось получить изображение x. Итоговый HTML страницы будет выглядеть так:

Слепая XSS - разновидность хранимой XSS, при которой полезную нагрузку отображает другой пользователь в области сайта, обычно недоступной хакеру. Например, при создании личного профиля сайт может позволить указать XSS в имени и фамилии. Эти значения могут экранироваться, когда профиль просматривают обычные пользователи, но не очищаться на административной странице со списком всех новых пользователей. Когда администратор открывает страницу, XSS выполняется. Для обнаружения подобных случаев отлично подходит инструмент XSSHunter^[3] Мэтта Брайанта. Созданные Мэттом полезные нагрузки выполняют JavaScript, который загружает удалённый сценарий, предназначенный для чтения DOM, сведений о браузере, cookie,

и другой информации, а после выполнения отправляет собранные данные обратно в вашу учётную запись XSSHunter.

Уязвимости Self XSS могут быть хранимыми или нехранимыми, но обычно затрагивают только того пользователя, который вводит полезную нагрузку, откуда и слово «self» в названии. Например, XSS может отправляться POST-запросом, защищённым от CSRF, так что передать полезную нагрузку XSS способен только сам объект атаки. Поскольку злоумышленник может атаковать лишь себя, такая XSS обычно считается менее опасной и не оплачивается программами вознаграждений. Обнаружив её, лучше сохранить сведения и поискать возможность объединить находку с другой уязвимостью для атаки на невиновных пользователей, например с CSRF входа и выхода.

При такой атаке жертву выводят из её учётной записи и вводят в учётную запись злоумышленника, где выполняется вредоносный JavaScript. Обычно необходимо, чтобы вредоносный JavaScript мог снова войти в эту учётную запись от имени жертвы. Прекрасный пример на одном из сайтов Uber опубликовал Джек Уиттон^[4].

Последствия XSS зависят от множества факторов: является ли уязвимость хранимой или отражённой, доступны ли cookie, где выполняется полезная нагрузка и так далее. Несмотря на потенциальную серьёзность, исправить XSS часто несложно: разработчикам достаточно очищать пользовательский ввод перед отображением, как и при HTML-инъекции.

XSS-уязвимости представляют реальную угрозу для разработчиков сайтов и по-прежнему широко встречаются, нередко прямо на виду. Чтобы проверить поле ввода, достаточно передать вызов метода JavaScript alert, например alert('test'). Кроме того, можно объединить этот приём с HTML-инъекцией и отправить символы в кодировке ASCII, проверяя, отображается и интерпретируется ли текст.

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

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

Существует два вида инъекций шаблонов: серверные и клиентские. Обе возникают, когда движок отображает пользовательский ввод без правильной очистки, подобно межсайтовому скриптингу. Но, в отличие от XSS, инъекции шаблонов иногда позволяют удалённо выполнять код.

Серверные инъекции шаблонов (server-side template injection, SSTI) происходят, когда инъекция затрагивает серверную логику. Шаблонизаторы обычно связаны с конкретными языками программирования, поэтому при инъекции иногда удаётся выполнить произвольный код на соответствующем языке. Возможность выполнения зависит от средств безопасности движка и мер защиты самого сайта. Например, с шаблонизатором Python Jinja2 связывали произвольный доступ к файлам и удалённое выполнение кода; то же относится к шаблонизатору Ruby ERB, который Rails использует по умолчанию. В противоположность им движок Shopify Liquid предоставляет доступ лишь к ограниченному числу методов Ruby, препятствуя полноценному удалённому выполнению кода. Среди других популярных движков - Smarty и Twig для PHP, Haml для Ruby, Mustache и многие другие.

Синтаксис проверки SSTI зависит от движка, но обычно нужно передать шаблонные выражения в определённой записи. Например, PHP-шаблонизатор Smarty обозначает выражения четырьмя фигурными скобками ({{ }}), а ERB - сочетанием угловых скобок, знаков процента и равенства (<%= %>). Для проверки инъекции в Smarty можно отправить {{7*7}} в любом месте, где ввод отражается на странице - в форме, параметре URL и так далее, - и посмотреть, появится ли 49 в результате выполнения кода 7*7 внутри выражения.

Если отображается 49, выражение было успешно внедрено и вычислено шаблонизатором.

Поскольку у шаблонизаторов нет единого синтаксиса, важно определить, на каком программном обеспечении построен проверяемый сайт. Инструменты Wappalyzer и BuiltWith созданы именно для этого, поэтому рекомендую один из них. Установив используемую технологию, отправьте полезную нагрузку 7*7 в её синтаксисе.

Клиентские инъекции шаблонов (client-side template injection, CSTI) возникают при инъекции в клиентские шаблонизаторы, обычно написанные на JavaScript. Среди популярных клиентских движков - AngularJS, разработанный Google, и ReactJS от Facebook.

Поскольку CSTI происходит в программе, работающей в браузере пользователя, большинство таких инъекций обычно позволяет добиться только межсайтового скриптинга, а не удалённого выполнения кода. Но даже для XSS порой приходится обходить защиту, как и при SSTI. Например, версии AngularJS до 1.6 содержали песочницу, которая должна была ограничивать доступ к некоторым функциям JavaScript и тем самым защищать от XSS. Версию AngularJS можно проверить, открыв в браузере консоль разработчика и введя angular.version. Однако этичные хакеры регулярно находили и публиковали обходы песочницы. Для версий 1.3.0-1.5.7 при обнаружении инъекции Angular широко использовался следующий обход:

Другие опубликованные способы выхода из песочницы Angular находятся по адресам pastebin.com и jsfiddle.net.

Чтобы продемонстрировать серьёзность CSTI, необходимо проверить, какой код потенциально выполняется. Сайт может вычислять некоторый JavaScript, но использовать дополнительную защиту от эксплуатации. Например, я обнаружил CSTI, передав полезную нагрузку {{4+4}}, которая вернула 8 на сайте с AngularJS. Однако после ввода {{4*4}} сайт вернул текст {{44}}, поскольку очищал данные удалением звёздочки. Поле также удаляло специальные символы () и [] и принимало не более 30 символов. Вместе эти ограничения фактически делали CSTI бесполезной.

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

Инъекция языка структурированных запросов (SQL injection, SQLi) возникает, когда уязвимость сайта, опирающегося на базу данных, позволяет злоумышленнику выполнять запросы к этой базе или иным образом атаковать её. За SQLi часто выплачивают крупные вознаграждения, поскольку последствия могут быть разрушительными. Злоумышленник способен изменять или извлекать сведения и даже создать себе в базе данных учётную запись администратора.

Базы данных хранят сведения в записях и полях, содержащихся в наборе таблиц. Таблица состоит из одного или нескольких столбцов, а каждая строка таблицы представляет запись базы данных.

Для создания, чтения, изменения и удаления записей пользователи применяют язык программирования SQL - язык структурированных запросов. Пользователь отправляет базе данных команды SQL, называемые также инструкциями или запросами. Если база принимает команду, то интерпретирует её и выполняет некоторое действие. Среди популярных баз данных SQL - MySQL, PostgreSQL, MSSQL и другие. В этой главе мы будем использовать MySQL, но общие принципы относятся ко всем базам SQL.

Инструкции SQL состоят из ключевых слов и функций. Например, следующая инструкция предписывает базе выбрать сведения из столбца name таблицы users для записей, где столбец id равен 1:

Многие веб-сайты хранят сведения в базах данных и используют их для динамического создания содержимого. Например, сайт https://www.leanpub.com/ хранит в базе сведения о прежних заказах и список купленных электронных книг; доступ к ним открывается после входа в учётную запись. Веб-браузер обращается к базе сайта и создаёт HTML на основании возвращённых сведений.

Рассмотрим условный пример серверного кода PHP, создающего команду MySQL после посещения пользователем URL https://www.leanpub.com?name=yaworsk:

Код посредством $_GET[] получает из параметров URL значение name, указанное между квадратными скобками, и сохраняет его в переменной $name. Затем параметр без какой-либо очистки передаётся в переменную $q. Переменная $q представляет выполняемый запрос, который извлекает все данные из таблицы users, где значение столбца name совпадает с параметром URL name. Запрос выполняется передачей переменной $q PHP-функции mysql_query.

Сайт ожидает, что name содержит обычный текст. Но если пользователь введёт в параметр URL вредоносную строку test' OR 1='1, как в https://www.leanpub.com?name=test' OR 1='1, выполнится следующий запрос:

Вредоносный ввод закрывает начальную одинарную кавычку после значения test и добавляет в конец запроса SQL-код OR 1='1. Висящая одинарная кавычка в OR 1='1 открывает закрывающую одинарную кавычку, жёстко записанную после ввода. Если бы во внедрённом запросе не было открывающей одинарной кавычки, висящая кавычка привела бы к синтаксической ошибке SQL и запрос не выполнился бы.

SQL поддерживает условные операторы наподобие AND и OR. В данном случае инъекция изменяет предложение WHERE: теперь оно ищет записи, где столбец name соответствует test или уравнение 1='1' истинно. MySQL услужливо преобразует '1' в целое число. Поскольку 1 всегда равно 1, условие истинно и запрос возвращает все записи таблицы users.

Однако инъекция test' OR 1='1 не сработает, если очищаются другие части запроса. Например, запрос может выглядеть так:

Здесь параметр пароля тоже управляется пользователем, но правильно очищается функцией mysql_real_escape_string. Если применить ту же полезную нагрузку test' OR 1='1 в качестве имени, а пароль будет равен 12345, инструкция примет следующий вид:

Запрос ищет все записи, где имя равно test либо 1='1' и пароль равен 12345. Мы не станем останавливаться на том, что база хранит пароли открытым текстом, хотя это ещё одна уязвимость.

Поскольку для проверки пароля применяется оператор AND, запрос не возвращает данные, если пароль записи не равен 12345. Попытка SQLi терпит неудачу, но ничто не мешает выбрать другой способ атаки.

Нам необходимо исключить параметр пароля, и это можно сделать добавлением ;--: test' OR 1='1;-- . Инъекция решает две задачи: точка с запятой (;) завершает инструкцию SQL, а два дефиса (--) сообщают базе, что остальной текст является комментарием. Внедрённый параметр превращает запрос в SELECT * FROM users WHERE name = 'test' OR 1='1';. Код AND password = '12345' становится комментарием, и команда возвращает все записи таблицы. Применяя -- для комментария, помните: MySQL требует пробел после двух дефисов и перед оставшейся частью запроса, иначе вернёт ошибку и не выполнит команду.

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

Веб-фреймворки Ruby on Rails, Django, Symfony и другие тоже предлагают встроенные средства предотвращения SQLi. Но они несовершенны и не способны предотвратить уязвимость везде. Два простых примера SQLi, рассмотренные выше, обычно не сработают на сайтах с фреймворками, если только разработчики не нарушили передовые практики или не поняли, что защита не предоставляется автоматически. Например, сайт https://www.rails-sqli.org/ поддерживает список распространённых шаблонов SQLi в Rails, возникающих из-за ошибок разработчиков. При поиске SQLi лучше всего проверять старые сайты, которые выглядят как самостоятельно разработанные либо построены на веб-фреймворках и системах управления содержимым без всех встроенных защит современных систем.

SQLi может быть серьёзной и опасной для сайта уязвимостью. Обнаружив её, злоумышленник способен получить полные разрешения на сайте. Иногда SQLi удаётся развить, вставив в базу данные, которые предоставляют административные права, как в примере Drupal. При поиске SQLi обращайте внимание на места, где запросу можно передать неэкранированные одинарные или двойные кавычки. Признаки найденной уязвимости могут быть малозаметными, как при слепых инъекциях. Ищите также места, где данные можно передать сайту неожиданным способом, например заменить обычные параметры запроса массивами, как в ошибке Uber.

Подделка запросов на стороне сервера (server-side request forgery, SSRF) - уязвимость, позволяющая злоумышленнику заставить сервер выполнять непредусмотренные сетевые запросы. SSRF похожа на CSRF, но между ними есть важное отличие: жертвой CSRF является пользователь, а жертвой SSRF - сам веб-сайт.

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

Уязвимость внешних сущностей XML (XML External Entity, XXE) эксплуатирует то, как приложение разбирает входные данные XML, а точнее - как оно обрабатывает включённые во ввод внешние сущности. Чтобы в полной мере понять эксплуатацию и её возможности, сначала следует разобраться, что такое расширяемый язык разметки (eXtensible Markup Language, XML) и внешние сущности.

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

Например, в HTML есть теги <title>, <h1>, <table>, <p> и другие, которые определяют способ отображения содержимого. Тег <title> задаёт заголовок страницы - неожиданно, правда? Теги <h1> обозначают заголовки, <table> представляет данные в строках и столбцах, а <p> отображается как простой текст. В XML предопределённых тегов нет. Автор XML-документа сам определяет теги для описания представляемого содержимого. Вот пример:

По этому фрагменту нетрудно догадаться о назначении XML-документа: он представляет объявление о работе. Но вы не знаете, как оно будет выглядеть на веб-странице. Первая строка XML - заголовок объявления, где указаны версия XML и вид кодировки. На момент написания книги существовали две версии XML: 1.0 и 1.1. Различия между ними выходят за рамки книги и не должны влиять на вашу работу.

После начального заголовка идёт тег <jobs>, окружающий все теги <job>, внутри которых находятся <title>, <compensation> и <responsibility>. В HTML некоторые теги, например <br>, не требуют закрывающего тега, но в XML закрываться должен каждый тег. В приведённом примере <jobs> является начальным тегом, а </jobs> - соответствующим конечным. Кроме того, у каждого тега есть имя и могут быть атрибуты. У тега <job> имя job, но атрибутов нет. Тег <responsibility>, напротив, имеет имя responsibility и атрибут optional, состоящий из имени optional и значения 1.

Поскольку любой человек может определить произвольный тег, возникает очевидный вопрос: как разобрать и использовать XML-документ, если теги могут быть какими угодно? Документ XML считается действительным, когда соответствует общим правилам XML - перечислять их все незачем, но примером служит обязательный закрывающий тег - и своему определению типа документа (document type definition, DTD). Именно ради DTD мы так подробно изучаем тему: это одна из составляющих, которая позволит нам, хакерам, провести эксплуатацию.

DTD XML подобно документу с определениями применяемых тегов и создаётся проектировщиком, то есть автором XML. В приведённом примере проектировщиком был бы я, поскольку определил документ jobs в XML. DTD задаёт существующие теги, возможные атрибуты, элементы, которые могут входить в другие элементы, и так далее. Мы с вами можем создавать собственные DTD, но некоторые формализованы и широко распространены: Really Simple Syndication (RSS), общие ресурсы данных (RDF), обмен медицинскими сведениями (HL7 SGML/XML) и другие.

Файл DTD для приведённого XML выглядел бы так:

По фрагменту можно догадаться о значении большинства строк. Наш тег <jobs> в действительности является XML-элементом !ELEMENT и может содержать элемент Job. Job - элемент, способный содержать Title, Compensation и Responsibility. Все они тоже являются !ELEMENT и могут хранить только символьные данные, обозначенные (#PCDATA). Наконец, у элемента Responsibility может быть атрибут optional - !ATTLIST, - значение которого по умолчанию равно 0.

Не слишком сложно, правда? Помимо DTD остались два важных тега, которые мы ещё не обсудили: !DOCTYPE и !ENTITY. До сих пор я подразумевал, что файлы DTD находятся вне XML. Помните первый пример? Определения тегов отсутствовали в XML-документе и находились в DTD из второго примера. Но DTD можно включить в сам XML-документ. Для этого первой строкой XML после объявления должен быть элемент <!DOCTYPE>.

Объединив два предыдущих примера, получим следующий документ:

Это называется внутренним объявлением DTD. Мы по-прежнему начинаем с заголовка, где указано соответствие документа XML 1.0 и кодировка UTF-8, но сразу после него определяем DOCTYPE для следующего далее XML. Внешний DTD выглядел бы похоже, но !DOCTYPE был бы записан как <!DOCTYPE jobs SYSTEM "jobs.dtd">. При разборе XML-файла анализатор прочитал бы содержимое jobs.dtd. Это важно, поскольку тег !ENTITY обрабатывается похожим образом и лежит в самой основе нашей эксплуатации.

Сущность XML подобна заполнителю сведений. Снова воспользуемся прежним примером. Если необходимо добавить к каждой вакансии ссылку на наш сайт, было бы утомительно всякий раз писать адрес, особенно если URL может измениться. Вместо этого можно применить !ENTITY: при разборе анализатор получает содержимое и вставляет значение в документ. Надеюсь, вы понимаете, к чему я веду.

Подобно внешнему файлу DTD, XML можно изменить в соответствии с этой идеей:

Обратите внимание: я добавил !ELEMENT с именем Website, но вместо (#PCDATA) указал ANY. Это означает, что тег Website может содержать любое сочетание разбираемых данных. Кроме того, определена сущность !ENTITY с атрибутом SYSTEM, предписывающим анализатору получить содержимое файла website.txt. Картина должна становиться яснее.

Как вы думаете, что произойдёт, если вместо website.txt указать /etc/passwd? Как вы, вероятно, догадались, XML будет разобран, а содержимое конфиденциального серверного файла /etc/passwd попадёт в документ. Но ведь автор XML - мы сами; зачем нам это делать?

Атака XXE становится возможной, когда приложение-жертву удаётся заставить включать подобные внешние сущности при разборе XML. Иными словами, приложение ожидает определённый XML, но не проверяет полученные данные, а просто разбирает их. Допустим, я управляю доской вакансий и позволяю регистрироваться и загружать вакансии в XML. Разрабатывая приложение, я могу предоставить вам свой DTD и предположить, что отправленный файл будет соответствовать требованиям. Не осознавая опасности, я без проверки разбираю всё полученное. Но вы, будучи хакером, отправляете следующее:

Теперь вы знаете, что мой анализатор получит документ и распознает внутренний DTD. Тот определяет тип документа foo, разрешает foo включать любые разбираемые данные и объявляет сущность !ENTITY xxe. При разборе она должна прочитать мой файл /etc/passwd; запись file:// обозначает полный URI-путь к файлу. Элементы &xxe; заменяются содержимым файла. Наконец, вы завершаете действительный XML тегом <foo>, который выводит сведения моего сервера. Вот, друзья, почему XXE так опасна.

Но это ещё не всё. Что, если приложение ничего не выводит, а только разбирает содержимое? В предыдущем примере файл будет прочитан, но мы его не получим. Тогда вместо включения локального файла можно обратиться к вредоносному серверу:

Вы, возможно, заметили, что в URL callhome используется %xxe;, а не &xxe;. Знак % применяется, когда сущность вычисляется внутри самого определения DTD, а & - когда она вычисляется в XML-документе. Теперь при разборе документа сущность callhome читает содержимое /etc/passwd и выполняет удалённый вызов к www.malicious.com, передавая файл как параметр URL. Поскольку сервер находится под нашим управлением, мы проверяем журналы и, конечно же, находим содержимое /etc/passwd. Для веб-приложения игра окончена.

Как сайты защищаются от XXE? Отключают разбор внешних сущностей.

XXE - интересный вектор атаки с огромным потенциалом. Как мы увидели, провести атаку можно несколькими способами: заставить уязвимое приложение вывести свой файл /etc/passwd, обратиться к удалённому серверу с содержимым /etc/passwd либо запросить удалённый DTD, который предписывает анализатору выполнить обратный вызов сервера с файлом /etc/passwd.

Удалённое выполнение кода означает внедрение кода, который интерпретируется и выполняется уязвимым приложением. Обычно причиной служит пользовательский ввод, который приложение применяет без какой-либо очистки или проверки.

Пример может выглядеть так:

Уязвимое приложение может использовать URL index.php?page=1. Но если пользователь введёт index.php?page=1;phpinfo(), приложение выполнит функцию phpinfo() и вернёт её результат.

Термин «удалённое выполнение кода» иногда применяют и к инъекциям команд, хотя OWASP различает эти понятия. Согласно OWASP, при инъекции команд уязвимое приложение выполняет произвольные команды в операционной системе узла. Это снова становится возможным из-за неправильной очистки или проверки пользовательского ввода, который попадает в команды операционной системы.

Например, в PHP пользовательский ввод может передаваться функции system().

Удалённое выполнение кода, как и другие уязвимости, обычно возникает из-за неправильной проверки и обработки пользовательского ввода. В первом примере ImageMagick неправильно экранировала потенциально вредоносное содержимое. Вместе со знанием уязвимости это позволило Бену целенаправленно найти и проверить области, которые, вероятно, были подвержены атаке. Простого ответа на вопрос, как искать такие уязвимости, нет. Следите за опубликованными CVE и за программным обеспечением сайтов, которое может быть устаревшим, а следовательно - уязвимым.

Хотя уязвимости памяти прекрасно подходят для громких заголовков, работать с ними очень трудно и для этого требуется серьёзное мастерство. Если у вас нет опыта программирования на низкоуровневых языках, лучше оставить их в покое.

Захват поддомена означает именно то, что следует из названия: злоумышленник получает возможность присвоить поддомен законного сайта. В двух словах, сайт создаёт запись DNS для поддомена у внешней службы, например хостинговой компании Heroku, но никогда не регистрирует сам поддомен.

Захват поддомена не слишком трудно осуществить, когда сайт уже создал неиспользуемую запись DNS, которая указывает на стороннюю службу или незарегистрированный домен. Мы увидели это с Heroku, Fastly, незарегистрированными доменами, S3 и Zendesk; наверняка существуют и другие варианты. Обнаруживать уязвимости можно разными способами: с помощью KnockPy, запросов Google Dork site:*.hackerone.com, Recon-ng, crt.sh и прочих инструментов. Все они описаны в главе «Инструменты».

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

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

Уязвимость небезопасной прямой ссылки на объект (insecure direct object reference, IDOR) возникает, когда злоумышленник может получить доступ к ссылке на какой-либо объект - файл, запись базы данных, учётную запись и так далее - либо изменить её, хотя этот объект должен быть ему недоступен. Например, при просмотре своей учётной записи на сайте с закрытыми профилями вы можете посетить www.site.com/user=123. Но если вы попробуете открыть www.site.com/user=124 и получите доступ, сайт будет уязвим для IDOR.

IDOR возникают, когда злоумышленник получает доступ к ссылке на объект или может изменить её, хотя объект должен быть ему недоступен. Это прекрасный тип уязвимостей для проверки: сложность варьируется от простого прибавления и вычитания единицы из целочисленного идентификатора до более трудных случаев с UUID или случайными значениями. Если сайт применяет UUID или случайные идентификаторы, ещё не всё потеряно. Иногда их можно угадать или найти места, где сайт их раскрывает, например JSON-ответы, HTML-содержимое и URL.

Согласно сайту OAuth, это открытый протокол, который позволяет простым и стандартным способом выполнять безопасную авторизацию в веб-приложениях, мобильных и настольных приложениях. Иначе говоря, OAuth - форма аутентификации, с помощью которой пользователь разрешает сайту или приложению обращаться к своим данным на другом сайте, не раскрывая и не передавая пароль. Именно этот процесс даёт возможность входить на сайты через Facebook, Twitter, LinkedIn и другие службы. Существуют две несовместимые версии OAuth - 1.0 и 2.0. В этой главе мы будем работать с версией 2.0.

Поскольку процесс может показаться весьма запутанным, а при его реализации легко допустить множество ошибок, ниже приведена прекрасная схема из блога Филиппа Хэрвуда^[1], показывающая общий ход событий.

Филипп Хэрвуд - процесс OAuth Facebook

Разберём схему. Вверху находятся три участника: браузер пользователя, серверный код вашего приложения и API Facebook. В терминах OAuth это соответственно владелец ресурса (Resource Owner), клиент (Client) и сервер ресурсов (Resource Server). Главное заключается в следующем: ваш браузер выполняет и обрабатывает несколько HTTP-запросов, чтобы вы как владелец ресурса поручили серверу ресурсов предоставить клиенту доступ к своим личным сведениям в пределах запрошенных областей действия.

Области действия (scopes) подобны разрешениям: они управляют доступом к конкретным данным. Например, Facebook предлагает области email, public_profile, user_friends и другие. Если вы разрешили только email, сайт сможет получить из Facebook лишь адрес электронной почты, но не список друзей, профиль и прочие сведения.

Теперь пройдём по этапам.

Процесс OAuth начинается в браузере пользователя, когда тот нажимает «Войти через Facebook». В результате браузер отправляет GET-запрос текущему сайту. Путь обычно выглядит примерно так: www.example.com/oauth/facebook.

Сайт отвечает перенаправлением 302, которое приказывает браузеру выполнить GET-запрос по URL из заголовка Location. Адрес выглядит примерно так:

В этом URL есть несколько важных частей. Параметр client_id определяет сайт, с которого вы пришли. redirect_uri сообщает Facebook, куда вернуть вас после того, как вы разрешите сайту - клиенту - доступ к сведениям, указанным в параметре scope, который также находится в URL.

Параметр response_type указывает Facebook, что вернуть: токен или код. Различие принципиально. Разрешённый сайт (клиент) использует код для повторного обращения к серверу ресурсов - в нашем случае Facebook - и получения токена. Если же на этом первом этапе запросить и получить токен, он немедленно предоставит доступ к серверу ресурсов и позволит запрашивать сведения учётной записи, пока остаётся действительным.

Наконец, значение state служит защитой от CSRF. Запрашивающий сайт (клиент) должен включить его в первоначальный вызов сервера ресурсов, а тот должен вернуть значение, подтверждая, что: а) исходный запрос действительно инициировал сайт; б) ответ не был подделан.

Если пользователь принимает диалог OAuth и разрешает клиенту доступ к своим данным на сервере ресурсов - в нашем случае Facebook, - сервер отвечает браузеру перенаправлением 302 обратно на сайт (клиент) по адресу redirect_uri. В зависимости от response_type первоначального URL к нему добавляется код или токен, обычно код.

Браузер выполняет GET-запрос к сайту (клиенту), передавая в URL полученные от сервера ресурсов значения code и state.

Сайт (клиент) должен проверить state, чтобы убедиться в отсутствии вмешательства, а затем вместе с известным только ему client_secret использовать код в GET-запросе токена к серверу ресурсов, то есть здесь к Facebook.

Сервер ресурсов - в нашем примере Facebook - возвращает сайту (клиенту) токен. С его помощью клиент вызывает API Facebook и получает доступ к областям, которые вы разрешили на третьем этапе.

Помня обо всём процессе, обратите внимание: после того как вы разрешили сайту (клиенту) обращаться к серверу ресурсов, то есть к Facebook в нашем случае, повторное посещение URL со второго этапа запускает все остальные действия полностью в фоновом режиме и уже не требует вмешательства пользователя.

Поэтому одна из возможных уязвимостей OAuth - кража возвращаемых сервером ресурсов токенов. Она позволит злоумышленнику обращаться к серверу от имени жертвы и получать всё, что было разрешено областями действия на третьем этапе. Судя по моему исследованию, обычно это становится возможным из-за изменения redirect_uri и запроса токена вместо кода.

Первую проверку проводят на втором этапе. После перенаправления к серверу ресурсов измените response_type и посмотрите, вернёт ли сервер токен. Если да, поменяйте redirect_uri, чтобы выяснить, как настроен сайт или приложение. Иногда сами серверы OAuth настроены неверно и принимают адреса наподобие www.example.ca и www.example.com@attacker.com. В первом случае добавление .ca фактически меняет домен. Если вы можете сделать нечто подобное и приобрести этот домен, токены будут поступать на ваш сервер. Во втором случае символ @ также меняет смысл URL: первая половина считается именем пользователя и паролем, а запрос направляется на attacker.com.

Оба варианта - наилучший для хакера сценарий, если пользователь уже предоставил сайту (клиенту) разрешение. При повторном посещении теперь уже вредоносного URL с изменёнными response_type и redirect_uri сервер ресурсов поймёт, что пользователь ранее дал разрешение, и без всякого взаимодействия автоматически вернёт токен вашему серверу. Например, жертве можно показать вредоносный тег <img>, атрибут src которого содержит этот URL.

Предположим, перенаправить запрос прямо на свой сервер нельзя. Всё равно проверьте, принимает ли сервер ресурсов другие поддомены, например test.example.com, или пути вроде www.example.com/attacker-controlled. При недостаточно строгой настройке redirect_uri сервер ресурсов может отправить токен на управляемый вами URL. Однако для его кражи потребуется объединить это поведение с другой уязвимостью. Подойдут открытое перенаправление, запрос удалённого изображения или XSS.

В случае открытого перенаправления, если вы управляете путём и/или поддоменом назначения, токен из URL утечёт в заголовке Referer, который поступит вашему серверу. Иными словами, открытое перенаправление отправит пользователя на ваш вредоносный сайт, а запрос к серверу будет содержать URL предыдущей страницы. Сервер ресурсов направил жертву к открытому перенаправлению и включил токен в URL, поэтому токен окажется и в полученном вами заголовке Referer.

Удалённое изображение действует сходным образом. Сервер ресурсов перенаправляет браузер на страницу, которая загружает изображение с вашего сервера. Когда браузер жертвы запрашивает файл, заголовок Referer этого запроса содержит URL. Поскольку в URL находится токен, он попадёт в запрос к вашему серверу.

Наконец, XSS: если на любом поддомене или пути перенаправления найдена хранимая XSS либо отражённая XSS является частью redirect_uri, злоумышленник может запустить сценарий, который извлечёт токен из URL и отправит его на свой сервер.

Это лишь некоторые способы злоупотребления OAuth. Из примеров вы узнаете и о других.

В начале изучения OAuth бывает трудно понять - во всяком случае, так было со мной и хакерами, у которых я учился. Но сложность протокола создаёт множество возможностей для уязвимостей. Во время проверки ищите творческие решения, подобные захвату стороннего приложения Филиппом или злоупотреблению доменными суффиксами Пракхаром.

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

Уязвимости логики приложения не всегда связаны с внедрением кода. Для их эксплуатации чаще нужны внимательность и нестандартное мышление.

• Path Traversal Cheat Sheet Linux

• XXE Cheat Sheet

• HTML5 Security Cheat Sheet

• Brute XSS Cheat Sheet

• XSS Polyglots

• MySQL SQL Injection Cheat Sheet

• AngularJS Sandbox Bypass Collection, включая 1.5.7

Чёрный хакер (Black Hat Hacker) - человек, который «нарушает компьютерную безопасность без особой причины, кроме злого умысла, либо ради личной выгоды» (Роберт Мур, 2005, Cybercrime). В индустрии безопасности и среди современных программистов их также называют взломщиками (crackers). Они нередко совершают вредоносные действия, уничтожая, изменяя или похищая данные. Противоположность белого хакера.

Переполнение буфера (Buffer Overflow) - ситуация, когда программа записывает в буфер, то есть область памяти, больше данных, чем для неё выделено места. В результате запись затрагивает память, которую изменять не следовало.

Предложение сайта, по которому белые хакеры получают признание или оплату за сообщения об ошибках, особенно уязвимостях безопасности. Примеры - HackerOne.com и Bugcrowd.com.

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

CRLF-инъекция, или внедрение последовательности «возврат каретки - перевод строки» (Carriage Return Line Feed), возникает, когда пользователь вставляет CRLF в приложение. Иногда её называют разделением HTTP-ответа.

Атака межсайтовой подделки запроса (Cross-Site Request Forgery, CSRF) происходит, когда вредоносный сайт, письмо, мгновенное сообщение, приложение или другой источник заставляет браузер пользователя выполнить действие на сайте, где тот уже аутентифицирован, то есть вошёл в систему.

Межсайтовый скриптинг (Cross-Site Scripting, XSS) заключается в том, что сайт включает непредусмотренный код JavaScript, затем передаёт его пользователям, а их браузеры этот код исполняют.

Инъекция языка гипертекстовой разметки (HTML), иногда называемая виртуальным искажением сайта, - атака, при которой приложение неправильно обрабатывает пользовательский ввод и позволяет злоумышленнику внедрить HTML.

Загрязнение параметров HTTP (HTTP Parameter Pollution, HPP) возникает, когда сайт принимает пользовательский ввод и без проверки применяет его в HTTP-запросе к другой системе.

Другое название CRLF-инъекции, при которой злоумышленник внедряет заголовки в ответ сервера.

Повреждение памяти (Memory Corruption) - способ обнаружить уязвимость, заставив код вести себя необычно или непредусмотренно. Последствие похоже на переполнение буфера: раскрывается память, которая должна быть недоступна.

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

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

Также известны как белые хакеры. Любые люди, изучающие потенциальную проблему безопасности технологии: академические исследователи, инженеры-программисты, системные администраторы и даже технически увлечённые любители.

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

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

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

Процесс совместной работы всех сторон над устранением уязвимости. Например, взаимодействие исследователя (белого хакера) с компанией на HackerOne или с сообществом открытого проекта.

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

Белый хакер (White Hat Hacker) - этичный исследователь, работа которого направлена на обеспечение безопасности организации. Иногда белых хакеров называют специалистами по испытаниям на проникновение. Противоположность чёрного хакера.

• Переписана глава «С чего начать».

• В главу «Инструменты» добавлены новые средства: Gowitness, Gobuster, Meg.

• Переписаны описания XSS, SSTI, SQLi, SSRF и состояний гонки.

• Добавлен новый пример SQLi Uber от Orange.

• Добавлен новый пример сканирования портов через SSRF.

• Добавлены два новых примера состояний гонки: Keybase и HackerOne.

• Добавлена новая уязвимость SSRF Google.

• По всей книге исправлены небольшие опечатки и грамматические ошибки.

• Переписаны описания глав об открытых перенаправлениях, HPP, CSRF, HTML-инъекциях и CRLF; пересмотрены соответствующие примеры.

• Добавлен пример захвата поддомена Uber.

• Добавлены новые примеры IDOR Moneybird и Twitter.

• Добавлен новый пример логики приложения Twitter.

• Добавлена новая глава об OAuth и один пример.

• Пример OAuth Facebook Филиппа перенесён из главы о захвате поддоменов в OAuth.

• Изменён порядок глав; состояния гонки и IDOR выделены в самостоятельные главы.

• В главу «Инструменты» добавлены GitRob и Race the Web.

• Добавлен новый пример состояния гонки HackerOne с принятием приглашений.

• Добавлены две новые уязвимости удалённого выполнения кода.

• Глава об XXE обновлена для уточнения примера Facebook.

• Исправлены разные опечатки.

• Добавлен новый, шестой пример захвата поддомена: api.legalrobot.com.

• Добавлено приложение B с выводами.

• Добавлен новый, пятый пример захвата поддомена: Snapchat Fastly s.sc.

• Добавлены новые инструменты: XSSHunter, Censys, OnlineHashCrack, Ysoserial.

• Добавлена новая памятка AngularJS, включая обход песочницы версии 1.5.7.