Уязвимые приложения что такое
Программные уязвимости
Термин «уязвимость» часто упоминается в связи с компьютерной безопасностью, во множестве самых различных контекстов.
В общем случае, уязвимость ассоциируется с нарушением политики безопасности, вызванным неправильно заданным набором правил или ошибкой в обеспечивающей безопасность компьютера программе. Стоит отметить, что теоретически все компьютерные системы имеют уязвимости. Но то, насколько велик потенциальный ущерб от вирусной атаки, использующей уязвимость, позволяет подразделять уязвимости на активно используемые и не используемые вовсе.
Предпринималось много попыток четко определить термин «уязвимость» и разделить два его значения. MITRE, исследовательская группа, финансируемая федеральным правительством США, занимающаяся анализом и разрешением критических проблем с безопасностью, разработала следующие определения:
Согласно терминологии MITRE CVE:
[…] Уязвимость — это состояние вычислительной системы (или нескольких систем), которое позволяет:
Предпринималось много попыток четко определить термин «уязвимость» и разделить два его значения.
В MITRE считают, что атака, производимая вследствие слабой или неверно настроенной политики безопасности, лучше описывается термином «открытость» (exposure).
Открытость — это состояние вычислительной системы (или нескольких систем), которое не является уязвимостью, но:
Когда хакер пытается получить неавторизованный доступ к системе, он производит сбор информации (расследование) о своем объекте, собирает любые доступные данные и затем использует слабость политики безопасности («открытость») или какую-либо уязвимость. Существующие уязвимости и открытости являются точками, требующими особенно внимательной проверки при настройке системы безопасности против неавторизованного вторжения.
Поиск
Продукты для дома
Наши передовые решения помогают защитить то, что для вас ценно. Узнайте больше о нашей удостоенной наград защите.
Бесплатные утилиты
Наши бесплатные утилиты помогают обеспечить защиту ваших устройств на базе Windows, Mac и Android.
О компании
Узнайте больше о том, кто мы, как мы работаем и почему наша главная цель – сделать цифровой мир безопасным для всех.
Пробные версии
Попробуйте наши решения. Всего за несколько кликов вы можете скачать бесплатные пробные версии нашего продукта и проверить их в действии.
Связаться с нами
Наша главная цель – обеспечить вашу безопасность. Мы всегда готовы ответить на ваши вопросы и оказать техническую поддержку.
🕵 Что такое Топ-10 OWASP и какие уязвимости веб-приложений наиболее опасны?
B1bikua
OWASP важен для организаций, потому что его рекомендации высоко ценятся проверяющими безопасность корпоративных систем аудиторами. Рекомендации проекта по защите приложений необходимо включить в жизненный цикл разработки программного обеспечения и использовать для формирования политик безопасности.
Отчет об уязвимостях OWASP формируется на основе консенсуса мнений экспертов по безопасности со всего мира. Он ранжирует риски на основе частоты дефектов, серьезности уязвимостей и их потенциального воздействия. Это дает разработчикам и специалистам по безопасности понимание наиболее серьезных рисков и позволяет им минимизировать возможные последствия эксплуатации уязвимостей злоумышленниками.
В последнем отчете OWASP перечислены 10 основных уязвимостей:
1. Инъекции
Инъекционные атаки можно предотвратить путем проверки и/или очистки отправленных пользователем данных. В первом случае подозрительные данные отклоняются полностью, а во втором производится очистка только их подозрительной части. Кроме того, администратор базы данных может установить специальные элементы управления, чтобы минимизировать объем информации, которую может раскрыть атака с использованием SQL-инъекций.
2. Нарушенная аутентификация
Веб-сайты часто имеют проблемы с механизмами аутентификации. Прежде всего связаны они с некорректным управлением сеансами, что может быть использовано злоумышленниками для получения доступа к учетным записям пользователей и учетным данным для входа.
OWASP Top 10 содержит целый список подобных уязвимостей:
Количество уязвимостей можно уменьшить путем внедрения многофакторной аутентификации, а также внедрения ограничений, делающих невозможности автоматизированные атаки грубой силы (например, путем перебора). Не менее важно отсутствие спешки и наличие у разработчиков времени на проверку изменений перед запуском в продакшен, а также внедрение процедур тестирования кода на безопасность. Также необходимо внедрить жесткую парольную политику и использовать безопасные диспетчеры сеансов.
3. Раскрытие критически важных данных
Основная причина риска раскрытия критически важных данных связана с отсутствием шифрования или с использованием ненадежных методов генерации и управления ключами, слабых алгоритмов шифрования, ненадежных способов хранения паролей и т.д. Кроме того, разработчики веб-приложений часто хранят конфиденциальные данные, даже если в этом нет необходимости.
4. Внешние объекты XML (XXE)
Атаки XXE нацелены на веб-приложения, которые анализируют расширяемый язык разметки (XML). Они возникают, когда ввод содержащего ссылку на внешний объект кода XML обрабатывается синтаксическим анализатором со слабой конфигурацией. Анализаторы XML часто по умолчанию уязвимы для XXE, а значит разработчики должны удалить уязвимость вручную.
Атаки XXE можно избежать, если веб-приложения принимают менее сложные формы данных (например, веб-токены JavaScript Object Notation (JSON)), исправляя синтаксические анализаторы XML или отключая использование внешних сущностей. Защититься от атак XXE можно, развернув шлюзы безопасности интерфейса прикладного программирования (API), виртуальные исправления и брандмауэры веб-приложений (WAF).
5. Нарушенный контроль доступа
Риск нарушения контроля доступа можно снизить, развернув концепцию наименее привилегированного доступа, регулярно проверяя серверы и веб-сайты, применяя MFA и удаляя с серверов неактивных пользователей и ненужные службы. Можно также защитить элементы управления доступом, используя токены авторизации при входе пользователей в веб-приложение и делая их недействительными после выхода из системы. Другие рекомендации включают регистрацию и отчеты об ошибках доступа, а также использование ограничения скорости для минимизации причиняемого автоматическими атаками ущерба.
6. Неправильная конфигурация безопасности
Неправильная конфигурация безопасности может быть где угодно: в приложениях и веб-серверах, базах данных, сетевых службах, пользовательском коде, фреймворках, предустановленных виртуальных машинах и контейнерах.
Конфигурацию безопасности можно исправить, изменив настройки веб-сервера или CMS по умолчанию, удалив неиспользуемые функции кода и контролируя данные пользователей и видимость пользовательской информации. Разработчики также должны удалить ненужную документацию, функции, структуры и образцы, сегментировать архитектуру приложений и автоматизировать проверку эффективности конфигураций и настроек веб-среды.
7. Межсайтовый скриптинг (XSS)
Предотвратить эксплуатацию уязвимостей XSS можно с помощью брандмауэров веб-приложений (WAF), в то время как разработчики могут снизить вероятность XSS-атак, отделяя ненадежные данные от активных браузеров. Это включает в себя использование фреймворков, которые избегают XSS по своей конструкции, использование очистки и проверки данных, избегание ненадежных данных запроса протокола передачи гипертекста (HTTP) и развертывание политики безопасности контента (CSP).
8. Небезопасная десериализация
Рекомендации OWASP по защите в отношении небезопасной десериализации касаются супер-файлов cookie, которые содержат сериализованную информацию о пользователях. Если злоумышленники могут успешно десериализовать объект, они могут предоставит себе роль администратора, сериализовать данные и поставить под угрозу все веб-приложения.
9. Использование компонентов с известными уязвимостями
Этого можно избежать с помощью виртуального исправления, которое защищает устаревшие веб-сайты от эксплуатации уязвимостей с помощью брандмауэров, систем обнаружения вторжений (IDS) и WAF. Эксплуатацию уязвимостей также можно предотвратить, сохранив только реально необходимые компоненты и удалив все неиспользуемые или не обслуживаемые. Лучшим методом будет установка компонентов из надежных источников и постоянное их обновление.
10. Недостаточно подробные журналы и слабый мониторинг
Успешную хакерскую атаку или утечку данных удается обнаружить далеко не всегда. Часто злоумышленники не только получают несанкционированный доступ к информационным системам, но хозяйничают в них месяцами или годами, оставаясь невидимыми. Чтобы этого не произошло, необходимо регистрировать и отслеживать поведение веб-приложения, чтобы своевременно распознать подозрительную активность и либо предотвратить атаку, любо минимизировать ее последствия.
Уязвимости программ
Уязвимости программ — ошибки, допущенные программистами на этапе разработки программного обеспечения. Они позволяют злоумышленникам получить незаконный доступ к функциям программы или хранящимся в ней данным. Изъяны могут появиться на любом этапе жизненного цикла, от проектирования до выпуска готового продукта. В ряде случаев программисты нарочно оставляют лазейки для проведения отладки и настройки, которые также могут рассматриваться в качестве бекдоров или недекларированных возможностей.
В некоторых случаях возникновение уязвимостей обусловлено применением средств разработки различного происхождения, которые увеличивают риск появления в программном коде дефектов диверсионного типа.
Уязвимости появляются вследствие добавления в состав ПО сторонних компонентов или свободно распространяемого кода (open source). Чужой код часто используется «как есть» без тщательного анализа и тестирования на безопасность.
Не стоит исключать и наличие в команде программистов-инсайдеров, которые преднамеренно вносят в создаваемый продукт дополнительные недокументированные функции или элементы.
Классификация уязвимостей программ
Уязвимости возникают в результате ошибок, возникших на этапе проектирования или написания программного кода.
В зависимости от стадии появления этот вид угроз делится на уязвимости проектирования, реализации и конфигурации.
Согласно статистике, особенно часто уязвимости обнаруживают в популярных и распространенных продуктах — настольных и мобильных операционных системах, браузерах.
Риски использования уязвимых программ
Программы, в которых находят наибольшее число уязвимостей, установлены практически на всех компьютерах. Со стороны киберпреступников имеется прямая заинтересованность в поиске подобных изъянов и написании эксплойтов для них.
Поскольку с момента обнаружения уязвимости до публикации исправления (патча) проходит довольно много времени, существует изрядное количество возможностей заразить компьютерные системы через бреши в безопасности программного кода. При этом пользователю достаточно только один раз открыть, например, вредоносный PDF-файл с эксплойтом, после чего злоумышленники получат доступ к данным.
Заражение в последнем случае происходит по следующему алгоритму:
Исследования, проводимые различными компаниями («Лаборатория Касперского», Positive Technologies), показывают, что уязвимости есть практически в любом приложении, включая антивирусы. Поэтому вероятность установить программный продукт, содержащий изъяны разной степени критичности, весьма высока.
Чтобы минимизировать количество брешей в ПО, необходимо использовать SDL (Security Development Lifecycle, безопасный жизненный цикл разработки). Технология SDL используется для снижения числа багов в приложениях на всех этапах их создания и поддержки. Так, при проектировании программного обеспечения специалисты по ИБ и программисты моделируют киберугрозы с целью поиска уязвимых мест. В ходе программирования в процесс включаются автоматические средства, сразу же сообщающие о потенциальных изъянах. Разработчики стремятся значительно ограничить функции, доступные непроверенным пользователям, что способствует уменьшению поверхности атаки.
Чтобы минимизировать влияние уязвимостей и ущерб от них, необходимо выполнять некоторые правила:
Уязвимости в коде. Как отличить опасную брешь от незначительной ошибки?
Как обычно выглядит проверка кода приложений на уязвимости? Специалист по безопасности инициирует процедуру, код сканируется, в приложении обнаруживаются тысячи уязвимостей. Все — и безопасник, и разработчики — в шоке. Естественная реакция разработчика: «Да наверняка половина — это ложные срабатывания, а другая — некритичные уязвимости!»
Что касается ложных срабатываний, здесь все просто: можно взять и посмотреть непосредственно те места кода, где обнаружены уязвимости с подозрением на false positive. Действительно, какая-то их часть может оказаться ложными срабатываниями, (хотя явно не половина от общего числа).
А вот о том, что критично, а что нет, хотелось бы поговорить более предметно. Если вы понимаете, почему сейчас уже нельзя использовать SHA-1 и зачем экранировать «;», возможно, эта статья не откроет вам чего-то нового. Но если по итогам сканирования от найденных уязвимостей рябит в глазах, добро пожаловать под кат – расскажем, какие «дыры» чаще всего встречаются в мобильных и веб-приложениях, как они работают, как их исправить, а главное — как понять, что перед вами — опасная брешь или незначительная ошибка в коде.
Внедрение
Ну ооочень распространенный тип уязвимости. Куда только не внедряются: в запросы SQL, LDAP, XML, XPath, XSLT, Xquery… Все эти внедрения отличает использование недоверенных данных, благодаря которому злоумышленник получает доступ к информации или изменяет поведение приложения. Например, с помощью пользовательского ввода, который недостаточно валидируется.
Согласно международной классификации уязвимостей OWASP, атаки с использованием метода «Внедрение» занимают первое место по уровню критичности угроз безопасности веб-приложений. Рассмотрим наиболее типичные виды внедрений.
Внедрение в SQL-запрос. Недоверенные данные попадают в SQL-запрос к базе данных.
Если в запросе к базе данных не реализована корректная проверка подлинности вводимых данных, злоумышленник может испортить SQL-запрос:
Если злоумышленник может записывать данные в XML-документ, то он может изменять и его семантику. В таком случае самый безобидный сценарий позволит внедрить в документ лишние теги, в результате чего XML-парсер завершит работу с ошибкой. Но можно столкнуться и с инцидентом посерьезнее: например, с подменой аутентификационных данных в базе клиентов или ценой в базе товаров магазина. Внедрение в XML также может привести и к межсайтовому скриптингу (XSS) — внедрению вредоносного кода, который выполнится в браузере пользователя при открытии страницы.
Что можем посоветовать?
В примере ниже приложение создаёт и выполняет XQuery-выражение на основе параметров username и password из HTTP-запроса (недоверенный источник):
В случае корректных данных запрос вернёт информацию о пользователе с соответствующими именем и паролем:
Если злоумышленник задаст в качестве параметра строку, содержащую специальные символы (например, admin’ or 1=1 or »=’ ), семантика запроса изменится:
Полученный запрос вернёт данные обо всех пользователях.
Безопасный вариант (использует prepared statements ):
Внедрение в XSLT (язык преобразования XML-документов) возможно, если приложение использует данные из недоверенного источника при работе с XSL.
Приложения используют XSL для преобразования XML-документов. Стилевые XSL-файлы содержат функции, которые описывают трансформацию, и при неправильной реализации могут включать в себя уязвимости. В таком случае возрастает риск осуществления сценариев атак, при которых злоумышленник меняет структуру и содержимое стилевого XSL-файла, а значит, и соответствующего XML-файла. Что можем получить на выходе?
Во-первых, XSS-атаку: внедрение в страницу, которую выдает веб-система, вредоносного кода и взаимодействие этого кода с сервером злоумышленника. Во-вторых, получение хакером доступа к системным ресурсам. В-третьих, выполнение произвольного кода. И на десерт – XXE-атаку (XML eXternal Entity — внедрение внешней сущности в XML).
Внедрение в команды LDAP (Lightweight Directory Access Protocol — «легкорасширяемый протокол доступа к каталогам») может привести к утрате конфиденциальности данных или их модификации. В данном случае недоверенные данные попадают в LDAP-запрос.
Внедрение вредоносной команды интерпретатора. Недоверенные данные попадают в команду интерпретатора. Злоумышленник может подобрать такой ввод, чтобы команда выполнилась успешно и ему стали доступны дополнительные полномочия в приложении.
В примере ниже приложение выполняет скрипт, предназначенный для создания резервной копии базы данных. Приложение принимает тип резервной копии в качестве параметра и запускает скрипт с повышенными привилегиями:
Небезопасное включение внешнего файла в HTML. Уязвимости типа «file inclusion» возникают, когда пользователь вводит путь к подключаемому файлу. Дело в том, что современные скриптовые языки позволяют динамически подключать код из сторонних файлов, чтобы использовать его повторно. Этот механизм применяют для единого внешнего вида страниц или для разделения кода на небольшие модули. Однако таким включением может воспользоваться злоумышленник, подменив путь и подключив свой файл.
Рекомендуем специалистам в области корпоративной информационной безопасности составить «белый список» допустимых путей подключения файлов, чтобы сотрудники могли добавлять файлы только по сценариям из этого списка.
Закладки
Закладками именуют преднамеренно внесённые в код приложения части, с помощью которых при определённых условиях можно выполнить не заложенные в приложении действия. Рассмотрим самые распространенные виды закладок.
Специальные учётные записи. Если приложение сравнивает значение переменной пароля или логина с неизменным значением, стоит насторожиться: эта учётная запись может быть частью закладки. Посмотрим, как это происходит.
Разработчик приложения использует специальную учётную запись (возможно, с повышенными привилегиями) при отладке и оставляет соответствующие участки кода в финальной версии, сохранив за собой доступ к приложению. Злоумышленник может восстановить исходный код приложения, извлечь константные значения специальной учётной записи и получить доступ к приложению.
Хранить логины, пароли, ключи в исходном коде приложения категорически нельзя.
Скрытая функциональность (НДВ). Код скрытой функциональности запускается, когда срабатывает определенный триггер. В веб-приложениях триггером часто служит «невидимый» параметр запроса. Иногда дополнительно осуществляется проверка, с какого IP пришел запрос с триггером, чтобы активировать закладку мог только её автор. Такие проверки служат сигналом к возможным закладкам.
Недокументированная сетевая активность. К такому виду активности относятся: соединение со сторонними ресурсами в фоновом режиме, прослушивание недокументированных портов, передача информации по протоколами SMTP, HTTP, UDP, ICMP.
Если вы обнаружили в коде подозрительное соединение с адресом, который не входит в список заведомо безопасных, настоятельно рекомендуем вам его удалить.
Изменение параметров безопасности. Приложение содержит код, который изменяет значение переменной, хранящей успешность аутентификации. Распространённая ошибка — использование присваивания (=) вместо сравнения (==). В методах, связанных с аутентификацией, она особенно опасна, поскольку может быть частью бэкдора:
Временной триггер (timebomb). Закладка, которая срабатывает в определенный момент времени. Приложение сравнивает текущую дату с конкретными годом, месяцем и днём: 1 января 2021 года всех ждёт сюрприз:
А может быть и нет… На практике при поиске временных триггеров часто происходят ложные срабатывания. Например, если API времени используют и по назначению: запись в лог, вычисление времени выполнения, временные метки для ответов сервера на HTTP-запросы.
Но! Мы все же рекомендуем не закрывать глаза на все подобные срабатывания, так как знаем реальные примеры реализации таких уязвимостей.
Мёртвый код. Куски внедренного кода, которые ничего полезного не делают. Сам по себе мёртвый код не опасен, однако он может быть частью закладки, которую распределили по нескольким файлам. Или же триггер срабатывания закладки планируется внедрить позже. В любом случае, мёртвый код должен вызывать подозрения.
Отсутствие шифрования и использование слабых алгоритмов шифрования
Основные проблемы с шифрованием заключаются в том, что его либо не используют вовсе, либо применяют слабые алгоритмы, а ключи и соль слишком просты или хранятся небезопасно. Последствие у всех этих уязвимостей одно — конфиденциальные данные проще украсть.
В примере показана инициализация шифрования по устаревшему алгоритму DES:
Примеры уязвимых алгоритмов шифрования: RC2, RC4, DES. Безопасный вариант:
Согласно международной классификации OWASP, уязвимости типа «утечка конфиденциальных данных» занимают третье место по уровню критичности угроз безопасности веб-приложений.
Наши рекомендации разработчикам: обязательно используйте шифрование с учётом требований безопасности.
Применение незащищённого протокола HTTP вместо HTTPS чревато атакой типа Man in the middle.
Безопасный протокол HTTPS основан на HTTP, но также поддерживает шифрование через криптографические протоколы SSL/TLS. HTTPS шифрует все передаваемые по нему данные, в частности, страницы ввода логина и пароля или данные банковских карт пользователя, защищая их от несанкционированного доступа и изменения. В отличие от HTTP, который не защищает передаваемые данные. В результате злоумышленник может подменить информационный сайт по HTTP и заставить пользователя ввести данные на поддельной странице (фишинговая атака).
Ключ шифрования задан в исходном коде. В результате такие ключи доступны каждому разработчику приложения. Кроме того, после установки приложения удалить ключ из кода можно только с помощью обновления.
В целом, константные строки легко извлекаются из исполняемого файла с помощью программы для восстановления исходного кода (декомпилятора). Поэтому злоумышленнику необязательно иметь доступ к исходному коду, чтобы узнать значение используемого ключа. В нашей практике мы нередко сталкиваемся со случаями, когда в качестве значения ключа разработчики задают null или пустую строку, что просто недопустимо.
Наш совет: генерируйте ключи криптостойкими генераторами псевдослучайных чисел (ГПСЧ) и храните их с помощью специальных модулей.
Небезопасный алгоритм дополнения при шифровании. Если алгоритм шифрования RSA используется без OAEP-дополнения, зашифрованные данные становятся уязвимыми.
Алгоритм OAEP нужен, чтобы обработать сообщения перед использованием RSA. Сначала сообщение дополняется до фиксированной длины с помощью OAEP, затем шифруется с помощью RSA. Такая схема шифрования называется RSA-OAEP и является частью действующего стандарта.
Это пример инициализации RSA-шифрования без дополнения:
Недостаточный размер ключа шифрования. Если вы используете ключ малой длины, такое шифрование уязвимо для атаки методом перебора.
Криптоанализ не стоит на месте, постоянно возникают новые алгоритмы атак, компьютеры обретают бОльшие мощности. Параметры шифрования, которые раньше считались безопасными, устаревают и уже не рекомендуются к использованию. Так, RSA с длиной ключа 1024 бит перестал считаться безопасным в 2010–2015 годах.
Слабый алгоритм хеширования. По описанным в предыдущем пункте причинам хеш-функции MD2, MD5, SHA1 являются небезопасными. Чтобы найти коллизии для функций MD2 и MD5, существенных ресурсов не требуется.
Для SHA1 есть примеры двух разных файлов с одинаковыми хешами. Алгоритм взлома предложили сотрудники Google и Центра математики и информатики в Амстердаме.
Если пароли пользователей хранятся в виде хешей, но с использованием небезопасной хеш-функции, злоумышленник вполне может получить к ним доступ, реализовав следующий сценарий. Зная хеш пароля и используя уязвимость алгоритма хеширования, можно вычислить строку, для которой хеш такой же, как и для пароля. С помощью вычисленной строки злоумышленник проходит аутентификацию.
Хеш-функция для хранения паролей должна быть устойчивой к коллизиям и не слишком быстрой, чтобы нельзя было реализовать атаку методом перебора. Следует использовать безопасные алгоритмы PBKDF2, bcrypt, scrypt.
Несколько интересных цифр: с помощью PBKDF2 скорость перебора ключей сократили до 70 штук в секунду для Intel Core2 и около 1 тысячи на ПЛИС Virtex-4 FX60. Для сравнения, классические функции хеширования пароля LANMAN имеют скорость перебора около сотен миллионов вариантов в секунду.
Слабый алгоритм шифрования. Как и в случае алгоритмов хеширования, безопасность алгоритма шифрования определяется временем и ресурсами, которые придется потратить на его дешифровку. Уязвимыми алгоритмами считаются RC2, RC4, DES. Последний из-за небольшой длины ключа (56 бит) можно взломать методом полного перебора.
Слабый генератор псевдослучайных чисел (ГПСЧ) порождает предсказуемые последовательности. Хакер может обойти аутентификацию и захватить сессию пользователя.
Статистические ГПСЧ порождают предсказуемые последовательности, которые по статистическим характеристикам похожи на случайные. Их нельзя использовать для обеспечения безопасности.
Слабое зерно генератора псевдослучайных чисел. Использовать в качестве seed значение из недоверенного источника небезопасно, так как это порождает предсказуемую последовательность.
Работа многих криптографических алгоритмов основана на использовании устойчивого к криптоанализу ГПСЧ. Некоторые алгоритмы могут принимать в качестве дополнительного аргумента значение seed и для каждого значения этого параметра порождать предсказуемую последовательность. В таком случае безопасность системы основана на предположении о том, что значения seed будут непредсказуемы.
Соль задана в исходном коде. Вспомним, для чего нужна соль. Чтобы взломать пароль методом перебора, используют заранее составленные таблицы со значениями хеш-функций от популярных паролей. Соль — произвольная строка, которая подаётся на вход хеш-функции вместе с паролем, чтобы затруднить такую атаку.
Если соль хранится в исходном коде, возникают ровно те же самые проблемы, что и с паролями и ключами. Значение соли доступно разработчикам и легко могут получить злоумышленники, а убрать соль из финальной версии приложения можно только вместе с очередным обновлением приложения.
Манипуляции с логами
Различные ошибки в логах чреваты внедрением в приложения вредоносного кода. Чаще всего встречаются такие связанные с логированием уязвимости, как подделка файла лога и неструктурированное логирование.
Подделка файла лога происходит, когда приложение записывает недоверенные данные в журнал событий (лог). Хакер может подделать записи лога или внедрить в них вредоносный код.
Как правило, приложения записывают в лог историю транзакций для дальнейшей обработки, отладки или сбора статистики. Логи можно разбирать вручную или автоматически.
Если записывать в лог данные «как есть», злоумышленник может внедрить в лог фальшивые записи, нарушить структуру файла, вызвав сбои обработчика логов, или же внедрить вредоносный код, эксплуатирующий известные уязвимости в обработчике.
В этом примере web-приложение пытается считать целочисленное значение из параметра запроса. Если введённое значение не удалось конвертировать в целое число, приложение записывает в лог это значение вместе с сообщением об ошибке:
Злоумышленник может добавить в лог произвольную запись, например, строка twenty-one%0a%0aINFO:+User+logged+out%3dbadguy отразится в логе так:
Аналогичным образом в лог можно внедрить произвольные записи.
Безопасный вариант (использует NumberFormatException ):
Неструктурированное логирование, то есть вывод сообщений об ошибках в стандартные потоки out или err является небезопасным методом. Рекомендуется вместо него использовать структурированное логирование. Последнее позволяет генерировать лог с уровнями, метками времени, стандартным форматированием. Если в программе реализован механизм структурированного логирования, но при этом сообщения об ошибках выводятся в стандартные потоки, то в логе может не оказаться критически важной информации.
Выводить сообщения об ошибках в стандартные потоки допустимо только на ранних стадиях разработки.
Небезопасная работа с куки
Уязвимости, связанные со сбором пользовательских куки, весьма разнообразны.
Небезопасная работа с куки. Приложение включает в куки данные из недоверенного источника, что может привести к атакам типа «отравление кэша», XSS (межсайтовый скриптинг) и «расщепление ответа».
Если в приложение внедряется вредоносный код (межсайтовый скриптинг), то злоумышленник сможет изменять куки пользователя.
Содержимое второго ответа полностью контролируется злоумышленником, что приводит к отравлению кэша, XSS, вредоносным перенаправлениям и другим атакам.
Пример создания куки без флага httpOnly :
N.B. Согласно международной классификации OWASP, уязвимости типа «утечка конфиденциальных данных» занимают третье место по уровню критичности угроз безопасности веб-приложений.
В следующем примере приложение создаёт куки без флага secure :
Если приложение использует как HTTPS, так и HTTP, то при отсутствии флага secure куки, созданные в рамках HTTPS-запроса, будут передаваться в незашифрованном виде при последующих HTTP-запросах, что может привести к компрометации приложения. Это особенно опасно, если куки содержит ценные данные, в частности, идентификатор сессии.
Куки с неограниченным сроком действия. Если хранить ценные куки слишком долго, злоумышленник может успеть получить к ним доступ.
По умолчанию используются непостоянные (сессионные) куки, которые не сохраняются на диск и удаляются после закрытия браузера. Однако разработчик веб-приложения может указать срок хранения куки – в этом случае они будут записаны на диск и сохранены между перезапусками браузера и перезагрузками компьютера. Так мы даем злоумышленнику продолжительное время для разработки плана атаки.
Рекомендации разработчикам: убедитесь, что приложение не создаёт куки с длительным сроком хранения:
Указывайте разумный максимальный срок, следуя рекомендациям OWASP.
Утечка информации
Пожалуй, наиболее чувствительный для пользователей приложения вид уязвимостей.
Внешняя утечка информации через страницы ошибок. Приложение использует стандартные страницы ошибок, в которые может попасть информация о конфигурации системы.
Сообщения об ошибках и отладочная информация записываются в лог, выводятся в консоль или передаются пользователю. Из сообщений об ошибках злоумышленник может узнать об уязвимостях системы, что облегчит ему жизнь. Например, ошибка базы данных может говорить о незащищённости от SQL-инъекции. Информация о версии операционной системы, сервера приложений и конфигурации системы упростят хакеру задачу планирования атаки на приложение.
Внешняя утечка ценной информации. В данном случае речь идёт об утечке технической информации о приложении путем ее передачи по сети на другой компьютер. В целом, внешние утечки опаснее внутренних.
Внутренняя утечка ценной информации. Механизм эксплуатации схож с предыдущими двумя видами утечек, но в данном случае информация о системе записывается в лог или выводится на экран пользователя.
Утечка конфиденциальных данных. Ценные персональные данные пользователей попадают в приложение из разных источников: от самого пользователя, из различных баз данных, из сторонних хранилищ. Иногда эти данные не помечены как конфиденциальные либо оказываются ценными не сами по себе, а только в определённом контексте.
Это как раз тот самый случай, когда безопасность приложения и конфиденциальность персональных данных противоречат друг другу. Для обеспечения безопасности целесообразно подробно записывать информацию о действиях в системе, чтобы выявлять вредоносные действия. С точки зрения приватности данных, наоборот, при логировании конфиденциальной информации риск её утечки больше. В целом же обеспечение конфиденциальности персональных данных пользователей приложения является более приоритетной задачей.
Послесловие
Рассмотренные в статье виды уязвимостей охватывают бОльшую часть «универсальных» брешей в приложениях, написанных на разных языках программирования. Однако для некоторых языков встречаются свои, специфические уязвимости. Но это уже тема для отдельной статьи. А напоследок, напомним: при создании приложений не забывайте следовать вышеизложенным рекомендациям, внимательно читайте документацию и проверяйте приложения на уязвимости с помощью специализированного ПО.
Автор: Елизавета Харламова, руководитель отдела аналитики Solar appScreener