Как избежать внедрения XML

Я бы начал с рассмотрения того, что является допустимым вводом для вашего конкретного случая использования, а затем посмотрел бы на способы ограничить все остальное. Если у вас есть фиксированный диапазон значений ввода, я бы ограничил ввод только этими значениями. В противном случае, если ваш вариант использования требует, чтобы вы принимали во внимание будущее, вы, вероятно, захотите проверить модификаторы оси и разделители путей, такие как : и \.

Это зависит от того, что вы подразумеваете под «XML-инъекцией». Есть ли в документе конфиденциальные части, недоступные для просмотра пользователю? Или вы открываете его как доступное для записи состояние и позволяете пользователю обновлять части документа, и им должно быть разрешено обновлять только определенные части?

На базовом уровне, чтобы ответить на ваш вопрос, вам нужно как минимум искать операции оси xpath (например, //, /, ::) и подстановочные знаки (@*, *). Но я считаю, что использование пользовательского ввода для прямого построения xpath может быть не оптимальным решением. Может быть, если вы дадите нам больше контекста о том, чего вы пытаетесь достичь, мы сможем предложить альтернативные подходы?

Этот документ подробно описывает концепцию «слепого внедрения XPath».

В нем приведены конкретные примеры инъекций XPath и обсуждаются способы их предотвращения.

В разделе «Защита от внедрения XPath» сказано:

"Защита от внедрения XPath по сути аналогична защите от SQL инъекция. Приложение должно очищать вводимые пользователем данные. В частности, одинарные и двойные символы кавычек должны быть запрещены. Это можно сделать либо в приложении сам или в стороннем продукте (например, брандмауэре приложения). Тестирование приложения на восприимчивость к XPath Injection может быть легко выполнено с помощью ввод одинарной или двойной кавычки и проверка ответа. Если возникла ошибка произошла, то вполне вероятно, что внедрение XPath возможно."

Как уже говорили другие, следует также обратить внимание на использование осей и аббревиатуры //. Если используется XPath 2.0, то функция doc () не должна быть разрешена, поскольку она дает доступ к любому документу с известным URI (или именем файла).

Рекомендуется использовать API, который предварительно компилирует выражение XPath, но оставляет возможность работы с динамически определяемыми параметрами или переменными. Тогда ввод пользователя будет определять содержимое только этих параметров и никогда не будет рассматриваться как модификация уже скомпилированного выражения.

Переверните свою тактику с ног на голову.

Не пытайтесь отфильтровать недопустимые символы - политика «Считай, что все в порядке, если я не знаю, что это плохо»

Вместо этого используйте фильтр в допустимых символах - политика «С этим все в порядке, я предполагаю, что все остальное плохо».

С точки зрения безопасности используйте политику «Запрет по умолчанию» вместо «Принять по умолчанию».

Например ...

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

Один из способов - ограничиться A-Z, а затем убедиться, что ваша техника поиска учитывает акцент (например, i = ì = í = î = ï и так далее), хотя это падает на неевропейское именование.

... если вы запрашиваете число, ограничьтесь цифрами и отклоните все остальное.

Закрытие этой уязвимости - это всего лишь исправление. Так что применять политику «Запрет по умолчанию» сейчас слишком опасно. Я решил проверить ввод на наличие следующих символов [, ", ', *, =, {, \,., Пробел. Я думаю, что это может предотвратить большинство распространенных атак Всем спасибо за ответы!

Проверка входной строки будет полезна, возможно, используя что-то вроде регулярного выражения (что-то вроде этого ^ \ w +), основанное на том, что специальные символы не будут разрешены.