22 распространенные уязвимости веб-приложений, о которых нужно знать

Опубликовано: 2021-10-14

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

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

  1. Поврежденный контроль доступа

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

  1. Поврежденная аутентификация

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

  1. Вставка возврата каретки и перевода строки (CRLF)

    Возврат каретки действует как команда, обозначающая начало строки кода, обычно обозначаемая как /r. С другой стороны, перевод строки — это команда, обозначающая конец строки кода, обычно обозначаемая как /n. Как и некоторые другие программы, каждая операционная система использует различные комбинации возврата каретки и перевода строки. Когда злоумышленники участвуют в инъекциях CRLF, введенный код изменяет способ, которым веб-приложение реагирует на команды. Это может быть использовано либо для раскрытия конфиденциальных данных, либо для выполнения кода.

  1. Преобразование шифра небезопасно

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

  1. Компоненты с явными уязвимостями

    Работа каждого веб-приложения зависит от других компонентов. Например, если вы работаете с приложением на неисправленном веб-сервере или сервере приложений, сервер является частью с очевидными уязвимостями. Список Common Vulnerabilities and Exposures (CVE) включает все известные уязвимости системы безопасности. Поскольку злоумышленники знают этот список, они часто ищут компоненты без соответствующих исправлений безопасности. В тот момент, когда они могут проникнуть в один компонент веб-приложения, они также могут получить доступ к данным приложения.

  1. Политика совместного использования ресурсов между источниками (CORS)

    Все веб-приложения используют URL-адрес в качестве средства подключения браузера пользователя к его серверу. Единая политика происхождения — это одна общая защита. В соответствии с этим сервер будет отвечать только на URL-адрес с тем же протоколом, схемой пути и доменным именем верхнего уровня. Это означает, что вы можете получить доступ к http://organization.com/page1 и http://organization.com/page2, потому что они оба имеют следующее:

    • Протокол: HTTP
    • Домен: Company.com
    • Схема пути: /page#

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

    Политика CORS предоставляет браузеру разрешение на просмотр этих взаимосвязанных ресурсов, устанавливая ряд разрешенных заголовков HTTP, которые считаются «доверенными». Например, приложению может потребоваться получить данные из двух баз данных на разных веб-серверах. Составление определенного «разрешенного» списка становится чрезмерной работой, поскольку вы включаете дополнительные серверы. Поскольку оба сервера «разделяют» приложение, компания пишет политику CORS, которая позволяет браузерам подключаться к обоим. Однако если политика CORS не определена должным образом, она может позволить серверам предоставлять доступ по запросу злоумышленника.

  1. Управление учетными данными

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

  1. Подделка межсайтовых запросов (CSRF)

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

  1. Межсайтовый скриптинг (XXS)

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

  1. Индексация каталога

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

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

  1. Обход каталога

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

  1. Инкапсуляция

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

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

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

  1. Небезопасные прямые ссылки на объекты (IDOR)

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

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

    Другие распространенные уязвимости веб-приложений , о которых вы должны знать:

  1. Разделение HTTP-ответа

    Это своего рода атака с внедрением CRLF. HTTP — это процесс, посредством которого браузеры отправляют запросы, а серверы возвращают ответы. В этой уязвимости веб-приложения злоумышленники используют нотации CR и LR, чтобы манипулировать тем, как браузеры и серверы взаимодействуют друг с другом, что доставляет запрос, но сообщает серверу «разделить» ответ на различные части. Разделение ответа на две разные части позволяет злоумышленнику получить контроль над информацией, которую сервер предоставляет в ответ на другую часть запроса. Когда такие запрошенные данные представляют собой данные идентификатора пользователя или конфиденциальную информацию, злоумышленник успешно выполнил атаку.

  1. Дефект впрыска

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

  1. Небезопасная уязвимость дайджеста сообщений

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

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

  1. Недостаточная защита транспортного уровня

    Безопасность транспортного уровня (TLS) относится к процессу, с помощью которого компьютерные приложения могут безопасно «общаться» друг с другом в Интернете. Некоторые приложения используют TLS только в процессе аутентификации, что делает данные и информацию о сеансе идентификации уязвимыми, когда человек использует приложение.

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

  1. Удаленное выполнение кода (RCE)

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

  1. Удаленное включение файлов (RFI)

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

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

  1. Неправильная настройка безопасности

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

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

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

  1. Непроверенная автоматическая активация библиотеки

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

    • Отсутствие документально подтвержденного права собственности повышает риск добавления вредоносного кода.
    • Заброшенные проекты, которые больше не обновляются

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

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