Помощь Фильтрация данных при GET запросе для модуля DLE

Attyla

Профессор
Регистрация
21 Ноя 2012
Сообщения
160
Реакции
44
Есть сторонний модуль для DLE, у меня есть некоторые подозрения на безопасность, так как в нем нет (насколько я понял) никаких проверок для входящих данных. Возможно, я ошибаюсь, но решил спросить тут.
Как надо фильтровать параметры GET запроса для того чтобы не нарушить безопасность? Автор моего модуля сказал, что нехорошие символы сканируются в functions.php. Там есть конструкция, которая не пропускает url если в нем есть кавычки и другие небезопасные символы (выдает Hacking attempt!). Этого достаточно или надо дополнительно их проверять?

Вот что я нашел и есть ли нужда в таких проверках?

Код:
$number = intval($_GET['input_number']);

Код:
function strip_data($text)

{
    $quotes = array ("\x27", "\x22", "\x60", "\t", "\n", "\r", "*", "%", "<", ">", "?", "!" );
    $goodquotes = array ("-", "+", "#" );
    $repquotes = array ("\-", "\+", "\#" );
    $text = trim( strip_tags( $text ) );
    $text = str_replace( $quotes, '', $text );
    $text = str_replace( $goodquotes, $repquotes, $text );
    $text = ereg_replace(" +", " ", $text);
           
    return $text;
}
$input_text = strip_data($_GET['input_text']);
$input_text = htmlspecialchars($input_text);
$input_text = mysql_escape_string($input_text);

Какие общие рекомендации для фильтрации GET в Datalife Engine если данные пойдут в SQL запрос? Как это должно выглядеть? Кто может, поделитесь заготовками для фильтрации данных. Спасибо.

Версия DLE: >=10.0
 
Не могу сказать, что я спец по безопасности, поэтому текст ниже - это моё ИМХО и основано на моих знаниях PHP и MySQL, а так же на основе кодов DataLife Engine и модулей к нему.

$number = intval($_GET['input_number']); - 99,99999% безопасная строка. На выходе в $number может попасть только целое число. Дальше проблемы могут быть только если в скрипте кривая обработка нуля и отрицательных чисел, которые вполне могут быть на выходе функции intval.

А вот вторая запись уже очень сомнительна... Дело в том, что функцию mysql_escape_string надо вызывать только после коннекта к БД (если память не изменяет). Но в DLE уже есть готовая конструкция на этот счёт: $db->safesql();

Но с точки зрения SQL-инъекции защита правильная. А вот с точки зрения других уязвимостей - не факт.
 
Но в DLE уже есть готовая конструкция на этот счёт: $db->safesql();
Но с точки зрения SQL-инъекции защита правильная. А вот с точки зрения других уязвимостей - не факт.

Хотел бы уточнить:

Вот нашел такой код в functions.php
Код:
   if( $url ) {
       
        if( (strpos( $url, '<' ) !== false) || (strpos( $url, '>' ) !== false) || (strpos( $url, './' ) !== false) || (strpos( $url, '../' ) !== false) || (strpos( $url, '\'' ) !== false) || (strpos( $url, '.php' ) !== false) ) {
            if( $_GET['do'] != "search" OR $_GET['subaction'] != "search" ) die( "Hacking attempt!" );
        }
   
    }
   
    $url = html_entity_decode( urldecode( $_SERVER['REQUEST_URI'] ), ENT_QUOTES, 'ISO-8859-1' );
    $url = str_replace( "\\", "/", $url );
   
    if( $url ) {
       
        if( (strpos( $url, '<' ) !== false) || (strpos( $url, '>' ) !== false) || (strpos( $url, '\'' ) !== false) ) {
            if( $_GET['do'] != "search" OR $_GET['subaction'] != "search" ) die( "Hacking attempt!" );
       
        }
   
    }
Я так понимаю он уже не пропускает запрос с разными нехорошими символами, а в модуле для переменной которая будет частью sql-запроса нужно еще $somevar = $db->safesql($somevar);? Этого достаточно?!
 
В SQL есть 2 типа данных: те, что заключены в кавчки, и те, что в них не заключены.

Для защиты от SQL-инъекций достаточно для данных без кавычек (цифры, списки и т.д.) использовать функцию intval. Для данных, которые требуют кавычек, достаточно mysql_real_escape_string(), в DLE эту функцию вызывает $db->safesql($somevar);

Но не стоит забывать, что получение неожиданных данных из БД тоже может стать уязвимостью, но выше указанного достаточно, чтобы в БД не выполнили произвольный запрос.
 
Вот нашел такой код в functions.php
Я так понимаю он уже не пропускает запрос с разными нехорошими символами, а в модуле для переменной которая будет частью sql-запроса нужно еще $somevar = $db->safesql($somevar);? Этого достаточно?!

Ха-ха-ха :-], этот интересный код сначала проверяет $url на 6 запретных вхождений, а потом заново получает $url из $_SERVER['REQUEST_URI'] и проверяет уже только на 3 вхождения, что выглядит по меньшей мере странно.
Ни первая ни вторая проверка не фильтрует на символы ` (обратная кавычка) и " (двойная кавычка), которые активно используют в SQL-иньекциях. Это не означает, что есть скуля, но вызывает подозрение.

Конечно этот $url может проходить дополнительную очистку, так же может где-то реализована функция проверки всех параметров $_GET, $_POST, $_REQUEST, etc.
Но конкретно этот код имеет довольно небольшую степень защиты и сам по себе безопасности не гарантирует.
 
Ха-ха-ха :-], этот интересный код сначала проверяет $url на 6 запретных вхождений, а потом заново получает $url из $_SERVER['REQUEST_URI'] и проверяет уже только на 3 вхождения, что выглядит по меньшей мере странно.
Ни первая ни вторая проверка не фильтрует на символы ` (обратная кавычка) и " (двойная кавычка), которые активно используют в SQL-иньекциях. Это не означает, что есть скуля, но вызывает подозрение.

Конечно этот $url может проходить дополнительную очистку, так же может где-то реализована функция проверки всех параметров $_GET, $_POST, $_REQUEST, etc.
Но конкретно этот код имеет довольно небольшую степень защиты и сам по себе безопасности не гарантирует.
Как более опытный, подскажи, мой ответ верен был? Или я заблуждаюсь в безопасности функции?
 
Как более опытный, подскажи, мой ответ верен был? Или я заблуждаюсь в безопасности функции?
В функции safesql используется mysql_real_escape_string - это правильный подход для того чтобы заслешивать "вредные" символы в строках.
И про использование intval - тоже хороший совет.
 
Назад
Сверху