Как я могу предотвратить SQL-инъекцию в PHP?

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

$unsafe_variable = $_POST['user_input']; 

mysql_query("INSERT INTO `table` (`column`) VALUES ('$unsafe_variable')");

Это потому, что пользователь может ввести что-то вроде value'); DROP TABLE table;--, и запрос будет выглядеть следующим образом:

INSERT INTO `table` (`column`) VALUES('value'); DROP TABLE table;--')

Что можно сделать, чтобы это не произошло?

2780
задан Andrew G. Johnson 13 сент. '08 в 2:55
источник поделиться
28 ответов

Использовать подготовленные операторы и параметризованные запросы. Это операторы SQL, которые отправляются и анализируются сервером базы данных отдельно от любых параметров. Таким образом, злоумышленник не может внедрить вредоносный SQL.

В основном у вас есть два варианта:

  • Используя PDO (для любого поддерживаемого драйвера базы данных):

    $stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name');
    
    $stmt->execute(array('name' => $name));
    
    foreach ($stmt as $row) {
        // do something with $row
    }
    
  • Использование MySQLi (для MySQL):

    $stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?');
    $stmt->bind_param('s', $name); // 's' specifies the variable type => 'string'
    
    $stmt->execute();
    
    $result = $stmt->get_result();
    while ($row = $result->fetch_assoc()) {
        // do something with $row
    }
    

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

Правильная настройка соединения

Обратите внимание, что при использовании PDO для доступа к базе данных MySQL реальные подготовленные операторы не используются по умолчанию. Чтобы исправить это, вы должны отключить эмуляцию подготовленных операторов. Пример создания соединения с использованием PDO:

$dbConnection = new PDO('mysql:dbname=dbtest;host=127.0.0.1;charset=utf8', 'user', 'pass');

$dbConnection->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$dbConnection->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

В приведенном выше примере режим ошибки не является строго необходимым, , но рекомендуется добавить его. Таким образом, script не остановится с Fatal Error, когда что-то пойдет не так. И это дает разработчику шанс catch любой ошибки (я), которые throw n как PDOException s.

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

Хотя вы можете установить charset в параметрах конструктора, важно отметить, что более старые версии PHP (< 5.3.6) молча игнорирует параметр charset в DSN.

Описание

Что происходит, так это то, что оператор SQL, который вы передаете в prepare, анализируется и компилируется сервером базы данных. Задав параметры (либо ?, либо именованный параметр, например :name в приведенном выше примере), вы указываете механизм базы данных, в который вы хотите включить фильтр. Затем, когда вы вызываете execute, подготовленный оператор объединяется со значениями параметров, которые вы указываете.

Важно то, что значения параметров объединены с скомпилированным оператором, а не с строкой SQL. SQL-инъекция работает путем обмана script, включая вредоносные строки, когда он создает SQL для отправки в базу данных. Поэтому, отправляя фактический SQL отдельно от параметров, вы ограничиваете риск того, что закончите то, чего не намеревались. Любые параметры, которые вы отправляете при использовании подготовленного оператора, будут обрабатываться только как строки (хотя механизм базы данных может сделать некоторую оптимизацию, поэтому, конечно, параметры могут также оказаться как числа). В приведенном выше примере, если переменная $name содержит 'Sarah'; DELETE FROM employees, результат будет просто поиском строки "'Sarah'; DELETE FROM employees", и вы не получите пустой стол.

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

О, и поскольку вы спросили о том, как это сделать для вставки, вот пример (с использованием PDO):

$preparedStatement = $db->prepare('INSERT INTO table (column) VALUES (:column)');

$preparedStatement->execute(array('column' => $unsafeValue));

Могут ли подготовленные операторы использоваться для динамических запросов?

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

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

// Value whitelist
// $dir can only be 'DESC' otherwise it will be 'ASC'
if (empty($dir) || $dir !== 'DESC') {
   $dir = 'ASC';
}
8091
ответ дан Theo 13 сент. '08 в 15:30
источник поделиться

Внимание:Этот пример кода ответа (например, примерный код вопроса) использует расширение PHP mysql, которое устарело в PHP 5.5.0 и полностью удалено в PHP 7.0.0.

Если вы используете последнюю версию PHP, опция mysql_real_escape_string, описанная ниже, больше не будет доступна (хотя mysqli::escape_string является современным эквивалентом). В наши дни опция mysql_real_escape_string имеет смысл только для устаревшего кода на старой версии PHP.


У вас есть два варианта - экранирование специальных символов в unsafe_variable или использование параметризованного запроса. Оба будут защищать вас от SQL-инъекций. Параметрированный запрос считается лучшей практикой, но для его использования потребуется переходить на более новое расширение mysql, прежде чем вы сможете его использовать.

Мы рассмотрим нижнюю строку удара, которая будет первой.

//Connect

$unsafe_variable = $_POST["user-input"];
$safe_variable = mysql_real_escape_string($unsafe_variable);

mysql_query("INSERT INTO table (column) VALUES ('" . $safe_variable . "')");

//Disconnect

См. также описание функции mysql_real_escape_string.

Чтобы использовать параметризованный запрос, вам нужно использовать MySQLi, а не MySQL. Чтобы переписать ваш пример, нам нужно что-то вроде следующего.

<?php
    $mysqli = new mysqli("server", "username", "password", "database_name");

    // TODO - Check that connection was successful.

    $unsafe_variable = $_POST["user-input"];

    $stmt = $mysqli->prepare("INSERT INTO table (column) VALUES (?)");

    // TODO check that $stmt creation succeeded

    // "s" means the database expects a string
    $stmt->bind_param("s", $unsafe_variable);

    $stmt->execute();

    $stmt->close();

    $mysqli->close();
?>

Ключевая функция, которую вы хотите прочитать, будет mysqli::prepare.

Также, как предложили другие, вы можете счесть полезным/легче повысить уровень абстракции с помощью PDO.

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

  • Если вы хотите изменить структуру SQL на основе ввода пользователем, параметризованные запросы не помогут, и требуемое экранирование не покрывается mysql_real_escape_string. В этом случае вам будет лучше пропускать пользовательский ввод через белый список, чтобы обеспечить только "безопасные" значения.
  • Если вы используете целые числа из пользовательского ввода в состоянии и применяете подход mysql_real_escape_string, вы столкнетесь с проблемой, описанной Polynomial в комментариях ниже, Этот случай более сложный, поскольку целые числа не будут окружены кавычками, поэтому вы можете справиться, подтвердив, что пользовательский ввод содержит только цифры.
  • Есть, вероятно, другие случаи, о которых я не знаю. Вы можете найти этот - полезный ресурс по некоторым из более тонких проблем, с которыми вы можете столкнуться.
1538
ответ дан Matt Sheppard 13 сент. '08 в 12:48
источник поделиться

Каждый ответ здесь охватывает только часть проблемы.
На самом деле существует четыре разных частей запроса, которые мы можем добавить к нему динамически:

  • строка
  • число
  • идентификатор
  • ключевое слово синтаксиса.

и подготовленные утверждения охватывают только 2 из них

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

В целом такой подход защиты основан на "белом списке". В этом случае каждый динамический параметр должен быть жестко закодирован в вашем script и выбран из этого набора.
Например, для динамического упорядочения:

$orders  = array("name","price","qty"); //field names
$key     = array_search($_GET['sort'],$orders)); // see if we have such a name
$orderby = $orders[$key]; //if not, first one will be set automatically. smart enuf :)
$query   = "SELECT * FROM `table` ORDER BY $orderby"; //value is safe

Однако есть еще один способ защитить идентификаторы - экранирование. Пока вы указываете идентификатор, вы можете избежать обратных звонков внутри, удвоив их.

В качестве следующего шага мы можем заимствовать поистине блестящую идею использования некоторого заполнителя (прокси для представления фактического значения в запросе) из подготовленных операторов и изобретать местозаполнитель другого типа - заполнителя идентификатора.

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

Итак, общая рекомендация может быть сформулирована так: Пока вы добавляете динамические части в запрос с использованием заполнителей (и эти правильно заполнители правильно обработаны, конечно), вы можете быть уверены, что ваш запрос безопасен.

Тем не менее, есть проблема с ключевыми словами синтаксиса SQL (например, AND, DESC и т.д.), но белый список - единственный подход в этом случае.

Update

Несмотря на то, что существует общее соглашение о лучших методах защиты SQL-инъекций, существует еще еще много плохих методов.. И некоторые из них слишком глубоко укоренены в умах пользователей PHP. Например, на этой странице есть (хотя и невидимые для большинства посетителей) более 80 удаленных ответов - все удалены сообществом из-за плохого качества или продвижения плохих и устаревших практик. Хуже того, некоторые из плохих ответов не удаляются, а скорее процветают.

Например, там (1) являются (2) еще (3) many (4) ответы (5), включая второй наиболее ответный ответ, предлагающий вам ручное стирание строки - устаревший подход, который оказался небезопасным.

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

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

Независимо от того, что написано в руководстве по PHP в течение веков, *_escape_string ни в коем случае не делает данные безопасными и никогда не предназначалось. Помимо бесполезности для любой части SQL, отличной от строки, ручное экранирование неверно, поскольку оно является ручным, как автоматическое.

И OWASP делает это еще хуже, подчеркивая, что вы избегаете ввода пользователя, что является полной бессмыслицей: таких слов в контексте защиты от инъекций не должно быть. Каждая переменная потенциально опасна - независимо от источника! Или, другими словами, каждая переменная должна быть должным образом отформатирована для включения в запрос - независимо от источника. Это пункт назначения имеет значение. В тот момент, когда разработчик начинает отделять овец от коз (думая, является ли какая-то конкретная переменная "безопасной" или нет), он делает свой первый шаг к катастрофе. Не говоря уже о том, что даже формулировка предполагает массовое ускорение в точке входа, напоминающее очень волшебную функцию кавычек - уже презренную, устаревшую и удаленную.

Таким образом, в отличие от любого "экранирования" подготовленные операторы являются мерой, которая действительно защищает от SQL-инъекции (если применимо).

Если вы все еще не уверены, вот пошаговое объяснение, которое я написал, The Hitchhiker Guide to SQL Injection Prevention, где я подробно объяснил все эти вопросы и даже составил раздел, полностью посвященный плохим практикам и их раскрытию.

963
ответ дан Your Common Sense 24 нояб. '11 в 12:50
источник поделиться

Я бы рекомендовал использовать PDO (объекты данных PHP) для запуска параметризованных SQL-запросов.

Это не только защищает от SQL-инъекции, но и ускоряет запросы.

И используя функции PDO, а не mysql_, mysqli_ и pgsql_, вы делаете свое приложение немного более абстрактным из базы данных, в редких случаях, когда вам приходится переключать поставщиков баз данных.

780
ответ дан Kibbee 13 сент. '08 в 3:02
источник поделиться

Используйте PDO и подготовленные запросы.

($conn - объект PDO)

$stmt = $conn->prepare("INSERT INTO tbl VALUES(:id, :name)");
$stmt->bindValue(':id', $id);
$stmt->bindValue(':name', $name);
$stmt->execute();
576
ответ дан Imran 13 сент. '08 в 16:20
источник поделиться

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

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

Мой подход:

  • Если вы ожидаете, что ввод будет целым, убедитесь, что оно действительно целое. В языке с переменным типом, таком как PHP, это очень важно. Вы можете использовать, например, это очень простое, но мощное решение: sprintf("SELECT 1,2,3 FROM table WHERE 4 = %u", $input);

  • Если вы ожидаете чего-либо еще от целого числа hex it. Если вы отбросите его, вы полностью избежите ввода. В C/С++ существует функция, называемая mysql_hex_string(), в PHP вы можете использовать bin2hex().

    Не беспокойтесь о том, что строка с экранированной строкой будет иметь размер в 2 раза ее первоначальной длины, потому что, даже если вы используете mysql_real_escape_string, PHP должен выделять ту же емкость ((2*input_length)+1), что то же самое.

  • Этот шестнадцатеричный метод часто используется при передаче двоичных данных, но я не вижу причин, почему бы не использовать его во всех данных для предотвращения атак SQL-инъекций. Обратите внимание, что вам необходимо добавить данные с помощью 0x или использовать функцию MySQL UNHEX.

Итак, например, запрос:

SELECT password FROM users WHERE name = 'root'

Станет:

SELECT password FROM users WHERE name = 0x726f6f74

или

SELECT password FROM users WHERE name = UNHEX('726f6f74')

Hex - идеальный побег. Никоим образом не вводить.

Разница между функцией UNHEX и префиксом 0x

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

Префикс ** 0x ** может использоваться только для столбцов данных, таких как char, varchar, text, block, binary и т.д..
Кроме того, его использование немного сложно, если вы собираетесь вставить пустую строку. Вам придется полностью заменить его на '', или вы получите сообщение об ошибке.

UNHEX() работает в столбце any; вам не нужно беспокоиться о пустой строке.


Hex-методы часто используются в качестве атак

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

Например, если вы просто делаете что-то вроде этого:

"SELECT title FROM article WHERE id = " . mysql_real_escape_string($_GET["id"])

атака может ввести вас очень легко. Рассмотрим следующий введенный код, возвращенный с вашего script:

SELECT... WHERE id = -1 union all select table_name from information_schema.tables

а теперь просто извлеките структуру таблицы:

SELECT... WHERE id = -1 union all select column_name from information_schema.column, где table_name = 0x61727469636c65

И затем просто выберите нужные данные. Разве это не круто?

Но если кодер инъекционного сайта будет его шестнадцатеричным, инъекция не будет возможна, потому что запрос будет выглядеть следующим образом: SELECT ... WHERE id = UNHEX('2d312075...3635')

510
ответ дан Zaffy 03 окт. '12 в 17:07
источник поделиться

ВАЖНО

Лучший способ предотвратить SQL Injection - использовать Подготовленные утверждения вместо экранирования, как показано принятый ответ.

Существуют библиотеки, такие как Aura.Sql и EasyDB, которые позволяют разработчикам легче использовать подготовленные заявления. Чтобы узнать больше о том, почему подготовленные утверждения лучше на остановить SQL-инъекцию, обратитесь к этому mysql_real_escape_string() обходному и недавно зафиксированные уязвимости Unicode SQL Injection в WordPress.

Предотвращение инъекций - mysql_real_escape_string()

У PHP есть специально созданная функция для предотвращения этих атак. Все, что вам нужно сделать, это использовать функцию функции, mysql_real_escape_string.

mysql_real_escape_string берет строку, которая будет использоваться в запросе MySQL и возвращает ту же строку, при которой все попытки SQL-инъекций безопасно экранированы. В принципе, он заменит эти неприятные кавычки ('), которые пользователь может ввести с помощью заменителя в MySQL, сэкономленной цитатой.

ПРИМЕЧАНИЕ. вы должны подключиться к базе данных, чтобы использовать эту функцию!

//Подключение к MySQL

$name_bad = "' OR 1'"; 

$name_bad = mysql_real_escape_string($name_bad);

$query_bad = "SELECT * FROM customers WHERE username = '$name_bad'";
echo "Escaped Bad Injection: <br />" . $query_bad . "<br />";


$name_evil = "'; DELETE FROM customers WHERE 1 or username = '"; 

$name_evil = mysql_real_escape_string($name_evil);

$query_evil = "SELECT * FROM customers WHERE username = '$name_evil'";
echo "Escaped Evil Injection: <br />" . $query_evil;

Подробнее вы можете найти в MySQL - SQL Injection Prevention.

462
ответ дан rahularyansharma 17 июня '11 в 7:00
источник поделиться

Предупреждение о безопасности. Этот ответ не соответствует рекомендациям по безопасности. Эвакуация неадекватна для предотвращения внедрения SQL, вместо этого используйте подготовленные инструкции. Используйте стратегию, изложенную ниже, на свой страх и риск. (Кроме того, mysql_real_escape_string() был удален в PHP 7.)

Вы можете сделать что-то общее:

$safe_variable = mysql_real_escape_string($_POST["user-input"]);
mysql_query("INSERT INTO table (column) VALUES ('" . $safe_variable . "')");

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

418
ответ дан Tanerax 13 сент. '08 в 3:15
источник поделиться

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

354
ответ дан Rob 08 дек. '08 в 8:26
источник поделиться

Параметрированный запрос И проверка ввода - это путь. Существует множество сценариев, в которых может произойти SQL-инъекция, даже если используется mysql_real_escape_string().

Эти примеры уязвимы для SQL-инъекций:

$offset = isset($_GET['o']) ? $_GET['o'] : 0;
$offset = mysql_real_escape_string($offset);
RunQuery("SELECT userid, username FROM sql_injection_test LIMIT $offset, 10");

или

$order = isset($_GET['o']) ? $_GET['o'] : 'userid';
$order = mysql_real_escape_string($order);
RunQuery("SELECT userid, username FROM sql_injection_test ORDER BY `$order`");

В обоих случаях вы не можете использовать ' для защиты инкапсуляции.

Источник: Неожиданная инъекция SQL (когда Escaping недостаточно)

336
ответ дан Cedric 04 июля '11 в 0:50
источник поделиться

На мой взгляд, лучший способ вообще запретить SQL-инъекцию в вашем приложении PHP (или любом веб-приложении, если на то пошло) - это думать о вашей архитектуре приложения. Если единственный способ защитить от SQL-инъекции - не забудьте использовать специальный метод или функцию, которая делает The Right Thing каждый раз, когда вы разговариваете с базой данных, вы делаете это неправильно. Таким образом, это всего лишь вопрос времени, пока вы не забудете правильно отформатировать свой запрос в какой-то момент вашего кода.

Принятие шаблона MVC и структуры, например CakePHP или CodeIgniter, вероятно, правильный путь: общие задачи, такие как создание безопасных запросов к базе данных, были решены и централизованно реализованы в таких рамках. Они помогают организовать ваше веб-приложение разумным образом и заставляют вас больше думать о загрузке и сохранении объектов, а не о безопасном построении отдельных SQL-запросов.

287
ответ дан Johannes Fahrenkrug 03 июля '12 в 13:14
источник поделиться

Я пользуюсь хранимыми процедурами (У MySQL была поддержка хранимых процедур с 5.0) с точки зрения безопасности - преимущества -

  • Большинство баз данных (включая MySQL) позволяют ограничить доступ пользователей к выполнению хранимых процедур. Четкое управление доступом к безопасности полезно для предотвращения эскалации атак привилегий. Это предотвращает возможность взлома приложений, которые могут быть запущены непосредственно с базой данных.
  • Они абстрагируют необработанный SQL-запрос из приложения, поэтому для приложения доступно меньше информации о структуре базы данных. Это затрудняет понимание людьми базовой структуры базы данных и разработку подходящих атак.
  • Они принимают только параметры, поэтому существуют преимущества параметризованных запросов. Конечно, IMO вам все равно нужно дезинфицировать ваш вход, особенно если вы используете динамический SQL внутри хранимой процедуры.

Недостатки -

  • Им (хранимые процедуры) сложно поддерживать и стремиться к размножению очень быстро. Это позволяет им решить проблему.
  • Они не очень подходят для динамических запросов - если они созданы для принятия динамического кода в качестве параметров, тогда многие преимущества сбрасываются.
271
ответ дан Nikhil 03 нояб. '09 в 21:05
источник поделиться

Существует множество способов предотвращения SQL-инъекций и других SQL-хаков. Вы можете легко найти его в Интернете (Google Search). Конечно, PDO - одно из хороших решений. Но я хотел бы предложить вам некоторые хорошие ссылки для предотвращения SQL Injection.

Что такое SQL-инъекция и как предотвратить

Руководство по PHP для SQL-инъекции

Microsoft объясняет SQL-инъекцию и предотвращение в PHP

и некоторые другие, такие как Предотвращение SQL-инъекций с MySQL и PHP

Теперь, , почему вы делаете, вам нужно предотвратить запрос из SQL-инъекции?

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

Запрос для аутентификации входа:

$query="select * from users where email='".$_POST['email']."' and password='".$_POST['password']."' ";

Теперь, если кто-то (хакер) ставит

$_POST['email']= admin@emali.com' OR '1=1

и пароль ничего....

Запрос будет анализироваться в системе только до:

$query="select * from users where email='admin@emali.com' OR '1=1';

Другая часть будет отброшена. Итак, что будет? Неавторизованный пользователь (хакер) сможет войти в систему как администратор без своего пароля. Теперь он может делать все, что может сделать администратор/адрес электронной почты. Смотрите, это очень опасно, если SQL-инъекция не предотвращается.

267
ответ дан Manish Shrivastava 23 июля '12 в 13:19
источник поделиться

Я думаю, что если кто-то захочет использовать PHP и MySQL или какой-нибудь другой сервер базы данных:

  • Подумайте об обучении PDO (объекты данных PHP) - это уровень доступа к базе данных, обеспечивающий единый метод доступа к нескольким базам данных.
  • Подумайте об обучении MySQLi
  • Используйте собственные PHP-функции, такие как strip_tags, mysql_real_escape_string или если переменная числовая, просто (int)$foo. Подробнее о типах переменных в PHP читайте здесь. Если вы используете библиотеки, такие как PDO или MySQLi, всегда используйте PDO:: quote() и mysqli_real_escape_string().

Примеры библиотек:

---- PDO

----- Без заполнителей - спелые для SQL-инъекций! Плохо

$request = $pdoConnection->("INSERT INTO parents (name, addr, city) values ($name, $addr, $city)");

----- Без названия заполнители

$request = $pdoConnection->("INSERT INTO parents (name, addr, city) values (?, ?, ?);

----- Именованные заполнители

$request = $pdoConnection->("INSERT INTO parents (name, addr, city) value (:name, :addr, :city)");

--- MySQLi

$request = $mysqliConnection->prepare('
       SELECT * FROM trainers
       WHERE name = ?
       AND email = ?
       AND last_login > ?');

    $query->bind_param('first_param', 'second_param', $mail, time() - 3600);
    $query->execute();

P.S

PDO выигрывает эту битву с легкостью. С поддержкой двенадцати разные драйверы базы данных и именованные параметры, мы можем игнорировать небольшие потери производительности и привыкнуть к его API. Из безопасности точка зрения, обе они безопасны, пока разработчик их использует как они должны использоваться

Но хотя PDO и MySQLi довольно быстры, MySQLi выполняет незначительно быстрее в контрольных показателях - ~ 2,5% для незаготовленных и ~ 6.5% для подготовленных.

И, пожалуйста, проверьте каждый запрос в своей базе данных - это лучший способ предотвратить инъекцию.

246
ответ дан RDK 10 окт. '12 в 17:53
источник поделиться

Если возможно, введите типы параметров. Но он работает только на простых типах, таких как int, bool и float.

$unsafe_variable = $_POST['user_id'];

$safe_variable = (int)$unsafe_variable ;

mysqli_query($conn, "INSERT INTO table (column) VALUES ('" . $safe_variable . "')");
233
ответ дан devOp 12 июня '12 в 11:03
источник поделиться

Если вы хотите использовать механизмы кэширования, например Redis или Memcached, возможно, DALMP может быть выбором. Он использует чистый MySQLi. Проверьте это: Уровень абстракции базы данных DALMP для MySQL с использованием PHP.

Кроме того, вы можете "подготовить" свои аргументы перед подготовкой своего запроса, чтобы вы могли создавать динамические запросы и в конце иметь полностью подготовленный запрос. Уровень абстракции базы данных DALMP для MySQL с использованием PHP.

217
ответ дан nbari 15 окт. '12 в 16:52
источник поделиться

Для тех, кто не знает, как использовать PDO (исходя из функций mysql_), я сделал очень, очень простую PDO-оболочку, которая это один файл. Он существует, чтобы показать, насколько легко выполнять все обычные приложения, которые необходимо выполнить. Работает с PostgreSQL, MySQL и SQLite.

В принципе, прочитайте пока вы читаете руководство, чтобы узнать, как использовать функции PDO в реальной жизни, чтобы упростить хранение и получить значения в формате вы.

Я хочу один столбец

$count = DB::column('SELECT COUNT(*) FROM `user`);

Мне нужны результаты массива (key = > value) (т.е. для создания selectbox)

$pairs = DB::pairs('SELECT `id`, `username` FROM `user`);

Я хочу получить результат одной строки

$user = DB::row('SELECT * FROM `user` WHERE `id` = ?', array($user_id));

Я хочу получить массив результатов

$banned_users = DB::fetch('SELECT * FROM `user` WHERE `banned` = ?', array(TRUE));
209
ответ дан Xeoncross 19 сент. '12 в 21:10
источник поделиться

Используя эту функцию PHP mysql_escape_string(), вы можете быстро получить хорошую профилактику.

Например:

SELECT * FROM users WHERE name = '".mysql_escape_string($name_from_html_form)."'

mysql_escape_string - Сбрасывает строку для использования в mysql_query

Для большей профилактики вы можете добавить в конце...

wHERE 1=1   or  LIMIT 1

Наконец, вы получите:

SELECT * FROM users WHERE name = '".mysql_escape_string($name_from_html_form)."' LIMIT 1
209
ответ дан Nicolas Finelli 03 авг. '12 в 22:59
источник поделиться

Несколько рекомендаций по экранированию специальных символов в операторах SQL.

Не используйте MySQL, это расширение устарело, используйте MySQLi или PDO.

MySQLi

Для ручного экранирования специальных символов в строке вы можете использовать функцию mysqli_real_escape_string. Функция не будет работать должным образом, если правильный набор символов не установлен с mysqli_set_charset.

Пример:

$mysqli = new mysqli( 'host', 'user', 'password', 'database' );
$mysqli->set_charset( 'charset');

$string = $mysqli->real_escape_string( $string );
$mysqli->query( "INSERT INTO table (column) VALUES ('$string')" );

Для автоматического экранирования значений с помощью подготовленных операторов используйте mysqli_prepare и mysqli_stmt_bind_param, где должны быть указаны типы для соответствующих переменных привязки для соответствующего преобразования:

Пример:

$stmt = $mysqli->prepare( "INSERT INTO table ( column1, column2 ) VALUES (?,?)" );

$stmt->bind_param( "is", $integer, $string );

$stmt->execute();

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

Итак, если вы используете подготовленный оператор, вы должны указать типы переменных для функции mysqli_stmt_bind_param.

И использование mysqli_real_escape_string для, как сказано в названии, означает экранирование специальных символов в строке, поэтому оно не сделает целые числа безопасными. Цель этой функции - предотвратить разрыв строк в операторах SQL и повреждение базы данных, которое она может вызвать. mysqli_real_escape_string - полезная функция при правильном использовании, особенно в сочетании с sprintf.

Пример:

$string = "x' OR name LIKE '%John%";
$integer = '5 OR id != 0';

$query = sprintf( "SELECT id, email, pass, name FROM members WHERE email ='%s' AND id = %d", $mysqli->real_escape_string( $string ), $integer );

echo $query;
// SELECT id, email, pass, name FROM members WHERE email ='x\' OR name LIKE \'%John%' AND id = 5

$integer = '99999999999999999999';
$query = sprintf( "SELECT id, email, pass, name FROM members WHERE email ='%s' AND id = %d", $mysqli->real_escape_string( $string ), $integer );

echo $query;
// SELECT id, email, pass, name FROM members WHERE email ='x\' OR name LIKE \'%John%' AND id = 2147483647
191
ответ дан Danijel 09 мая '13 в 19:36
источник поделиться

Простую альтернативу этой проблеме можно решить, предоставив соответствующие разрешения в самой базе данных. Например: если вы используете базу данных mysql, введите в базу данных через терминал или предоставленный интерфейс и просто следуйте этой команде:

 GRANT SELECT, INSERT, DELETE ON database TO username@'localhost' IDENTIFIED BY 'password';

Это ограничит пользователя только ограничением только указанным запросом. Удалите разрешение удаления, и поэтому данные никогда не будут удалены из запроса, запущенного с php-страницы. Второе, что нужно сделать, - это очистить привилегии, чтобы mysql обновлял разрешения и обновления.

FLUSH PRIVILEGES; 

Дополнительная информация о flush.

Чтобы просмотреть текущие привилегии для пользователя, выполните следующий запрос.

select * from mysql.user where User='username';

Подробнее о GRANT.

170
ответ дан Apurv Nerlekar 25 окт. '12 в 11:07
источник поделиться

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

  • Использование mysql_real_escape_string(), которое является предопределенной функцией в PHP, и этот код добавляет обратную косую черту к следующим символам: \x00, \n, \r, \, ', " и \x1a. Передайте входные значения в качестве параметров, чтобы свести к минимуму вероятность внедрения SQL.
  • Самый продвинутый способ - использование PDO.

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

Рассмотрим следующий запрос:

$iId = mysql_real_escape_string("1 OR 1=1"); $sSql = "SELECT * FROM table WHERE id = $iId";

mysql_real_escape_string() не будет защищать здесь. Если вы используете одиночные кавычки ('') вокруг ваших переменных внутри вашего запроса, это то, что защищает вас от этого. Ниже приведено ниже решение:

$iId = (int) mysql_real_escape_string("1 OR 1=1"); $sSql = "SELECT * FROM table WHERE id = $iId";

В этом question есть хорошие ответы.

Я предлагаю, что использование PDO - лучший вариант.

Edit:

mysql_real_escape_string() устарел с PHP 5.5.0. Используйте либо mysqli, либо PDO.

Альтернативой mysql_real_escape_string() является

string mysqli_real_escape_string ( mysqli $link , string $escapestr )

Пример:

$iId = $mysqli->real_escape_string("1 OR 1=1");
$mysqli->query("SELECT * FROM table WHERE id = $iId");
166
ответ дан Soumalya Banerjee 14 сент. '12 в 17:37
источник поделиться

Простым способом было бы использовать фреймворк PHP, например CodeIgniter или Laravel, которые имеют встроенные функции, такие как фильтрация и активная запись, поэтому вам не нужно беспокоиться об этих нюансах.

160
ответ дан Deepak Thomas 25 июня '13 в 22:00
источник поделиться

Что касается многих полезных ответов, я надеюсь добавить некоторые значения в этот поток. SQL-инъекция - это атака, которая может быть выполнена через пользовательские входы (входные данные, заполненные пользователем, а затем используемые внутри запросов). Шаблоны инъекций SQL - это правильный синтаксис запроса, в то время как мы можем назвать это: плохие запросы по неверным причинам, мы предполагаем, что быть плохим человеком, который пытается получить секретную информацию (в обход контроля доступа), которая влияет на три принципа безопасности (конфиденциальность, целостность, доступность).

Теперь мы хотим предотвратить угрозы безопасности, такие как атаки SQL-инъекций, вопрос с вопросом (как предотвратить атаку SQL-инъекций с использованием PHP), быть более реалистичным, фильтрация данных или очистка входных данных происходит при использовании пользовательского ввода данные внутри такого запроса, используя PHP или любой другой язык программирования, не так, или, как рекомендовано больше людей использовать современные технологии, такие как подготовленный оператор или любые другие инструменты, которые в настоящее время поддерживают предотвращение внедрения SQL-инъекций, считают, что эти инструменты больше не доступны? Как вы защищаете свое приложение?

Мой подход к внедрению SQL: очистка пользовательских данных перед отправкой в ​​базу данных (прежде чем использовать ее в любом запросе).

Фильтрация данных для (Преобразование небезопасных данных в безопасные данные) Учтите, что PDO и MySQLi недоступны, как можно вы защищаете свое приложение? Вы заставляете меня использовать их? Как насчет других языков, кроме PHP? Я предпочитаю предоставлять общие идеи, поскольку он может использоваться для более широкой границы не только для конкретного языка.

  • Пользователь SQL (ограничение полномочий пользователя): наиболее распространенными операциями SQL являются (SELECT, UPDATE, INSERT), а затем, почему предоставление привилегий UPDATE пользователю, который этого не требует? Например, логин и поисковые страницы используют только SELECT, а затем зачем использовать пользователей БД на этих страницах с высокими привилегиями? ПРАВИЛО: не создавайте одного пользователя базы данных для всех привилегий, для всех операций SQL вы можете создать свою схему как (deluser, selectuser, updateuser) в качестве имен пользователей для удобства использования.

см. Принцип наименьших привилегий

  1. Фильтрация данных: перед созданием какого-либо запроса пользовательский ввод должен быть проверен и отфильтрован, для программистов важно определить некоторые свойства для каждой переменной, вводимой пользователем: тип данных, шаблон данных и длина данных. поле, которое является числом между (x и y), должно быть точно проверено с использованием точного правила, для поля, которое является строкой (текстом): шаблон имеет значение, например, имя пользователя должно содержать только некоторые символы, позволяющие сказать [a- zA-Z0-9_-.] длина изменяется между (x и n), где x и n (целые числа, x <= n). Правило: создание точных фильтров и правил проверки - лучшая практика для меня.

  2. Используйте другие инструменты: здесь я также соглашусь с вами, что подготовленный оператор (параметризованный запрос) и хранимые процедуры, недостатки здесь - эти способы требуют передовых навыков, которых не существует для большинства пользователей, основная идея здесь состоит в том, чтобы различать SQL-запрос и данные, которые используются внутри, оба подхода могут использоваться даже с небезопасными данными, поскольку данные, вводимые пользователем, не добавляют ничего к исходному запросу, например (any или x = x). Для получения дополнительной информации, пожалуйста, прочитайте OWASP SQL Injection Prevention Cheat Sheet.

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

Наконец, рассмотрим, что пользователь отправляет этот текст ниже, а не вводит его имя пользователя:

[1] UNION SELECT IF(SUBSTRING(Password,1,1)='2',BENCHMARK(100000,SHA1(1)),0) User,Password FROM mysql.user WHERE User = 'root'

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

Последняя точка - обнаружение неожиданного поведения, требующего больших усилий и сложности; он не рекомендуется для обычных веб-приложений. Неожиданным поведением в пользовательском входе является SELECT, UNION, IF, SUBSTRING, BENCHMARK, SHA, root после обнаружения этих слов, вы можете избежать ввода.

Update1:

Пользователь прокомментировал, что этот пост бесполезен, ОК! Вот что OWASP.ORG при условии:

Первичная защита:
 
    Вариант №1: Использование подготовленных заявлений (параметризованные запросы)
    Вариант № 2: Использование хранимых процедур
    Вариант № 3: выход из всех входящих в систему пользователей
 
Дополнительная защита:
 
    Также принудительно: наименьшая привилегия
    Также выполните: подтверждение ввода белого списка

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

Update2:

Из руководства PHP, PHP: Подготовленные утверждения - Руководство:

Escaping и SQL-инъекция

Связанные переменные будут автоматически экранированы сервером. сервер вставляет свои экранированные значения в соответствующие места в перед выполнением. Подсказка должна быть предоставлена сервера для типа связанной переменной, чтобы создать соответствующий преобразование. См. Функцию mysqli_stmt_bind_param() для получения дополнительной информации. Информация.

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

Update3:

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

PDO:

$user = "''1''"; //Malicious keyword
$sql = 'SELECT * FROM awa_user WHERE userame =:username';
$sth = $dbh->prepare($sql, array(PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY));
$sth->execute(array(':username' => $user));

Журнал запросов:

    189 Query SELECT * FROM awa_user WHERE userame ='\'\'1\'\''
    189 Quit

MySQLi:

$stmt = $mysqli->prepare("SELECT * FROM awa_user WHERE username =?")) {
$stmt->bind_param("s", $user);
$user = "''1''";
$stmt->execute();

Журнал запросов:

    188 Prepare   SELECT * FROM awa_user WHERE username =?
    188 Execute   SELECT * FROM awa_user WHERE username ='\'\'1\'\''
    188 Quit

Ясно, что подготовленный оператор также ускользает от данных, и ничего больше.

Как уже упоминалось выше в приведенном выше утверждении The automatic escaping of values within the server is sometimes considered a security feature to prevent SQL injection. The same degree of security can be achieved with non-prepared statements, if input values are escaped correctly, это доказывает, что проверка данных, такая как intval(), является хорошей идеей для целочисленных значений перед отправкой любого запроса, кроме того, предотвращение вредоносных пользовательских данных перед отправкой запроса правильный и действительный подход.

Подробнее см. этот вопрос: PDO отправляет необработанный запрос в MySQL, а Mysqli отправляет подготовленный запрос, оба дают тот же результат

Литература:

158
ответ дан user1646111 28 янв. '13 в 22:37
источник поделиться

** Предупреждение: подход, описанный в этом ответе, применим только к очень конкретным сценариям и не является безопасным, поскольку атаки SQL-инъекций не только полагаются на возможность ввода X=Y. **

Если злоумышленники пытаются взломать форму с помощью переменной PHP $_GET или с помощью строки запроса URL, вы сможете поймать их, если они не защищены.

RewriteCond %{QUERY_STRING} ([0-9]+)=([0-9]+)
RewriteRule ^(.*) ^/track.php

Потому что 1=1, 2=2, 1=2, 2=1, 1+1=2 и т.д.... являются распространенными вопросами к базе данных SQL злоумышленника. Возможно, он также используется многими хакерскими приложениями.

Но вы должны быть осторожны, чтобы не переписывать безопасный запрос с вашего сайта. В приведенном выше коде вам дается подсказка, чтобы переписать или перенаправить (это зависит от вас) эту динамическую строку запроса, зависящую от хакерства, на страницу, в которой будет храниться злоумышленник IP-адрес или EVEN THEIR COOKIES, историю, браузер или любую другую конфиденциальную информацию, чтобы вы могли с ними справиться позже, запретив их учетную запись или контактные органы.

133
ответ дан 5ervant 04 апр. '13 в 11:15
источник поделиться

Есть так много ответов для PHP и MySQL, но вот код для PHP и Oracle для предотвращения SQL-инъекции, а также для регулярного использования драйверов oci8:

$conn = oci_connect($username, $password, $connection_string);
$stmt = oci_parse($conn, 'UPDATE table SET field = :xx WHERE ID = 123');
oci_bind_by_name($stmt, ':xx', $fieldval);
oci_execute($stmt);
125
ответ дан Chintan Gor 30 янв. '14 в 10:00
источник поделиться

Хорошей идеей является использование 'объектно-реляционного mapper', например Idiorm:

$user = ORM::for_table('user')
->where_equal('username', 'j4mie')
->find_one();

$user->first_name = 'Jamie';
$user->save();

$tweets = ORM::for_table('tweet')
    ->select('tweet.*')
    ->join('user', array(
        'user.id', '=', 'tweet.user_id'
    ))
    ->where_equal('user.username', 'j4mie')
    ->find_many();

foreach ($tweets as $tweet) {
    echo $tweet->text;
}

Это не только избавляет вас от SQL-инъекций, но и от синтаксических ошибок! Также поддерживает коллекции моделей с цепочкой методов для фильтрации или применения действий к нескольким результатам одновременно и нескольких подключений.

120
ответ дан Thomas Ahle 20 марта '14 в 3:17
источник поделиться

Использование PDO и MYSQLi хорошая практика для предотвращения инъекций SQL, но если вы действительно хотите работать с функциями и запросами MySQL, было бы лучше использовать

mysql_real_escape_string

$unsafe_variable = mysql_real_escape_string($_POST['user_input']);

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

is_string

$unsafe_variable = (is_string($_POST['user_input']) ? $_POST['user_input'] : '');

is_numeric

$unsafe_variable = (is_numeric($_POST['user_input']) ? $_POST['user_input'] : '');

И гораздо лучше использовать эти функции для проверки входных данных с помощью mysql_real_escape_string.

117
ответ дан Rakesh Sharma 17 янв. '14 в 9:25
источник поделиться

Я написал эту небольшую функцию несколько лет назад:

function sqlvprintf($query, $args)
{
    global $DB_LINK;
    $ctr = 0;
    ensureConnection(); // Connect to database if not connected already.
    $values = array();
    foreach ($args as $value)
    {
        if (is_string($value))
        {
            $value = "'" . mysqli_real_escape_string($DB_LINK, $value) . "'";
        }
        else if (is_null($value))
        {
            $value = 'NULL';
        }
        else if (!is_int($value) && !is_float($value))
        {
            die('Only numeric, string, array and NULL arguments allowed in a query. Argument '.($ctr+1).' is not a basic type, it\ type is '. gettype($value). '.');
        }
        $values[] = $value;
        $ctr++;
    }
    $query = preg_replace_callback(
        '/{(\\d+)}/', 
        function($match) use ($values)
        {
            if (isset($values[$match[1]]))
            {
                return $values[$match[1]];
            }
            else
            {
                return $match[0];
            }
        },
        $query
    );
    return $query;
}

function runEscapedQuery($preparedQuery /*, ...*/)
{
    $params = array_slice(func_get_args(), 1);
    $results = runQuery(sqlvprintf($preparedQuery, $params)); // Run query and fetch results.   
    return $results;
}

Это позволяет запускать операторы в однострочном С# -и String.Format, например:

runEscapedQuery("INSERT INTO Whatever (id, foo, bar) VALUES ({0}, {1}, {2})", $numericVar, $stringVar1, $stringVar2);

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

ОБНОВЛЕНИЕ БЕЗОПАСНОСТИ: предыдущая версия str_replace допускала инъекции, добавляя токены {#} в пользовательские данные. Эта версия preg_replace_callback не вызывает проблем, если замена содержит эти токены.

81
ответ дан Calmarius 18 февр. '14 в 23:38
источник поделиться

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