Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Питер
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Russisch
Среди огромного количества информации по сетевой и ИТ-безопасности практически не найти книг по безопасности веб-приложений. Познакомьтесь на практике с разведкой, защитой и нападением! Вы изучите методы эффективного исследования и анализа веб-приложений, даже тех, к которым нет прямого доступа, узнаете самые современные хакерские приемы и научитесь защищать собственные разработки.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 339
Veröffentlichungsjahr: 2023
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Переводчик И. Рузмайкина
Литературный редактор Ю. Зорина
Художник В. Мостипан
Корректоры С. Беляева, Г. Шкатова
Эндрю Хоффман
Безопасность веб-приложений. — СПб.: Питер, 2021.
ISBN 978-5-4461-1786-4
© ООО Издательство "Питер", 2021
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.
Оглавление
Особая благодарность следующим людям:
Анджеле Руфино (Angela Rufino) и Дженнифер Поллок (Jennifer Pollock) за помощь в процессе публикации и на многих этапах написания.
Августу Детлефсену (August Detlefsen), Райану Фладу (Ryan Flood), Четану Каранде (Chetan Karande), Аллану Лиске (Allan Liska) и Тиму Галло (Tim Gallo) за то, что они дали отличные технические отзывы и предложения по улучшению.
Эми Адамс (Amy Adams) за безоговорочную поддержку и за то, что она лучший друг, о котором только можно мечтать.
Предисловие
Добро пожаловать в Безопасность веб-приложений. В предисловии к этой книге мы сразу же обозначим цели обучения, а также навыки и знания, необходимые читателю для получения максимальной пользы от материала. Прежде чем перейти к первой главе, обязательно ознакомьтесь со всеми исходными требованиями, особенно если вы не уверены, что вам нужна эта книга, или же сомневаетесь в своей компетенции.
Исходные требования и цели обучения
Эта книга не просто поможет защитить ваше веб-приложение от хакеров, но также расскажет об их тактике поиска уязвимостей и взлома.
Мы обсудим множество приемов, которыми пользуются современные хакеры для взлома веб-приложений, поддерживаемых корпорациями, правительствами, а иногда и любителями.
После тщательного изучения этих методов мы перейдем к средствам защиты.
Вы сможете по-новому взглянуть на архитектуру приложений, а также научитесь применять передовой опыт обеспечения безопасности при их разработке. Мы оценим различные методы защиты от наиболее распространенных и опасных типов атак на сегодняшний день.
После прочтения этой книги у вас появятся знания, необходимые для предварительного сбора информации о приложениях, к которым у вас нет доступа на уровне кода. Вы научитесь определять направление угрозы и находить дыры в безопасности, а также воздействия, предназначенные для создания угрозы данным, прерывания выполнения или вмешательства в ход работы приложений.
Вы сможете самостоятельно находить уязвимые области и поймете, как написать код для защиты от атак, ставящих под угрозу ваше приложение и его пользователей.
Сложность материала в книге нарастает постепенно, поэтому если вы решите начать чтение с середины и обнаружите, что упустили важную информацию, просто вернитесь на несколько глав назад.
Если же какая-то тема не обозначена как нечто предварительно необходимое для понимания главы, к ней будет идти объяснение.
Требования к уровню подготовки
Книга предназначена для широкой аудитории, но из-за стиля написания и представленных примеров она больше всего подходит людям со средним уровнем подготовки в области разработки ПО.
Возможно, вы спросите: «А что такое средний уровень подготовки?» Ответ на этот вопрос будет зависеть от множества факторов. По большому счету, для чтения этой книги достаточно начального уровня подготовки в области разработки ПО. Другими словами, системный администратор с (достаточным) опытом веб-разработки и/или написания сценариев, пожалуй, сможет понять все примеры из книги. И все же в ней есть вещи, для которых нужно разбираться в написании кода как для клиентской, так и для серверной стороны. Опыта лишь в одной из этих областей может быть недостаточно для глубокого понимания материала.
В книге также обсуждаются основы сетевого взаимодействия клиент–сервер по протоколу HTTP. Рассматривается и архитектура программного обеспечения, поскольку мы будем говорить о способах снижения рисков при интеграции стороннего ПО в собственный код.
В книге затрагивается очень много тем, вот поэтому для понимания материала и необходим «средний уровень». Читателям, у которых совсем нет опыта или знаний в разработке ПО для приложений, она не подойдет.
Минимальный набор навыков
«Средний уровень знаний в разработке ПО» включает в себя:
• Умение писать программы с базовыми функциями CRUD (создание, чтение, обновление, удаление) хотя бы на одном языке.
• Умение писать серверный код (бэкенд).
• Умение писать код, который запускается в браузере (фронтенд, обычно JavaScript).
• Понимание HTTP и умение выполнить на нем или хотя бы прочесть запросы GET/POST через HTTP на каком-либо языке или платформе.
• Умение писать или, по крайней мере, читать и понимать приложения, которые используют как серверный, так и клиентский код, и обмениваться данными между ними через HTTP.
• Знакомство как минимум с одной популярной базой данных (MySQL, MongoDB и т.п.).
Эти навыки позволят вам получить максимальную пользу от материала. Любой дополнительный опыт сверх перечисленного будет только плюсом и облегчит восприятие этой книги.
Для простоты большинство примеров кода написано на JavaScript (для единообразия клиентской и серверной частей), но их нетрудно переписать на другом языке.
Я очень постарался сохранять адекватный темп усложнения материала, а также давать как можно более подробные объяснения. Именно поэтому все рассказы о новых технологиях начинаются с их краткой предыстории и обзора принципов работы.
Кому больше всего пригодится эта книга?
Я считаю важным уточнить, кому эта книга пригодится больше всего, и таким способом лучше очертить свою целевую аудиторию. Этот раздел я структурировал по целям обучения и профессиональным интересам. Но даже если вы не попадаете ни в одну из перечисленных категорий, вы все равно можете узнать много ценных или, по крайней мере, интересных идей.
Я пытался написать книгу, которая сможет выдержать испытание временем, поэтому, если позже вы решите специализироваться в одной из перечисленных профессий, вся информация все равно будет актуальной.
Инженеры-программисты и разработчики веб-приложений
Основной целевой аудиторией своей книги я считаю инженеров-программистов или разработчиков веб-приложений в начале своего карьерного пути или уже с опытом работы по специальности. В идеале такой читатель заинтересован в том, чтобы отлично понимать тактики хакеров или методы противодействия атакам.
К сожалению, термины «разработчик веб-приложений» и «инженер-программист» часто взаимозаменяемы, что может привести к некоторой путанице. Так как я использую оба этих термина в следующих главах, мне хотелось бы дать некоторые пояснения.
Инженеры-программисты
Говоря об инженерах-программистах, я имею в виду специалистов широкого профиля, умеющих писать ПО для различных платформ. Таким специалистам моя книга будет полезна по нескольким причинам.
Во-первых, большая часть информации, которую я даю, может быть легко перенесена на ПО, работающее не в интернете. Ее также можно перенести на другие типы сетевых приложений, причем в первую очередь на ум приходят нативные мобильные приложения.
Более того, рассмотренные здесь варианты эксплуатации уязвимостей используют преимущества серверной стороны, связанные с коммуникацией веб-приложения с другими программными компонентами. В результате любое ПО (базы данных, CRM-системы, системы бухгалтерского учета, средства ведения журналов и т.п.), которое взаимодействует с веб-приложением, можно рассматривать как потенциальную мишень.
Разработчики веб-приложений
Что касается разработчиков веб-приложений, по моему определению это специалисты в области написании ПО, работающего в Сети. Их часто подразделяют на фронтенд-, бэкэнд- и фуллстек- разработчиков.
Исторически сложилось так, что наибольшее количество атак приходилось на уязвимые места серверной части веб-приложения. Поэтому мне кажется, что бэкенд- и фуллстек-разработчикам будет несложно понять информацию из этой книги.
Но я также считаю, что книга пригодитсяи другим типам разработчиков веб-приложений, в том числе тем, кто пишет код не для сервера, а для браузера (фронтенд/JavaScript-разработчики).
В следующих главах я расскажу о том, что многие успешные атаки хакеров на веб-приложения происходят с помощью вредоносного кода, запускаемого в браузере. Некоторые хакеры даже используют для этой цели DOM браузера или таблицы стилей CSS.
Это означает, что фронтенд-разработчики также должны быть осведомлены об уязвимостях своего кода и о способах их снижения.
Общие цели обучения
Эта книга может послужить отличным источником информации для всех, кто хочет сменить род деятельности и заняться вопросами, связанными с безопасностью. Будет она полезна и тем, кто хочет узнать, как защитить свой код.
Если вы хотите защитить свое приложение от специфических эксплойтов, тогда эта книга для вас. Уникальная структура книги позволят использовать ее в качестве справочника по безопасности без необходимости читать главы, посвященные взлому.
Я бы посоветовал прочитать ее от корки до корки, чтобы максимизировать полученные знания. Но если вам нужен только справочник по защите от определенных типов атак, просто откройте соответствующие главы и приступайте к чтению.
Инженеры по безопасности, пентестеры и охотники за багами
Структура этой книги позволяет использовать ее как ресурс для получения информации, связанной с тестированием на проникновение, поиском ошибок и любыми другими работами по обеспечению безопасности на уровне приложений. Если эти направления для вас актуальны или интересны, вам подойдет информация из первой половины книги.
Мы глубоко погрузимся в варианты эксплуатации уязвимостей как на уровне кода, так и на уровне архитектуры, а не просто расскажем о том, как пользоваться популярным ПО с открытым исходным кодом или платными автоматизированными программами. Соответственно, книга может представлять интерес и для инженеров по безопасности программного обеспечения, инженеров по ИТ-безопасности, инженеров по сетевой безопасности, пентестеров и охотников за багами.
Эта книга будет очень полезна специалистам по безопасности, которые хотели бы глубже погрузиться в системы и код, лежащие в основе инструментов или сценариев.
Хотите подзаработать, одновременно развивая навыки взлома? Прочтите эту книгу, а затем зарегистрируйтесь в одной из программ охоты за багами, о которых идет речь в третьей части. Это отличный способ помочь различным компаниям повысить безопасность своих продуктов и поднять немного денег.
Современные пентестеры зачастую используют набор готовых сценариев эксплуатации уязвимостей. Это привело к появлению множества платных инструментов с открытым исходным кодом, которые автоматизируют классические атаки. Для их запуска не нужно глубоких знаний об архитектуре приложения или о логике в конкретном блоке кода.
В этой книге рассказ об атаках и мерах противодействия им не связан с использованием каких-либо специализированных инструментов. Мы будем полагаться на собственные сценарии, сетевые запросы и инструменты, которые входят в стандартную комплектацию операционных систем на базе Unix, а также на стандартные инструменты, встроенные в основные веб-браузеры (Chrome, Firefox и Edge).
Это не умаляет ценности специализированных инструментов защиты. Более того, я считаю многие из них исключительно полезными и значительно упрощающими проведение профессиональных тестов на проникновение!
Но мне хотелось сосредоточиться на наиболее важных этапах поиска уязвимости, разработке методов ее эксплуатации, определении приоритетности компрометируемых данных и обеспечении средств защиты от всего вышеперечисленного. Мне кажется, что со знаниями, полученными из этой книги, вы сможете отправиться в самостоятельное плавание и искать уязвимости новых типов, разрабатывать способы взлома систем, которые никогда не использовались ранее, и защищать самые сложные системы от самых настойчивых злоумышленников.
Структура книги
Вы быстро обнаружите, что эта книга построена совсем иначе, чем большинство других изданий подобной тематики. Это сделано намеренно. Материал целенаправленно структурирован таким образом, чтобы соотношение глав, касающихся взлома (нападения) и безопасности (защиты) было практически одинаковым.
Наше путешествие начинается с небольшого урока истории, где мы познакомимся с прошлыми исследованиями методов эксплуатации уязвимостей, инструментов и порядком действий. От него мы быстро перейдем к основной теме: эксплуатации уязвимостей и мерам противодействия в современных веб-приложениях.
Книга разбита на три части, и в идеале ее имеет смысл читать линейно, от первой страницы до последней. Именно такой порядок даст вам максимум знаний. Но, как я уже упоминал выше, эту книгу можно использовать и как справочник по различным атакам или по мерам защиты, сосредоточив внимание на первой или второй частях соответственно.
Думаю, вы уже понимаете, как ориентироваться в книге, поэтому давайте кратко рассмотрим три основные части, чтобы понять важность каждой из них.
Разведка
Первая часть называется «Разведка» и посвящена способам получения информации о веб-приложении без попыток его взлома.
Мы обсудим ряд важных технологий и концепций, которые необходимо освоить любому, кто хочет стать хакером. Эти темы также будут важны для тех, кто хочет обезопасить свое приложение, потому что можно принять меры, препятствующие получению информации описанными в книге методами.
У меня была возможность поработать с одними из лучших в мире пентестеров и охотников за багами. Беседуя с ними и анализируя их действия, я пришел к выводу, что тема предварительного сбора данных гораздо важнее, чем считают другие авторы.
Почему важна разведка?
Я бы сказал, что у многих из лучших охотников за багами есть разведывательные способности экспертного уровня. Именно это отличает «великих» хакеров от просто «хороших».
Другими словами, можно владеть быстрым авто (ну или в рассматриваемом случае — знать, как эксплуатировать уязвимости), но без знания наиболее рационального маршрута к финишу нельзя выиграть гонку. Более медленный автомобиль может дойти до финиша быстрее, если выберет более правильный путь.
Если вам ближе аналогии из фэнтези, можно вспомнить игры-рогалики, в которых задача состоит не в нанесении большого урона, а в том, чтобы пойти на разведку впереди остальной группы и вернуться обратно с информацией. Именно разведчик помогает выстроить тактику боя и понять, какие битвы принесут больше всего наград. Последнее особенно важно, потому что многие варианты атак могут вестись против хорошо защищенных целей. Так и у хакера может быть только один шанс использовать дыру в программном обеспечении, прежде чем она будет обнаружена и закрыта.
Кроме того, можно с уверенностью сказать, что второе применение полученных в ходе разведки данных — это определение приоритетности ваших действий.
Эта часть книги будет крайне важна для тех, кто заинтересован в карьере пентестера или в участии в программе охоты за ошибками. Ведь тесты с целью поиска ошибок делаются в стиле «черного ящика»: структура и код приложения неизвестны, и, следовательно, нужно самостоятельно с помощью тщательного анализа и изучения понять, как все устроено.
Нападение
Во второй части фокус смещается к анализу кода и сетевых запросов. Полученные в результате сведения мы попытаемся использовать для взлома небезопасно написанных или неправильно настроенных веб-приложений.
Некоторые главы содержат описания фактических методов взлома, используемых киберпреступниками (также известными как хакеры Black Hat). Соответственно, практическое применение подобных техник допустимо только с вашими собственными приложениями или с теми, на тестирование которых вы имеете письменное разрешение.
Во всех прочих случаях ваши действия могут привести к штрафам или, в зависимости от законов вашей страны, даже к тюремному заключению.
Во второй части я покажу, как создавать и развертывать эксплойты, предназначенные для кражи данных или принудительного изменения поведения приложения.
Эта часть книги основывается на информации из первой части. Полученные в ней навыки разведки в сочетании с навыками взлома позволят нам атаковать демонстрационные веб-приложения.
Каждой уязвимости посвящена отдельная глава. Я объясняю суть ее эксплуатации, чтобы вы могли понять, как все работает. Затем мы научимся искать обсуждаемые уязвимости и создаем вредоносный код, чтобы развернуть его в приложении и понаблюдать за результатами.
Подробный разбор уязвимостей
Один из первых способов эксплуатации уязвимости, который мы изучим — межсайтовый скриптинг (XSS) — представляет собой атаку против широкого спектра веб-приложений, применимую и к приложениям других типов (например, мобильным приложениям, флэш-играм и др.). Хакер пишет вредоносный код и, используя слабость механизмов фильтрации в приложении, запускает его на чужом компьютере.
Обсуждение этого варианта атаки мы начнем с уязвимого приложения. Демонстрационное приложение будет простым и точным, в идеале состоящим всего из нескольких абзацев кода. Мы напишем вредоносный код, который будет внедрен в это приложение и затем воспользуется преимуществами гипотетического пользователя на другой стороне.
Звучит просто, не правда ли? Так и должно быть. При отсутствии защиты большинство программных систем легко взламываются. На примере такой атаки, как XSS, от которой существует множество вариантов защиты, мы постепенно начнем копать все глубже и глубже, изучая специфику написания и развертывания атак.
Начнем мы с попытки сломать стандартную защиту и в конечном итоге перейдем к обходу более продвинутых защитных механизмов. Помните: построенная кем-то стена для защиты кодовой базы не означает, что через нее невозможно перелезть или сделать подкоп. Здесь есть простор для творчества и поиска уникальных и интересных решений.
Вторая часть важна и тем, что понимание образа мышления хакера часто имеет жизненно важное значение для создания защищенной кодовой базы. И важно это для любого читателя, заинтересованного во взломе, тестировании на проникновение или поиске ошибок.
Защита
Третья и последняя часть этой книги посвящена защите кода от взлома. Мы снова рассмотрим все типы эксплойтов, с которыми имели дело во второй части, но на этот раз с противоположной точки зрения.
Теперь мы будем концентрироваться не на взломе программных систем, а на мерах, позволяющих его предотвратить или уменьшить вероятность проникновения.
Вы узнаете, как защититься от атак, описанных во второй части, и познакомитесь с общими средствами защиты, варьирующихся от «безопасных по умолчанию» инженерных методологий до передовых практик безопасного кодирования, которые легко реализуются командой инженеров с помощью тестов и других простых автоматизированных инструментов (таких как линтер). Вы не только научитесь писать более безопасный код, но и узнаете ряд полезных приемов, позволяющих ловить хакеров на месте преступления и улучшить отношение вашей организации к безопасности ПО.
Большинство глав по структуре напоминает главы, посвященные навыкам взлома из второй части. Мы начинаем с обзора технологий и навыков, необходимых для подготовки защиты от атак определенного типа.
Первым делом мы рассматриваем защиту базового уровня, помогающую смягчить атаки, но не предотвращающую их полностью. В какой-то момент мы сможем улучшить ее до такой степени, что остановим большинство, если не все, попыток взлома.
После этого структура третьей части начинает отличаться от структуры второй, так как мы переходим к обсуждению вещей, которыми приходится платить за повышение защиты приложений. Говоря общими словами, любые меры по повышению безопасности могут ухудшать какие-то характеристики самого приложения. Возможно, лично вам не придется выбирать приемлемый для приложения уровень риска, но знать о том, на какие компромиссы при этом приходится идти, следует.
Часто платить приходится ухудшением производительности. Чем больше усилий уходит на чтение и очистку данных, тем больше выполняется дополнительных операций, отличающихся от стандартной функциональности приложения. Следовательно, безопасная функциональность обычно требует больше вычислительных ресурсов, чем небезопасная.
Дополнительные операции означают увеличение объема кода, а это означает больше времени на обслуживание, тесты и разработку. Увеличение накладных расходов на разработку, связанную с безопасностью, также часто связано с необходимостью логирования или мониторинга.
Наконец, существуют меры безопасности, за которые приходится платить удобством пользования.
Оценка компромиссов
В качестве простого примера сравнения преимуществ, которые дает безопасность, и уменьшения удобства использования и производительности, которыми за это преимущество приходится заплатить, может быть рассмотрена форма входа. Сообщение об ошибке, которое появляется при вводе неверного имени пользователя, упрощает хакеру подбор комбинации из имени пользователя и пароля. Ведь приложение само подтверждает активность учетных записей — соответственно, отпадает необходимость искать список активных имен пользователей для входа.
Остается только воспользоваться методом полного перебора для определения пароля. Этот метод требует гораздо меньше математических вычислений и затрат по времени по сравнению с подбором полной комбинации «имя пользователя/пароль».
Если же для входа в систему приложение использует схему из адреса электронной почты и пароля, возникает другая проблема. Форма входа позволяет искать действительные адреса электронной почты, которые можно продать в маркетинговых целях или для рассылки спама. Даже если приняты меры против метода полного перебора, специальным образом созданные входные данные (например, [email protected], [email protected], [email protected]) дают возможность изменить схему, используемую для учетных записей электронной почты компании, и определить действительные учетные записи руководителей продаж или лиц с нужным уровнем доступа с целью последующего фишинга.
Поэтому лучшей практикой часто считается предоставление сведений об ошибках в более общей форме. Конечно, это будет не так удобно для пользователя, но это плата за повышение уровня безопасности. Это отличный пример компромисса, на который приходится идти при реализации защитных средств. Именно такие компромиссы мы будем обсуждать в третьей части.
Эта часть чрезвычайно важна для любого инженера по безопасности, который хочет повысить уровень своих навыков, или любого инженера-программиста, желающего перейти на должность инженера по безопасности. Информация из третьей части поможет в разработке и написании более безопасных приложений.
Разумеется, знание методов защиты приложений — ценный актив для любого хакера. Обычные средства защиты часто можно легко обойти, а вот обход более сложных механизмов требует глубокого понимания и знаний. Именно поэтому я предлагаю прочитать книгу от начала до конца.
Разумеется, некоторые части окажутся для вас более полезными, чем другие. Все зависит от ваших целей. Но перекрестное обучение такого рода особенно хорошо позволяет посмотреть на одну и ту же задачу с разных сторон.
Язык и терминология
Надеюсь, вы уже поняли, что эта книга написана, чтобы научить вас ряду очень полезных и одновременно очень редких методик, которые улучшат вашу конкурентоспособность на рынке труда. Но овладеть этими знаниями довольно сложно. Для этого требуется сосредоточенность, сообразительность и способность усвоить совершенно новую ментальную модель, определяющую ваш взгляд на веб-приложения.
Для корректной передачи знаний необходим общий язык. Он поможет мне провести вас через книгу так, чтобы вы не запутались, а также позволит вам выражаться так же, как это делают в организациях по безопасности и инжинирингу.
Я стараюсь объяснять все новые термины и фразы. В частности, при первом упоминании аббревиатуры я раскрываю ее значение: ранее вы видели, как я расшифровал межсайтовый скриптинг (Cross-Site Scripting, XSS).
Кроме того, я постарался определить все термины, для которых может понадобиться объяснение. Я собрал их и организовал в виде таблиц (с П.1 по П.3).
Обнаружив в тексте термин или фразу, которую вы не совсем понимаете, вернитесь к этой главе (добавьте ее в закладки!). Если здесь этот термин не указан, не стесняйтесь отправить электронное письмо моему редактору: возможно, мы сможем включить его в следующее издание книги. Если, конечно, мне повезет и я продам достаточно экземпляров, чтобы гарантировать продолжение!
Таблица П.1. Виды деятельности
Род занятий
Описание
Хакер (Hacker)
Кто-то, кто взламывает системы, обычно с целью захватить данные или заставить систему работать так, как ее разработчики изначально не планировали
White Hat
Еще их иногда называют «этичными хакерами», так как они используют хакерские методы для помощи организациям в повышении безопасности
Black Hat
Киберпреступник. Человек, использующий хакерские методы для взлома систем с целью получения прибыли, создания хаоса или удовлетворения своих собственных целей и интересов
Grey Hat
Нечто среднее между этичными хакерами и киберпреступниками. Иногда такие хакеры нарушают закон, например пытаются взломать приложения без разрешения, но часто это делается ради интереса или признания, а не ради выгоды или создания хаоса
Пентестер (Penetration tester)
Человек, которому платят за взлом системы теми способами, какие применил бы хакер. В отличие от хакеров, пентестерам платят за сообщения об ошибках и недосмотрах в прикладном ПО, чтобы компания-владелец могла исправить уязвимость до того, как она будет обнаружена хакером и использована со злым умыслом
Охотник за багами (Bug bounty hunter)
Внештатный пентестер. Часто крупные компании создают «программы ответственного раскрытия информации», в рамках которых за сообщение о дырах в системе безопасности можно получить денежное вознаграждение. Некоторые охотники за багами работают фулл-тайм, но часто таким вещами занимаются профессионалы во внерабочее время в виде подработки
Инженер по безопасности приложений (Application security engineer)
Иногда их называют инженерами по безопасности продукта. Это разработчик ПО, чья роль заключается в оценке и повышении безопасности кодовой базы и архитектуры приложений
Инженер по безопасности ПО (Software security engineer)
Инженер-программист, чья роль заключается в разработке продуктов, связанных с безопасностью, но который не обязательно отвечает за оценку безопасности для всей организации
Администратор (Admin)
Иногда их называют сисадминами. Это технический персонал, которому поручено поддерживать конфигурацию и безотказную работу веб-сервера или веб-приложения
Скрам-мастер (Scrum master)
Руководящая должность в инженерной организации, помогающая группе инженеров в планировании и выполнении разработки
Security champion
Инженер-программист, не связанный с организацией, занимающейся безопасностью, и не отвечающий за безопасность, но заинтересованный в повышении безопасности кода компании
Таблица П.2. Термины
Термин
Описание
Уязвимость (Vulnerability)
Ошибка в программной системе, часто возникающая в результате недосмотра или как неожиданное последствие соединения нескольких модулей. Ошибки этого типа позволяют хакеру выполнять в системе непредусмотренные действия
Вектор угрозы или вектор атаки (Threat vector or attack vector)
Часть функциональности приложения, которая с точки зрения хакера написана небезопасно и, следовательно, может быть хорошей целью для взлома
Поверхность атаки (Attack surface)
Список уязвимостей приложения, созданный хакером, чтобы определить, с какой стороны лучше всего атаковать программную систему
Эксплойт (Exploit)
Обычно это блок кода или список команд, позволяющие воспользоваться уязвимостью
Полезная нагрузка (Payload)
Эксплойт, отформатированный для отправки на сервер. Зачастую это означает просто упаковку вредоносного кода в соответствующий формат для отправки по сети
Red Team
Команда из пентестеров, инженеров по сетевой безопасности и инженеров по безопасности ПО, которая пытается взломать софт, чтобы оценить способность противостоять настоящим хакерам
Blue Team
Команда из инженеров по безопасности ПО и инженеров по сетевой безопасности, которая пытается улучшить защиту софта компании, зачастую пользуясь отчетами красной команды для определения приоритетов
Purple Team
Команда, которая выполняет обязанности как красной, так и синей команды. Фактически это команда общего назначения, так как специализированную команду труднее правильно укомплектовать из-за обширных требований к навыкам
Веб-сайт (Website)
Набор документов, доступный через интернет, обычно по протоколу HTTP
Веб-приложение (Web application)
Приложение, похожее на настольное, которое предоставляется через интернет и запускается в браузере, а не в самой операционной системе. В отличие от традиционных сайтов имеет много уровней доступа, хранит пользовательские данные в базах и часто позволяет обмениваться контентом
Гибридное приложение (Hybrid application)
Мобильное приложение, созданное на базе веб-технологий. Обычно использует другую библиотеку, например Apache Cordova, чтобы совместно пользоваться встроенной функциональностью с веб-приложением поверх нее
Таблица П.3. Аббревиатуры
Аббревиатура
Описание
API (Application programming interface)
Интерфейс прикладного программирования — набор функций, предоставляемых одним модулем кода для использования другим. В книге обычно применяется для обозначения предоставляемых через HTTP функций, которые браузер может вызывать на сервере. Также может использоваться для обозначения локально взаимодействующих модулей, включая отдельные модули в одном пакете ПО
CSRF (Cross-Site Request Forgery)
Межсайтовая подделка запроса — атака, при которой хакер пользуется согласием авторизованного пользователя при выполнении запросов к серверу
CSS (Cascading Style Sheets)
Каскадные таблицы стилей — язык, обычно используемый в комбинации с HTML для создания визуально привлекательного и правильно оформленного пользовательского интерфейса
DDoS (Distributed denial of service)
Распределенный отказ в обслуживании. Атака выполняется сразу несколькими компьютерами, подавляя сервер огромным количеством запросов. Один компьютер, скорее всего, не сможет вызвать такой хаос
DOM (Document Object Model)
Объектная модель документа — API, поставляемый с каждым веб-браузером. Включает все необходимые функции для организации и управления HTML на странице, а также API для управления историей, файлами cookie, URL-адресами и другой общей функциональностью браузера
DoS (Denial of service)
Отказ в обслуживании — атака, направленная не на кражу данных, а на запрос такого количества ресурсов сервера или клиента, что ухудшается взаимодействие с пользователем или приложение перестает функционировать
HTML (HyperText Markup Language)
Язык гипертекстовой разметки — язык шаблонов, используемый в интернете наряду с CSS и JavaScript
HTTP (HyperText Transfer Protocol)
Протокол передачи гипертекста — самый распространенный сетевой протокол для связи между клиентами и серверами в веб-приложении или на веб-сайте
HTTPS (HyperText Transfer Protocol Secure)
Безопасный протокол передачи гипертекста — HTTP-трафик, зашифрованный с использованием TLS или SSL
JSON (JavaScript Object Notation)
Текстовый формат обмена данными, основанными на JavaScript, — требования к хранению иерархических данных таким образом, чтобы они мало весили, а также легко читались людьми и машинами. В современных веб-приложениях часто используется при обмене данными между браузером и веб-сервером
OOП (Object-oriented programming, OOP)
Объектно-ориентированное программирование — модель программирования, в которой код строится вокруг объектов и структур данных, а не вокруг функциональности или логики
REST (Representational State Transfer)
Передача состояния представления — особая архитектура для API без сохранения состояния, в которой конечные точки API определяются как ресурсы, а не как функции. В REST разрешены многие форматы данных, но обычно используется JSON
RTC (Real time communication)
Связь в реальном времени — новый сетевой протокол, позволяющий браузерам взаимодействовать друг с другом и веб-серверами
SOAP (Simple Object Access Protocol)
Простой протокол доступа к объектам — протокол для управляемых функциями API, требующих строго написанных схем. Поддерживает только формат XML
SPA (Single-page application)
Одностраничное приложение — сайт в интернете, который функционирует аналогично десктопному приложению, управляя собственным пользовательским интерфейсом и состоянием без использования UI, предоставляемых браузером по умолчанию
SSDL (Secure software development life cycle)
Жизненный цикл безопасной разработки ПО, также называемый SDLC/SDL. Общая структура для совместной работы разработчиков ПО и инженеров по безопасности
SSL (Secure Sockets Layer)
Слой защищенных сокетов — криптографический протокол, предназначенный для защиты информации при передаче по сети, в частности для использования в HTTP
TLS (Transport Layer Security)
Протокол защиты транспортного уровня — криптографический протокол, предназначенный для защиты информации при передаче по сети, обычно используемый в HTTP. Заменил устаревший протокол SSL
XML (Extensible Markup Language)
Расширяемый язык разметки — спецификация для хранения иерархических данных, подчиняющаяся строгому набору правил. Тяжелее, чем JSON, но зато более настраиваемый
XSS (Cross-Site Scripting)
Межсайтовый скриптинг — тип атаки, заключающийся в принуждении другого клиента (часто браузера) к запуску вредоносного кода
XXE (XML External Entity)
Атака внешнего объекта XML. При ней неправильные настройки синтаксического анализатора XML используются для кражи локальных файлов на веб-сервере или внедрения вредоносных файлов с другого веб-сервера
Итоги
Эта многоцелевая книга предназначена как для желающих научиться приемам взлома, так и для тех, кто ставит своей целью интересы безопасности. Я постарался сделать материал легкодоступным для любого разработчика или администратора с достаточным опытом веб-программирования (клиент–сервер).
Безопасность веб-приложений знакомит с приемами взлома приложений из арсенала талантливых хакеров и охотников за багами, а затем обучает методам и процессам защиты от таких злоумышленников.
Эта книга может быть прочитана целиком либо использоваться как справочник по конкретным методам разведки, атак и защиты от них. В конечном счете, она написана, чтобы помочь читателю изучить вопросы безопасности веб-приложений на практике от простого к сложному, поэтому для ее чтения особого опыта в области безопасности не требуется.
Я искренне надеюсь, что сотни часов, потраченные на написание этой книги, принесут вам пользу и вы извлечете интересные уроки. Вы можете писать мне любые отзывы или предложения для следующих версий книги.
Условные обозначения
В книге используются следующие условные обозначения:
Курсив
Обозначает новые термины.
Интерфейс
Используется, чтобы отмечать URL-адреса, адреса электронной почты, имена и расширения файлов.
Моноширинный шрифт
Используется для листингов и элементов программ вроде имен переменных или функций, типов данных, переменных среды, операторов и ключевых слов.
Этот элемент указывает на совет или предложение.
Этот элемент указывает на примечание.
Этот элемент указывает на предостережение.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
Глава 1. История защиты программного обеспечения
Прежде чем мы начнем рассматривать приемы атак ПО и техники защиты от них, хотелось бы дать вам представление о долгой и интересной истории безопасности программного обеспечения. Краткий обзор главных событий в этой области за последние сто лет позволяет более-менее представить технологию, на которой основываются современные веб-приложения. Попутно вы увидите, что разработка механизмов безопасности всегда тесно связана с находчивостью и дальновидностью хакеров, которые все время ищут способы взломать или обойти эти механизмы.
Истоки хакерства
За последние два десятилетия хакеры не только приобрели известность, но и стали пользоваться дурной славой. В результате незнакомому с этой областью человеку может показаться, что хакерство связано исключительно с интернетом и что массовым это явление стало в последние 20 лет.
Но это так лишь отчасти. Разумеется, число хакеров резко возросло с появлением Всемирной паутины, но первые из них появились в середине XX века, а возможно и раньше. Все упирается в определение самого понятия «взлом». Эксперты спорят, в каком же именно десятилетии появились хакеры, потому что некоторые примечательные события, случившиеся в начале прошлого века, очень напоминают современные хакерские атаки.
К примеру, в 1910-х и 1920-х годах наблюдались отдельные характерные случаи, которые можно квалифицировать как взлом. Большинство из них связано с вмешательством в работу передатчиков и приемников кода Морзе или радиоволн. Но эти вещи случались редко, и я не могу вспомнить ни одной крупномасштабной сделки, которая была сорвана в результате злоупотребления этими технологиями.
Впрочем, я не историк. Я специалист по безопасности с опытом поиска и устранения глубоких архитектурных проблем и уязвимостей на уровне кода в корпоративном ПО. До этого я много лет работал инженером-программистом, создавая веб-приложения на разных языках и в различных средах. Я до сих пор продолжаю писать программы автоматизации безопасности, а в свободное время участвую в проектах. Поэтому я не буду углубляться в исторические детали, а просто упомяну, что этот раздел основывается на многолетних независимых исследованиях, и ключевое значение тут имеют уроки, которые можно извлечь из событий давно ушедших дней и применить сегодня.
Я не ставил себе цели написать исчерпывающий обзор, поэтому в этой главе будет краткое описание переломных исторических событий, а отсчет мы начнем с 1930-х. Давайте же посмотрим, какие события привели к современной расстановке сил между хакерами и инженерами.
«Энигма», 1930-е
Показанная на рис. 1.1 электромеханическая роторная машина «Энигма» использовалась для шифрования и расшифровки текстовых сообщений, отправляемых по радио. Это устройство немецкого производства появилось во время Второй мировой войны и стало важным технологическим достижением.
Устройство напоминало большую механическую пишущую машинку. При каждом нажатии клавиши роторы перемещались и записывали на первый взгляд случайный символ, который передавался на все ближайшие «Энигмы». На самом деле символы не были случайными, а определялись вращением ротора и параметрами конфигурации, которые можно было изменить в любой момент. Читать или расшифровывать отправленные сообщения могла только «Энигма» с идентичной конфигурацией. Именно это ценное свойство позволяло избежать перехвата важных сообщений.
Сейчас уже невозможно сказать, кто конкретно изобрел механизм шифрования на основе роторов, но популяризовала эту технологию немецкая компания Chiffriermaschinen AG, которой управляли два человека. В 1920-х годах представители этой компании путешествовали по Германии, демонстрируя технологию, в результате чего в 1928 году ее взяли на вооружение немецкие военные для обеспечения безопасности передачи сверхсекретных сообщений.
Рис. 1.1. Шифровальная машина «Энигма»
Предотвращение перехвата передаваемых на дальние расстояния сообщений стало достижением, которое раньше невозможно было даже представить. Перехват сообщений до сих пор остается популярной у хакеров техникой, которую называют атакой посредника (man-in-the-middle attack). И для защиты от таких атак современное ПО использует методы, аналогичные (хотя и гораздо более мощные) тем, которые использовались сто лет назад машинами «Энигма».
Для своего времени эта машина была впечатляющим технологическим достижением, хотя и не лишенным недостатков. Для перехвата и дешифровки сообщений требовалась «Энигма» с такой же конфигурацией, как и у отправителя. Поэтому один раскрытый журнал конфигурации (или в современных терминах закрытый ключ (private key)) мог вывести из строя всю сеть этих машин.
Для борьбы с этим все группы, отправляющие сообщения через «Энигму», регулярно меняли конфигурацию машин. Перенастройка занимала много времени. Во-первых, обмен журналами конфигурации происходил только лично, поскольку безопасных способов удаленного обмена данными еще не существовало. Для пары машин с двумя операторами это было нетрудно сделать. Но для более крупной сети требовалось несколько курьеров, что увеличивало вероятность кражи журнала конфигурации или, например, его продажи.
Вторая проблема с передачей записей конфигурации заключалась в том, что перенастройка «Энигмы» проводилась вручную. И для этого требовался специально обученный сотрудник. Программного обеспечения в те времена еще не было, и корректировка конфигурации означала вмешательство в аппаратную часть, сводясь к изменению физической компоновки и проводки коммутационной панели. Настройщик должен был разбираться в электронике, а таких специалистов в начале 1900-х годов было крайне мало.
Сложность и длительность процесса перенастройки привела к тому, что обновления обычно производились раз в месяц. И только для особо важных линий связи это делалось ежедневно. Это означало, что перехват или утечка журнала конфигурации давали злоумышленникам — «хакерам» прошлого — доступ ко всем передачам до конца месяца.
Для машин «Энигма» использовался алгоритм, известный как симметричное шифрование. В этом случае для шифрования и дешифровки служит один и тот же криптографический ключ. Такая схема шифрования до сих пор применяется в ПО для защиты данных при передаче (между отправителем и получателем), но в классическую схему, ставшую популярной благодаря машинам «Энигма», уже внесено множество улучшений.
ПО позволяет создавать намного более сложные ключи. Современные алгоритмы генерации создают ключи, подбор которых методом перебора всех возможных комбинаций (атака «грубой силой») на самом мощном современном оборудовании может занять более миллиона лет. Кроме того, в отличие от перенастройки конфигурации машин «Энигма», программные ключи можно быстро менять.
Ключи могут пересоздаваться при каждом входе пользователя в систему, при каждом сетевом запросе или через определенный интервал времени. В результате при использовании такого типа шифрования в софте утечка ключа дает доступ к одному сетевому запросу или, в худшем случае, если ключ заново генерируется при входе в систему, доступ к сеансу появляется на несколько часов.
Если углубиться в историю современной криптографии, мы в итоге дойдем до 1930-х годов и Второй мировой войны. Можно с уверенностью утверждать, что машина «Энигма» стала важной вехой в обеспечении безопасности удаленной связи. Соответственно, именно ее можно считать отправной точкой для развития такой дисциплины, как защита программного обеспечения.
Это технологическое достижение породило и тех, кого сейчас называют хакерами. Ведь именно появление у стран гитлеровской коалиции машины «Энигма» заставило силы союзников разрабатывать методы взлома шифров. Генерал армии Дуайт Дэвид Эйзенхауэр говорил, что это необходимо для победы над нацистами.
В сентябре 1932 года польскому математику Мариану Реевскому (Marian Rejewski) предоставили украденную «Энигму». В октябре 1932 года французский шпион Ганс-Тило Шмидт (Hans-Thilo Schmidt) смог передать ему действующие конфигурации, что дало Реевскому возможность перехватывать сообщения и позволило начать анализ шифрования машины.
Мариан пытался определить как механический, так и математический принципы работы машины. Он хотел понять, как конкретная конфигурация аппаратного обеспечения приводит к выводу зашифрованного сообщения.
Попытки дешифровки базировались на ряде теорий относительно того, как определенная конфигурация машины влияет на результат вывода. Анализируя закономерности в зашифрованных сообщениях и выдвигая теории, основывающиеся на механическом устройстве «Энигмы», Реевский и его коллеги Ежи Ружицкий и Генрих Зыгальский в конечном итоге смогли понять принцип ее работы. Поняв порядок и положение роторов, а также схему соединений на коммутационной панели, команда смогла эмпирически определить соответствие между конфигурациями и шаблонами шифрования. Они смогли с приемлемой точностью перенастроить плату и после нескольких попыток приступить к считыванию зашифрованной радиопередачи. К 1933 году команда ежедневно перехватывала и расшифровывала сообщения, передаваемые «Энигмами».
Подобно современным хакерам, команда Реевского перехватывала поток данных и путем перестраивания схемы шифрования получала доступ к чужим ценным данным. Именно поэтому я считаю Мариана Реевского и его команду одними из первых хакеров.
После этого Германия начала наращивать сложность шифрования для машин «Энигма». Для этого постепенно увеличивали число роторов, осуществляющих шифрование. В конце концов, процесс перестраивания конфигурации стал слишком трудоемким, и команда Реевского не могла осуществить его за разумное время. Эта противомера отлично демонстрирует отношения, которые складываются между хакерами и теми, кто пытается им помешать.
Такие отношения продолжаются и по сей день, потому что изобретательные хакеры постоянно совершенствуют методы взлома программных систем. А по другую сторону хорошо подготовленные инженеры постоянно разрабатывают новые методы защиты.
Автоматизированный взлом шифра «Энигмы», 1940-е
Английский математик Алан Тьюринг (Alan Turing) наиболее известен благодаря разработке теста, известного сегодня как «тест Тьюринга». Тест предназначался для оценки сложности машинных диалогов и для установления их отличий от разговоров с реальными людьми. В сфере искусственного интеллекта (ИИ) этот тест часто считается одним из ключевых принципов.
Наибольшую известность Алан Тьюринг приобрел за свои работы, связанные с ИИ, но при этом он также был пионером в области криптографии и автоматизации. Перед Второй мировой войной и во время нее исследования Тьюринга были сосредоточены в первую очередь на криптографии. С сентября 1938 года он по совместительству работал в Правительственной школе кодирования и шифрования (Government Code and Cypher School, GC&CS). Это одновременно научно-исследовательский институт и разведывательное управление, которое финансировалось британской армией и располагалось в особняке Блетчли-парк в Англии.
Исследования Тьюринга в основном были связаны с анализом машин «Энигма». В Блетчли-парке он занимался этим под руководством Дилли Нокса (Dilly Knox), который в то время уже был опытным криптографом.
Как и польские математики до них, Тьюринг и Нокс хотели найти способ взломать (ставший значительно более мощным) шифр немецких «Энигм». Благодаря сотрудничеству с Польским бюро шифров (Polish Cipher Bureau) они получили доступ ко всем проведенным десятью годами ранее исследованиям группы Реевского. Это означает, что к тому моменту они хорошо разобрались, как работала «Энигма». Они понимали взаимосвязь между роторами и электрической схемой и знали, как конфигурация устройства связана с шифрованием передаваемых сообщений (рис. 1.2).
Группа Реевского смогла обнаружить в шифровании закономерности, позволившие логически определять конфигурацию «Энигм». Но это решение было невозможно масштабировать на увеличившееся в десять раз количество роторов. За время перебора всех возможных комбинаций успевала выйти новая версия конфигурации. Поэтому перед Тьюрингом и Ноксом стояла задача найти решение, допускающее масштабирование. Фактически им требовался универсальный, а не узкоспециализированный метод.
Рис. 1.2. Пара роторов, использовавшаяся для калибровки конфигурации передачи машин «Энигма», аналоговый эквивалент изменений первичного ключа цифрового шифра
Появление «бомбы»
Криптологическая бомба (рис. 1.3) представляла собой механическое устройство с электрическим приводом, которое пыталось автоматически реконструировать положение роторов в «Энигме», анализируя отправленные этой машиной сообщения.
Рис. 1.3. Одна из первых «бомб» из Блетчли-парка, использовавшаяся во время Второй мировой войны (обратите внимание, сколько рядов роторов применялось для быстрого определения конфигураций «Энигм»)
