Перейти к содержанию

Software and Data integrity failures

Суть уязвимости сводится к отсутствию проверки целостности файлов, что позволяет загрузить вредоносный код под видом легитимного.

Уязвимости из этой категории включают в себя:

  • небезопасную сериализацию данных (Data integrity failures)
  • отсутствие проверки целостности загружаемых из вне различных плагинов, библиотек, модулей. Использование недоверенных контуров CI/CD, доступ к которым могут иметь посторонние лица (Software integrity failures)

К сведению

В OWASP 2017, данная категория называлась Insecure deseralization и заключалась лишь в небезопасной сереализации данных.

Data integrity failures (Insecure deseralization)

Для передачи данных между приложениями или его частями используется сериализация данных - кодирование данных в определенный формат (например base64).

Обратный процесс называется десериализацией и происходит на принимающей стороне.

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

Пример Data Integrity Failures: Подмена JWT токена

Популярным методом сериализации данных в веб приложениях является использование JWT токенов. В двух словах, JWT токены: сериализируют данные в формате JSON с использованием подписи.

Представляет из себя строку кодированную base64: 

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VybmFtZSI6Imd1ZXN0IiwiZXhwIjoxNjY1MDc2ODM2fQ.C8Z3gJ7wPgVLvEUonaieJWBJBYt5xOph2CpIhlxqdUw
Каждая часть строки, разделенная точкой, представляет из себя:

  1. Header - тип токена и алгоритм шифрования;

  2. Payload - данные в JSON формате;

  3. Signature - закодированные c помощью симетричного ключа значения Header и Payload ALGO_NAME(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

До недавнего времени, некоторые библиотеки реализующие JWT токены содержали в себе уязвимость которая заключалась в возможности записать вместо используемого алгоритма шифрования значение none, отбросив таким образом третью часть токена.

Следовательно, можно было закодировать нужный header и payload в base64 разделив их точкой и предъявить в таком виде токен принимающей стороне. Таким образом, можно было, например, выдать себя за другого пользователя.

Software integrity failures

Представим себе, что некоторые скрипты необходимые для работы web приложения загружаются из стороннего источника:

<script src="https://code.jquery.com/jquery-3.6.1.min.js"></script>
Так как не проводится никакая проверка целостности загружаемого скрипта, в случае злоумышленного изменения кода в репозитории code.jquery.com браузеры пользователей web приложения без всяческих сомнений будут его выполнять.

Современные браузеры позволяют выполнять такие загружамые скрипты лишь в случае соответствия хэша загружаемого файла заранее прописанному значению. Такой механизм защиты называется Subresource Integrity SRI.

Корректный вызов скрипта с проверкой целостности выглядит так: 

<script src="https://code.jquery.com/jquery-3.6.1.min.js" integrity="sha256-o88AwQnZB+VDvE9tvIXrMQaPlFFSUTR+nldQm1LuPXQ=" crossorigin="anonymous"></script>

Способы противодействия

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

Остальное на - owasp.org