alkimcoskun/yordam-kutuphane-otomasyonunda-coklu-html-enjeksiyonuCVE-2026-77818 — Yordam Kütüphane Otomasyon Sistemi — отражённая HTML-инъекция в трёх отдельных точках, перехват действия формы и кража учётных данных (CWE-79)
CVE-2026-77818 · CVSS 3.1 6.1 (Средний) · Управление кибербезопасности · Опубликовано 2026-09-04 · TR-26-1011
Статус: Уязвимости устранены в версии v22.2. Затронутым установкам необходимо обновиться до v22.2 или выше.
Yordam Kütüphane Otomasyon Sistemi — это коммерческое программное обеспечение для автоматизации библиотек и онлайн-каталога (OPAC), широко используемое в университетских, публичных и ведомственных библиотеках Турции. Установка выполняется on-premise; у каждого клиента работает отдельная копия в учреждении.
В версии v22.1 продукта обнаружены отражённые HTML-инъекции в трёх независимых точках. Все три не требуют аутентификации, все три срабатывают по одной ссылке.
| # | Точка | Корневая причина |
|---|---|---|
| 1 | Страница входа, параметр devam | Экранирование не применяется вовсе |
| 2 | Атрибут value скрытого поля формы | Повторное URL-декодирование после экранирования |
| 3 | Атрибут name скрытого поля формы | Экранирование применяется только к значению, но не к имени |
Поскольку все три находятся в одной версии одного продукта и относятся к одному классу уязвимостей, они объединены в одно уведомление и опубликованы под одним идентификатором CVE. Наиболее серьёзной по воздействию является точка № 1.
devamЭто самая критичная точка. Место инъекции — непосредственно сам HTML-тег формы аутентификации.
Параметр devam содержит адрес, на который пользователь вернётся после входа, и передаётся в hex-кодировке — значение 2f796f7264616d2f означает /yordam/. Приложение декодирует это значение из hex и записывает его в открывающий тег формы входа. Никакого экранирования между этим нет:
<form class='girisForm collapse show ikiAdimliGiris' method='post'
action='inc/islem.fm.inc.php'
data-url='<ДЕКОДИРОВАННЫЙ ИЗ HEX ПОЛЬЗОВАТЕЛЬСКИЙ ВВОД>'
autocomplete="off">
В выводе символы <, > и кавычки присутствуют в сыром виде. Единственное, что удерживает payload, — это обрамление атрибута data-url одинарными кавычками. При добавлении одинарной кавычки внутрь ввода она тоже завершается: атрибут закрывается, тег <form> закрывается, и написанный атакующим HTML заменяет форму аутентификации страницы.
Перехват action формы. Здесь не рисуется поддельная форма — собственная форма приложения оставляется пустой и закрывается, сразу после неё открывается новая <form> с теми же CSS-классами. Поскольку поля имени пользователя, пароля и проверочного кода на странице являются оригинальным HTML приложения, они остаются внутри этой новой формы. Пользователь видит настоящую форму, заполняет настоящую форму; введённые данные уходят на сервер атакующего. Визуально отличий нет.
Ключевой момент: инъекция происходит не на случайной странице, а на странице, где пользователь и так должен вводить свой пароль. При обычной отражённой инъекции атакующему нужно убедить жертву; здесь работу убеждения выполняет собственный интерфейс приложения.
value скрытого поля формы — двойное URL-декодированиеНа странице поиска значения GET-параметров записываются в скрытые поля формы. В этой точке экранирование применяется — но в неправильном порядке.
Одно и то же значение q используется в трёх разных контекстах в рамках одного ответа, и каждый имеет разную глубину декодирования:
| Контекст | Декодирование | Статус |
|---|---|---|
JS-строка в блоке <script> | 1 раз | Безопасно |
Основное поле поиска <input value="…"> | 1 раз | Безопасно |
Скрытые поля формы <input type='hidden' value="…"> | 2 раза | Уязвимо |
Последовательность операций следующая:
Ввод клиента : %2522
↓ разбор $_GET
Переменная PHP : %22
↓ входной фильтр → вредоносного содержимого не видит, кавычек нет
↓ htmlspecialchars → экранировать нечего, изменений нет
↓ urldecode → %22 декодируется
Выводится на страницу: " ← сырая кавычка, выход из атрибута
Входной фильтр и экранирование работают на первом уровне декодирования, тогда как вывод питается со второго уровня. При сравнении одинарно и двойно закодированных версий одного payload разница хорошо видна:
| Отправлено | Ответ | Вывод скрытого поля |
|---|---|---|
q=foo%22… (одинарное кодирование) | 302 Found | value="foo"…" — фильтр срабатывает |
q=foo%2522… (двойное кодирование) | 200 OK | value="foo"><…>" — сырой HTML |
Уязвимость не специфична для параметра q. Блок, генерирующий скрытые поля, перебирает все GET-параметры запроса; дополнительно проверено на tip и alan.
name скрытого поля формы — инъекция в имени параметраТот же блок для каждого GET-параметра генерирует следующую структуру:
<input type='hidden' name="<ИМЯ ПАРАМЕТРА>" value="<ЗНАЧЕНИЕ ПАРАМЕТРА>"/>
Экранирование применяется только к стороне value. К стороне name оно не применяется вовсе. В этой точке двойное кодирование также не требуется — достаточно одинарного, поскольку обходить экранирование не нужно: его просто нет.
Выдуманное имя параметра записывается напрямую в атрибут name в сыром виде, и из атрибута можно выйти. Поскольку имя параметра находится под контролем атакующего, оно не обязано быть параметром, известным приложению.
Точки № 2 и № 3 из этих трёх происходят из одного и того же блока кода, и этот блок повторяется в шести различных формах: dilForm, adetForm, siralaForm, tkForm, ekForm, tmForm. То есть в одном запросе инъекция происходит шесть раз.
Динамичность блока подтверждена сравнением вывода двух запросов:
Запрос A: ?p=1&dil=0&alan=&tip=basit&gorunum=liste&q=…
Вывод A: name="p" · name="alan" · name="tip" · name="gorunum" · name="q"
Запрос B: ?p=2&dil=0&devam=…
Вывод B: name="p" · name="devam"
Генерируемые поля берутся не из фиксированного списка, а напрямую выводятся из параметров запроса. Следовательно, содержимое, записываемое как в атрибут name, так и в атрибут value, находится под контролем атакующего.
Атакующему нужна лишь одна вещь — ссылка, которую откроет жертва. Ему не нужно входить в систему или иметь учётную запись.
action формы входа перенаправляется на атакующего. Подтверждено.Поскольку затронутая платформа хранит учётные данные и персональные данные библиотечных пользователей, через скомпрометированные учётные записи возможен доступ к записям пользователей.
Приложение использует CSP, и script-src с object-src основаны на nonce; то есть классический скриптовый XSS на этих страницах не работает. На первый взгляд это как будто снижает находку до уровня «только искажение контента».
Полная политика выглядит так:
Content-Security-Policy: script-src 'nonce-...'; object-src 'nonce-...'; frame-ancestors 'self'
form-action отсутствует. default-src также отсутствует — следовательно, нет и значения по умолчанию, к которому можно было бы обратиться для неопределённых директив. Итог: отправка формы POST на сервер атакующего никак не блокируется браузером.
Для кражи учётных данных не требуется выполнять JavaScript. Достаточно простого HTML, а CSP простой HTML не останавливает.
Основная
Связанные