Форум PHP

Подскажите, пожалуйста, что такое XPath injection? В чем ее особенности и отличия от SQL injection и есть ли разници в способах защиты. Или BlindSQL injection?

Что, никто так не ответит?

Может быть заинтересует
http://www.styler.ru/styler/classes-web-attack/

Ага, именно оттуда и я прочитала о XPath injection :)

Атаками вида "???-injection" называют действия пользователя, основанные на том факте, что в скриптах на сайте формируется программа (команда, опрератор, запрос) на языке некоторой исполняющей системы ??? (SQL, JS, PHP, XPath, unix shell и т.п.) причем формируется с использованием пользовательских строк входных параметров скрипта. Причем формируется с нарушением правил формирования констант на этом языке.
Для защиты нужно лишь знать, как правильно записываются константы на выбранном языке, и корректно преобразовывать к их форматам входные параметры скрипта.

То есть, никаких особых способов защиты от них не нужно? Если скрипт хорошо защищен от SQL injection - можно считать, что и от других injections тоже? Или все-таки нет? Просто по SQL injection много материала в инете, а вот по другим видам - не особо...

И еще заодно вопрос Trianon - с вашей помощью я вроде бы защитила скрипт, по крайней мере ни Acunetix, ни XSpider уже уязвимостей не находят, хотя раньше их было СТОЛЬКО!!!! Почти не находят :(

Дело в том, что Acunetix упрямо твердит This script is possibly vulnerable to Cross Site Scripting (XSS) attacks
и в качестве уязвимого параметра приводит переменную auth (используется в куках). Если вы помните в файле login.php устанавливается
setcookie("auth",intval($ff[id])); а затем в файле проверки
$auth = intval($_COOKIE['auth']);, после чего в скрипте используется where id='$auth'

Мне казалось, что intval достаточно для фильтрации auth, тем более, что уязвимости SQL injection сканнер уже не показывает. А вот для XSS пишет -

The Cookie variable auth has been set to </textarea><ScRiPt%20%0a%0d>alert(513613717)%3B</ScRiPt>.

Вот мне и непонятно - ка auth может быть set to </textarea><ScRiPt%20%0a%0d>alert(513613717)%3B</ScRiPt> если auth отфильтрована как intval?

Раньше сканнер показывал SQL уязвимость и писал
The Cookie variable auth has been set to \" или, например auth has been set to %00'.
Сейчас этого не показывет, то есть фильтрация происходит.
Почему же тогда XSS возможно? Ведь должен пропускать только intval значения?

может быть всё же эта переменная применяется еще где-то кроме intval() ?
Кроме того, Вы гасите значение этой переменной с помощью unset после применения в setcookie() как я Вам показал?


В языке MySQL - одни правила формирования текстовых констант, а в MS Access SQL - совсем другие.
Так что даже в пределах работы с СУБД обработка текста может отличаться. Смотрите правила формирования констант в XPath.

Не исключено, что фраза "правила формирования констант" звучит как китайская грамота.
Можно сказать и на пальцах.
Ход Вашей мысли должен быть таким.
Вася мы писать умеем. Константа выглядит как "Вася".
А как тогда будет записана сама строка "Вася" ?
Думаем. Читаем мануал. Приходим к выводу. "\"Вася\"".
Окей. А как будет записано "\"Вася\""?
Опять думаем. Читаем мануал. Приходим к выводу. "\\\"Вася\\\"\".
С этим разобрались.
А если две-три строки текста?
А если попадутся символы, которые в обычной кодовой странице не отображаются?
и т.д.
Когда на все эти вопросы мы получим четкий ответ - пишем обработку.

К слову сказать, те же строки в MS access SQL будут выглядет как
"Вася"
"""Вася"""
"\""""Вася""""\"

перепроверила еще раз все, что связано с auth. Она устанавлвается только в login и затем проверяется в member, дальше везде идет только как where $id=$'auth'; И unset я устанавливаю. А все равно XSS :(. Буду дальше разбираться... А за наводку по правилам формирования констант - спасибо. Нашла информацию - разбираюсь.

По первых везде надо использовать кавычки..а именно в MYSQL запросах...

Вот код записывающий в мускл

if(!get_magic_quotes_gpc())             {                 $_POST['name']         = mysql_escape_string($_POST['name']);                  $_POST['pass']         = mysql_escape_string($_POST['pass']);             }             if(empty($_POST['name']) || empty($_POST['pass']))             exit("Заполните обязательные поля");             $_POST['pass'] = md5($_POST['pass']);             $date = date('d.m.Y');             $query = "INSERT INTO `users` VALUES(NULL, '".$_POST['name']."', '".$_POST['pass']."', '".$date."'";             if(mysql_query($query))             {                 echo "Регистрация успешно завершена";             }             else             {                 exit("Ошибка - ".mysql_error());             }

Вывести без XSS достаточно легко..воспользовавшись функцией htmlspecialchars($string);

$_POST['pass']         = mysql_escape_string($_POST['pass']);  ...                  $_POST['pass'] = md5($_POST['pass']);

Как Вы думаете, сможет функция md5 правильно вычислить хеш, если Вы в строку насуете экранирующих слэшей?

Возможно я чего-то не понимаю, но XSS уязвимость у меня показывает для переменной auth, а $auth - это должно быть число, я фильтрую через intval, зачем мне еще htmlspecialchars? Но XSS все равно показывает. Черт знает что - замучилась уже.

Ну, если бы вообще фильтрация не проходила - чего-то я не так сделала - так показывала бы и MySQL уязвимость, как раньше, пока вообще фильтрации не было. Но теперь-то MySQL injection нет - значит данные фильтруются?

Получается идет фильтрация, но она недостаточная - MySQL injection фильтрует, а XSS нет.
А как она может быть недостаточной, если это intval? Мне казалось, что там, где число, все как раз должно быть легко и ясно - inval и все, больше ничего не нужно

И вот еще - mysql_real_escape_string - она же не фильтрует % и _ - так что их по-любому нужно дополнительно фильтровать?

>И вот еще - mysql_real_escape_string - она же не фильтрует % и _ - так что их по-любому нужно дополнительно фильтровать?

Эти символы не несут никакой специальной нагрузки, кроме как в шаблонах операции LIKE .
Поэтому обрабатывать специальным образом их нужно лишь в правом аргументе LIKE.
Что а) бывает крайне редко, и б) даже если встречается, то прямых injection-дыр не создает.

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