Это полное руководство по Top 10 OWASP (Open Web Application Security Project ) и способам их устранения

Что такое OWASP

OWASP – это аббревиатура от Open Web Application Security Project.

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

Впервые рейтинг OWASP был опубликован в 2003 году и впоследствии выпускался каждые три-четыре года.

Список OWASP Top 10

Список включает следующее:

  • Инъекция
  • Нарушенная аутентификация
  • Раскрытие чувствительных данных
  • Внешние сущности XML (XXE)
  • Нарушенный контроль доступа
  • Неправильная конфигурация системы безопасности
  • Межсайтовый скриптинг (XSS)
  • Небезопасная десериализация
  • Использование компонентов с известными уязвимостями
  • Недостаточное протоколирование и мониторинг

Давайте подробнее разберемся в этих уязвимостях!

1. Инъекция

Это атака заключается в инъекции SQL, NoSQL, OS и LDAP в приложение.

Это может быть в виде SQL-запросов через входной интерфейс приложения.

Успешная инъекция SQL может привести к раскрытию конфиденциальной информации из базы данных.

С помощью SQL-инъекции можно изменять данные базы данных с помощью операторов Insert, Update и Delete, и даже СУБД (система управления базами данных) может быть отключена с помощью SQL-инъекции.

Инъекция происходит, когда данные вставляются в программу из ненадежного источника из-за отсутствия проверки ввода и санитарии данных, что может напрямую подвергнуть ввод в запрос.

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

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

Имя и пароль – это параметры, которые вы передаете в качестве входных данных и которые непосредственно вставляются в запрос.

1

SELECT * FROM credit_login WHERE user='admin' AND password='anything 1' OR '1' ='1'

Этот запрос означает имя пользователя = admin, где пароль – что угодно или 1=1.

1=1 всегда будет равен true, и результатом запроса будет пользователь с именем admin и паролем = true.

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

SQL-запрос для получения информации о пользователе будет выглядеть следующим образом:

1=1 всегда будет равен true, и результатом запроса будет пользователь с именем admin и паролем = true.

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

Введенные пользователем данные вставляются в SQL-запрос, который обрабатывается SQL-интерпретатором.

SQL-запрос для получения информации о пользователе будет выглядеть следующим образом:

1

"SELECT * FROM users WHERE name = '" + firstname + "'";

Переменная firstname получает ввод от пользователя и вводится в запрос.

Предположим, что ввод был “Mich”, тогда запрос будет выглядеть следующим образом:

1

"SELECT * FROM users WHERE name = 'Mich'";

Этот запрос будет обработан и извлечет все данные для пользователя с именем Mich.

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

На рисунке показана высокоуровневая диаграмма атаки SQLi:

Устранение инъекций:

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

2. Нарушенная аутентификация

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

Эта уязвимость всегда проявляется в двух областях: управление сеансами и управление учетными данными.

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

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

Согласно OWASP, эта форма уязвимости может проявляться различными способами.

В вашем веб-приложении нарушена аутентификация, если оно делает следующее:

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

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

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

Устранение неработающей аутентификации:

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

3. Раскрытие чувствительных данных

Это одна из самых критических уязвимостей OWASP Top 10, приводящая к компрометации данных, которые нуждаются в защите.

Это также известно как раскрытие информации или утечка информации.

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

Согласно OWASP, вот некоторые из сведений, которые могут стать достоянием общественности:

  • Финансовая информация
  • Учетные данные для входа в систему
  • Коммерческие или деловые данные
  • Медицинская информация
  • Технические данные о приложении или веб-сайте.

Даже если вы можете не использовать DEBUG=True, но вам нужно быть осторожным при администрировании конфигурационного параметра.

Всегда следите за тем, чтобы все чувствительные переменные использовали одно из этих ключевых слов:

  • TOKEN
  • API
  • PASS
  • SECRET
  • SIGNATURE
  • KEY

Митигация:

  • Всегда определяйте и классифицируйте, какие данные являются конфиденциальными в соответствии с законами о конфиденциальности и нормативными требованиями.
  • Немедленно удаляйте все данные, которые не нужно хранить.
  • Если вы собираетесь хранить какие-либо конфиденциальные данные, убедитесь, что они зашифрованы.
  • Используйте надлежащее управление ключами.
  • Обязательно шифруйте все данные при передаче с помощью таких протоколов безопасности, как TLS и SSL.
  • Вы можете обеспечить шифрование в своем приложении, просто используя HTTP Strict Transport Security (HSTS).
  • Не кэшируйте конфиденциальные данные.
  • Всегда храните пароли с использованием различных методов шифрования.

4. Инъекция XXE

OWASP перечисляет XML external entity injection (также известный как XXE) как уязвимость безопасности, которая дает злоумышленнику доступ к приложению, обрабатывающему XML-данные или анализирующему XML-ввод.

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

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

Эта XXE-атака может быть далее эскалирована для компрометации других внутренних или базовых серверов с помощью атак Server Side Request Forgery (SSRF).

Когда вы отправляете данные на сервер в форме XML, они не уязвимы, но на самом деле уязвимость заключается в способе парсинга XML.

Когда парсеры XML, позволяющие извлекать DTD (Document Type Definition), не имеют надлежащей входной проверки XML-данных, они могут быть уязвимы для XXE-инъекций, позволяющих злоумышленнику внедрить команду или содержимое в XML-документ.

Согласно OWASP Top 10, атака XML external entities (XXE) может использовать:

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

Устранение инъекций XXE:

  • Вы должны отключить DTD и функции внешних сущностей XML.
  • Все XML-процессоры и библиотеки, используемые в приложении, должны быть всегда обновлены и исправлены.
  • Необходимо обеспечить надлежащую валидацию для каждого пользовательского ввода.
  • Используйте хорошие парсеры XML, которые по умолчанию не уязвимы.
  • Используйте очень хороший инструмент SAST, который поможет обнаружить XXE в вашем исходном коде.
  • Убедитесь, что функции загрузки XML и XSL файлов проверяют каждый входящий XML с помощью проверки XSD.
  • Используйте шлюзы безопасности API
  • Используйте WAF (Web Application Firewall) для обнаружения и блокирования любых XXE-атак, а также для закрытого мониторинга.
  • Вы можете начать использовать формат данных JSON, который является менее сложным.

5. Нарушенный контроль доступа

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

Он также может контролировать доступ к содержимому и функциям приложения.

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

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

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

Ниже приведены примеры нарушенного контроля доступа:

  • Доступ к панели администратора.
  • Доступ к серверу через FTP / SFTP / SSH.
  • Доступ к панели управления веб-сайта.
  • Доступ к другим приложениям с ограниченным доступом на вашем сервере.
  • Доступ к базе данных.

Устранение нарушений контроля доступа:

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

6. Неправильная конфигурация системы безопасности

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

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

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

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

Согласно OWASP, приложение может быть уязвимым, если:

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

Устранение ошибок в конфигурации системы безопасности:

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

7. Межсайтовый скриптинг

Согласно OWASP, межсайтовый скриптинг, иначе известный как XSS, представляет собой инъекцию кода на стороне клиента.

При такой форме атаки злоумышленник пытается внедрить вредоносный скрипт на доверенный сайт.

Этот скрипт выполняется в виде кода JavaScript, который может перенаправить жертву с ее законного сайта на сайт злоумышленника без ее ведома.

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

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

Согласно OWASP Top 10, существует три типа межсайтового скриптинга:

  • Отраженный XSS
  • Хранимый XSS
  • DOM XSS

Защита от межсайтового скриптинга:

  • Мы можем закодировать следующие символы с помощью кодировки сущности HTML, чтобы предотвратить выполнение любой формы.

& -> & amp;

< -> & lt;

-> & gt;

‘ -> & quot;

‘ -> &# x27;

  • Кодировать CSS и убедиться, что он проверен перед вводом недоверенных данных в значения свойств стиля HTML.
  • Использование таких фреймворков, как Ruby on Rails и React JS, которые позволяют легко избежать XSS.
  • JavaScript кодировать перед вводом недоверенных данных в значения данных JavaScript.
  • HTML-кодирование значений JSON в контексте HTML и чтение данных с помощью JSON.parse.
  • Кодируйте URL перед вводом недоверенных данных в значения параметров HTML URL.
  • Внедрите политику безопасности содержимого.
  • Используйте флаг HTTPOnly cookie.
  • Разверните брандмауэр, защищающий от XSS.

8. Небезопасная десериализация

Эта уязвимость включена в список OWASP Top 10 на основании проведенного отраслевого опроса.

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

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

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

Эти недостатки безопасности могут вызвать атаку RCE (Remote Code Execution), которая является одной из основных атак.

Влияние, которое это оказывает на бизнес, заключается в необходимости защиты приложения и его данных, что может привести к двум нижеперечисленным типам атак:

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

Устранение небезопасной десериализации:

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

9. Использование компонентов с известной уязвимостью

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

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

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

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

Компоненты с известными средствами защиты от уязвимостей:

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

10. Недостаточное логгирование и мониторинг

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

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

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

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

Журнал аудита – это система, которая записывает каждое событие, происходящее на сайте, и вы можете заметить любые аномалии и быстро устранить их.

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

Недостаточное протоколирование и мониторинг:

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

Заключение

Мы рассмотрели OWASP top 10.

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

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