¿Cómo puedo prevenir la inyección SQL en PHP?

Si la entrada del usuario se inserta sin modificación en una consulta SQL, entonces la aplicación se vuelve vulnerable a la inyección SQL , como en el siguiente ejemplo:

$unsafe_variable = $_POST['user_input']; mysql_query("INSERT INTO `table` (`column`) VALUES ('$unsafe_variable')"); 

Eso es porque el usuario puede ingresar algo como value'); DROP TABLE table;-- value'); DROP TABLE table;-- , y la consulta se convierte en:

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

¿Qué se puede hacer para evitar que esto suceda?

Use declaraciones preparadas y consultas parametrizadas. Estas son sentencias SQL que el servidor de la base de datos envía y analiza independientemente de cualquier parámetro. De esta forma, es imposible para un atacante inyectar SQL malicioso.

Básicamente tienes dos opciones para lograr esto:

  1. Usando PDO (para cualquier controlador de base de datos compatible):

     $stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name'); $stmt->execute(array('name' => $name)); foreach ($stmt as $row) { // do something with $row } 
  2. Usando MySQLi (para 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 } 

Si se está conectando a una base de datos que no es MySQL, hay una segunda opción específica del controlador a la que puede hacer referencia (por ejemplo, pg_prepare() y pg_execute() para PostgreSQL). PDO es la opción universal.

Configurar correctamente la conexión

Tenga en cuenta que al usar PDO para acceder a una base de datos MySQL, las declaraciones preparadas de verdad no se usan por defecto . Para solucionar esto, debe desactivar la emulación de las declaraciones preparadas. Un ejemplo de crear una conexión usando PDO es:

 $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); 

En el ejemplo anterior, el modo de error no es estrictamente necesario, pero se recomienda agregarlo . De esta forma, la secuencia de comandos no se detendrá con un Fatal Error cuando algo salga mal. Y le da al desarrollador la oportunidad de catch cualquier error que se throw n como PDOException .

Sin embargo, lo que es obligatorio es la primera línea setAttribute() , que le dice a PDO que deshabilite las declaraciones preparadas emuladas y que use las declaraciones preparadas reales . Esto asegura que PHP no analiza la statement y los valores antes de enviarlos al servidor MySQL (lo que da al posible atacante la posibilidad de inyectar SQL malicioso).

Aunque puede establecer el juego de charset en las opciones del constructor, es importante tener en cuenta que las versiones “anteriores” de PHP (<5.3.6) ignoraron silenciosamente el parámetro del juego de caracteres en el DSN.

Explicación

Lo que ocurre es que la statement SQL que pasa a prepare es analizada y comstackda por el servidor de la base de datos. Al especificar los parámetros (ya sea un ? O un parámetro nombrado como :name en el ejemplo anterior) le dice al motor de la base de datos donde desea filtrar. Luego, cuando execute , la instrucción preparada se combinará con los valores de parámetros que especifique.

Lo importante aquí es que los valores de los parámetros se combinan con la statement comstackda, no con una cadena de SQL. La inyección SQL funciona al engañar al script para que incluya cadenas maliciosas cuando crea SQL para enviar a la base de datos. Entonces al enviar el SQL real por separado de los parámetros, usted limita el riesgo de terminar con algo que no pretendía. Cualquier parámetro que envíe al usar una statement preparada simplemente se tratará como cadenas (aunque el motor de la base de datos puede hacer algo de optimización para que los parámetros también puedan terminar como números, por supuesto). En el ejemplo anterior, si la variable $name contiene 'Sarah'; DELETE FROM employees 'Sarah'; DELETE FROM employees el resultado sería simplemente una búsqueda de la cadena "'Sarah'; DELETE FROM employees" , y no terminará con una tabla vacía .

Otro beneficio del uso de declaraciones preparadas es que si ejecuta la misma statement muchas veces en la misma sesión, solo se analizará y comstackrá una vez, lo que le dará algunas ganancias de velocidad.

Ah, y ya que preguntaste cómo hacerlo para insertar, aquí hay un ejemplo (usando PDO):

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

¿Se pueden usar declaraciones preparadas para consultas dinámicas?

Si bien aún puede usar declaraciones preparadas para los parámetros de consulta, la estructura de la consulta dinámica en sí no se puede parametrizar y ciertas características de consulta no se pueden parametrizar.

Para estos escenarios específicos, lo mejor que puede hacer es usar un filtro de lista blanca que restrinja los valores posibles.

 // Value whitelist // $dir can only be 'DESC' otherwise it will be 'ASC' if (empty($dir) || $dir !== 'DESC') { $dir = 'ASC'; } 

Advertencia: El código de muestra de esta respuesta (como el código de muestra de la pregunta) usa la extensión de mysql de PHP, que se desaprobó en PHP 5.5.0 y se eliminó por completo en PHP 7.0.0.

Si está utilizando una versión reciente de PHP, la opción mysql_real_escape_string describe a continuación ya no estará disponible (aunque mysqli::escape_string es un equivalente moderno). En estos días, la opción mysql_real_escape_string solo tendría sentido para el código heredado en una versión anterior de PHP.


Tienes dos opciones: escapar de los caracteres especiales en tu unsafe_variable o usar una consulta parametrizada. Ambos lo protegerían de la inyección de SQL. La consulta parametrizada se considera la mejor práctica, pero requerirá cambiar a una nueva extensión mysql en PHP antes de poder usarla.

Cubriremos la cadena de impacto más baja escapando primero.

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

Ver también, los detalles de la función mysql_real_escape_string .

Para utilizar la consulta parametrizada, necesita utilizar MySQLi en lugar de las funciones de MySQL . Para volver a escribir su ejemplo, necesitaríamos algo como lo siguiente.

 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(); ?> 

La función clave que querrá leer aquí sería mysqli::prepare .

Además, como otros han sugerido, puede resultarle útil / más fácil boost una capa de abstracción con algo como PDO .

Tenga en cuenta que el caso sobre el que preguntó es bastante simple y que casos más complejos pueden requerir enfoques más complejos. En particular:

  • Si desea modificar la estructura del SQL según la entrada del usuario, las consultas parametrizadas no ayudarán, y el escape requerido no está cubierto por mysql_real_escape_string . En este tipo de caso, sería mejor pasar la entrada del usuario a través de una lista blanca para garantizar que solo se permitan los valores ‘seguros’.
  • Si utiliza números enteros de la entrada del usuario en una condición y toma el enfoque mysql_real_escape_string , sufrirá el problema descrito por Polinomio en los comentarios a continuación. Este caso es más complicado porque los enteros no estarían rodeados de comillas, por lo que podría tratar validando que la entrada del usuario contenga solo dígitos.
  • Es probable que haya otros casos de los que no tengo conocimiento. Puede encontrar que este es un recurso útil en algunos de los problemas más sutiles que puede encontrar.

Cada respuesta aquí cubre solo una parte del problema.
De hecho, hay cuatro partes de consulta diferentes que podemos agregar de forma dinámica:

  • una cuerda
  • un número
  • un identificador
  • una palabra clave de syntax

y las declaraciones preparadas cubren solo 2 de ellas

Pero a veces tenemos que hacer que nuestra consulta sea aún más dinámica, agregando operadores o identificadores también.
Entonces, necesitaremos diferentes técnicas de protección.

En general, dicho enfoque de protección se basa en la inclusión de listas blancas . En este caso, todos los parámetros dynamics deben estar codificados en su secuencia de comandos y elegidos de ese conjunto.
Por ejemplo, para hacer un pedido dynamic:

 $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 

Sin embargo, hay otra forma de proteger los identificadores: escapar. Siempre que tengas un identificador citado, puedes escapar de los palos de atrás en el interior al doblarlos.

Como un paso más, podemos tomar prestada una idea realmente shiny de usar algún marcador de posición (un proxy para representar el valor real en la consulta) de las declaraciones preparadas e inventar un marcador de posición de otro tipo – un marcador de posición identificador.

Entonces, para resumir la larga historia: es un marcador de posición , una statement no preparada puede considerarse como una bala de plata.

Por lo tanto, una recomendación general puede formularse como
Siempre que agregue partes dinámicas a la consulta utilizando marcadores de posición (y estos marcadores de posición procesados ​​correctamente por supuesto), puede estar seguro de que su consulta es segura .

Aún así, existe un problema con las palabras clave de syntax de SQL (como AND , DESC y DESC ), pero la inclusión de listas blancas parece ser el único enfoque en este caso.

Actualizar

Aunque existe un acuerdo general sobre las mejores prácticas en materia de protección de inyección SQL, también existen muchas malas prácticas. Y algunos de ellos están muy arraigados en la mente de los usuarios de PHP. Por ejemplo, en esta misma página hay (aunque son invisibles para la mayoría de los visitantes) más de 80 respuestas eliminadas , todas eliminadas por la comunidad debido a la mala calidad o la promoción de prácticas desagradables y desactualizadas. Peor aún, algunas de las malas respuestas no se eliminan, sino que prosperan.

Por ejemplo, hay (1) son (2) todavía (3) muchas (4) respuestas (5) , incluida la segunda respuesta más votada que sugiere el escape manual de cadenas: un enfoque desactualizado que se ha demostrado inseguro.

O hay una respuesta ligeramente mejor que sugiere simplemente otro método de formateo de cadenas e incluso lo presume como la última panacea. Si bien, por supuesto, no lo es. Este método no es mejor que el formato de cadena regular, pero conserva todos sus inconvenientes: se aplica únicamente a las cadenas y, como cualquier otro formateo manual, es esencialmente opcional, no obligatorio, propenso a errores humanos de cualquier tipo.

Creo que todo esto debido a una superstición muy antigua, respaldada por autoridades como el manual OWASP o PHP , que proclama la igualdad entre lo que sea que “escape” y la protección contra las inyecciones de SQL.

Independientemente de lo que diga el manual de PHP durante años, *_escape_string de ninguna manera hace que los datos sean seguros y nunca se ha tenido la intención de hacerlo. Además de ser inútil para cualquier parte de SQL que no sea una cadena, el escapado manual es incorrecto porque es manual, lo contrario que automatizado.

Y OWASP lo empeora aún más, haciendo hincapié en escapar de la entrada del usuario, lo cual es una completa tontería: no deberían existir tales palabras en el contexto de la protección de inyección. Cada variable es potencialmente peligrosa, ¡sin importar la fuente! O, en otras palabras, todas las variables deben estar formateadas adecuadamente para ser puestas en una consulta, sin importar la fuente de nuevo. Es el destino lo que importa. En el momento en que un desarrollador comienza a separar las ovejas de las cabras (pensando si alguna variable en particular es “segura” o no), da el primer paso hacia el desastre. Sin mencionar que incluso la redacción sugiere un escape masivo en el punto de entrada, que se asemeja a la función de comillas muy mágicas, ya despreciadas, obsoletas y eliminadas.

Entonces, a diferencia de lo que “escapa”, las declaraciones preparadas son la medida que de hecho protege de la inyección SQL (cuando corresponda).

Si todavía no está convencido, aquí hay una explicación paso a paso que escribí, La guía del autoestopista para la prevención de inyección SQL , donde expliqué todos estos asuntos en detalle e incluso compilé una sección dedicada por completo a las malas prácticas y su divulgación.

Recomiendo usar PDO (objetos de datos PHP) para ejecutar consultas SQL parametrizadas.

Esto no solo protege contra la inyección de SQL, sino que también acelera las consultas.

Y al usar las mysql_ PDO en lugar de mysql_ , mysqli_ y pgsql_ , su aplicación se abstrae un poco de la base de datos, en el caso poco frecuente de que tenga que cambiar de proveedores de bases de datos.

Use PDO y consultas preparadas.

( $conn es un objeto PDO )

 $stmt = $conn->prepare("INSERT INTO tbl VALUES(:id, :name)"); $stmt->bindValue(':id', $id); $stmt->bindValue(':name', $name); $stmt->execute(); 

Como puede ver, las personas sugieren que use declaraciones preparadas como máximo. No está mal, pero cuando tu consulta se ejecuta solo una vez por proceso, habrá una leve penalización de rendimiento.

Estaba enfrentando este problema, pero creo que lo resolví de una manera muy sofisticada: la forma en que los piratas informáticos usan para evitar el uso de comillas. Usé esto junto con declaraciones preparadas emuladas. Lo uso para prevenir todo tipo de posibles ataques de inyección SQL.

Mi acercamiento:

  • Si espera que la entrada sea entera, asegúrese de que sea realmente entera. En un lenguaje de tipo variable como PHP, es muy importante. Puede usar, por ejemplo, esta solución muy simple pero potente: sprintf("SELECT 1,2,3 FROM table WHERE 4 = %u", $input);

  • Si esperas algo más del número entero, hexágalo . Si lo haces, escaparás perfectamente de todas las entradas. En C / C ++ hay una función llamada mysql_hex_string() , en PHP puedes usar bin2hex() .

    No se preocupe porque la cadena escapada tendrá un tamaño 2x de su longitud original porque incluso si usa mysql_real_escape_string , PHP tiene que asignar la misma capacidad ((2*input_length)+1) , que es lo mismo.

  • Este método hexadecimal a menudo se usa cuando transfieres datos binarios, pero no veo ninguna razón para no usarlo en todos los datos para evitar ataques de inyección SQL. Tenga en cuenta que debe anteponer datos con 0x o usar la función MySQL UNHEX en UNHEX lugar.

Entonces, por ejemplo, la consulta:

 SELECT password FROM users WHERE name = 'root' 

Se convertirá:

 SELECT password FROM users WHERE name = 0x726f6f74 

o

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

Hex es el escape perfecto. No hay forma de inyectar

Diferencia entre la función UNHEX y el prefijo 0x

Hubo algo de discusión en los comentarios, así que finalmente quiero dejarlo en claro. Estos dos enfoques son muy similares, pero son un poco diferentes en algunos aspectos:

El prefijo ** 0x ** solo se puede usar para columnas de datos como char, varchar, text, block, binary, etc.
Además, su uso es un poco complicado si está por insertar una cadena vacía. Tendrás que reemplazarlo por completo con '' , o obtendrás un error.

UNHEX () funciona en cualquier columna; no tiene que preocuparse por la cadena vacía.


Los métodos hexadecimales a menudo se usan como ataques

Tenga en cuenta que este método hexadecimal a menudo se usa como un ataque de inyección SQL donde los enteros son como cadenas y se escapan solo con mysql_real_escape_string . Entonces puedes evitar el uso de comillas.

Por ejemplo, si solo haces algo como esto:

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

un ataque puede inyectarte muy fácilmente . Considere el siguiente código inyectado devuelto por su script:

SELECCIONAR … DONDE id = -1 unión seleccionar todo table_name de information_schema.tables

y ahora solo extrae la estructura de la tabla:

SELECCIONAR … DONDE id = -1 unión, todos seleccionan column_name de information_schema.column donde table_name = 0x61727469636c65

Y luego solo selecciona los datos que desees. ¿No es genial?

Pero si el codificador de un sitio inyectable lo hexagonal, no sería posible inyectar porque la consulta sería así: SELECT ... WHERE id = UNHEX('2d312075...3635')

IMPORTANTE

La mejor manera de evitar la inyección de SQL es usar declaraciones preparadas en lugar de escapar , como lo demuestra la respuesta aceptada .

Hay bibliotecas como Aura.Sql y EasyDB que les permiten a los desarrolladores usar declaraciones preparadas más fácilmente. Para obtener más información acerca de por qué las declaraciones preparadas son mejores para detener la inyección de SQL , consulte esta mysql_real_escape_string() y solucione las vulnerabilidades de Inyección SQL Unicode recientemente en WordPress .

Prevención de inyección: mysql_real_escape_string ()

PHP tiene una función especialmente diseñada para prevenir estos ataques. Todo lo que necesitas hacer es usar la bocanada de una función, mysql_real_escape_string .

mysql_real_escape_string toma una cadena que se usará en una consulta MySQL y devuelve la misma cadena con todos los bashs de inyección SQL escapados de forma segura. Básicamente, reemplazará esas citas problemáticas (‘) un usuario podría ingresar con un sustituto seguro de MySQL, una cita escapada \’.

NOTA: ¡debe estar conectado a la base de datos para usar esta función!

// Conectarse a 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: 
" . $query_bad . "
"; $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:
" . $query_evil;

Puede encontrar más detalles en MySQL – SQL Injection Prevention .

Advertencia de seguridad : esta respuesta no está en línea con las mejores prácticas de seguridad. Escapar es inadecuado para evitar la inyección de SQL ; en su lugar, use declaraciones preparadas . Use la estrategia descrita debajo bajo su propio riesgo. (Además, mysql_real_escape_string() se eliminó en PHP 7.)

Podrías hacer algo básico como esto:

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

Esto no resolverá todos los problemas, pero es un buen trampolín. Olvidé elementos obvios como verificar la existencia de la variable, el formato (números, letras, etc.).

Lo que sea que magic_quotes usando, asegúrate de comprobar que tu entrada no haya sido magic_quotes por magic_quotes o alguna otra basura bienintencionada, y si es necesario, stripslashes través de stripslashes o lo que sea para desinfectarla.

La consulta parametrizada Y la validación de entrada es el camino a seguir. Hay muchos escenarios en los que se puede producir inyección SQL, aunque se haya utilizado mysql_real_escape_string() .

Esos ejemplos son vulnerables a la inyección 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"); 

o

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

En ambos casos, no puede usar ' para proteger la encapsulación.

Fuente : la inyección inesperada de SQL (cuando escaparse no es suficiente)

En mi opinión, la mejor manera de evitar la inyección de SQL en su aplicación PHP (o cualquier aplicación web, en realidad) es pensar en la architecture de su aplicación. Si la única forma de protegerse contra la inyección de SQL es recordar utilizar un método o función especial que haga Lo correcto cada vez que hable con la base de datos, lo está haciendo mal. De esta forma, solo es cuestión de tiempo hasta que te olvides de formatear correctamente tu consulta en algún punto de tu código.

Adoptar el patrón MVC y un framework como CakePHP o CodeIgniter es probablemente el camino correcto: tareas comunes como crear consultas de bases de datos seguras se han resuelto e implementado de forma centralizada en dichos marcos. Te ayudan a organizar tu aplicación web de una manera sensata y te hacen pensar más sobre la carga y el almacenamiento de objetos que sobre la construcción segura de consultas SQL individuales.

I favor stored procedures ( MySQL has had stored procedures support since 5.0 ) from a security point of view – the advantages are –

  1. Most databases (including MySQL ) enable user access to be restricted to executing stored procedures. The fine-grained security access control is useful to prevent escalation of privileges attacks. This prevents compromised applications from being able to run SQL directly against the database.
  2. They abstract the raw SQL query from the application so less information of the database structure is available to the application. This makes it harder for people to understand the underlying structure of the database and design suitable attacks.
  3. They accept only parameters, so the advantages of parameterized queries are there. Of course – IMO you still need to sanitize your input – especially if you are using dynamic SQL inside the stored procedure.

The disadvantages are –

  1. They (stored procedures) are tough to maintain and tend to multiply very quickly. This makes managing them an issue.
  2. They are not very suitable for dynamic queries – if they are built to accept dynamic code as parameters then a lot of the advantages are negated.

There are many ways of preventing SQL injections and other SQL hacks. You can easily find it on the Internet (Google Search). Of course PDO is one of the good solutions. But I would like to suggest you some good links prevention from SQL Injection.

What is SQL injection and how to prevent

PHP manual for SQL injection

Microsoft explanation of SQL injection and prevention in PHP

and some other like Preventing SQL injection with MySQL and PHP

Now, why you do you need to prevent your query from SQL injection?

I would like to let you know: Why do we try for preventing SQL injection with a short example below:

Query for login authentication match:

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

Now, if someone (a hacker) puts

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

and password anything….

The query will be parsed into the system only up to:

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

The other part will be discarded. So, what will happen? A non-authorized user (hacker) will be able to log in as admin without having his password. Now, he can do anything that admin/email person can do. See, it’s very dangerous if SQL injection is not prevented.

I think if someone wants to use PHP and MySQL or some other dataBase server:

  1. Think about learning PDO (PHP Data Objects) – it is a database access layer providing a uniform method of access to multiple databases.
  2. Think about learning MySQLi
  3. Use native PHP functions like: strip_tags , mysql_real_escape_string or if variable numeric, just (int)$foo . Read more about type of variables in PHP here . If you’re using libraries such as PDO or MySQLi, always use PDO::quote() and mysqli_real_escape_string() .

Libraries examples:

—- PDO

—– No placeholders – ripe for SQL injection! It’s bad

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

—– Unnamed placeholders

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

—– Named placeholders

 $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 wins this battle with ease. With support for twelve different database drivers and named parameters, we can ignore the small performance loss, and get used to its API. From a security standpoint, both of them are safe as long as the developer uses them the way they are supposed to be used

But while both PDO and MySQLi are quite fast, MySQLi performs insignificantly faster in benchmarks – ~2.5% for non-prepared statements, and ~6.5% for prepared ones.

And please test every query to your database – it’s a better way to prevent injection.

If possible, cast the types of your parameters. But it’s only working on simple types like int, bool, and float.

 $unsafe_variable = $_POST['user_id']; $safe_variable = (int)$unsafe_variable ; mysqli_query($conn, "INSERT INTO table (column) VALUES ('" . $safe_variable . "')"); 

If you want to take advantage of cache engines, like Redis or Memcached , maybe DALMP could be a choice. It uses pure MySQLi . Check this: DALMP Database Abstraction Layer for MySQL using PHP.

Also, you can ‘prepare’ your arguments before preparing your query so that you can build dynamic queries and at the end have a fully prepared statements query. DALMP Database Abstraction Layer for MySQL using PHP.

Using this PHP function mysql_escape_string() you can get a good prevention in a fast way.

Por ejemplo:

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

mysql_escape_string — Escapes a string for use in a mysql_query

For more prevention, you can add at the end …

 wHERE 1=1 or LIMIT 1 

Finally you get:

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

For those unsure of how to use PDO (coming from the mysql_ functions), I made a very, very simple PDO wrapper that is a single file. It exists to show how easy it is to do all the common things applications need to be done. Works with PostgreSQL, MySQL, and SQLite.

Basically, read it while you read the manual to see how to put the PDO functions to use in real life to make it simple to store and retrieve values in the format you want.

I want a single column

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

I want an array(key => value) results (ie for making a selectbox)

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

I want a single row result

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

I want an array of results

 $banned_users = DB::fetch('SELECT * FROM `user` WHERE `banned` = ?', array(TRUE)); 

A few guidelines for escaping special characters in SQL statements.

Don’t use MySQL , this extension is deprecated, use MySQLi or PDO .

MySQLi

For manually escaping special characters in a string you can use the mysqli_real_escape_string function. The function will not work properly unless the correct character set is set with mysqli_set_charset .

Ejemplo:

 $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')" ); 

For automatic escaping of values with prepared statements, use mysqli_prepare , and mysqli_stmt_bind_param where types for the corresponding bind variables must be provided for an appropriate conversion:

Ejemplo:

 $stmt = $mysqli->prepare( "INSERT INTO table ( column1, column2 ) VALUES (?,?)" ); $stmt->bind_param( "is", $integer, $string ); $stmt->execute(); 

No matter if you use prepared statements or mysqli_real_escape_string, you always have to know the type of input data you’re working with.

So if you use a prepared statement, you must specify the types of the variables for mysqli_stmt_bind_param function.

And the use of mysqli_real_escape_string is for, as the name says, escaping special characters in a string, so it will not make integers safe. The purpose of this function is to prevent breaking the strings in SQL statements, and the damage to the database that it could cause. mysqli_real_escape_string is a useful function when used properly, especially when combined with sprintf.

Ejemplo:

 $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 

The simple alternative to this problem could be solved by granting appropriate permissions in the database itself. For example: if you are using a mysql database then enter into the database through terminal or the UI provided and just follow this command:

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

This will restrict the user to only get confined with the specified query’s only. Remove the delete permission and so the data would never get deleted from the query fired from the php page. The second thing to do is to flush the privileges so that the mysql refreshes the permissions and updates.

 FLUSH PRIVILEGES; 

more information about flush .

To see the current privileges for the user fire the following query.

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

Learn more about GRANT .

I use three different ways to prevent my web application from being vulnerable to SQL injection.

  1. Use of mysql_real_escape_string() , which is a pre-defined function in PHP , and this code add backslashes to the following characters: \x00 , \n , \r , \ , ' , " and \x1a . Pass the input values as parameters to minimize the chance of SQL injection.
  2. The most advanced way is to use PDOs.

I hope this will help you.

Considere la siguiente consulta:

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

mysql_real_escape_string() will not protect here. If you use single quotes (‘ ‘) around your variables inside your query is what protects you against this. Here is an solution below for this:

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

This question has some good answers about this.

I suggest, using PDO is the best option.

Editar:

mysql_real_escape_string() is deprecated as of PHP 5.5.0. Use either mysqli or PDO.

An alternative to mysql_real_escape_string() is

 string mysqli_real_escape_string ( mysqli $link , string $escapestr ) 

Ejemplo:

 $iId = $mysqli->real_escape_string("1 OR 1=1"); $mysqli->query("SELECT * FROM table WHERE id = $iId"); 

A simple way would be to use a PHP framework like CodeIgniter or Laravel which have inbuilt features like filtering and active-record so that you don’t have to worry about these nuances.

Regarding many useful answers, I hope to add some values to this thread. SQL injection is an attack that can be done through user inputs (Inputs that filled by user and then used inside queries), The SQL injection patterns are correct query syntax while we can call it: bad queries for bad reasons, we assume that there might be bad person that try to get secret information (bypassing access control) that affect the three principles of security (Confidentiality, Integrity, Availability).

Now, our point is to prevent security threats such as SQL injection attacks, the question asking (How to prevent SQL injection attack using PHP), be more realistic, data filtering or clearing input data is the case when using user-input data inside such query, using PHP or any other programming language is not the case, or as recommended by more people to use modern technology such as prepared statement or any other tools that currently supporting SQL injection prevention, consider that these tools not available anymore? How you secure your application?

My approach against SQL injection is: clearing user-input data before sending it to the database (before using it inside any query).

Data filtering for (Converting unsafe data to safe data) Consider that PDO and MySQLi not available, how can you secure your application? Do you force me to use them? What about other languages other than PHP? I prefer to provide general ideas as it can be used for wider border not just for specific language.

  1. SQL user (limiting user privilege): most common SQL operations are (SELECT, UPDATE, INSERT), then, why giving UPDATE privilege to a user that not require it? For example login, and search pages are only using SELECT, then, why using DB users in these pages with high privileges? RULE: do not create one database user for all privileges, for all SQL operations, you can create your scheme like (deluser, selectuser, updateuser) as usernames for easy usage.

see Principle of least privilege

  1. Data filtering: before building any query user input should be validated and filtered, for programmers, it’s important to define some properties for each user-input variables: data type, data pattern, and data length . a field that is a number between (x and y) must be exactly validated using exact rule, for a field that is a string (text): pattern is the case, for example, username must contain only some characters lets say [a-zA-Z0-9_-.] the length varies between (x and n) where x and n (integers, x <=n ). Rule: creating exact filters and validation rules are best practice for me.

  2. Use other tools: Here, I will also agree with you that prepared statement (parametrized query) and Stored procedures, the disadvantages here is these ways requires advanced skills which do not exist for most users, the basic idea here is to distinguish between SQL query and the data that being used inside, both approaches can be used even with unsafe data, because the user-input data here not add anything to the original query such as (any or x=x). For more information, please read OWASP SQL Injection Prevention Cheat Sheet .

Now, if you are an advanced user, start using this defense as you like, but, for beginners, if they can’t quickly implement stored procedure and prepared the statement, it’s better to filter input data as much they can.

Finally, let’s consider that user sends this text below instead of entering his username:

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

This input can be checked early without any prepared statement and stored procedures, but to be on safe side, using them starts after user-data filtering and validation.

The last point is detecting unexpected behavior which requires more effort and complexity; it’s not recommended for normal web applications. Unexpected behavior in above user input is SELECT, UNION, IF, SUBSTRING, BENCHMARK, SHA, root once these words detected, you can avoid the input.

UPDATE1:

A user commented that this post is useless, OK! Here is what OWASP.ORG provided:

Primary defenses:

Option #1: Use of Prepared Statements (Parameterized Queries)
Option #2: Use of Stored Procedures
Option #3: Escaping all User Supplied Input

Additional defenses:

Also Enforce: Least Privilege
Also Perform: White List Input Validation

As you may know, claiming on an article should be supported by valid argument, at least one reference! Otherwise, it’s considered as an attack and bad claim!

Actualización2:

From the PHP manual, PHP: Prepared Statements – Manual :

Escaping and SQL injection

Bound variables will be escaped automatically by the server. The server inserts their escaped values at the appropriate places into the statement template before execution. A hint must be provided to the server for the type of bound variable, to create an appropriate conversion. See the mysqli_stmt_bind_param() function for more information.

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.

Update3:

I created test cases for knowing how PDO and MySQLi send the query to MySQL server when using prepared statement:

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)); 

Query Log:

  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(); 

Query Log:

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

It’s clear that a prepared statement is also escaping the data, nothing else.

As also mentioned in above statement 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 , therefore, this proves that data validation such as intval() is a good idea for integer values before sending any query, in addition, preventing malicious user data before sending the query is correct and valid approach .

Please see this question for more detail: PDO sends raw query to MySQL while Mysqli sends prepared query, both produce the same result

Referencias

  1. SQL Injection Cheat Sheet
  2. Inyección SQL
  3. Seguridad de información
  4. Security Principles
  5. Data validation

** Warning: the approach described in this answer only applies to very specific scenarios and isn’t secure since SQL injection attacks do not only rely on being able to inject X=Y .**

If the attackers are trying to hack into the form via PHP’s $_GET variable or with the URL’s query string, you would be able to catch them if they’re not secure.

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

Because 1=1 , 2=2 , 1=2 , 2=1 , 1+1=2 , etc… are the common questions to an SQL database of an attacker. Maybe also it’s used by many hacking applications.

But you must be careful, that you must not rewrite a safe query from your site. The code above is giving you a tip, to rewrite or redirect (it depends on you) that hacking-specific dynamic query string into a page that will store the attacker’s IP address , or EVEN THEIR COOKIES, history, browser, or any other sensitive information, so you can deal with them later by banning their account or contacting authorities.

There are so many answers for PHP and MySQL , but here is code for PHP and Oracle for preventing SQL injection as well as regular use of oci8 drivers:

 $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); 

A good idea is to use an ‘object-relational mapper’ like 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; } 

It not only saves you from SQL injections but from syntax errors too! Also Supports collections of models with method chaining to filter or apply actions to multiple results at once and multiple connections.

Using PDO and MYSQLi is a good practice to prevent SQL injections, but if you really want to work with MySQL functions and queries, it would be better to use

mysql_real_escape_string

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

There are more abilities to prevent this: like identify – if the input is a string, number, char or array, there are so many inbuilt functions to detect this. Also, it would be better to use these functions to check input data.

is_string

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

is_numeric

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

And it is so much better to use those functions to check input data with mysql_real_escape_string .

I’ve written this little function several years ago:

 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; } 

This allows running statements in an one-liner C#-ish String.Format like:

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

It escapes considering the variable type. If you try to parameterize table, column names, it would fail as it puts every string in quotes which is an invalid syntax.

SECURITY UPDATE: The previous str_replace version allowed injections by adding {#} tokens into user data. This preg_replace_callback version doesn’t cause problems if the replacement contains these tokens.