Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
«Чтобы чему-то научиться, надо применять знания на практике. Именно так мы освоили ремесло взлома» - Майкл Принс и Йоберт Абма, соучредители HackerOne. «Ловушка для багов» познакомит вас с белым хакингом — поиском уязвимостей в системе безопасности. Неважно, являетесь ли вы новичком в области кибербезопасности, который хочет сделать интернет безопаснее, или опытным разработчиком, который хочет писать безопасный код, Питер Яворски покажет вам, как это делается. В книге рассматриваются распространенные типы ошибок и реальные хакерские отчеты о таких компаниях, как Twitter, Facebook, Google, Uber и Starbucks. Из этих отчетов вы поймете принципы работы уязвимостей и сможете сделать безопасней собственные приложения. Вы узнаете: •как работает интернет, и изучите основные концепции веб-хакинга; •как злоумышленники взламывают веб-сайты; •как подделка запросов заставляет пользователей отправлять информацию на другие веб-сайты; •как получить доступ к данным другого пользователя •с чего начать охоту за уязвимостями; •как заставить веб-сайты раскрывать информацию с помощью фейковых запросов.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 267
Veröffentlichungsjahr: 2024
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Переводчик С. Черников
Питер Яворски
Ловушка для багов. Полевое руководство по веб-хакингу. — СПб.: Питер, 2024.
ISBN 978-5-4461-1708-6
© ООО Издательство "Питер", 2024
Питер Яворски стал хакером, самостоятельно изучая опыт предшественников (некоторые из них упоминаются в книге). Ныне это успешный охотник за уязвимостями, на счету которого благодарности от Salesforce, Twitter, Airbnb, Verizon Media, Министерства обороны США и др., сейчас он является инженером по безопасности приложений в Shopify.
Цан Чи Хонг, известный под псевдонимом FileDescriptor, — пентестер и охотник за уязвимостями. Проживает в Гонконге, пишет статьи о веб-безопасности на сайте blog.innerht.ml, интересуется саундтреками и криптовалютой.
Чтобы чему-то научиться, надо применять знания на практике. Именно так мы освоили ремесло взлома.
Как и у всех в этом деле, нашей главной мотивацией было любопытство. Мы обожали компьютерные игры, и к 12 годам захотели создавать собственные программы. Освоить программирование на Visual Basic и PHP нам помогли книжки из библиотеки.
Имея некоторое представление о разработке ПО, мы начали находить ошибки разработчиков. И перешли от созидания к разрушению. Чтобы отпраздновать окончание средней школы, мы перехватили управление каналом телевещания и прокрутили ролик с поздравлением нашего класса. Это казалось забавным, пока мы не узнали о последствиях подобных действий — такой хакинг не поощрялся. Мы были наказаны и провели все лето за мытьем окон. В колледже нас занимал доходный консалтинговый бизнес, который обслуживал государственных и частных клиентов во всем мире. А кульминацией нашего опыта стала компания HackerOne, которую мы основали в 2012 году. Мы хотели, чтобы любая организация могла сотрудничать с хакерами, и это остается нашей миссией по сей день.
Если вы это читаете, вам присуще любопытство хакера. Эта книга станет для вас отличным путеводителем. Она полна показательных примеров нахождения уязвимостей.
Чрезвычайно важна и ее направленность на этичный хакинг. Умение взламывать дает человеку рачаги влияния, которые, как мы надеемся, будут использованы во благо. Успешные хакеры умеют балансировать на тонкой грани между добром и злом. Разрушать могут многие, и на этом даже можно подзаработать. Но сделать интернет безопаснее, сотрудничать с крупными компаниями и получать серьезные вознаграждения смогут не все. Надеемся, что вы направите ваш талант на безопасность людей и их данных.
Мы бесконечно благодарны Питу за то, что он задокументировал множество примеров и сделал это настолько выразительно. Жаль, что в начале нашего пути не было такого материала. Эту книгу приятно читать, и в ней есть вся информация, необходимая для начинающего хакера.
Приятного чтения и хакинга!
Будьте ответственным хакером.
Майкл Принс и Йоберт Абма, соучредители HackerOne
Эта книга стала возможной благодаря сообществу HackerOne. Я хочу поблагодарить генерального директора HackerOne Мартена Микоса, который связался со мной в самом начале пути и неустанно делился своими впечатлениями и идеями, помогая сделать книгу лучше. Он даже заплатил за профессиональный дизайн обложки, когда изданием занимался я сам.
Также хочу выразить признательность соучредителям HackerOne Михелю Принсу и Джоберту Абме, которые поучаствовали в написании некоторых глав, когда я работал над ранними версиями книги. Джоберт выполнил редактуру каждой главы, предоставив технический анализ. Его правки укрепили мою уверенность и многому меня научили.
Не могу не упомянуть Адама Бакуса, который прочитал эту книгу через пять дней после начала своей работы в HackerOne. Он предложил свои правки и объяснил, что чувствует человек, получающий отчеты об уязвимостях. Компания HackerOne с большим вниманием отнеслась к созданию книги, направленной на поддержку сообщества хакеров.
Хочу поблагодарить отдельно Бена Садегипура, Патрика Ференбаха, Франса Розена, Филиппа Хэрвуда, Джейсона Хэддикса, Арне Свиннена, FileDescriptor и других опытных хакеров, поделившихся своими знаниями.
Эта книга не появилась бы на свет, если бы хакеры не обменивались информацией и не раскрывали обнаруженные ими уязвимости. Спасибо вам всем.
И, наконец, именно благодаря любви и поддержке жены и двух дочерей я стал успешным хакером и сумел собрать этот материал. А также большое спасибо остальным членам моей семьи, особенно моим родителям, которые вместо приставки Nintendo дарили мне компьютеры, приговаривая, что за ними будущее.
Эта книга познакомит вас с этичным хакингом — поиском уязвимостей безопасности для уведомления владельца приложения о находках, заслуживающих внимания. Меня всегда интересовали не только сами уязвимости, но и то, как они были найдены.
Я не мог ответить на вопросы:
• Какие уязвимости хакеры находят в приложениях?
• Откуда хакеры узнают об этих уязвимостях?
• С чего начинается проникновение на сайт?
• Как выглядит процесс взлома? Как он выполняется: автоматически или вручную?
• Каким образом я могу начать заниматься хакингом?
В конце концов я остановился на платформе для поиска уязвимостей за вознаграждение HackerOne — связующем звене между этичными хакерами и компаниями, заинтересованными в них. Возможности, заложенные в HackerOne, позволяют хакерам и компаниям раскрывать найденные и исправленные ошибки.
Но мне приходилось перечитывать раскрытые отчеты по два-три раза, чтобы в них разобраться. Так и возникла идея доступного описания реальных уязвимостей для новичков.
«Ловушка для багов» — это заслуживающий доверия справочник, который поможет понять разного рода веб-уязвимости, найти программные ошибки, сообщить о них, получить вознаграждение и написать защитный код. Но эта книга охватывает не только успешные примеры: в ней вы найдете ошибки и извлеченные уроки, многие из которых взяты из моего личного опыта.
Чтение этой книги — первый шаг к безопасному интернету и дополнительному доходу.
Книга написана для начинающих хакеров. Ими могут быть веб-разработчики, веб-дизайнеры, родители в декрете, школьники, пенсионеры и др.
Конечно, опыт программирования и общее представление о веб-технологиях пригодятся, но не будут обязательным условием для хакинга.
Навыки программирования могут облегчить поиск уязвимостей, связанных с программной логикой. Если вы сможете поставить себя на место программиста или прочитать его код (если таковой доступен), ваши шансы на успех будут выше.
Издательство No Starch Press предлагает много книг по программированию. Также существуют бесплатные обучающие курсы на Udacity и Coursera. Дополнительные ресурсы перечислены в Приложении Б.
Каждая глава описывает определенный тип уязвимостей и имеет следующую структуру:
1. Описание типа уязвимости.
2. Примеры уязвимости этого типа.
3. Краткий обзор с выводами.
Каждый пример уязвимости содержит пояснения:
• Моя оценка сложности поиска и подтверждения уязвимости.
• URL-адрес места обнаружения уязвимости.
• Ссылка на исходный отчет о раскрытии или статью.
• Дата подачи отчета об уязвимости.
• Сумма, полученная за предоставление информации об уязвимости.
• Четкое описание уязвимости.
• Выводы.
Главы необязательно читать по порядку. Если вас интересуют отдельные темы, можете начать с них. В некоторых случаях я ссылаюсь на концепции, описанные в предыдущих главах, но при этом стараюсь указывать, где находится определение соответствующего понятия. Держите эту книгу открытой во время занятия хакингом.
Ниже дается краткое описание содержания каждой главы:
Глава 1. Основы охоты за уязвимостями. Вы узнаете, что такое уязвимости и награды за их обнаружение и в чем разница между клиентами и серверами. Также мы рассмотрим работу интернета: HTTP-запросы, ответы и методы и отсутствие состояния в протоколе HTTP.
Глава 2. Open Redirect. Мы опишем атаку, при которой доверенный домен перенаправляет пользователей на адрес злоумышленника.
Глава 3. Засорение HTTP-параметров. Мы рассмотрим внедрение в HTTP-запрос дополнительных параметров.
Глава 4. Межсайтовая подделка запросов. Вы узнаете, как с помощью вредоносного веб-сайта заставить браузер послать другому сайту HTTP-запрос, который будет принят.
Глава 5. Внедрение HTML и подмена содержимого. Мы объясним, как злоумышленники внедряют собственные HTML-элементы в веб-страницы атакуемого сайта.
Глава 6. Внедрение символов переноса строки. Вы научитесь внедрять закодированные символы в HTTP-сообщения, чтобы повлиять на их интерпретацию сервером, прокси и браузером.
Глава 7. Межсайтовый скриптинг. Мы объясним, как злоумышленники запускают собственный JavaScript-код на сайте, не фильтрующем пользовательский ввод.
Глава 8. Внедрение шаблонов. Вы научитесь использовать движки шаблонизации на сайте, который не фильтрует пользовательский ввод. Эта глава содержит клиентские и серверные примеры.
Глава 9. Внедрение SQL. Мы опишем, как злоумышленник запрашивает информацию у базы данных или атакует ее.
Глава 10. Подделка серверных запросов. Мы объясним, каким образом злоумышленник может заставить серверную платформу выполнять непреднамеренные сетевые запросы.
Глава 11. Внешние XML-сущности. Мы покажем, как пользоваться ошибками, которые допускает приложение в ходе анализа XML-ввода и обработки включения в этот ввод внешних сущностей.
Глава 12. Удаленное выполнение кода. Мы рассмотрим примеры эксплуатации злоумышленниками серверов и приложений для выполнения собственного кода.
Глава 13. Уязвимости памяти. Вы узнаете, как использовать механизм управления памятью приложения, чтобы спровоцировать непреднамеренное поведение, в том числе выполнение команд.
Глава 14. Захват поддомена. Мы покажем, как злоумышленник может управлять поддоменом от имени реального родительского домена.
Глава 15. Состояние гонки. Вы научитесь пользоваться ситуациями, в которых процессы сайта выполняют работу с учетом исходных условий, которые во время выполнения становятся недействительными.
Глава 16. Небезопасные прямые ссылки на объекты. Вы научитесь получать несанкционированный доступ к ссылке на объект, такой как файл, запись базы данных или учетная запись.
Глава 17. Уязвимости в OAuth. Мы опишем ошибки в реализации протокола, призванного упростить и стандартизировать безопасную авторизацию в веб, на мобильных устройствах и в настольных приложениях.
Глава 18. Уязвимости в логике и конфигурации приложений. Вы научитесь пользоваться ошибкой в программной логике или конфигурации приложения, чтобы заставить сайт выполнять действия.
Глава 19. Самостоятельный поиск уязвимостей. Мы опишем, где и как искать уязвимости, с учетом опыта и методологии. Эта глава не является пошаговой инструкцией для взлома сайтов.
Глава 20. Отчеты об уязвимостях. Мы расскажем, как писать информативные и заслуживающие доверия отчеты об уязвимостях, чтобы найденные вами ошибки не были проигнорированы.
Приложение А. Инструменты. Мы перечислим инструменты, предназначенные для хакинга, в том числе для проксирования веб-трафика, составления перечня поддоменов, создания снимков экрана и т.д.
Приложение Б. Дополнительный материал. Мы перечислим дополнительные ресурсы для расширения ваших хакерских познаний (онлайн-обучение, платформы для охоты за уязвимостями, блоги и т.д.)
Если почитать о публичном раскрытии уязвимостей и о том, сколько денег получают хакеры, может сложиться впечатление, что это простой и короткий путь к богатству. Но это не так. Хакинг может быть прибыльным, но мало кто пишет о неудачах в этом деле (я написал).
Возможно, успех придет к вам быстро. Но пока уязвимость не найдена, продолжайте копать. Разработчики безустанно пишут новый код, и ошибки неизбежно попадают в приложения. С каждой новой попыткой хакинг становится проще.
На этой ноте позвольте завершить введение. О своих успехах можете писать мне в Twitter: @yaworsk. Пишите, даже если что-то не получается, не держите в себе. А потом вместе отпразднуем победу, и, возможно, вашу находку я смогу добавить в следующее издание этой книги.
Удачи и веселого хакинга!
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
Начнем с обсуждения, как работает интернет и что происходит, когда вы вводите URL в адресную строку браузера. Открытие веб-сайта выглядит просто, но оно включает в себя множество скрытых процессов, таких как подготовка HTTP-запроса, идентификация домена, к которому нужно обратиться, перевод доменного имени в IP-адрес, отправка запроса, вывод ответа и т.д.
В этой главе рассмотрены основные понятия и термины, такие как уязвимость, награда за нахождение ошибок, клиент, сервер, IP-адрес и HTTP. Вы узнаете, как выполнение несанкционированных действий и предоставление доступа к закрытой информации может привести к уязвимостям. Мы детально разберем ввод URL в адресную строку браузера, HTTP-запрос и ответ на него, а также методы, которые поддерживает HTTP. В конце главы мы поговорим о том, что подразумевает отсутствие состояния в протоколе HTTP.
Уязвимость (vulnerability) — это слабое место в приложении, с помощью которого злоумышленник может выполнять действия или получить несанкционированный доступ к информации.
Уязвимости могут возникать в результате выполнения как стандартных, так и непредвиденных действий, таких как изменение идентификатора записи для доступа к закрытой информации.
Представьте веб-сайт, который позволяет создать профиль с личными данными, доступными только вашим друзьям. Добавление вас в «друзья» без вашего разрешения будет уязвимостью. В ходе проверки сайта ставьте себя на место злоумышленника.
Bug Bounty — это система вознаграждения, которое владелец веб-сайта или другая компания выплачивает человеку, сообщившему о реальной уязвимости с соблюдением этики. Их материальное выражение находится в диапазоне от десяти до десятков тысяч долларов либо представляет собой криптовалюту, авиабилеты, бонусные очки, скидки и т.д.
Компания, предлагающая вознаграждение, обычно создает специальную программу — набор правил и ограничений для поиска уязвимостей на ее сайте. Она отличается от программы раскрытия уязвимостей (vulnerability disclosure program, или VDP) — механизма этичного сообщения об уязвимости, который не предусматривает оплаты. И хотя не все находки, описанные в этой книге, привели к награде, каждая из них — это пример участия хакера в программах Bug Bounty.
Ваш браузер работает с интернетом — сетью компьютеров, которые обмениваются сообщениями — пакетами. Пакеты содержат данные и сведения о том, куда и откуда эти данные передаются. Каждый компьютер в сети имеет адрес. Но некоторые компьютеры имеют доступ только к пакетам определенного типа и / или адресам из ограниченного списка. Принимающая сторона сама решает, что делать с пакетами и как на них отвечать. В этой книге мы сосредоточимcя на данных, а именно на HTTP-сообщениях.
Инициатора запроса — компьютер с браузером, командной строкой или др. — называют клиентом. Веб-сайты и веб-приложения, которые получают запросы, называются серверами. Если какая-то концепция применима и к клиентам и к серверам, я буду использовать общий термин «компьютер».
Количество компьютеров, которые общаются между собой через интернет, не ограниченно, поэтому их взаимодействие требует стандартизации. Документы RFC (Request for Comments — рабочие предложения) включают, например, протокол передачи гипертекста (Hypertext Transfer Protocol или HTTP), который определяет правила взаимодействия веб-браузера с удаленным сервером с помощью интернет-протокола (Internet Protocol, или IP). Клиент и сервер должны реализовывать один стандарт, чтобы правильно интерпретировать отправляемые и получаемые пакеты.
В этой книге основное внимание уделяется HTTP-сообщениям, поэтому важно в общих чертах описать процесс, который происходит при вводе URL в адресную строку браузера.
После получения URL-адреса http://www.google.com/ браузер вычленяет из него доменное имя — идентификатор веб-сайта, который вы хотите открыть. По документам RFC оно может содержать только алфавитно-цифровые символы, дефисы и подчеркивания. Исключения составляют интернационализованные доменные имена (RFC 3490). В данном случае мы имеем домен www.google.com. С его помощью можно найти адрес сервера.
Определив доменное имя, ваш браузер использует DNS (domain name system — cистема доменных имен) для получения IP-адреса, связанного с ним. Этот процесс называется разрешением IP-адреса.
Адреса бывают двух видов: IPv4 (версия 4) и IPv6 (версия 6). В IPv4 они состоят из четырех чисел, разделенных точками, каждое из которых находится в диапазоне от 0 до 255. IPv6 разработана из-за нехватки возможностей IPv4 и включает адреса из восьми групп по четыре шестнадцатеричных цифры, разделенных двоеточиями. IPv6 поддерживает сокращенную запись. Например, IPv4-адрес 8.8.8.8 можно представить в IPv6 как 2001:4860:4860::8888.
Чтобы найти IP-адрес по доменному имени, компьютер отправляет запрос серверам DNS — специальным компьютерам, подключенным к интернету, которые содержат реестр всех доменов и соответствующих им IP-адресов. Приведенные выше адреса IPv4 и IPv6 принадлежат DNS-серверам Google.
В данном примере DNS-сервер, к которому вы подключаетесь, сопоставляет www.google.com с IPv4-адресом 216.58.201.228 и возвращает полученный результат вашему компьютеру. Чтобы узнать больше об IP-адресе сайта, введите в терминале команду dig A site.com, подставив вместо site.com сайт, который вас интересует.
Далее компьютер использует протокол управления передачей (Transmission Control Protocol, или TCP), чтобы установить соединение с IP-адресом на порту 80, так как в начале имени сайта указано http://. Не будем останавливаться на принципе работы TCP, но отметим, что этот протокол обеспечивает двунаправленное взаимодействие компьютеров, при котором адресат может проверить полученную информацию и убедиться в ее целостности.
Сервер, к которому вы обращаетесь, может предоставлять сразу несколько сервисов (считайте их компьютерными программами) и использует порты, чтобы определить, какой из процессов должен получать запросы. Порты — это своеобразные двери, соединяющие сервер с интернетом. Без них сервисам пришлось бы конкурировать за информацию, отправленную в одно и то же место. Стандартный порт для отправки и получения незашифрованных HTTP-запросов имеет номер 80. Еще один распространенный порт, 443, используется для зашифрованных HTTPS-запросов. Несмотря на это, взаимодействие по TCP может осуществляться на любом порту в зависимости от того, как администратор сконфигурировал приложение.
Вы можете самостоятельно установить TCP-соединение с веб-сайтом на порту 80, открыв терминал и выполнив команду nc <IP-адрес> 80. В этой строке для создания сетевого соединения с возможностью чтения и записи сообщений используется утилита Netcat (nc).
Вернемся к примеру с http://www.google.com/. После установки соединения в шаге 3 браузер готовит и отправляет HTTP-запрос, показанный в листинге 1.1:
Листинг 1.1. Отправка HTTP-запроса
GET / HTTP/1.1
Host: www.google.com
Connection: keep-alive
Accept: application/html, */*
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
В поисках корневой страницы браузер выполняет GET-запрос . Содержимое веб-сайта делится на пути, подобные папкам и файлам. По мере продвижения по иерархии к имени корневой страницы прибавляются имена новых «папок», разделенные слешами /. Также браузер сигнализирует о том, что использует протокол HTTP версии 1.1. Запрос типа GET просто извлекает информацию. Ниже он описан подробнее.
Заголовок Host содержит дополнительную информацию, которая передается в рамках запроса. HTTP 1.1 требует уточнить имя получателя запроса, поскольку один IP-адрес может соответствовать нескольким доменным именам. Заголовок Connection обозначает, что соединение с сервером останется открытым, чтобы не пришлось его закрывать и устанавливать снова и снова.
Формат ожидаемого ответа показан в строке . Мы надеемся получить application/html, но примем любой формат, так как указали знаки подстановки (*/*). Существуют сотни разных типов содержимого, но в наших примерах чаще будут встречаться application/html, application/json, application/octet-stream и text/plain. Наконец, в заголовке User-Agent указано программное обеспечение, ответственное за отправку запроса.
В ответ на запрос сервер должен вернуть нечто, похожее на листинг 1.2:
Листинг 1.2. Ответ сервера
HTTP/1.1 200 OK
Content-Type: text/html
<html>
<head>
<title>Google.com</title>
</head>
<body>
--пропуск--
</body>
</html>
Мы получили HTTP-ответ с кодом состояния 200 , соотвествующим HTTP 1.1. Коды состояния определяют ответ сервера. Они описаны в RFC и обычно представляют собой трехзначные числа, начинающиеся с 2, 3, 4 или 5. Коды вида 2xx сигнализируют о том, что запрос был удачным.
Но строгих требований к использованию HTTP-кодов нет, и вы можете получить 200, даже если в теле HTTP-сообщения говорится о программной ошибке. Мы убрали содержимое и подставили --пропуск--, так как тело ответа от Google довольно большое. Текст ответа обычно имеет формат HTML (если это веб-страница), реже JSON (в случае с программным интерфейсом) или представляет собой содержимое загружаемого файла и т.д.
Заголовок Content-Type информирует браузер о MIME-типе тела ответа. MIME-тип определяет, как браузер выведет содержимое тела. Часто браузер самостоятельно выполняет распознавание MIME, считывая первый бит тела. Приложения могут запретить такое поведение браузера, указав заголовок X- Content-Type- Options: nosniff.
Цифра 3 в начале кода ответа означает перенаправление. Например, если компании Google понадобится постоянно перенаправлять пользователей с одного URL-адреса на другой, она теоретически может использовать ответ 301. Для временного перенаправления предусмотрен код 302.
Получив ответ 3xx, браузер должен сделать новый HTTP-запрос по URL-адресу из заголовка Location:
HTTP/1.1 301 Found
Location: https://www.google.com/
Код 4xx обычно сигнализирует о пользовательской ошибке. Например, 403 сообщает, что HTTP-запрос не содержит идентификационной информации для получения доступа к содержимому. Код 5xx указывает на серверную ошибку. Так, 503 говорит о том, что сервер не готов обработать полученный запрос.
Поскольку сервер вернул ответ с кодом 200 и типом содержимого text/html, браузер приступил к отображению полученных данных. Тело ответа описывает то, что следует показать пользователю.
В нашем примере пользователь увидит HTML для описания структуры страницы, каскадные таблицы стилей (сascading style sheets, или CSS) для стилизации и компоновки, а также JavaScript для добавления динамических возможностей и мультимедийной информации вроде изображений или видеороликов. Также сервер может вернуть содержимое типа XML (глава 11).
Когда веб-страницы будут ссылаться на внешние ресурсы (CSS, JavaScript или медиафайлы), браузер будет выполнять дополнительные запросы для необходимых файлов, не переставая анализировать ответ и выводить его тело на экран, то есть отображать корневую страницу Google: www.google.com.
JavaScript — это скриптовый язык, поддерживаемый всеми основными браузерами. Он придает веб-страницам динамические возможности, позволяя им, к примеру, обновлять свое содержимое без полной перезагрузки, проверять устойчивость пароля (на некоторых веб-сайтах) и т.д. Как и другие языки программирования, JavaScript имеет встроенные функции, может хранить значения в переменных и выполнять код в ответ на события, произошедшие на веб-странице. Он также имеет доступ к различным программным интерфейсам браузера (API-интерфейсам), помогающим ему взаимодействовать с другими подсистемами, такими как объектная модель документа (document object model, или DOM).
DOM позволяет JavaScript работать с HTML и CSS веб-страницы. Если злоумышленник выполнит на сайте свой JavaScript-код, он получит доступ к DOM и сможет взаимодействовать с сайтом от имени жертвы (глава 7).
Метод запроса отражает назначение запроса и ожидания клиента. Например, в листинге 1.1 мы послали запрос GET по адресу http://www.google.com/, ожидая получить только содержимое http://www.google.com/ без дополнительных действий. Интернет играет роль интерфейса между удаленными компьютерами, где методы запроса помогают различать запрашиваемые действия.
В стандарте HTTP описываются следующие методы запроса: GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT и OPTIONS (у метода PATCH нет общепринятой реализации). Через HTML можно посылать только запросы типа GET и POST. Запросы типа PUT, PATCH и DELETE инициируются JavaScript.
В следующем разделе приводится краткий обзор методов запроса, которые встречаются в этой книге.
Метод GET извлекает информацию об унифицированном идентификаторе ресурса (uniform resource identifier, или URI). Термин URI часто используется как синоним URL (Uniform Resource Locator — унифицированный указатель ресурса). Формально URL — это разновидность URI, которая определяет ресурс и его местоположение в сети. Например, http://www.google.com/<example>/file.txtи /<example>/file.txt — корректные URI-адреса, но только первый из них соответствует спецификации URL, так как идентифицирует способ обращения к ресурсу по его домену http://www.google.com. Несмотря на этот нюанс, дальше в книге мы будем называть любые идентификаторы ресурсов URL-адресами.
GET-запросы не должны изменять данные. Их задача — извлекать информацию из сервера и возвращать ее в теле HTTP-сообщения. Но этому поведению угрожает межсайтовая подделка запросов (глава 4), и само посещение URL-адреса или ссылки на веб-сайте заставляет браузер отправлять соответствующему серверу GET-запрос, что может привести к уязвимости Open Redirect (глава 2).
Метод HEAD идентичен методу GET, но не обязывает сервер возвращать в ответе тело сообщения.
Метод POST вызывает удаленную функцию, которая заставляет принимающий сервер выполнить действие: создать комментарий, зарегистрировать пользователя, удалить учетную запись и т.д. — либо бездействовать. Ошибка обработки POST-запроса мешает сохранить запись на сервере.
Метод PUT относится к функции, которая обращается к уже существующей записи на удаленном сервере или в приложении. Он используется для обновления данных, статей в блоге и т.д. Выполняемые с его подачи действия тоже могут варьироваться или отсутствовать.
Метод DELETE запрашивает удаление ресурса с идентификатором URI.
TRACE — малораспространенный метод, который возвращает запрос обратно тому, кто его выполнил. Запрашивающая сторона видит, что получил сервер, и может использовать эту информацию для тестирования или сбора диагностических данных.
Метод CONNECT работает с прокси-сервером, который перенаправляет запросы другим серверам. Он инициирует двунаправленное взаимодействие с запрашиваемым ресурсом. С его помощью можно получить доступ к веб-сайтам, которые используют прокси для поддержки HTTPS.
Метод OPTIONS позволяет браузеру сделать запрос о доступных вариантах взаимодействия с сервером (для содержимого таких типов, как application/json, автоматически). Он помогает узнать, принимает ли сервер вызовы GET, POST, PUT, DELETE и OPTIONS (но не HEAD или TRACE). Запросы с этим методом называют предполетными (глава 4).
HTTP-запросы не имеют состояния. Это означает, что сервер не знает о прошлом взаимодействии с вашим браузером. В большинстве случаев сайтам нужно помнить, кто вы, чтобы не заставлять вас заново вводить свои имя пользователя, пароль и другие данные при отправлении каждого HTTP-запроса.
Общение без сохранения состояния хорошо иллюстрирует фильм «50 первых поцелуев» сДрю Бэрримор (рекомендую). Представьте, что каждую главу мне пришлось бы начинать словами: «Меня зовут Питер Яворски. Мы только что обсуждали хакинг». Затем вам нужно было бы заново загрузить всю информацию о хакинге, полученную в ходе чтения.
Чтобы вас запомнить, веб-сайты используют куки, или базовую HTTP-аутентификацию (глава 4).
Примечание
Во время хакинга вы можете встретить данные в кодировке base64. Их следует декодировать. Поисковый запрос «base64 декодирование» в Google поможет узнать, какими инструментами это делается.
Вы получили общее представление о работе интернета и узнали, что происходит при вводе URL в адресную строку браузера.
Мы описали уязвимости как слабое место в приложении, с помощью которого злоумышленник может выполнять действия или получить несанкционированный доступ к информации. И обозначили программы Bug Bounty, связанные с вознаграждением за этичный поиск уязвимостей и их описание в отчетах для владельцев веб-сайтов.