Наиболее распространенные уязвимости безопасности

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

Инъекции

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

(источник xkcd: Exploits of a mom.)

Хотя SQL-инъекции, вероятно, являются самыми распространенными примерами уязвимостей инъекции (см., например, Ruby on Rails и Spring Data JPA), существуют и другие типы инъекций. Например, может быть возможно выполнить код на сервере приложения (см. Ruby on Rails, Spring) или Django.

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

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

Раскрытие конфиденциальных данных

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

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

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

Следующее задание выполняется в Test My Code.

Ошибки конфигурации безопасности

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

Например, одна из атак типа Denial of Service частично стала возможной из-за тысяч устройств интернета вещей с паролями по умолчанию или слабыми паролями.

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

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

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

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

<script>alert(document.cookie);</script>

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

Использование компонентов с известными уязвимостями

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

У большинства инструментов управления зависимостями есть плагины, которые могут анализировать используемые зависимости и выявлять компоненты с уязвимостями. Например, пакеты Python safety и safety-db можно использовать для проверки уязвимых пакетов.

Непроверенные перенаправления и пересылки

Непроверенные перенаправления и пересылки могут заставить веб-приложение перенаправить пользователя в нежелательное место. Это может произойти, например, если адрес, на который пользователь перенаправляется после действия, можно подменить. Дополнительные сведения см. в OWASP Cheat Sheet.

Межсайтовая подделка запроса

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

В этой части курса Securing Software мы рассмотрели некоторые из самых распространенных проблем веб-безопасности. В следующей части мы подробнее рассмотрим поиск дефектов в программном обеспечении.

Не забудьте проверить свои баллы в индикаторе в правом нижнем углу материала!