Веб-приложения хранят данные и получают доступ к ним различными способами и формами в зависимости от их вариантов использования. Исторически реляционные базы данных были популярным выбором среди других баз данных для хранения больших объемов данных. Однако растет тенденция к использованию XML для хранения данных. При использовании XML данные хранятся во вложенной структуре в виде деревьев, а не столбцов и строк. У этого есть много недостатков, но его можно использовать для статических данных, таких как параметры конфигурации. Это связано с тем, что такие статические данные требуют меньше операций чтения / записи, что очень медленно в базах данных XML.
Что такое XPath?
Данные, хранящиеся в XML, можно запрашивать через XPath, который концептуально аналогичен SQL. Это также язык запросов, который используется для поиска определенных элементов в XML-документе. Нет разрешений уровня доступа, и можно ссылаться практически на любую часть XML-документа, в отличие от SQL, который допускает ограничения на базы данных, таблицы или столбцы.
Что такое внедрение XPath?
Проблемы, которые могут возникнуть при хранении данных с использованием XML, также похожи на проблемы, возникающие в SQL. Внедрение XPath - это тип атаки, при которой злонамеренный ввод может привести к несанкционированному доступу или раскрытию конфиденциальной информации, такой как структура и содержимое XML-документа. Это происходит, когда ввод пользователя используется при построении строки запроса. Большое количество методов, которые можно использовать в атаке с использованием SQL-инъекции, зависят от характеристик диалекта SQL, используемого целевой базой данных, тогда как внедрение XPath атаки могут быть гораздо более адаптируемыми и повсеместными.
Рассмотрим следующий сценарий.
Веб-сайт использует XML для хранения учетных данных пользователей и другой информации. XML-документ выглядит следующим образом:
<?xml version=”1.0" encoding="utf-8"?> <Employees> <Employee ID="1"> <Name>Sam</Name> <UserName>Johns</UserName> <Password>This is Secret</Password> </Employee> <Employee ID="2"> <Name>Peter</Name> <UserName>Pan</UserName> <Password>Ssssshh</Password> </Employee> </Employees>
Для входа на сайт пользователь вводит логин и пароль. Следовательно, запрос XPath, созданный для запроса данных, будет следующим:
"//Employee[UserName/text()='" & Request("UserName") & "' And Password/text()='" & Request("Password") & "']"
Если мы вставим вредоносную полезную нагрузку в качестве имени пользователя, сгенерированный запрос XPath будет следующим:
Username : test' or 1=1 or 'a'='a
Password : test
XPath Query:
//Employee[UserName/text()='test' or 1=1 or 'a'='a' And Password/text()='test']
This is equivalent to:
//Employee[(UserName/text()='test' or 1=1) or ('a'='a' And Password/text()='test')]
Таким образом, первая часть запроса выполняется, а вторая часть игнорируется. Пароль становится неактуальным, и злоумышленник получает несанкционированный доступ к сайту.
В дополнение к приведенному выше примеру можно также получить весь XML-документ с помощью B oolenization и XMLCrawling, что обычно называется слепое внедрение XPath . Сервер возвращает True, если злоумышленник успешно входит на сайт, и False в случае сбоя. Можно определить количество узлов, идентифицируя данные в XML-документе, используя различные подфункции XPath. Вот некоторые из подфункций:
Returns the number of nodes: count(//user/child::node() Checks if the password node has 6 characters string-length(//user[position()=1]/child::node()[position()=3])=6
Как это предотвратить?
- Пользовательский ввод необходимо очистить, например, quote (‘) можно заменить на « ». Проверка должна быть добавлена как на стороне клиента, так и на стороне сервера.
- Мы можем использовать параметризованные запросы (например, подготовленные операторы в SQL), в которых запросы предварительно скомпилированы, а пользовательский ввод передается как параметры, а не выражения.
"//users[LoginID/text()= $LoginID and passwd/text()= $password]"
- Должны использоваться правильные страницы ошибок, которые не раскрывают никакой информации во время ошибки, которая может принести пользу злоумышленнику.
Отказ от ответственности: информация, опубликованная в этой статье, предназначена только для образовательных целей. Содержание этой статьи основано на моих личных знаниях и опыте. Автор не несет ответственности за неправомерное использование информации.
