Являются ли аддлаши PHP уязвимыми к атакам SQL-инъекций?

Возможный дубликат:
Что mysql_real_escape_string() делает, что addlashes() не делает?

Я просматривал статьи о том, как / почему PHP addlashes функция уязвима для SQL инъекций. Все, что я прочитал, говорит, что есть проблемы с определенными типами кодировки mysql (default-символ-набор =GBK), или есть проблемы, если включены magic_quotes. Тем не менее, я не смог вырваться из функции addlashes() в этом сценарии и сделать что-то вредоносное - например, войти в систему как администратор.

    $user = addslashes($_POST['user']);
    $pass = sha1($_POST['pass']);
    $sql = "SELECT * FROM admins WHERE user = '".$user."' AND `pass` = '".$pass."'";

    $nums = mysql_num_rows(mysql_query($sql));

    if($nums==1){
    $_SESSION['admin_user'] = $user;
    $_SESSION['admin_pass'] = $pass;

Это (незначительный) аудит безопасности для клиента, и я рекомендую использовать PDO, но мне нужно показать их текущую уязвимость.

Рекомендации:

Источник

4 ответа

Решение

Шифлет показывает полный рабочий подвиг в своей записи в блоге. Код, показанный выше, похоже, не следует этому примеру, поскольку он не использует набор символов, который демонстрирует уязвимость. Тем не менее, дыра определенно существует.

Даже если это окажется безопасным в конкретном сценарии, практика использования addslashes() все еще опасно, и статья Шифлетта должна дать вам достаточно материала, чтобы спорить с ним, даже несмотря на то, что обстоятельства, которые требует эксплойт, очень эзотеричны и воспроизводить их не совсем тривиально.

Если ваш клиент не воспринимает опасность, не увидев живого эксплойта в своей конкретной системе, для него не стоит проводить аудит безопасности.

Источник

Являются ли аддлаши PHP уязвимыми к атакам SQL-инъекций?

Да. С условиями, упомянутыми в статье, на которую вы ссылаетесь.

Мне нужно отобразить их текущую уязвимость.

Я сомневаюсь, что вы можете отобразить это, так как кажется, что кодировка клиента не является известным GBK.

Хотя, скорее всего, существуют и другие возможные уязвимости только потому, что люди склонны злоупотреблять экранирующей функцией, ошибочно принимая ее.

Но я могу заверить вас, что до тех пор, пока кодирование вашего клиента либо однобайтовое, либо UTF-8, и до тех пор, пока эта функция используется правильно (как в коде, который вы опубликовали), - внедрение не будет возможным.

Источник

В вашем конкретном случае не кажется, что выполнить SQL-инъекцию так просто, но обычно нужно попробовать что-то вроде, если я введу нулевую переменную Юникода? лайк \0? Это сломает скрипт и вернет все? Скорее всего нет.

Таким образом, вам не всегда нужны косые черты для выполнения SQL-инъекций. Некоторые SQL могут быть написаны так ужасно неправильно, вот пример

"SELECT * FROM admins WHERE id = $id"

Если $id это число, его совершенно правильный SQL, и вы выполняете addslashes на $id, (кто бы это сделал?). Но для этого конкретного случая все, что вам нужно для внедрения SQL, это 1 OR 1=1 сделать запрос похожим

"SELECT * FROM admins WHERE id = 1 OR 1=1"

Выхода нет addslashes или же magic_quotes может защитить тебя от такой глупости.

Чтобы вернуться к рассматриваемому вопросу, зачем кому-то в здравом уме использовать GBK над чем-то вроде UTF-8 или же UTF-16?

Источник

Я не уверен, почему вы захотите использовать addlashes вместо mysql_real_escape_string(), но я полагаю, что это полностью ваш выбор.

addlashes() делает именно то, что говорит: цитирует строку с косой чертой

Example #1 An addslashes() example
<?php
$str = "Is your name O'reilly?";

// Outputs: Is your name O\'reilly?
echo addslashes($str);

Но некоторые атаки SQL могут выполняться без кавычек (некоторые инъекции оболочки и некоторые слепые инъекции SQL).

По этой причине я бы лично использовал mysql_real_escape_string() над addlashes() для защиты ваших данных в этом случае.

Также рассмотрите возможность использования sprintf() для ваших SQL-запросов, так как это делает его немного более безопасным:

$query = sprintf("SELECT `username`,`password`
        FROM admins 
        WHERE user = '%s' 
        AND `pass` = '%s'", 
    $user, $pass);

Это делает его более безопасным, поскольку не позволяет использовать другие типы данных, кроме тех, которые вы указали.

% d = цифра%s = строка и т. д.

Надеюсь, это поможет.

Источник
Другие вопросы по тегам