PHP - автоматическая защита SQL-инъекций? - PullRequest
3 голосов
/ 26 апреля 2010

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

Например, посмотрите, как работает этот код для входа в административный раздел:

    $password = md5(HASH_SALT . $_POST['loginPass']);
    $query = "SELECT * FROM `administrators` WHERE `active`='1' AND `email`='{$_POST['loginEmail']}' AND `password`='{$password}'";
    $userInfo = db_fetch_array(db_query($query));

    if($userInfo['id']) {
        $_SESSION['adminLoggedIn']  = true;
        // user is logged in, other junk happens here, not important

Создатели сайта создали специальный метод db_query и метод db_fetch_array, показанный здесь:

function db_query($qstring,$print=0)        { return @mysql(DB_NAME,$qstring); }
function db_fetch_array($qhandle)       { return @mysql_fetch_array($qhandle); }

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

' OR 'x'='x' LIMIT 1;

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

Может ли быть какая-то глобальная конфигурация PHP, которую они позволили блокировать эти атаки? Где это будет настроено?

Вот информация о версии PHP:

# php --version
PHP 5.2.12 (cli) (built: Feb 28 2010 15:59:21) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
    with the ionCube PHP Loader v3.3.14, Copyright (c) 2002-2010, by ionCube Ltd., and
    with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies

Ответы [ 4 ]

2 голосов
/ 26 апреля 2010

Я предполагаю, что ваши попытки с помощью приложения будут сорваны магическими кавычками .

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

0 голосов
/ 03 мая 2010

Вы упомянули в комментарии, что пытались определить, были ли включены магические кавычки:

<?php get_magic_quotes_gpc(); ?>

Вы, вероятно, хотели сделать это вместо этого:

<?php echo get_magic_quotes_gpc(); ?>

Наиболее вероятная ситуация, как говорили другие, заключается в том, что включены магические кавычки.

0 голосов
/ 03 мая 2010

Если вы откроете $ _POST ['loginEmail'] на своем сервере и попытаетесь атаковать, вы, скорее всего, увидите, что magic_quotes включен.

Если он включен, он будет выглядеть примерно так: \ 'OR \' x \ '= \' x

Вы должны использовать класс PDO (http://www.php.net/manual/en/pdo.prepare.php) во всех ваших SQL-запросах.

0 голосов
/ 26 апреля 2010

Все, что вы можете сделать в этой задаче, это то, что у вас должна быть хорошая проверка данных, и для каждого небезопасного символа, например, «вы должны добавить обратную косую черту перед этим, как это: \» и блок для получения / * (это Комментарий mysql, использующийся в sql-инъекции, для комментария следующий sql statments после внедрения.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...