Это первый материал из цикла статей про OWASP Top 10 Project — проекта, который начинался как задумка энтузиастов, а стал самым авторитетным источником классификации векторов атак и уязвимостей веб приложений.

В этой статье мы кратко разберем все основные уязвимости из перечня OWASP Top 10, а также посмотрим, почему так важно знать о типовых уязвимостях, чтобы разрабатывать безопасные приложения.

Лет 10 назад какой-то очень наблюдательный человек сформулировал новую мантру – HTTP is new TCP. Конечно же, не в смысле, что человек решил помесить HTTP на транспортный уровень. Ни в коем случае! Речь только о том, что для современных коммуникаций протокол HTTP выполняет ту же функцию, что и TCP на своём уровне – подавляющее большинство современных приложений, в том числе мобильных, используют HTTP в качестве транспорта. А с появлением HTTP 2.0 эта ситуация забронзовела и в ближайшее время, судя по всему не изменится. Протокол стал стандартом доставки контента де факто, и HTTP уже нельзя рассматривать как веб-протокол.

Может показаться что HTTP существовал всегда, и это почти правда, если учесть, что первая официальная спецификация в RFC появилась в 1997 году, хотя сам протокол начали использовать существенно раньше.

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

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

Полёт осы

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

Так чем же конкретно занимается OWASP? В рамках своей компетенции у OWASP две крупные задачи: выпускать документацию и предоставлять инструменты, причем абсолютно бесплатно.
В этом цикле статей мы разберем, пожалуй, самый популярный материал OWASP TOP 10 Project. Это документ, представляющий перечень наиболее значимых и критических рисков веб-приложений. Решение о включении уязвимостей в этот список базируется на экспертном мнении специалистов по ИБ со всего мира (куда же без него), и по большому счету, понимание этих уязвимостей является первым шагом для того, чтобы изменить культуру разработки программного обеспечения.

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

Десять смертельных заклятий

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

• A1:2017 – Инъекции, они же “Внедрение кода”

Речь про все типы инъекций: SQL, NoSQL, LDAP – что угодно. Внедрение кода становится возможным, когда непроверенные данные отправляются интерпретатору как часть команды или запроса. Такой “злонамеренный” запрос благополучно выполняется и наносит свой ущерб. В 90% случаев, когда вы слышите, что был получен доступ к закрытой базе данных через веб, – это как раз наш A1.

• A2:2017 – Некорректная аутентификация

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

• A3:2017 – Раскрытие чувствительной информации

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

• A4:2017 – Внедрение внешних XML-сущностей (XXE)

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

• A5:2017 – Нарушенный контроль доступа

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

• A6:2017-Security Misconfiguration – Ошибки в конфигурировании

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

• A7:2017 – Межсайтовый скриптинг (XSS)

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

• A8:2017 – Небезопасная десериализация

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

• A9:2017 – Использование компонентов с известными уязвимостями

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

• A10:2017 – Недостаточное логирование и мониторинг

Тут всё просто – вы построили замечательную систему, однако забыли прикрутить инструменты мониторинга. Речь даже не о подключенной SIEM-системе, а просто о банальном логировании основных событий сервера. К сожалению, не редкость, когда взлом системы замечают через полгода после собственно взлома, причем узнают об этом не из логов, а от внешних наблюдателей.

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

Подготовил Сергей Полунин.

OWASP TOP 10 Project: введение