Как я могу предотвратить внедрение 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;--')
Что можно сделать, чтобы этого не случилось?
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);
В приведенном выше примере режим ошибки не является строго необходимым, но рекомендуется добавить его. Таким образом, скрипт не остановится на Fatal Error когда что-то идет не так. И это дает разработчику возможность catch любые ошибки, которые throwн как PDOExceptions.
Что является обязательным, однако, является первым setAttribute() строка, которая указывает PDO отключить эмулированные подготовленные операторы и использовать реально подготовленные операторы. Это гарантирует, что оператор и значения не будут проанализированы PHP перед отправкой его на сервер MySQL (не давая возможности злоумышленнику внедрить вредоносный SQL).
Хотя вы можете установить charset в опциях конструктора важно отметить, что "старые" версии PHP (< 5.3.6) молча игнорировали параметр charset в DSN.
объяснение
Что происходит, так это то, что оператор SQL, который вы передаете prepare анализируется и компилируется сервером базы данных. Указывая параметры (либо ? или именованный параметр, как :name в приведенном выше примере) вы указываете ядру базы данных, куда вы хотите фильтровать. Затем, когда вы звоните executeподготовленный оператор объединяется с указанными вами значениями параметров.
Здесь важно то, что значения параметров объединяются с скомпилированным оператором, а не строкой SQL. Инъекция SQL работает путем обмана скрипта, включающего вредоносные строки, когда он создает 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';
}
Предупреждение: пример кода этого ответа (как пример кода вопроса) использует 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 в PHP.
Мы покроем нижнюю ударную струну, избегая первой.
//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 в комментариях ниже. Этот случай сложнее, потому что целые числа не будут заключены в кавычки, так что вы могли бы справиться, проверив, что пользовательский ввод содержит только цифры. - Есть, вероятно, другие случаи, о которых я не знаю. Вы можете обнаружить, что это полезный ресурс по некоторым из более тонких проблем, с которыми вы можете столкнуться.
Каждый ответ здесь охватывает только часть проблемы. На самом деле, есть четыре различных части запроса, которые мы можем динамически добавить к ним:
- строка
- число
- идентификатор
- синтаксическое ключевое слово.
И подготовленные заявления охватывают только два из них.
Но иногда нам приходится делать наш запрос еще более динамичным, добавляя также операторы или идентификаторы. Итак, нам понадобятся разные методы защиты.
В общем, такой подход к защите основан на белых списках.
В этом случае каждый динамический параметр должен быть жестко задан в вашем сценарии и выбран из этого набора. Например, чтобы сделать динамическое упорядочение:
$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
Однако есть еще один способ защитить идентификаторы - экранирование. Пока у вас есть идентификатор в кавычках, вы можете избежать обратных кавычек внутри, удвоив их.
В качестве дальнейшего шага мы можем позаимствовать действительно блестящую идею использования некоторого заполнителя (прокси для представления фактического значения в запросе) из подготовленных операторов и изобрести заполнитель другого типа - заполнитель идентификатора.
Итак, короче говоря, это заполнитель, а не подготовленное утверждение может рассматриваться как серебряная пуля.
Таким образом, общая рекомендация может быть сформулирована так:пока вы добавляете динамические части в запрос с использованием заполнителей (и, конечно, эти заполнители правильно обрабатываются), вы можете быть уверены, что ваш запрос безопасен.
Тем не менее существует проблема с ключевыми словами синтаксиса SQL (например, AND, DESC и так далее), но белый список кажется единственным подходом в этом случае.
Обновить
Несмотря на то, что существует общее согласие с лучшими практиками, касающимися защиты от SQL-инъекций, все еще есть много плохих практик И некоторые из них слишком глубоко укоренились в сознании пользователей PHP. Например, на этой самой странице есть (хотя и невидимые для большинства посетителей) более 80 удаленных ответов - все они удалены сообществом из-за плохого качества или из-за пропаганды плохой и устаревшей практики. Хуже того, некоторые плохие ответы не удаляются, а процветают.
Например, (1) есть (2) еще (3) много (4) ответов (5), включая второй ответ с наибольшим количеством голосов, предлагающий вам ручное экранирование строк - устаревший подход, который, как оказалось, небезопасен.
Или есть немного лучший ответ, который предлагает просто другой метод форматирования строки и даже может похвастаться этим как окончательной панацеей. Хотя, конечно, это не так. Этот метод ничем не лучше обычного форматирования строк, но при этом он сохраняет все свои недостатки: он применим только к строкам и, как и любое другое ручное форматирование, по сути является необязательной, необязательной мерой, подверженной человеческим ошибкам любого рода.
Я думаю, что все это из-за одного очень старого суеверия, поддерживаемого такими авторитетами, как OWASP или руководство по PHP, которое провозглашает равенство между любыми "выходами" и защитой от SQL-инъекций.
Независимо от того, что руководство PHP говорило целую вечность, *_escape_stringни в коем случае не делает данные безопасными и никогда не предназначались. Помимо бесполезности для любой части SQL, кроме строки, ручное экранирование является неправильным, поскольку оно является ручным, в отличие от автоматического.
И OWASP делает это еще хуже, подчеркивая необходимость избегать пользовательского ввода, что является полной ерундой: в контексте защиты от инъекций не должно быть таких слов. Каждая переменная потенциально опасна - независимо от источника! Или, другими словами - каждая переменная должна быть правильно отформатирована, чтобы ее можно было вставить в запрос - независимо от источника снова. Это пункт назначения, который имеет значение. В тот момент, когда разработчик начинает отделять овец от коз (думая, является ли какая-то конкретная переменная "безопасной" или нет), он / она делает свой первый шаг к катастрофе. Не говоря уже о том, что даже формулировка предполагает массовый выход в точке входа, напоминающий функцию очень волшебных кавычек - уже презирали, осуждали и удаляли.
Таким образом, в отличие от любого "выхода", подготовленные операторы - это мера, которая действительно защищает от внедрения SQL (когда это применимо).
Если вы все еще не уверены, вот пошаговое объяснение, которое я написал, Руководство по автостопу по предотвращению SQL-инъекций, где я подробно объяснил все эти вопросы и даже составил раздел, полностью посвященный плохим практикам и их раскрытию.
Я бы рекомендовал использовать PDO (объекты данных PHP) для запуска параметризованных запросов SQL.
Это не только защищает от внедрения SQL, но и ускоряет запросы.
И используя PDO, а не mysql_, mysqli_, а также pgsql_ функции, вы делаете ваше приложение немного более абстрагированным от базы данных, в редких случаях, когда вам приходится переключать поставщиков базы данных.
Использование PDO и подготовленные запросы.
($conn это PDO объект)
$stmt = $conn->prepare("INSERT INTO tbl VALUES(:id, :name)");
$stmt->bindValue(':id', $id);
$stmt->bindValue(':name', $name);
$stmt->execute();
Как видите, люди советуют вам использовать максимально подготовленные высказывания. Это не так, но когда ваш запрос выполняется только один раз за процесс, это может привести к небольшому снижению производительности.
Я столкнулся с этой проблемой, но думаю, что решил ее очень изощренным способом - способом, которым хакеры используют, чтобы избежать использования кавычек. Я использовал это в сочетании с подготовленными утверждениями. Я использую его для предотвращения всевозможных атак с использованием SQL-инъекций.
Мой подход:
Если вы ожидаете, что ввод будет целочисленным, убедитесь, что он действительно целочисленный. В языке переменных типов, таких как PHP, это очень важно. Например, вы можете использовать это очень простое, но мощное решение:
sprintf("SELECT 1,2,3 FROM table WHERE 4 = %u", $input);Если вы ожидаете что-то еще от целого числа, закройте его Если вы это сделаете, вы полностью избежите ввода. В C/C++ есть функция под названием
mysql_hex_string()в PHP вы можете использоватьbin2hex(),Не беспокойтесь о том, что экранированная строка будет иметь двукратный размер по сравнению с первоначальной длиной, потому что даже если вы используете
mysql_real_escape_stringPHP должен выделить такую же емкость((2*input_length)+1), что то же самое.Этот шестнадцатеричный метод часто используется при передаче двоичных данных, но я не вижу причин, почему бы не использовать его для всех данных, чтобы предотвратить атаки с использованием SQL-инъекций. Обратите внимание, что вы должны добавить данные с
0xили используйте функцию MySQLUNHEXвместо.
Так, например, запрос:
SELECT password FROM users WHERE name = 'root'
Станет:
SELECT password FROM users WHERE name = 0x726f6f74
или же
SELECT password FROM users WHERE name = UNHEX('726f6f74')
Гекс это идеальный побег. Нет способа сделать инъекцию.
Разница между функцией UNHEX и префиксом 0x
В комментариях была некоторая дискуссия, поэтому я, наконец, хочу прояснить это. Эти два подхода очень похожи, но они немного отличаются в некоторых отношениях:
Префикс ** 0x** можно использовать только для столбцов данных, таких как char, varchar, text, block, binary и т. Д.
Кроме того, его использование немного сложнее, если вы собираетесь вставить пустую строку. Вам придется полностью заменить его '', или вы получите ошибку.
UNHEX () работает на любом столбце; вам не нужно беспокоиться о пустой строке.
Шестнадцатеричные методы часто используются как атаки
Обратите внимание, что этот шестнадцатеричный метод часто используется как атака SQL-инъекции, где целые числа похожи на строки и экранируются только mysql_real_escape_string, Тогда вы можете избежать использования кавычек.
Например, если вы просто делаете что-то вроде этого:
"SELECT title FROM article WHERE id = " . mysql_real_escape_string($_GET["id"])
атака может сделать вам инъекцию очень легко. Рассмотрим следующий внедренный код, возвращаемый из вашего скрипта:
SELECT... WHERE id = -1 объединить все выбрать имя таблицы из таблицы information_schema.tables
а теперь просто извлеките структуру таблицы:
SELECT... WHERE id = -1 объединить все выбрать столбец_имя из information_schema.column, где имя_таблицы = 0x61727469636c65
А затем просто выберите все данные, которые хотите. Разве это не круто?
Но если кодировщик сайта для инъекций закодирует его, никакое внедрение не будет возможно, потому что запрос будет выглядеть так: SELECT ... WHERE id = UNHEX('2d312075...3635')
ВАЖНЫЙ
Лучший способ предотвратить инъекцию SQL - использовать подготовленные операторы вместо экранирования, как показывает принятый ответ.
Существуют библиотеки, такие как 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.
Предупреждение безопасности: этот ответ не соответствует рекомендациям по безопасности. Экранирование не подходит для предотвращения внедрения SQL, вместо этого используйте подготовленные операторы. Используйте стратегию, изложенную ниже, на свой страх и риск. (Также,
mysql_real_escape_string()был удален в PHP 7.)Устаревшее предупреждение. Расширение mysql в настоящее время устарело. мы рекомендуем использовать расширение mysqli
Вы можете сделать что-то простое, как это:
$safe_variable = mysqli_real_escape_string($_POST["user-input"]);
mysqli_query("INSERT INTO table (column) VALUES ('" . $safe_variable . "')");
Это не решит всех проблем, но это очень хорошая ступенька. Я упустил очевидные элементы, такие как проверка существования переменной, формат (цифры, буквы и т. Д.).
Что бы вы ни делали в конечном итоге, убедитесь, что вы проверили, что ваши данные еще не были искажены magic_quotes или какой-то другой благими намерениями, и, если необходимо, пропустите его stripslashes или что угодно, чтобы продезинфицировать это.
Параметризованный запрос И проверка ввода - путь. Существует много сценариев, при которых может происходить внедрение 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-инъекция (когда побега недостаточно)
На мой взгляд, лучший способ вообще предотвратить внедрение SQL в ваше PHP-приложение (или, в любом случае, любое веб-приложение) - это подумать об архитектуре вашего приложения. Если единственный способ защитить себя от внедрения SQL-кода - это не забывать использовать специальный метод или функцию, которая выполняет правильные действия каждый раз, когда вы обращаетесь к базе данных, вы делаете это неправильно. Таким образом, это просто вопрос времени, пока вы не забудете правильно отформатировать свой запрос в какой-то момент кода.
Принятие шаблона MVC и инфраструктуры, такой как CakePHP или CodeIgniter, вероятно, является правильным решением: общие задачи, такие как создание безопасных запросов к базе данных, были решены и централизованно реализованы в таких платформах. Они помогают разумно организовать ваше веб-приложение и заставляют задуматься о загрузке и сохранении объектов, а не о безопасном построении отдельных SQL-запросов.
Существует много способов предотвращения SQL-инъекций и других SQL-хаков. Вы можете легко найти его в Интернете (поиск Google). Конечно, PDO является одним из хороших решений. Но я хотел бы предложить вам хорошую защиту ссылок от SQL-инъекций.
Что такое 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-инъекция не предотвращена.
Я предпочитаю хранимые процедуры ( MySQL имеет поддержку хранимых процедур с 5.0) с точки зрения безопасности - преимущества -
- Большинство баз данных (включая MySQL) позволяют пользователю ограничивать доступ к выполнению хранимых процедур. Детальное управление безопасным доступом полезно для предотвращения атаки на повышение привилегий. Это не позволяет скомпрометированным приложениям запускать SQL напрямую против базы данных.
- Они абстрагируют необработанный SQL-запрос от приложения, поэтому приложение получает меньше информации о структуре базы данных. Это затрудняет понимание людьми структуры базы данных и разработку подходящих атак.
- Они принимают только параметры, поэтому преимущества параметризованных запросов есть. Конечно - IMO вам все еще нужно санировать ваш ввод - особенно если вы используете динамический SQL внутри хранимой процедуры.
Недостатки -
- Они (хранимые процедуры) сложны в обслуживании и имеют тенденцию очень быстро размножаться. Это делает управление ими проблемой.
- Они не очень подходят для динамических запросов - если они созданы для принятия динамического кода в качестве параметров, то многие преимущества сводятся на нет.
Я думаю, если кто-то хочет использовать PHP и MySQL или какой-либо другой сервер базы данных:
- Подумайте об изучении PDO (PHP Data Objects) - это уровень доступа к базе данных, обеспечивающий единый метод доступа к нескольким базам данных.
- Подумайте об изучении 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();
PS:
PDO выигрывает эту битву с легкостью. Благодаря поддержке двенадцати различных драйверов баз данных и именованных параметров мы можем игнорировать небольшую потерю производительности и привыкнуть к ее API. С точки зрения безопасности, они оба безопасны, если разработчик использует их так, как они должны использоваться.
Но хотя PDO и MySQLi работают довольно быстро, MySQLi работает незначительно быстрее в тестах - ~2,5% для неподготовленных операторов и ~6,5% для подготовленных.
И, пожалуйста, проверяйте каждый запрос к вашей базе данных - это лучший способ предотвратить инъекцию.
Если возможно, приведите типы ваших параметров. Но он работает только с простыми типами, такими как int, bool и float.
$unsafe_variable = $_POST['user_id'];
$safe_variable = (int)$unsafe_variable ;
mysqli_query($conn, "INSERT INTO table (column) VALUES ('" . $safe_variable . "')");
Если вы хотите воспользоваться механизмами кэширования, такими как Redis или Memcached, возможно, вам подойдет DALMP. Он использует чистый MySQLi. Проверьте это: Уровень абстракции базы данных DALMP для MySQL с использованием PHP.
Кроме того, вы можете "подготовить" свои аргументы перед подготовкой запроса, чтобы вы могли создавать динамические запросы и в конце получить полностью подготовленный запрос операторов. Уровень абстракции базы данных DALMP для MySQL с использованием PHP.
Для тех, кто не уверен, как использовать PDO (исходя из mysql_ функции), я сделал очень, очень простую оболочку PDO, которая представляет собой один файл. Он существует, чтобы показать, как легко выполнять все обычные задачи, которые необходимо выполнять приложениям. Работает с PostgreSQL, MySQL и SQLite.
В основном, прочитайте его , читая руководство, чтобы узнать, как использовать функции PDO в реальной жизни, чтобы упростить хранение и получение значений в нужном формате.
Я хочу одну колонку
$count = DB::column('SELECT COUNT(*) FROM `user`);Я хочу, чтобы массив (ключ => значение) результатов (т.е. для создания 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));
Несколько рекомендаций по экранированию специальных символов в операторах 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
Используя эту функцию 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
Простую альтернативу этой проблеме можно решить, предоставив соответствующие разрешения в самой базе данных. Например: если вы используете базу данных MySQL, войдите в базу данных через терминал или предоставленный пользовательский интерфейс и просто выполните следующую команду:
GRANT SELECT, INSERT, DELETE ON database TO username@'localhost' IDENTIFIED BY 'password';
Это ограничит пользователя только ограниченным указанным запросом. Удалите разрешение на удаление, чтобы данные никогда не удалялись из запроса, запущенного со страницы PHP. Второе, что нужно сделать, это сбросить привилегии, чтобы MySQL обновил разрешения и обновления.
FLUSH PRIVILEGES;
больше информации о флеше.
Чтобы увидеть текущие привилегии для пользователя, запустите следующий запрос.
select * from mysql.user where User='username';
Узнайте больше о GRANT.
Что касается многих полезных ответов, я надеюсь добавить некоторые значения в этой теме. SQL-инъекция - это атака, которая может быть осуществлена через пользовательские входные данные (входные данные, которые заполняются пользователем, а затем используются внутри запросов). Шаблоны SQL-инъекций представляют собой правильный синтаксис запроса, хотя мы можем его назвать: плохие запросы по плохим причинам, мы предполагаем, что быть плохим человеком, который пытается получить секретную информацию (в обход контроля доступа), которая затрагивает три принципа безопасности (конфиденциальность, целостность, доступность).
Теперь наша цель состоит в том, чтобы предотвратить угрозы безопасности, такие как атаки с использованием SQL-инъекций, задавая вопрос (Как предотвратить атаки с использованием SQL-инъекций с помощью PHP), быть более реалистичными, фильтрация или очистка входных данных - это тот случай, когда пользовательские входные данные внутри таких запрос, использующий PHP или любой другой язык программирования, не соответствует действительности, или как многие люди рекомендуют использовать современные технологии, такие как подготовленные операторы, или любые другие инструменты, которые в настоящее время поддерживают предотвращение SQL-инъекций, считаете, что эти инструменты больше не доступны? Как вы защищаете свое приложение?
Мой подход против внедрения SQL-кода: очистка данных, вводимых пользователем, перед отправкой в базу данных (перед использованием в любом запросе).
Фильтрация данных для (Преобразование небезопасных данных в безопасные данные). Считайте, что PDO и MySQLi недоступны, как вы можете защитить свое приложение? Вы заставляете меня использовать их? А как насчет других языков, кроме PHP? Я предпочитаю давать общие идеи, так как они могут быть использованы для более широкой границы, а не только для конкретного языка.
- Пользователь SQL (ограничение привилегий пользователя): наиболее распространенными операциями SQL являются (SELECT, UPDATE, INSERT), тогда зачем давать привилегию UPDATE пользователю, который в этом не нуждается? Например , страницы входа и поиска используют только SELECT, тогда зачем использовать пользователей БД на этих страницах с высокими привилегиями? ПРАВИЛО: не создавайте одного пользователя базы данных для всех привилегий, для всех операций SQL вы можете создать свою схему, такую как (deluser, selectuser, updateuser), в качестве имен пользователей для простоты использования.
см. принцип наименьших привилегий
Фильтрация данных: перед построением любого запроса пользовательский ввод должен быть проверен и отфильтрован, для программистов важно определить некоторые свойства для каждой пользовательской переменной ввода:тип данных, шаблон данных и длина данных. поле, которое является числом между (x и y), должно быть точно проверено с использованием точного правила, для поля, которое является строкой (текст): шаблон имеет место, например, имя пользователя должно содержать только несколько символов, скажем, [a-zA-Z0-9_-.] длина варьируется между (x и n), где x и n (целые числа, x <=n). Правило: создание точных фильтров и правил проверки - лучшая практика для меня.
Используйте другие инструменты: здесь я также согласен с вами в том, что подготовленные операторы (параметризованный запрос) и хранимые процедуры, недостатками которых являются эти способы, требуют продвинутых навыков, которых нет у большинства пользователей, основная идея здесь заключается в том, чтобы различать SQL запрос и данные, которые используются внутри, оба подхода могут использоваться даже с небезопасными данными, потому что введенные пользователем данные здесь не добавляют ничего к исходному запросу, например (any или x=x). Для получения дополнительной информации, пожалуйста, прочтите OWASP Шпаргалку по предотвращению инъекций.
Теперь, если вы опытный пользователь, начните использовать эту защиту по своему усмотрению, но для новичков, если они не могут быстро реализовать хранимую процедуру и подготовить оператор, лучше отфильтровать входные данные, насколько это возможно.
Наконец, давайте рассмотрим, что пользователь отправляет этот текст ниже вместо ввода своего имени пользователя:
[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: экранирование всех вводимых пользователем данных
Дополнительные защиты:
Также Enforce: Наименьшая привилегия
Также выполнить: проверка ввода белого списка
Как вы, возможно, знаете, утверждение статьи должно быть подтверждено действительным аргументом, хотя бы одной ссылкой! В противном случае это считается атакой и плохим требованием!
Update2:
Из руководства по PHP, PHP: Подготовленные заявления - Руководство:
Экранирование и внедрение 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 отправляет подготовленный запрос, оба дают одинаковый результат.
Рекомендации:
Я использую три различных способа предотвращения уязвимости моего веб-приложения для внедрения 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";
Этот вопрос имеет несколько хороших ответов об этом.
Я предлагаю использовать PDO - лучший вариант.
Редактировать:
mysql_real_escape_string() устарел начиная с PHP 5.5.0. Используйте либо MySQL, либо 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");
Простым способом было бы использовать PHP-фреймворк, такой как CodeIgniter или Laravel, который имеет встроенные функции, такие как фильтрация и активная запись, чтобы вам не приходилось беспокоиться об этих нюансах.
** Предупреждение: подход, описанный в этом ответе, применим только к очень конкретным сценариям и небезопасен, так как атаки с использованием 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-адрес злоумышленника, или ДАЖЕ ИХ КУКИ, историю, браузер или любой другой конфиденциальный информация, так что вы можете иметь дело с ними позже, заблокировав их учетную запись или связавшись с властями.
Хорошая идея - использовать "объектно-реляционный маппер", такой как 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-инъекций, но и от синтаксических ошибок! Также поддерживает коллекции моделей с цепочкой методов для фильтрации или применения действий к нескольким результатам одновременно и нескольким соединениям.
Существует множество ответов на 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);
Использование PDO и MYSQLi - хорошая практика для предотвращения SQL-инъекций, но если вы действительно хотите работать с функциями и запросами MySQL, было бы лучше использовать
$unsafe_variable = mysql_real_escape_string($_POST['user_input']);
Есть больше возможностей предотвратить это: например, определить - если входные данные являются строкой, числом, символом или массивом, существует так много встроенных функций, чтобы обнаружить это. Также было бы лучше использовать эти функции для проверки входных данных.
$unsafe_variable = (is_string($_POST['user_input']) ? $_POST['user_input'] : '');
$unsafe_variable = (is_numeric($_POST['user_input']) ? $_POST['user_input'] : '');
И гораздо лучше использовать эти функции для проверки входных данных с mysql_real_escape_string,
Я написал эту маленькую функцию несколько лет назад:
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\'s 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;
}
Это позволяет запускать операторы в однострочном C#-ish String.Format, например:
runEscapedQuery("INSERT INTO Whatever (id, foo, bar) VALUES ({0}, {1}, {2})", $numericVar, $stringVar1, $stringVar2);
Он избегает, учитывая тип переменной. Если вы попытаетесь параметризировать имена таблиц и столбцов, произойдет сбой, поскольку каждая строка будет заключена в кавычки, что является недопустимым синтаксисом.
ОБНОВЛЕНИЕ БЕЗОПАСНОСТИ: Предыдущее str_replace Версия допускает инъекции, добавляя токены {#} в пользовательские данные. это preg_replace_callback Версия не вызывает проблем, если замена содержит эти токены.