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

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

ПРИМЕЧАНИЕ. Медицинские приборы, как правило, являются системами ПО, работающими в режиме реального времени. «Режим реального времени» означает, что система должна реагировать на изменения в кратчайшие сроки, обычно исчисляющиеся в миллисекундах. Она не может работать с задержками – отклик должен быть максимально быстрым или немедленным. Когда у Боба начинается аритмия, кардиостимулятор должен сработать немедленно – задержки быть не может. В таком режиме функционируют только немногие приложения: 10-миллисекундная задержка при покупке новых кроссовок или при прогнозировании изменений дорожного трафика не приведет к действительно большой проблеме.

Рис. 1.4. Устойчивость повышает доступность

ПРИМЕЧАНИЕ. Многие пользователи переводят информацию в облако по той единственной причине, что оно чрезвычайно надежно (почти всегда доступно) по сравнению с более традиционными уровнями обслуживания во внутренних центрах обработки данных. Как показано на рис. 1.4, устойчивость повышает доступность, что делает публичное облако привлекательным вариантом с точки зрения безопасности.

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

«Предполагать взлом»

«Есть два типа компаний: те, которые взломаны, и те, которые еще не знают об этом»[2]. Это настолько известное высказывание в индустрии информационной безопасности, что мы уже не знаем, кому его приписывать. Возможно, звучит пессимистично, но те из нас, кто работает в области реагирования на инциденты, в судебно-медицинской экспертизе или в других сферах, связанных с расследованиями, знают, что оно более чем правдиво.

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

Рассмотрим два примера применения этого принципа: пример с потребителем и пример с профессионалом.

Как потребитель Алиса использует для обмена документами аккаунт в интернете. Если бы она «предполагала взлом», то не стала бы загружать в него ничего личного или ценного (например, незарегистрированную интеллектуальную собственность, фотографии личного характера, которые могут повредить профессиональной или частной жизни, коммерческие и государственные тайны и т. д.). Она также установила бы мониторинг учетной записи и разработала бы план на случай кражи, изменения, удаления, публичного распространения информации или другого несанкционированного доступа к документам. Наконец, она периодически проверяла бы весь интернет на предмет утечки данных. Все вышеперечисленные действия представляли бы собой нереальный уровень ответственности, который не ожидается от обычного потребителя. Эта книга не советует «предполагать взлом» в повседневной жизни, хотя периодически проводить поиск информации в интернете – хорошая идея, а также определенно рекомендуется не загружать в сеть конфиденциальные документы.

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

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

Согласно «Википедии», «координированное раскрытие» – это модель раскрытия уязвимостей, при которой уязвимость или проблема раскрывается только по истечении периода времени, позволяющего устранить либо исправить уязвимость или проблему.

Многие организации проводят программы Bug Bounty. Они выплачивают награду исследователям в области безопасности за сообщения об ошибках в системе. Особо ценятся те ошибки, которые связаны с уязвимостями.

Внутренние угрозы

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

Примеры умышленных угроз и затрагиваемых ими аспектов триады CIA

• Сотрудник загружает интеллектуальную собственность на переносной диск, покидает здание, а затем продает информацию конкурентам (конфиденциальность).

• Сотрудник удаляет базу данных и ее резервную копию в свой последний рабочий день, так как злится по поводу увольнения (доступность).

• Сотрудник встраивает бэкдор (тайный вход) в систему для последующей кражи у компании (целостность и конфиденциальность).

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

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

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

Примеры случайных угроз и затрагиваемых ими аспектов триады CIA

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

• Сотрудник случайно удаляет ценные данные, файлы или даже целые системы (доступность).

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

• Неопытный сотрудник направляет веб-прокси или инструмент, выполняющий динамическое тестирование безопасности приложений (Dynamic Application Security Testing, DAST), на одно из ваших внутренних приложений, что приводит к сбою приложения (доступность) или «засорению» базы данных (целостность). В последующих главах мы расскажем о том, как избежать такой ситуации и обеспечить успешное проведение всех тестирований безопасности.

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

Глубокая защита

«Глубокая защита» предполагает наличие нескольких уровней безопасности на случай, если одного окажется недостаточно (рис. 1.5). Хотя данная идея может показаться очевидной при столь простом объяснении, иногда непросто определить, сколько уровней необходимо иметь и какие это должны быть уровни (особенно если выделенный на обеспечение безопасности бюджет ограничен).

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

Рис. 1.5. Три уровня безопасности приложения; пример глубокой защиты

Примеры использования многочисленных уровней приведены ниже.

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

• Сетевая безопасность: включение мониторинга, наличие системы SIEM (Security information and event management – «Управление информацией о безопасности и событиями безопасности», панель инструментов для просмотра возможных событий безопасности в режиме реального времени), наличие системы IPS/IDS (Intrusion prevention/detection system – «Система предотвращения и обнаружения вторжений», инструмент для поиска и препятствования действиям злоумышленников в сети), брандмауэры и многое другое. Каждый новый элемент усиливает защиту приложения.

• Физическая безопасность: замки, колючая проволока, заборы, ворота, видеокамеры, охранники, сторожевые собаки, датчики движения, сигнализация и т. д.

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

ПРИМЕЧАНИЕ. Моделирование угроз – определение угроз, которым могут подвергаться приложения, и разработка планов по снижению их возникновения. Подробнее об этом см. в главе 3.

Система SIEM – мониторинг сети и приложений, панель инструментов для работы с возможными проблемами.

Система предотвращения и обнаружения вторжений (IPS/IDS) – программное обеспечение, установленное в сеть с целью обнаружения или предотвращения сетевых атак.

Принцип наименьших привилегий

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

Примеры реализации принципа наименьших привилегий таковы.

• Необходимость получения дополнительного разрешения от службы безопасности для доступа в лабораторию или часть здания с повышенным уровнем безопасности.

• Отсутствие привилегий администратора на рабочем компьютере.

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

• Создание сервисной учетной записи в приложении для входа в базу данных и предоставление разрешения на чтение и запись, но не доступ владельца базы данных (Database owner, DBO). Если приложению требуется доступ только для чтения, дайте ему не более того, что необходимо для нормальной работы. Сервисная учетная запись с доступом к базе данных только для чтения не может быть использована для изменения или удаления каких-либо данных, даже если через нее можно украсть копии данных. Все вышеперечисленное значительно снижает риски.

ПРИМЕЧАНИЕ. Разработчики программного обеспечения и системные администраторы являются привлекательными целями для большинства злоумышленников, поскольку обладают наибольшими привилегиями. Отказавшись от некоторых из них, вы защитите свою компанию больше, чем можете предположить, и одновременно заслужите уважение команды безопасности.

Безопасность цепи поставок

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

Объясним цепь поставок на примере. Если Боб хочет смастерить кукольный домик для своих внуков, он может купить изготовленный на фабрике набор. Фабрике требуются древесина, бумага, краска, клей, машины для резки, люди для управления и обслуживания техники, а также энергия для ее питания. Древесину фабрика заказывает у лесозаготовительной компании, вырубающей деревья в лесу. Компания владеет этим лесом либо имеет лицензионный доступ на вырубку в нем. Бумага, краска и клей, скорее всего, производятся на разных заводах. Возможно, люди работают непосредственно на фабрике или являются временными подрядчиками. Энергия, скорее всего, поступает от энергетической компании, но нельзя исключать использование альтернативных источников (солнце или ветер) или генератора в случае чрезвычайной ситуации. На рис. 1.6 показана (гипотетическая) цепь поставок для приобретенного Бобом набора, из которого он сделает кукольный домик для внуков на Рождество.

Рис. 1.6. Вероятная цепь поставок для кукольного домика Боба

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

При разработке программного обеспечения мы также используем цепь поставок: платформу – для написания кода, библиотеки – для записи на экране, выполнения сложных математических вычислений или отрисовки кнопки, интерфейсы программирования приложений (API) – для выполнения действий от имени приложений и т. д. Более того, каждый из этих фрагментов программного обеспечения обычно зависит от других фрагментов, и все они чаще всего поддерживаются различными группами, компаниями или людьми. Как правило, современные приложения на 20–40 % состоят из оригинального кода[3] (того, что написали вы и ваши коллеги), в остальном – из сторонних компонентов, часто называемых зависимостями. При подключении зависимостей к приложению вы принимаете на себя риски кода, который они содержат. Например, если вы добавите в приложение модуль для обработки изображений, вместо того чтобы самому написать часть соответствующего кода, и в этом модуле будет серьезный недостаток безопасности, то уязвимость приложения тоже значительно повысится.

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

ПРИМЕР АТАКИ НА ЦЕПЬ ПОСТАВОК

В 2018 году модуль Node.js с открытым исходным кодом под названием event-stream был передан новому разработчику, который добавил в него вредоносный код. Он дождался, пока миллионы людей скачают его через NPM (Node Package Manager – систему управления пакетами для Node.JS), а затем использовал эту уязвимость для кражи биткоинов с кошельков Copay, в которых применялась библиотека event-stream[4].

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

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

Безопасность через неясность

Концепция безопасности через неясность подразумевает, что если какой-то фрагмент системы скрыт, то он находится в «большей безопасности», поскольку не попадает в поле зрения потенциальных злоумышленников. Наиболее распространенная реализация этой концепции: компании – разработчики программного обеспечения скрывают свой исходный код, а не выкладывают его в открытый доступ (с целью защиты интеллектуальной собственности и в качестве меры безопасности). Некоторые доходят до обфускации своего кода, изменяя его таким образом, чтобы его было гораздо сложнее или вообще невозможно понять тому, кто попытается провести обратную разработку продукта.

ПРИМЕЧАНИЕ. Обфускация – это усложнение чего-то для понимания или чтения. Распространенной тактикой является кодирование всего исходного кода в ASCII, Base64 или Hex, но ее довольно легко видят профессиональные реверс-инженеры. Некоторые компании дважды или трижды шифруют свой код. Другая тактика – применение операции XOR (команды ассемблера) или создание собственной схемы кодирования и добавление ее программным путем. Также можно купить продукты, выполняющие более сложную обфускацию.

Другим примером «безопасности через неясность» является использование беспроводного маршрутизатора, скрывающего имя SSID/Wi-Fi (то есть при подключении к сети необходимо вручную указать ее имя), или размещение веб-сервера без доменного имени в надежде, что никто его не найдет. Существуют инструменты для обхода данных мер, но риск атаки на беспроводной маршрутизатор или веб-сервер снижается.

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

Хотя сам по себе подход «безопасность через неясность» вряд ли является превосходным методом защиты, он, безусловно, полезен в качестве одного из уровней стратегии обеспечения безопасности – «защиты в глубину».

Уменьшение поверхности атаки

Атаке подвержен каждый элемент программного обеспечения: любая функция, вход, страница или кнопка. Чем меньше приложение, тем меньше поверхность атаки. Четыре страницы с 10 функциями представляют гораздо меньшую поверхность атаки, чем 20 страниц со 100 функциями. Каждый элемент приложения, который может быть подвержен действию злоумышленника, считается поверхностью атаки.

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

СОВЕТ. Устаревшее программное обеспечение часто имеет очень большой объем неиспользуемой функциональности. Удаление ненужных функций – отличный способ уменьшить поверхность атаки.

Как вы помните, у Алисы и Боба есть медицинские имплантаты: устройство для измерения инсулина у Алисы и кардиостимулятор у Боба. Оба являются «смарт-устройствами», то есть к ним можно подключиться через смартфон. Устройство Алисы работает через Bluetooth, а кардиостимулятор Боба – через Wi-Fi. Одним из самых очевидных способов уменьшить поверхность атаки было бы не приобретать «смарт-версии» таких устройств. Однако в данном случае делать это уже поздно. Тем не менее Алиса могла бы отключить «видимость» Bluetooth у своего прибора для измерения инсулина, а Боб – скрыть SSID своего кардиостимулятора.

Жесткое кодирование

Жесткое кодирование означает программирование значений в коде вместо получения их естественным путем (от пользователя, из базы данных, API и т. д.). Например, если в разработанном вами приложении-калькуляторе пользователь вводит 4 + 4, нажимает Enter и на экране появляется 8, вы, скорее всего, решите, что калькулятор работает. Однако если пользователь вводит 5 + 5 и нажимает Enter, а на экране все равно отображается 8, это может говорить о возникновении ситуации жесткого кодирования.

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