Инъекции в XPath-запросы

• XML-хранилища пользователей, легаси SOAP-сервисы, конфигурации, системы документооборота, старые SSO
• XPath-инъекции массово обсуждались в 2000-х (OWASP, WASC), когда XML считался «будущим» веб-сервисов
• Сегодня их находят не на стартапах, а в корпоративном легаси: ERP-шные шлюзы, внутренние порталы, интеграции «на SOAP»

Авторизация по каталогу: //user[login/text()='«+login+"' and pass/text()='"+pass+"']. Подстановка ' or '1'='1 делает условие всегда истинным — и каталог возвращает первую запись, часто администратора.

Blind-сценарий: если различаются ответы «пользователь найден / не найден», можно посимвольно восстановить значения из XML — как в blind SQLi, только с XPath-функциями (substring, contains).

В крупной компании десятилетиями работала внутренняя система на SOAP: поиск сотрудников по XML-каталогу. Форма ввода фамилии «просто собирала» XPath-запрос. На внутренней сети это никого не волновало, пока систему не вынесли на портал для подрядчиков.

В ходе аудита нашли, что подстановка специальных символов меняет выборку — можно было получить карточки сотрудников, которых не должен видеть внешний пользователь. Данные не «утекли в интернет», но доверие к системе и сроки на её замену резко изменились: классическая проблема «старого, но живого» сервиса.

Чтение всего каталога, обход ролей, кража атрибутов. В связке с XML-десериализацией сценарии доходят до выполнения кода.

• Параметризованные XPath-запросы, экранирование кавычек, строгая валидация входа
• Не хранить пароли в XML «открытым» текстом; использовать современные identity-провайдеры
• Минимальные права хранилища XML, отладочные XPath-выражения — только вне прода
• Для легаси-SOAP — как минимум изоляция в сети и мониторинг: такие сервисы часто «забыты» за брандмауэром, но торчат наружу