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

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

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

• Ставить запрет по умолчанию – перед началом работы все функции должны проверять авторизацию пользователя.

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

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

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

• Проверять аутентификацию (AuthN) и авторизацию (AuthZ) для API в обоих направлениях (API → приложение → API).

• Блокировать доступ к любому не используемому приложением протоколу, порту, HTTP-глаголу, методу и всему остальному на сервере, PaaS или контейнере.

• Одно приложение на сервер, PaaS или контейнер в зависимости от модели развертывания и бюджета.

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

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

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

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

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

• Резервные копии должны храниться территориально в другой точке (не рядом с базой данных и веб-сервером).

• Резервные копии должны находиться в безопасном месте (как в физическом, так и в цифровом виде) и быть защищены так же, как и производственная база данных или веб-сервер.

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

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

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

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

• Проводите учебные откаты. Серьезно!

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

При проведении тестирования безопасности веб-приложений (например, тестирования на проникновение) в большинстве случаев используется так называемый веб-прокси или прокси перехвата (иногда в сочетании со сканером веб-приложений, что позволяет проводить автоматизированное тестирование). Веб-прокси, как следует из названия, располагается между браузером и веб-сервером и перехватывает трафик. Этот тип инструмента используется для прямого взаимодействия с приложением посредством отправки запросов на веб-сервер и откликов после завершения работы JavaScript в интерфейсе пользователя (в компьютере либо браузере пользователя). Если вы впишете код проверки в JavaScript, чтобы убедиться в безопасности пользовательского ввода, любой пользователь с помощью веб-прокси может ввести достоверные данные, приостановить их передачу (перехватить запрос) после того, как JavaScript закончит проверку данных, и заменить на вредоносные данные (отредактировать запрос и отправить его дальше). Будет правильным, если приложение повторно проверит данные на сервере: можно выполнить очень простую проверку данных в JavaScript, которая сэкономит время. Если же данные на сервере не будут проверены, злоумышленники легко могут отправить приложению вредоносные запросы с помощью веб-прокси. На рис. 3.5 изображен поток HTTP-запросов при использовании веб-прокси.

Рис. 3.5. Использование веб-прокси для обхода проверки JavaScript

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

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

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

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

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

СОВЕТ. Тайник – это место, где хранятся секреты приложения. В отличие от менеджеров паролей, предназначенных для людей, тайниками пользуются машины. В них можно и нужно хранить строки подключения, учетные данные, ключи, хеши и другие секреты.

Функции, касающиеся безопасности (это относится и к проектированию оборудования), по возможности следует изолировать от остальной функциональной части приложения. Благодаря этому нарушение функций, не связанных с обеспечением безопасности, не заденет защиту приложения и не станет причиной возникновения уязвимости. Данный совет упоминается в очень надежных руководствах по безопасности: ITSG-33[33]33
  ITSG-33: www.cse-cst.gc.ca/sites/default/files/itsg33-ann4a-eng.xls.


[Закрыть] канадского правительства и Специальной публикации NIST 800-53 S-3[34]34
  Специальная публикация NIST 800-53 S-3: nvd.nist.gov/800-53/Rev4/control/SC-3.


[Закрыть].

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

• Вынесение проверки ввода в отдельный объект или класс.

• Вынесение аутентификации и авторизации в отдельное приложение.

• Управление идентификацией, осуществляемое облачным провайдером или другой внешней системой.

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

Код функции безопасности может храниться на отдельном веб-сервере, PaaS, контейнере или файловой системе. Между двумя приложениями может быть брандмауэр или в крайнем случае совершенно отдельные сети.

Системы идентификации и аутентификации всегда должны находиться на отдельном сервере и следовать принципам по усилению защиты.

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

По возможности функции, касающиеся управления системой (администрирования), должны быть изолированы от остальной функциональной части приложения. Таким образом, нарушение функций, не связанных с обеспечением безопасности, не повлияет на управление системой (контроль доступа). Данный совет упоминается в очень надежных руководствах по безопасности: ITSG-33[35]35
  ITSG-33: www.cse-cst.gc.ca/sites/default/files/itsg33-ann4a-eng.xls.


[Закрыть] канадского правительства и Специальной публикации NIST 800-53 S-3[36]36
  Специальная публикация NIST 800-53 S-2: nvd.nist.gov/800-53/Rev4/control/SC-2.


[Закрыть].

ПРИМЕЧАНИЕ. Определение из стандарта ITSG-33: информационная система отделяет функциональные возможности пользователя (включая услуги пользовательского интерфейса) от функций управления информационной системой.

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

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

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

Ручное управление секретами – ужасная практика, которая отнимает много времени, имеет высокую сложность и чревата ошибками. Именно поэтому были созданы тайники – специальное программное обеспечение, которое управляет секретами и доступ к которому можно получить через приложение, конвейер CI/CD или сервисную учетную запись. Человек не должен иметь доступ к секретам, находящимся в тайнике, кроме тех случаев, когда их необходимо поместить в тайник или обновить либо когда произошла чрезвычайная ситуация. Доступ к тайнику должен тщательно охраняться, а все связанные с ним события – регистрироваться и сопровождаться оповещением.

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

Подделка межсайтовых запросов (CSRF)[37]37
  Подделка межсайтовых запросов (CSRF): www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF).


[Закрыть] – это уязвимость, при которой злоумышленник убеждает жертву перейти по ссылке или посетить вредоносный сайт. Ссылка или сайт запускает транзакцию в приложении (допустим, покупку нового модного телевизора, который будет отправлен злоумышленнику), и поскольку пользователь уже вошел в учетную запись (кто не оставляет браузер открытым несколько дней подряд?), уязвимое веб-приложение завершает транзакцию (покупку), о которой пользователь ничего не знает, пока не придет счет. Однако к тому времени уже слишком поздно реагировать. Лучший способ защиты от данной уязвимости – перед каждым важным действием приложения (покупка, деактивация аккаунта, смена пароля и т. д.) запрашивать у пользователя что-то, что может предоставить только он сам: предлагать повторно ввести пароль, ввести капчу или секретный токен, который будет только у него. Наиболее распространенным подходом является использование секретного токена (часто называемого анти-CSRF-токеном). На момент написания книги этот метод защиты настолько распространен, что уже включен во многие современные платформы (такие как. Net, Java и Ruby on Rails). Таким образом, нет необходимости кодировать эту функцию самостоятельно, а следует лишь убедиться в том, что она включена.

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

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

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

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

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

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

Многие разработчики, выступающие за использование открытого кода, утверждают, что если код будет доступен для всеобщего обозрения, то люди станут быстрее и чаще замечать уязвимости в проектах. Однако цифры говорят о другом: исследования показали, что проприетарные (закрытые) приложения имеют в среднем такое же количество уязвимостей, как и проекты с открытым исходным кодом[38]38
  Сравнение открытого исходного кода и закрытого исходного кода: www.researchgate.net/publication/220891308_Security_of_Open_Source_and_Closed_Source_Software_An_Empirical_Comparison_of_Published_Vulnerabilities.


[Закрыть]. Лишь малая часть инженеров по безопасности проверяют открытый исходный код «просто ради интереса». Эта работа утомительна, требует высокого уровня профессионализма и отнимает много времени. При нынешнем дефиците квалифицированных специалистов[39]39
  Нехватка специалистов в области информационной безопасности: www.infosecurity-magazine.com/news/cybersecurity-skills-shortage-tops.


[Закрыть] и очень высокой стоимости работы[40]40
  Высокая стоимость услуг специалистов информационной безопасности: www.mondo.com/blog-highest-paid-cybersecurity-jobs.


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

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

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

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