Как избежать инжекции XML

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

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

Переверните свою тактику вверх дном.

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

Вместо этого просочитесь приемлемые символы - политика "Этого материала в порядке, я предположу, что все остальное плохо".

В условиях безопасности примите политику "Значения по умолчанию, Отклоняют" вместо "Значения по умолчанию, Принимают".

Например...

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

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

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

Этот документ описывает подробно понятие "Слепой Инжекции XPath".

Это обеспечивает конкретные примеры инжекций XPath и обсуждает способы предотвратить такой.

В разделе "Defending against XPath Injection" это сказано:

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

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

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

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

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

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