Предлагаем вашему вниманию Top 10 Proactive Controls for Software developers – 10 аспектов безопасности, на которых должны сосредоточиться разработчики ПО. Данная статья содержит список техник по обеспечению безопасности, обязательных для реализации при разработке каждого нового проекта.

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

OWASP

Open Web Application Security Project (OWASP) – открытый проект обеспечения безопасности web-приложений. Сообщество OWASP включает в себя корпорации, образовательные организации и частных лиц со всего мира. OWASP работает над созданием общедоступных статей, учебных пособий, документации, инструментов и технологий.

На проект OWASP ссылается множество стандартов, инструментов и организаций, включая MITRE, PCI DSS, DISA, FTC и множество других.

Проект «Проактивная защита: Топ-10 требований OWASP» аналогичен проекту OWASP Top-10 ^[1], но в нем акцент делается на методах и рекомендациях по защите от угроз, а не на самих угрозах. Каждый метод и рекомендация в данном документе связаны с одной или несколькими угрозами из списка OWASP Top-10.

Цели и задачи

Цель проекта «Проактивная защита: Топ-10 требований OWASP» – привлечение внимания к безопасности приложений путем рассмотрения наиболее важных аспектов ИБ, которые стоит учитывать разработчикам ПО. Мы призываем организации воспользоваться рекомендациями OWASP по проактивной защите и научить разработчиков обращать внимание на безопасность приложений, придавая значение ошибкам, имевшим место в других организациях. Надеемся, что рекомендации OWASP окажутся для вас полезными при создании безопасных приложений.

Целевая аудитория

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

Топ-10 требований к проактивной защите

C1: Определение требований безопасности

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

Стандарт подтверждения безопасности приложений OWASP (ASVS) ^[2] представляет собой каталог доступных требований безопасности и параметров проверки. OWASP ASVS может служить источником расширенных требований безопасности для команд разработчиков.

Требования безопасности объединены в категории на основе общих функций безопасности высшего порядка. Например, ASVS содержит следующие категории: аутентификация, контроль доступа, обработка и журналирование ошибок, а также веб-службы. Для каждой категории существует список параметров, которые рекомендуется проверять.

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

C2: Использование безопасных фреймворков и библиотек

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

При включении сторонних библиотек или фреймворков в свое ПО необходимо учитывать следующие рекомендации:

• используйте библиотеки и фреймворки из доверенных источников, которые активно разрабатываются и широко применяются в приложениях;
• составьте и поддерживайте в актуальном состоянии каталог всех сторонних библиотек;
• своевременно обновляйте библиотеки и компоненты. Используйте инструменты, такие как Проверки зависимостей OWASP ^[3] и Retire.JS ^[4], для определения зависимостей в проектах, а также проверяйте наличие известных и опубликованных уязвимостей в стороннем коде;
• для снижения вероятности атак используйте инкапсуляцию библиотек и только необходимую для вашего ПО функциональность.

C3: Обеспечение безопасного доступа к базам данных

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

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

Для предотвращения SQL-внедрений необходимо избегать интерпретации непроверенных входных данных в составе SQL-команд. Наилучшим решением будет использование метода «параметризации запросов». Этот метод необходимо применять к конструкциям SQL и OQL, а также хранимым процедурам.

Примеры параметризации запросов для ASP, ColdFusion, C#, Delphi, .NET, Go, Java, Perl, PHP, PL/SQL, PostgreSQL, Python, R, Ruby и Scheme можно найти на сайте http://bobby-tables.com ^[5] и в памятке OWASP по параметризации запросов ^[6].

C4: Кодирование и экранирование данных

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

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

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

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

C5: Обязательная проверка всех входных данных

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

Синтаксическая и семантическая норма

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

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

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

Белые и черные списки

Существует два основных подхода к проверке синтаксиса входных данных — проверка по черным и белым спискам.

Первый способ предназначен для поиска в данных «потенциально вредоносного» контента. Например, веб-приложение может блокировать входные данные, содержащие слово SCRIPT, с целью предотвращения межсайтового выполнения сценариев. Однако подобную меру защиты можно обойти, используя для тега script строчные буквы или комбинацию из строчных и прописных букв.

Второй способ предназначен для подтверждения соответствия данных требованиям набора «проверенных» правил. Например, проверка штата США по белому списку будет представлять собой поиск 2-буквенного кода в списке существующих штатов США.

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

Проверки на стороне клиента и на стороне сервера

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

C6: Внедрение цифровой идентификации

Цифровая идентификация — это уникальное представление пользователя (или любого другого объекта) при онлайн-транзакциях. Аутентификация — это процесс подтверждения того, что человек или сущность является тем, кем представляется. Управление сессиями — это процесс, с помощью которого сервер контролирует состояние аутентификации пользователя, чтобы он мог продолжать пользоваться системой без повторной аутентификации. Специальное издание NIST 800-63B ^[7]: Руководство по цифровой идентификации (Аутентификация и управление жизненным циклом) содержит подробные рекомендации по реализации требований к цифровой идентификации, аутентификации и управлению сессиями.

C7: Обязательный контроль доступа

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

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

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

• избирательное управление доступом (DAC) — предполагает ограничение доступа к объектам (например, файлам или элементам данных) на основе идентификатора, а также принципа «необходимого знания» субъектов (например, пользователей или процессов) и/или групп, которым принадлежат объекты;
• мандатное управление доступом (MAC) — предполагает ограничение доступа к системным ресурсам на основе критичности данных (определяемой метками), содержащихся в этих ресурсах, и формальных полномочий (т.е. допуска) пользователей на доступ к информации указанной важности;
• ролевая модель управления доступом (RBAC) — предполагает контроль доступа к ресурсам на основе ролей, определяющих разрешенные действия с ресурсами, а не на основе идентификаторов субъектов;
• управление доступом на основе атрибутов (ABAC) — предполагает разрешение или запрещение запросов пользователя, исходя из атрибутов пользователя и атрибутов объекта, а также элементов окружения, которые могут определяться глобально и быть более релевантными для применяемых политик.

C8: Повсеместная защита данных

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

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

Классификация данных

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

Шифрование передаваемых данных

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

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

Шифрование хранимых данных

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

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

C9: Внедрение журналирования и мониторинга событий безопасности

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

Польза от журналирования событий безопасности

Журналы регистрации событий безопасности могут быть использованы для:

• снабжения системы обнаружения атак данными;
• анализа и расследования инцидентов;
• выполнения требований регулирующих органов.

Реализация журналирования событий безопасности

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

• Используйте стандартные формы и способы регистрации событий в системе и между системами вашей организации. Примером стандартной платформы для регистрации событий являются службы журналирования Apache (Apache Logging Services), которые обеспечивают совместимость журналирования между приложениями на Java, PHP, .NET и C++.
• Не регистрируйте слишком много или слишком мало данных. Например, убедитесь в обязательной регистрации временных меток и идентификационных данных, таких как IP-адрес источника и идентификатор пользователя, но никогда не записывайте персональные или конфиденциальные данные.
• Обратите особое внимание на синхронизацию времени между узлами для обеспечения согласованности временных меток.

Журналирование с целью обнаружения атак и противодействия им

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

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

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

C10: Обязательная обработка всех ошибок и исключений

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

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

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

Некорректная обработка ошибок

Исследователи из Университета Торонто выяснили, что даже небольшая оплошность при обработке ошибок или их игнорирование может привести к критическим сбоям в работе распределенных систем ^[9].

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

• Утечка данных. Разглашение конфиденциальной информации в сообщениях об ошибках может непреднамеренно помочь злоумышленникам. Например, сообщение, содержащее трассировку стека или подробности внутренней ошибки, может предоставить злоумышленнику данные о вашем окружении. Даже небольшие различия в обработке ошибок (например, сообщение о вводе некорректного имени пользователя или некорректного пароля при ошибке аутентификации) могут стать для атакующего источником важной информации. Как описывалось выше, необходимо обеспечить подробное журналирование ошибок для проведения расследований и отладки, но при этом избегать разглашения этих данных, особенно внешним клиентам.
• Обход защиты TLS. Уязвимость Apple «goto fail» была следствием ошибки управления в коде обработки ошибок, которая приводила к полной компрометации TLS-соединений систем Apple.
• Отказ в обслуживании. Отсутствие базовой обработки ошибок может привести к неработоспособности системы. Обычно это относительно простая в эксплуатации уязвимость. Другие проблемы с обработкой ошибок могут привести к повышенному использованию ресурсов ЦП или диска и таким образом ухудшить производительность системы.

Полезные советы

• Управляйте исключениями централизованно ^[10], чтобы избежать дублирования блокировок try/catch в коде. Убедитесь в корректной обработке непредвиденных режимов работы внутри приложения.
• Убедитесь в том, что выводимые сообщения об ошибках не содержат критичных данных, но при этом содержат достаточно информации для соответствующего реагирования на них.
• Обеспечьте журналирование исключений таким образом, чтобы специалисты из команды технической поддержки, контроля качества, расследования инцидентов или реагирования на атаки имели достаточно данных для решения проблемы.
• Тщательно протестируйте и проверьте код обработки ошибок.

Заключение

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

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

• ознакомиться с Топ-10 OWASP ^[11] и Топ-10 OWASP (мобильные устройства) ^[12] для понимания рисков, связанных с безопасностью веб-приложений;
• согласно требованию № 1 проактивной защиты, включить в программу обеспечения безопасной разработки подробный список требований к безопасности на основе стандартов, например, Стандарта подтверждения безопасности веб-приложений OWASP (ASVS) ^[2] и Стандарта подтверждения безопасности мобильных приложений OWASP (MASVS) ^[13];
• ознакомиться с положениями OWASP OpenSAMM ^[14] для более общего понимания ключевых блоков создания безопасного ПО.

---

Полная версия ^[15] перевода и оригинал ^[16]. В переводе и адаптации принимали участие: JZDLin ^[17], Алексей Скачков ^[18], Иван Кочуркин ^[19] и Тарас Иващенко ^[20].

---

Данный документ выпущен под лицензией Creative Commons Attribution ShareAlike 3.0, переведен и адаптирован при участии российского отделениия консорциума OWASP ^[21].

Автор: Лука Сафонов

Источник ^[22]