bannerbanner
Безопасность веб-приложений. Исчерпывающий гид для начинающих разработчиков
Безопасность веб-приложений. Исчерпывающий гид для начинающих разработчиков

Полная версия

Настройки чтения
Размер шрифта
Высота строк
Поля
На страницу:
1 из 3

Таня Янка

Безопасность веб-приложений

Исчерпывающий гид для начинающих разработчиков

Alice and Bob Learn Application Security

Tanya Janca © 2021 by John Wiley & Sons, Inc., Indianapolis, Indiana.

All Rights Reserved. This translation published under license with the original publisher John Wiley & Sons, Inc


© Райтман М. А., перевод на русский язык, 2023

© Оформление. ООО «Издательство «Эксмо», 2023

* * *

Отзывы о книге

Тани Янка «Безопасность веб-приложений. Визуальный гид для начинающих разработчиков»

Таня знает свое дело. Она обладает огромным объемом знаний и опыта в сфере безопасности приложений, DevSecOps и облачной безопасности. Мы все можем многое узнать от Тани, так что стоит прочитать ее книгу!

Дэфидд Штуттард, соавтор бестселлера The Web Application Hacker’s Handbook, создатель приложения Burp Suite

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

Джен Ким, автор бестселлера The Unicorn Project, соавтор The Phoenix Project, DevOps Handbook и Accelerate

Практическое руководство для современной эпохи. Таня отлично рассказывает о современном представлении о безопасности приложений понятным для всех языком.

Трой Хант, создатель веб-сайта Have I Been Pwned?

Я посвящаю эту книгу моей неутомимой группе поддержки: Лекси, Матеусу, Эшу и Вейну. Постоянно поддерживая, ободряя и отмечая завершение каждого этапа создания книги, вы не позволили мне бросить начатое. Также спасибо, что не осуждаете меня за то, сколько мороженого я съела во время редактирования.


Об авторе

Таня Янка, также известная под ником SheHacksPurple, является основательницей We Hack Purple, онлайн-академии, сообщества и канала подкастов, цель которых – обучение всех желающих созданию безопасного программного обеспечения. Она также является соучредителем компании WoSEC: Women of Security, руководит проектом OWASP DevSlop и отделением OWASP Victoria. Таня занимается программированием и работает в области IТ более двадцати лет. За это время она завоевала множество наград, успела потрудиться везде, от стартапов до государственных организаций и технологических гигантов (Microsoft, Adobe и Nokia). Она занимала различные должности: была основателем стартапа, пентестером (тестировщиком, проверяющим уязвимость киберзащиты информационной системы), директором по информационной безопасности, инженером по безопасности приложений и разработчиком программного обеспечения. Будучи превосходным оратором, активным блогером и стримером, она провела сотни выступлений и тренингов на шести континентах. Она ценит разнообразие, вовлеченность и человеколюбие, что проявляется в ее бесчисленных инициативах.

О технических редакторах

Доминик Ригетто начал свою карьеру в сфере разработки программного обеспечения, а восемь лет спустя перешел в область обеспечения безопасности, продолжая жить на границе двух миров. Доминику очень интересны наступательные и оборонительные аспекты безопасности приложений. В сфере безопасности (как и на всем протяжении профессиональной жизни) его главной целью было помогать командам разработчиков прагматически подходить к обеспечению безопасности своих проектов. С 2011 года Доминик является активным членом фонда OWASP, в рамках которого участвует в различных проектах, в основном касающихся его специализации в области доменов. Являясь приверженцем философии открытого исходного кода, в свободное время он участвует в различных проектах, соответствующих этой идее. Его домашняя страница – righettod.eu.


Эли Саад – опытный специалист в области информационной безопасности, работающий в банковской сфере. Он участвует в различных инициативах OWASP по стандартизации и регулярно публикует статьи по этой теме. Его основная цель – дать разработчикам программного обеспечения рекомендации по обеспечению безопасности и защите. Он провел несколько лекций, в которых знакомил новичков с безопасностью, и был гостем подкаста на платформе Security Journey, где рассказывал о различных проектах, связанных с безопасностью приложений. Он является сторонником разрушения фрагментированной культуры в мире безопасности приложений. Кроме того, Эли с удовольствием находит время для более простых вещей в жизни, хорошей передышки в горах и стакана вкусного виски (односолодового, конечно). Вы можете найти его в Twitter (@7hunderSon) и на GitHub (thunderson). С ним можно связаться также по электронной почте eliesaad7@gmail.com.

Благодарности

Я хотела бы поблагодарить моего издателя Джима Минателя за то, что он помог мне понять, что я готова написать книгу, и определиться с ее типом. Спасибо редактору Адаоби Оби Тултону за его бесконечное терпение, методическую помощь и эффективный контроль, которые помогли мне осуществить самый крупный проект в моей профессиональной жизни. Спасибо моим техническим редакторам Доминику Ригетто и Эли Сааду. Я никогда не смогу расплатиться с вами за вашу усердную работу по недопущению серьезных технических ошибок в книге. У меня нет слов, чтобы выразить мою признательность за ваше потраченное время, опыт и поддержку. Спасибо всем, кто отправился со мной в этот путь.

Предисловие

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

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

Вот где Алиса и Боб вступают в игру.

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

Для всего, начиная с требований безопасности для веб-приложений и заканчивая принципами проектирования безопасности, руководствами по написанию безопасного кода и распространенными «подводными камнями», в этой книге подобрано большое количество историй, примеров с Алисой или Бобом и схем. В ней также рассказывается о тестировании и развертывании программного обеспечения. Однако эта книга определенно не о «хакерстве». Она о том, как обеспечить прочность, надежность и безопасность приложений. В ней описывается, как создать безопасную программу, как обезопасить современные технологии и системы, какие привычки помогут разработчикам (или кому угодно) защитить себя и свои системы, и даже приводится план обучения в конце! Данную книгу, наполненную советами, хитростями и даже шутками, нельзя назвать обычным учебником.

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

Джим Манико, основатель и преподаватель по написанию безопасного кода в школе Manicode Security

Введение

Почему именно безопасность приложений? Зачем нужна эта книга? Почему безопасность важна? Почему данная тема вызывает большие трудности?

Если вы взяли в руки эту книгу, то, вероятно, уже знаете ответ на эти вопросы. Вы видели газетные заголовки о фирмах, которые были «хакнуты»: данные, в том числе личного характера, – украдены, компании и жизни – разрушены. Однако вы, возможно, не знаете, что причиной нарушения безопасности данных номер один является небезопасное программное обеспечение, из-за которого происходит от 26 до 40 % случаев утечек и краж (Verizon Breach Report, 2019)[1]. Однако если посмотреть на бюджеты большинства компаний, то сумма, выделяемая на защиту их программного обеспечения, обычно составляет очень малую часть.

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

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

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

Это одна часть проблемы.

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

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

Последняя часть проблемы заключается в том, что обеспечить безопасность приложений довольно сложно. В отличие от безопасности инфраструктуры, где все версии Microsoft Windows Server 2008 R2 PS2 абсолютно одинаковы, каждая часть пользовательского программного обеспечения – уникальная снежинка. При строительстве деревянной террасы на заднем дворе вы идете в хозяйственный магазин, чтобы купить древесину размером два на четыре дюйма длиной восемь футов. В какой бы магазин вы ни пошли, древесина будет везде одинаковой, а значит, вы можете делать предположения и расчеты без существенных рисков. С программным обеспечением так не получится. Никогда нельзя делать никаких предположений, нужно проверять каждый факт. Следовательно, запоминание методом «грубой силы», автоматизированные инструменты и другие универсальные решения работают редко, что делает обеспечение безопасности приложений очень сложной задачей.

Сдвиг влево

Если посмотреть на жизненный цикл разработки системы (англ. System Development Life Cycle, SDLС) на рис. В.1, можно увидеть, что все этапы сменяют друг друга слева направо. Требования предшествуют проектированию, за которым идет кодирование. Независимо от того, используете ли вы Agile, Waterfall, DevOps или любую другую методологию разработки программного обеспечения, всегда нужно узнать, какое ПО вы создаете (требования), составить план (проектирование), разработать его (кодирование), проверить, что оно выполняет все необходимые функции и ничего больше (тестирование), затем выпустить готовое ПО и поддерживать его работу (релиз).


Рис. В.1. Жизненный цикл разработки системы


Часто деятельность по обеспечению безопасности начинается на этапах выпуска или тестирования ПО – далеко справа и на довольно поздней стадии проекта. Проблема состоит в том, что чем позже исправлять недостаток (проблема проектирования) или ошибку (проблема реализации), тем дороже это обойдется и тем сложнее будет это сделать.

Позвольте мне объяснить мою мысль по-другому. Представьте, что Алиса и Боб строят дом. Они копили на него годами, и вот подрядчики завершают работу: клеят обои и прикручивают ручки на шкафчики. Вдруг Алиса поворачивается к Бобу и говорит: «Дорогой, у нас двое детей, а ванная комната только одна! Как мы станем делить ее?» Если сказать подрядчикам прекратить работу, дом не будет закончен вовремя. Если попросить пристроить вторую ванную комнату, где она должна находиться? Сколько это будет стоить? Обнаружение проблемы на столь поздней стадии проекта может привести к катастрофе. Однако если бы Алиса и Боб узнали о ней на этапе разработки требований или на этапе проектирования, то можно было бы легко добавить больше ванных комнат за очень небольшие деньги. То же самое справедливо и для решения проблем безопасности.

Именно здесь вступает в игру «сдвиг влево»: чем раньше вы начнете заниматься обеспечением безопасности во время проекта по разработке программного обеспечения, тем лучше будут результаты. Стрелки на рис. В.2 показывают последовательность действий по обеспечению безопасности, которые следует начинать как можно раньше в проекте. Позже мы обсудим, что это за действия.


Рис. В.2. Сдвиг влево


О книге

Эта книга научит вас основам безопасности приложений (сокращенно AppSec, от англ. Application Security), то есть тому, как создавать безопасное программное обеспечение. Она предназначена для разработчиков, специалистов по информационной безопасности, желающих узнать больше о безопасности программного обеспечения, и всех, кто хочет работать в этой области (которая включает в себя тестирование на проникновение, также известное как «этический взлом»).

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

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

Темы, выходящие за рамки книги

Хотелось бы сделать небольшое замечание по темам, которые выходят за рамки данной книги: реагирование на инциденты (IR), сетевой мониторинг и оповещение, облачная безопасность, безопасность инфраструктуры, сетевая безопасность, операции по обеспечению безопасности, управление идентификацией и доступом (IAM), безопасность предприятия, поддержка, антифишинг, обратная разработка, обфускация кода и другие передовые методы защиты, а также все остальные типы безопасности, не перечисленные здесь. О некоторых из них мы поговорим в книге, но данную информацию ни в коем случае нельзя считать исчерпывающей. Чтобы узнать больше об этих важных темах, обратитесь к дополнительным ресурсам.

Ответы

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

В течение нескольких месяцев после выхода этой книги на сайте youtube.com/shehackspurple в плейлисте «Алиса и Боб изучают безопасность приложений» будут появляться видео, где разбираются ответы на все вопросы. Вы можете подписаться на канал, чтобы не пропустить новые видео, посмотреть предыдущие и ознакомиться с другими бесплатными материалами.

Вы можете принять живое участие в обсуждениях, подписавшись на сайте newsletter.shehackspurple.ca на рассылку SheHacksPurple, чтобы получать приглашения на стримы (а также много другого бесплатного контента).

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

Часть I

Все, что нужно знать о коде, безопасном для публикации в интернете

Глава 1. Основы безопасности

Глава 2. Требования безопасности

Глава 3. Безопасность при проектировании ПО

Глава 4. Безопасность кода ПО

Глава 5. Часто встречающиеся подводные камни

Глава 1

Основы безопасности

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

Обязательство по обеспечению безопасности: «CIA»

Обязательство и цель каждой команды IТ-безопасности заключается в защите конфиденциальности, целостности и доступности систем и данных компании, правительства или организации, на которую команда работает. Вот почему служба безопасности беспокоит вас по поводу наличия ненужных прав администратора на вашем рабочем устройстве, не позволяет подключать неизвестные устройства к сети и требует выполнения всех остальных, как кажется, слишком сложных действий. Она хочет защитить эти три аспекта, которые для краткости называются «триадой CIA» (confidentiality, integrity, availability – конфиденциальность, целостность и доступность) (рис. 1.1).


Рис. 1.1. Триада CIA – причина существования команд IТ-безопасности


Рассмотрим данную триаду на примере наших друзей Алисы и Боба. Алиса страдает диабетом I типа и несколько раз в день использует имплантированное в руку крошечное устройство для проверки уровня инсулина. У Боба есть «умный» кардиостимулятор, регулирующий работу сердца, доступ к которому он получает через мобильное приложение на телефоне. Оба этих устройства в нашей отрасли называются имплантируемыми медицинскими устройствами IoT.

ПРИМЕЧАНИЕ. IoT значит Internet of Things – интернет вещей. Это физические продукты, подключенные к интернету. Умный тостер или холодильник, подключенный к интернету, является устройством IoT.

Конфиденциальность

Алиса – генеральный директор крупной компании, входящей в список Fortune 500. Она не стыдится своей болезни, но не хочет, чтобы эта информация стала достоянием общественности. Алиса часто дает интервью СМИ и выступает с публичными заявлениями, став примером для подражания для многих других женщин, работающих в ее отрасли. Она прилагает все усилия, чтобы сохранить в тайне сведения о личной жизни, в том числе и информацию о состоянии здоровья. Алиса считает, что некоторые люди в организации хотят занять ее место и пойдут на все, чтобы попытаться подорвать ее авторитет, представив ее «слабой». Случайно произошедшая утечка информации с устройства в сеть или взлом аккаунта поставили бы ее в затруднительное положение и могли бы навредить карьере. Для Алисы важно сохранить свою личную жизнь в тайне.


Рис. 1.2. Конфиденциальность: обеспечение сохранности информации


Боб, напротив, открыто говорит о своем заболевании сердца и с радостью рассказывает всем о кардиостимуляторе. У него отличная страховка от федерального правительства, и он высоко ценит возможность продолжать пользоваться ею после выхода на пенсию, несмотря на то что болезнь была обнаружена еще до начала работы на организацию. В данном случае конфиденциальность не является для Боба приоритетом (рис. 1.2).

ПРИМЕЧАНИЕ. Мы часто недооцениваем роль конфиденциальности в нашей жизни. Многие люди уверяют меня, что им «нечего скрывать». Тогда я спрашиваю: «У вас дома есть занавески на окнах? Да? Почему? Вам же нечего скрывать». Я просто жгу на вечеринках.

Целостность

Целостность (рис. 1.3) означает, что данные являются актуальными, правильными и точными. Целостность также подразумевает, что данные не были изменены во время передачи: необходимо сохранять правильность значения. Мы говорим о целостности компьютерной системы, когда результаты, которые она выдает, точны и правдивы.


Рис. 1.3. Целостность означает корректность


Для Боба и Алисы целостность, возможно, является самым важным из элементов триады CIA: некорректная работа одной из систем может привести к смерти. Для человека (в отличие от компании или государства) не существует более серьезного последствия, чем конец жизни. Таким образом, решающее значение для Боба и Алисы имеет целостность систем, связанных с их здоровьем.

Модель CIA – это центральное ядро всей нашей отрасли. Создание безопасного программного обеспечения невозможно без понимания сущности этой модели и ее влияния на членов команды, на программное обеспечение и, самое главное, на пользователей.

Доступность

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

У Боба же время от времени сбивается ритм сердцебиения, и он никогда не знает, в какой момент наступит аритмия. Если бы в периоды нестабильной работы сердца у Боба отсутствовал доступ к кардиостимулятору, то по прошествии времени это могло бы привести к критической для его жизни ситуации. Очень важно, чтобы при возникновении чрезвычайной ситуации кардиостимулятор был доступен и реагировал в режиме реального времени (немедленно).

На страницу:
1 из 3