Поскольку все три находятся в одной версии одного продукта и относятся к одному классу уязвимостей, они объединены в одно уведомление и опубликованы под одним идентификатором CVE. Наиболее серьёзной по воздействию является точка № 1.

1. Страница входа — параметр devam

Это самая критичная точка. Место инъекции — непосредственно сам HTML-тег формы аутентификации.

Параметр devam содержит адрес, на который пользователь вернётся после входа, и передаётся в hex-кодировке — значение 2f796f7264616d2f означает /yordam/. Приложение декодирует это значение из hex и записывает его в открывающий тег формы входа. Никакого экранирования между этим нет:

В выводе символы <, > и кавычки присутствуют в сыром виде. Единственное, что удерживает payload, — это обрамление атрибута data-url одинарными кавычками. При добавлении одинарной кавычки внутрь ввода она тоже завершается: атрибут закрывается, тег <form> закрывается, и написанный атакующим HTML заменяет форму аутентификации страницы.

Перехват action формы. Здесь не рисуется поддельная форма — собственная форма приложения оставляется пустой и закрывается, сразу после неё открывается новая <form> с теми же CSS-классами. Поскольку поля имени пользователя, пароля и проверочного кода на странице являются оригинальным HTML приложения, они остаются внутри этой новой формы. Пользователь видит настоящую форму, заполняет настоящую форму; введённые данные уходят на сервер атакующего. Визуально отличий нет.

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

2. Атрибут value скрытого поля формы — двойное URL-декодирование

На странице поиска значения GET-параметров записываются в скрытые поля формы. В этой точке экранирование применяется — но в неправильном порядке.

Одно и то же значение q используется в трёх разных контекстах в рамках одного ответа, и каждый имеет разную глубину декодирования:

Последовательность операций следующая:

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

Уязвимость не специфична для параметра q. Блок, генерирующий скрытые поля, перебирает все GET-параметры запроса; дополнительно проверено на tip и alan.

3. Атрибут name скрытого поля формы — инъекция в имени параметра

Тот же блок для каждого GET-параметра генерирует следующую структуру:

Экранирование применяется только к стороне value. К стороне name оно не применяется вовсе. В этой точке двойное кодирование также не требуется — достаточно одинарного, поскольку обходить экранирование не нужно: его просто нет.

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

Точки № 2 и № 3 из этих трёх происходят из одного и того же блока кода, и этот блок повторяется в шести различных формах: dilForm, adetForm, siralaForm, tkForm, ekForm, tmForm. То есть в одном запросе инъекция происходит шесть раз.

Динамичность блока подтверждена сравнением вывода двух запросов:

Генерируемые поля берутся не из фиксированного списка, а напрямую выводятся из параметров запроса. Следовательно, содержимое, записываемое как в атрибут name, так и в атрибут value, находится под контролем атакующего.

Воздействие

Атакующему нужна лишь одна вещь — ссылка, которую откроет жертва. Ему не нужно входить в систему или иметь учётную запись.

• Кража учётных данных. Через точку № 1 цель action формы входа перенаправляется на атакующего. Подтверждено.
• Поддельный контент от имени учреждения. В адресной строке остаются собственный домен учреждения и действующий TLS-сертификат. Можно разместить поддельное объявление, поддельную кампанию, поддельный информационный текст.
• Искажение контента и перенаправление. Внешний вид страницы может быть изменён, пользователь может быть перенаправлен на внешний адрес.

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

Почему существующие защиты не останавливают

Приложение использует CSP, и script-src с object-src основаны на nonce; то есть классический скриптовый XSS на этих страницах не работает. На первый взгляд это как будто снижает находку до уровня «только искажение контента».

Полная политика выглядит так:

form-action отсутствует. default-src также отсутствует — следовательно, нет и значения по умолчанию, к которому можно было бы обратиться для неопределённых директив. Итог: отправка формы POST на сервер атакующего никак не блокируется браузером.

Для кражи учётных данных не требуется выполнять JavaScript. Достаточно простого HTML, а CSP простой HTML не останавливает.

Связанные слабости

Основная

• CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Связанные

• CWE-116 — Improper Encoding or Escaping of Output
• CWE-174 — Double Decoding of the Same Data
• CWE-172 — Encoding Error
• CWE-451 — User Interface (UI) Misrepresentation of Critical Information

В записи CVE основная слабость классифицирована как CWE-79. На уровне корневой причины CWE-116 более описательна: причина всех трёх точек — либо полное отсутствие экранирования вывода, либо его применение в неправильном порядке.

Следует отметить, что в этом продукте скрипты не выполняются — собственная отправляемая продуктом политика script-src на основе nonce этого не допускает, а значение nonce невозможно прочитать из другого источника (cross-origin). Реализованное воздействие — это не выполнение скриптов, а HTML-инъекция и перехват формы входа. По этой причине также выполнено сопоставление с CAPEC-148 (Content Spoofing).

CWE-174 применима особенно к точке № 2 — повторное декодирование тех же данных после экранирования.

Серьёзность

Средний — CVSS 3.1 Базовый балл 6.1 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)

Атакующему не нужны никакие привилегии; поскольку жертва должна открыть подготовленную ссылку, взаимодействие с пользователем — Требуется. Scope принят как Changed, поскольку инъецированный контент обрабатывается в контексте безопасности браузера.

Все три точки соответствуют одному и тому же баллу. Наиболее серьёзной по воздействию является точка № 1: поскольку инъекция происходит непосредственно в самом теге формы аутентификации, возможны перехват цели action формы и кража учётных данных.

Затронутые версии

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

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

Затронутый компонент

Точки № 2 и № 3 происходят из одного и того же блока генерации скрытых полей; блок повторяется в формах dilForm, adetForm, siralaForm, tkForm, ekForm и tmForm.

Решение

Уязвимости устранены производителем. Приложение необходимо обновить до версии v22.2 или выше.

Запись CVE

Производитель: Yordam Bilgi Teknolojileri Danışmanlık Eğitim ve Elektronik Sistemler Sanayi ve Ticaret A.Ş.

Обнаруживший

Alkım Coşkun – Netlore Security

График раскрытия