Усунення небезпеки XPath-впровадження (исходники), Різне, Програмування, статті

Введення


У міру появи і становлення нових технологій зростають також загрози цим технологіям. Приховані атаки SQL-впровадження є добре відомими і розпізнаваними формами атак впровадження коду, але є багато інших форм, які не настільки добре документовані або розпізнавані. Нової атакою впровадження коду є атака XPath-впровадження, використовує переваги вільної типізації (loose typing) і поблажливість синтаксичних аналізаторів XPath, що дозволяють зловмисникам використовувати в своїх інтересах некоректні XPath-запити в URL, формах або інших методах для отримання доступу до привілейованої інформації та зміни її.


В даній статті розповідається, як здійснюються XPath-атаки, а також надається приклад для середовищ Java ™ і XML. Крім того, обговорюється питання, як виявити ці загрози, що можна зробити для зменшення небезпеки і, нарешті, що робити у відповідь на підозріле проникнення.


Початок роботи


Предметом обговорення даної статті є специфічний тип атаки з впровадженням коду Blind XPath-впровадження. У даній статті будуть використані приклади для XPath 1.0, але вони працюють і для XPath 2.0. XPath 2.0, фактично, розширює коло можливих проблем, з якими ви можете зіткнутися.


З даною статтею надається також приклад Java-коду, створений для роботи з Java JDK 5.0. Хоча концепції і теми, обговорювані в даній статті, є крос-платформеними, якщо в додатку для отримання конкретного прикладу коду застосовується XPath, необхідно використовувати JDK 5.0.


Впровадження коду


Однією з найбільш типових атак чи погроз для Web-додатків є певного роду впровадження коду, яке Вікіпедія визначає як:


… технічний прийом впровадження (або “ін’єкції”) коду в комп’ютерну програму або систему шляхом використання нереалізованих і не перевіряються припущень, які система повинна робити при введенні даних. Метою впровадження коду зазвичай є обхід чи зміна оригінальної функціональності програми. Коли такий функціональністю є система захисту, наслідки можуть бути фатальними.

Уважне ознайомлення з такими Web-сайтами як Web Application Security Consortium або Security Focus допоможе отримати інформацію про різноманітні атаках, що використовують форму впровадження коду будь-якого роду – від JavaScript до SQL-впровадження та інших форм атак. Однією з нових загроз (вперше згадана Амітом Клейном (Amit Klein) у статті 2004 року) є атака прихованого XPath-впровадження. Вона виконується майже так само, як і атака прихованого SQL-впровадження, але, на відміну від неї, не багато людей знають про атаки XPath-впровадження або вживають проти них якихось заходів. Аналогічно атаці SQL-впровадження, найчастіше можна легко запобігти цю загрозу, якщо слідувати передового досвіду розробки захищених додатків.


Атака XPath


Зазвичай більшість Web-додатків для зберігання даних і добування інформації використовує реляційні бази. Якщо, припустимо, у вас є Web-сайт, що вимагає аутентифікації, ймовірно, існує таблиця users з унікальним ID, ім’ям входу в систему, паролем, і (можливо) інформацією будь-якого іншого роду, наприклад, роллю. SQL-запит для отримання інформації про користувача з таблиці users може виглядати так, як показано в лістингу 1.


Лістинг 1. SQL-запит для отримання інформації про користувача з таблиці users




Select * from users where loginID=”foo” and password=”bar”

В даному запиті користувач повинен ввести loginID і password. Якщо зломщик введе для поля loginID: ” or 1=1 і для поля password: ” or 1=1, Сформований запит буде виглядати приблизно так, як показано в лістингу 2.


Лістинг 2. Запит, сформований зломщиком





Select * from users where loginID = “” or 1=1 and password=” ” or 1=1

Цей запит завжди повертає позитивний результат, тому зломщик увійде в систему. XPath-впровадження працює приблизно таким же способом. Припустимо, що замість таблиці users у вас є XML-файл, містить інформацію про користувача і виглядає так, як показано в лістингу 3.


Лістинг 3. user.xml





<?xml version=”1.0″ encoding=”UTF-8″?>
<users>
<user>
<firstname>Ben</firstname>
<lastname>Elmore</lastname>
<loginID>abc</loginID>
<password>test123</password>
</user>
<user>
<firstname>Shlomy</firstname>
<lastname>Gantz</lastname>
<loginID>xyz</loginID>
<password>123test</password>
</user>
<user>
<firstname>Jeghis</firstname>
<lastname>Katz</lastname>
<loginID>mrj</loginID>
<password>jk2468</password>
</user>
<user>
<firstname>Darien</firstname>
<lastname>Heap</lastname>
<loginID>drano</loginID>
<password>2mne8s</password>
</user>
</users>

Для XPath аналогічне SQL-запитом вираз приведено в лістингу 4.


Лістинг 4. XPath-вираз, відповідне SQL-запиту





//users/user[loginID/text()=”abc” and password/text()=”test123″]

Виконуючи подібну атаку (обхід аутентифікації), можна поступити так, як в лістингу 5.


Лістинг 5. Обхід аутентифікації





//users/user[LoginID/text()=”” or 1=1 and password/text()=”” or 1=1]

Можливо, у вашому Java-додатку є метод (наприклад, doLogin), Що виконує аутентифікацію, знову ж, з використанням XML-документа (лістинг 3). Він може виглядати так, як показано в лістингу 6.


Лістинг 6. XPathInjection.java





import java.io.IOException;
import org.w3c.dom.*;
import org.xml.sax.SAXException;
import javax.xml.parsers.*;
import javax.xml.xpath.*;
public class XpathInjectionExample {

public boolean doLogin(String loginID, String password)
throws ParserConfigurationException, SAXException,IOException,
XPathExpressionException {
DocumentBuilderFactory domFactory = DocumentBuilderFactory.newInstance();
domFactory.setNamespaceAware(true);
DocumentBuilder builder = domFactory.newDocumentBuilder();
Document doc = builder.parse(“users.xml”);
XPathFactory factory = XPathFactory.newInstance();
XPath xpath = factory.newXPath();
XPathExpression expr = xpath.compile(“//users/user[loginID/text()=””+loginID+””
and password/text()=””+password+”” ]/firstname/text()”);
Object result = expr.evaluate(doc, XPathConstants.NODESET);
NodeList nodes = (NodeList) result; / / Вивести прізвище на консоль
for (int i = 0; i < nodes.getLength(); i++) {
System.out.println(nodes.item(i).getNodeValue());}

if (nodes.getLength() >= 1) {
return true;}
else
{return false;}
}
}


При передачі для лістингу 6 імені та пароля у вигляді loginID = “abc” і password = “test123”, клас поверне значення true (У нашому прикладі список прізвищ, що виводяться на консоль). Якщо, наприклад, ви передасте значення ” or 1=1 or “”=”, Вам завжди повернеться значення true, Оскільки XPath закінчить пошук рядка, показаної в лістингу 7.


Лістинг 7. Рядок





//users/user[loginID/text()=”” or 1=1 or “”=”” and password/text()=”” or 1=1 or “”=””]

Цей рядок логічно призведе до запиту, завжди повертає true, тобто зломщик отримає постійний доступ.


Ще однією, навіть більш вірогідною і, можливо, більш неприємною атакою в XPath є здатність зломщиків використовувати XPath для управління XML-документами в додатку “на льоту”.


Витяг структури XML-документа


Запит, що використовувався для обходу аутентифікації, може також використовуватися для добування інформації про XML-документі. Припустимо, зломщик робить припущення про те, що ім’я першого підлеглого вузла в XML-документі одно loginID, і хоче упевнитися в цьому. Він вводить рядок, наведену в лістингу 8.


Лістинг 8. Рядок, що вводиться зломщиком





abc” or name(//users/LoginID[1]) = “LoginID” or “a”=”b

Замість 1 = 1 з лістингу 7 вираження в лістингу 8 перевіряє, чи дорівнює ім’я першого підлеглого вузла loginID. Сформований запит приведений в лістингу 9.


Лістинг 9. Запит





String(//users[LoginID/text()=”abc” or name(//users/LoginID[1]) =
“LoginID” or “a=b” and password/text()=””])

Шляхом проб і помилок зломщик може перевірити різні дочірні вузли XML-документа і зібрати інформацію, спостерігаючи за результатами XPath-вирази при успішній аутентифікації. Потім, в принципі, зломщик може написати простий сценарій, що передає різні XPath-впровадження та видобуває XML-документ із системи, як згадувалося в статті Клейна.


Запобігання XPath-впровадження


Оскільки XPath-впровадження в чому аналогічно SQL-впровадження, від нього можна захиститися методами, схожими на ті, які використовуються для запобігання атак SQL-впровадження. Не дивно, що більшість цих запобіжних методів можна і треба використовувати для запобігання інших типових атак з впровадженням коду.


Перевірка коректності


Незалежно від програми, середовища або мови необхідно слідувати наступним практичним правилам:



Параметризація


На відміну від більшості додатків баз даних, XPath не підтримує концепцію параметризації запитів, але ви можете зімітувати цю концепцію, використовуючи інші API, наприклад XQuery. Замість формування виразів у вигляді рядків, переданих потім у синтаксичний аналізатор XPath для динамічного виконання під час виконання (як показано в лістингу 10), можна параметризованих запит, створивши зовнішній файл, що зберігає його (див. лістинг 11).


Лістинг 10. Рядки, що передаються в синтаксичний аналізатор XPath





“//users/user[LoginID/text()=” ” + loginID+ ” ” and password/text()=”
“+ password +” “]”

У лістингу 11 запит параметризованих шляхом створення зовнішнього файлу, що зберігає запит.


Лістинг 11. dologin.xq





declare variable $loginID as xs:string external;
declare variable $password as xs:string external;//users/user[@loginID=
$loginID and @password=$password]

Потім можна виконати аналогічні лістингу 11 дії шляхом невеликий модифікації (лістинг 12).


Лістинг 12. XQuery-сніпет





Document doc = new Builder().build(“users.xml”);
XQuery xquery = new XQueryFactory().createXQuery(new File(”
dologin.xq”));
Map vars = new HashMap();
vars.put(“loginid”, “abc”);
vars.put(“password”, “test123”);
Nodes results = xquery.execute(doc, null, vars).toNodes();
for (int i=0; i < results.size(); i++) {
System.out.println(results.get(i).toXML());
}

Це обереже важливі явно задані змінні $ loginID і $ password від обробки як обчислюваних виразів під час виконання. Тобто логіка програми і дані розділені; на жаль, параметризація запиту не входить в XPath, але вона вільно доступна в синтаксичних аналізаторах з відкритим вихідним кодом, наприклад, SAXON. Деякі інші синтаксичні аналізатори реалізують такого роду функціональність і можуть бути хорошим способом захисту проти XPath-впровадження.


Перевірка даних на Web-сервері


Для захисту проти XPath-впровадження та інших форм впровадження коду необхідно перевіряти всі дані, передані від Web-сервера до служб системи зберігання даних. Наприклад, з Apache можна використовувати фільтр Mod_Security (наприклад, SecFilterSelective THE_REQUEST “(“/”)”), Щоб знайти в рядках одиночні та подвійні лапки і заборонити їх. Такий же підхід можна застосувати для фільтрації і заборони інших форм спеціальних символів (наприклад, (“* ^”; &> << /)), які можуть бути використані для різних атак з впровадженням коду. Цей підхід може бути дуже хороший для деяких додатків, які, можливо, використовують засновані на REST або SOAP XML-сервіси, але в інших випадках він може бути не можливий. Як завжди найкращим підходом є розумне проектування, починаючи з початкового дизайну і до реалізації програми.


А що, якщо?


У своїй більшості організації дійсно замислюються про виявлення загроз і їх запобігання, але справа рідко доходить до реалізації. Тільки тоді, коли їх системи зламуються, вони запрошують кваліфікованих фахівців для спільного планування заходів по захисту. Необхідно завжди припускати найгірший сценарій і відповідно планувати роботу.


Все в значній мірі залежить від конкретної організації і типу зламуємо системи, але зазвичай найкраще, що можна зробити – перевести систему в режим автономної роботи (offline) і почекати, коли професійний інженер з безпеки проаналізує ситуацію. Іноді люди відразу ж відключають систему і відновлюють дискові накопичувачі з образів, але це приховує сліди злочину, так само як і можливу інформацію про інші порушення, виконаних зломщиком в даній системі. По можливості завжди намагайтеся зберегти стан системи для аналізу експертом.


Резюме


Більшість додатків, що використовують XML, не буде вразливе для атак з XPath-впровадженням, а XML-додатки не повинні вважатися небезпечними тільки через виявлення якоїсь конкретної уразливості. У той же час, широке поширення нових платформ (наприклад, Ajax, RIA-платформи FLEX або Open Laszlo), а також інтеграція XML-сервісів від таких організацій як Google (які інтенсивно використовують XML для всього – від обміну даними з серверами зберігання даних до персистенції), змушує розробників враховувати загрози та ризики, створювані подібними методами роботи.


На щастя, в той час як дані конкретні загрози є новими, проблеми і принципи їх вирішення – ні. Дотримання передового досвіду допоможе захиститися не тільки від атак з XPath-впровадженням, а й від інших форм атак.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*