La protección de Inocencio MySQL de inyección SQL
Autor:
Ashfaq Ansari

Comentado por:
Clasificación:
5
En Octubre 19, 2012
Última modificación:Enero 18, 2013

Resumen:

Guía detallada sobre cómo prevenir la inyección de MySQL en PHP. Fijar reglas de codificación y funciones id="e6mp8h8j4t3_8"> class="e6mp8h8j4t3" para evitar la inyección SQL.

Introducción

 

Esta es una breve guía sobre cómo proteger su inocencia MySQL base de datos desde Inyección SQL ataques.
 

¿Qué es la inyección de SQL?

 

Como su nombre indica, SQL Injection se produce cuando el usuario inyecta sentencias SQL en la aplicación.
 
¿Cómo sucede esto?
 
Digamos que tenemos un formulario de acceso simple que toma un nombre de usuario y contraseña, y valida contra la base de datos. Si se valida el nombre de usuario y contraseña, el usuario ha iniciado sesión en el sistema.
 

El código para esto podría ser algo como esto:
 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?php
// conseguir que el usuario y contraseña de la petición POST
$nombre_usuario = $_POST[ 'Username' ];
$contraseña  = $_POST[ 'Password' ];

$pregunta = "SELECT nombre apellido, last_name, ACCOUNT_NUMBER DE users_table DONDE username = '$nombre_usuario'AND password ='$contraseña' ";

$resultar = mysql_query( $pregunta );

// comprobar si mysql encontró nada, y obtener el registro si tenía éxito
si ( mysql_num_rows( $resultar ) > 0 ) {
    $datos = mysql_fetch_assoc( $resultar );
    eco 'Welcome' . $usuario . '!';
    eco "Su número de cuenta es: ' . $datos[ '-Cuenta' ] . '';
} //Imprima el mensaje errorr
más {
    eco 'Nombre de usuario o contraseña no es válida! Por favor, vuelve a intentarlo!';
}
?>

 

El script de arriba funciona bien y que permitirá a los usuarios genuinos para introducir su nombre de usuario y la contraseña para ver su número de cuenta bancaria.
 

Supongamos que entro “manifestación” como mi nombre de usuario, y “demopass” como mi contraseña, a continuación, la consulta SQL que se pasa a la MySQL tiene este aspecto:
 

1
SELECT 'nombre, last_name, ACCOUNT_NUMBER DE users_table DONDE Nombre de usuario = 'Demo' Y contraseña = 'Demopass' ;

 

Si los datos de entrada se valida con éxito en la base de datos, entonces vamos a iniciar sesión en el sistema y que se presentará con el número de cuenta de otra cosa que no vamos a conseguir el acceso al sistema y se le presentará un mensaje de error “Nombre de usuario o contraseña no es válida! Por favor, vuelve a intentarlo!
 

El problema cuando un usuario malicioso entra otros personajes que tienen el propósito de interrumpir la instrucción SQL.
 

Supongamos que un usuario intenta iniciar sesión como usuario dem'o y contraseña demopass.
 

Ahora, Vamos a ver cómo la sentencia SQL se parece.
 

1
SELECT 'nombre, last_name, ACCOUNT_NUMBER DE users_table DONDE Nombre de usuario = 'El'la'AND password ='demopass' ;

 

Cuando MySQL se ejecuta la instrucción, sólo se tratará “la” como el nombre de usuario y cuando se encuentra con otra ‘la', a continuación, se trata ‘la‘ como un comando SQL y se lanzará y mensaje de error, ya que no reconoce ‘la‘ como un comando SQL válida.
 
ERROR 1064 (42000): Usted tiene un error en su sintaxis SQL; consulte el manual que corresponde a su versión del servidor MySQL para la sintaxis correcta a usar cerca 'o’ y la contraseña =”demopass”; ” en la línea 1
 

Impresionante. El mensaje de error anterior indica que hay un error en la sintaxis SQL. Si Comillas Mágicas han permitido, entonces no podríamos haber conseguido que el mensaje de error anterior.
 

Ahora, vamos a ver qué pasa si el usuario malicioso entra nombre de usuario como (‘ O '1' = '1) y contraseña “demopass“.

La consulta SQL se verá así:

1
SELECT 'nombre, last_name, ACCOUNT_NUMBER DE users_table DONDE Nombre de usuario = '' Oregón '1 '='1 ' Y contraseña = 'Demopass' ;

 

¿Qué significa la consulta SQL anterior? Le dice a MySQL para encontrar todas las filas con un nombre de usuario igual al “” (blanco) o (1= 1) y una contraseña igual a “demopass“.
 

Vamos a representar la consulta SQL anterior más lógica para entender lo que en realidad es malo en la sentencia SQL:
 

username = “” Oregón “1= 1” Y password = “demopass”
 

Ahora, ya sabemos que 1 = 1 siempre va a ser TRUE. Por lo tanto, el usuario podrá iniciar sesión en el sistema si la contraseña es correcta y el nombre de usuario es incorrecto.
 

Analicemos más peor escenario con una cadena de ataque diferente.
 

Cadena de ataque: ‘ OR 1 = 1–
 

Tenga en cuenta que ( y #) se utilizan para rescindir sentencia SQL. Vamos a poner la cadena de ataque en una consulta SQL y ver cómo la sentencia SQL final se verá.
 

Ahora, vamos a suponer que el atacante ni siquiera sabe la contraseña.
 

1
SELECT 'nombre, last_name, ACCOUNT_NUMBER DE users_table DONDE Nombre de usuario = '' Oregón 1=1--'AND password =' ​​idonotknow ' ;

 

Vea cómo la sentencia SQL es interpretada por MySQL.
 

username = “” OR 1 = 1– Y password = “idonotknow”
 

A tener en cuenta en la declaración anterior. Como sabemos que es un terminador de sentencia de SQL y 1= 1 siempre es cierto, después no se ejecuta la sentencia de terminación resto de la consulta SQL.
 

Por lo tanto, Todos los registros de la tabla conseguirán devuelto y el usuario se registrará en el sistema. El atacante será capaz de ver el número de cuenta del primer registro de la base de datos.
 

Ayudemos a MySQL inocente
 

Comillas Mágicas

 

Comillas Mágicas es una característica polémica del lenguaje de scripting PHP, en el que los caracteres especiales se prep-terminó con una barra invertida antes de ser transmitida.
 

Comillas Mágicas han habilitado de forma predeterminada en las nuevas instalaciones de PHP3 y PHP4, y puesto que su funcionamiento está detrás de las escenas y no es inmediatamente obvio, los desarrolladores pueden no ser conscientes de su existencia y los posibles problemas que puedan introducir.
 

Vamos a tener que encender la Comillas Mágicas en php.ini archivo en la web de la raíz del sitio web.
 

Cómo Comillas Mágicas ayuda?

 

Necesitamos escapar estos caracteres de comillas ( tanto las comillas simples y dobles, así como barras invertidas).
Esto se hace poniendo una barra inclinada delante de ellos.
 

So usename = dem'o se convierte en dem 'o , y MySQL puede trabajar con ese comillas, ya que es “protegido” con una barra.
 

Vamos a ver lo que sucede cuando Comillas Mágicas está encendido. Vamos a ver cómo el atacante se ve afectada con Comillas Mágicas.
 

1
SELECT 'nombre, last_name, ACCOUNT_NUMBER DE users_table DONDE Nombre de usuario = '\' OR 1 = 1 - ' Y contraseña = 'Idonotknow' ;

 

El nombre de usuario se interpreta como: \’ OR 1 = 1–

Eso es perfectamente escapado consulta SQL, Nada puede inyectarse. magic_quotes_gpc escapa a la comilla simple peligroso para nosotros. Por lo tanto, el atacante no podrá iniciar sesión en el sistema.

Problemas con Comillas Mágicas

 

Comillas mágicas sólo insertar una barra invertida antes de unos pocos caracteres, nada más. Esto nos protege de inyección SQL sólo en algunos casos particulares, como más arriba y sólo por coincidencia. Si tenemos display_errors EN, que acaba de hacer el atacante muy feliz con sus datos de la base de datos emitida ante sus ojos. Incluso si usted no lo hace, todavía hay una posibilidad de inyección SQL ciega y el uso de métodos de avance de la inyección de SQL es posible pasar por alto magic_quotes_gpc función.
 
Así, necesitamos una manera de escapar de los datos que no es malo, no es tan propenso a los problemas del conjunto de caracteres, y no es propenso a la magia de cría citas acuchilladas.
 
En Noviembre 2005 los desarrolladores del núcleo de PHP decidió a causa de estos problemas que la magic quotes característica podría ser eliminada de PHP 6.
Una vez que el Comillas mágicas características se retira, entonces no va a haber algunos problemas importantes que surgen.
 

SQL Injection Mitigación
 

Hay un número de maneras de prevenir MySQL inyecciones en PHP. Las formas más comunes están utilizando funciones como addslashes() y mysql_real_escape_string().
 

addslashes()

 

addslashes() devolverá una cadena con una barra invertida antes de los caracteres que deben ser desinfectados en las consultas de base de datos. Estos personajes son comillas simples (‘ = ’) comillas dobles (” = ”) y la nullbyte (%00 = \0).
 

addslashes() Sólo funcionará si la cadena de consulta se envuelve entre comillas. Una cadena como la siguiente seguiría siendo vulnerable a una inyección SQL:
 

1
2
3
$nombre_usuario = addslashes( $_POST[ 'Username' ] );
$contraseña  = addslashes( $_POST[ 'Password' ] );
$pregunta = "SELECT nombre apellido, last_name, ACCOUNT_NUMBER DE users_table DONDE username = '$nombre_usuario'AND password ='$contraseña' ";

mysql_real_escape_string()

 

mysql_real_escape_string() es un poco más potente que addslashes() ya que llama a la función de biblioteca de MySQL mysql_real_escape_string, que antepone barras invertidas de los siguientes caracteres: \x00, \n, \r, \, ', ” y x1a.
 

Al igual que con addslashes(), mysql_real_escape_string() Sólo funcionará si la cadena de consulta se envuelve entre comillas. Una cadena como la siguiente seguiría siendo vulnerable a una inyección SQL:
 

1
2
3
$nombre_usuario = mysql_real_escape_string( $_POST[ 'Username' ] );
$contraseña  = mysql_real_escape_string( $_POST[ 'Password' ] );
$pregunta = "SELECT nombre apellido, last_name, ACCOUNT_NUMBER DE users_table DONDE username = '$nombre_usuario'AND password ='$contraseña' ";

 

sprintf()

 

sprintf() se puede utilizar con especificaciones de conversión para asegurarse de que el argumento dinámica es tratado de la forma en que se supone que debe ser tratada. Por ejemplo, si una llamada para el número de identificación de los usuarios estaban en la cadena, %s se utilizarían para garantizar el argumento es tratado como una cadena. Un ejemplo de esto es la siguiente:
 

1
2
3
$nombre_usuario = $_POST[ 'Username' ];
$contraseña  = $_POST[ 'Password' ];
$pregunta = sprintf("SELECT nombre apellido, last_name, ACCOUNT_NUMBER DE users_table DONDE username = '%s'AND password ='%s' ", $nombre_usuario, $contraseña);

 

htmlentities($era, ENT_QUOTES)

 

htmlentities() en conjunto con el parámetro opcional segundo quote_style, permite el uso de ENT_QUOTES, que convertirá citas tanto individuales y dobles. Esto funcionará en el mismo sentido que addslashes() y mysql_real_escape_string() en lo que respecta a las comillas, sin embargo, en lugar de anteponer una barra invertida, que utilizará la entidad HTML de las comillas.
 

Además de utilizar ENT_QUOTES dentro htmlentities(), un tercer parámetro se puede establecer lo que obliga al uso de un conjunto de caracteres en la conversión. Esto ayudará a detener los resultados imprevistos de usar multibyte personajes de juegos de caracteres, tales como BIG5 y GPK.
 

El siguiente es un ejemplo de código que ayudaría a prevenir Inyección SQL en PHP.
 

1
2
3
4
5
$nombre_usuario = $_POST[ 'Username' ];
$nombre_usuario = htmlentities( $nombre_usuario, ENT_QUOTES, 'UTF-8' );
$contraseña  = $_POST[ 'Password' ];
$contraseña  = htmlentities( $contraseña, ENT_QUOTES, 'UTF-8' );
$pregunta = "SELECT nombre apellido, last_name, ACCOUNT_NUMBER DE users_table DONDE username = '$nombre_usuario'AND password ='$contraseña' ";

 

Optimizar el código SQL

 

Servidores de bases de datos son bestias complejas y tienen una funcionalidad mucho más de lo que necesita. En lo que se refiere a la seguridad, más que nunca es mejor. Por ejemplo, la xp_cmdshell procedimiento almacenado extendido en MS SQL da acceso a la shell y esto es sólo lo que un pirata informático sueños de. Es por eso que usted debe desactivar este procedimiento y cualquier otra funcionalidad, que puede ser fácilmente mal uso. Basta con retirar o al menos desactivar cualquier funcionalidad que se puede prescindir.
 

Deshabilitar defecto SQL Mensaje de error

 

Los mensajes de error son útiles para un atacante, ya que dan información adicional sobre las consultas de bases de datos y SQL. Y todos los ataques SQL se basan generalmente en tipo de error emitidos por SQL, significa que el tipo de error determina el enfoque de los hackers para hackear el sitio web o aplicación. Una mejor solución que no comprometa la seguridad sería la de mostrar un mensaje de error genérico que se limita a establecer un error ha ocurrido.
 

Almacenar las credenciales de base de datos segura

 

Con el fin de minimizar el daño en caso de una Ataque de inyección SQL, Guarde siempre las credenciales de base de datos en un archivo cifrado por separado. Ahora, incluso si un hacker logra romper en, él o ella no va a beneficiar a todo lo que no se puede hacer mucho en su base de datos.
 

Use menos Principio Privilege

 

El principio de privilegios mínimos es muy beneficioso y se aplica a Inyecciones SQL también. Piensa siempre o revise dos veces lo privilegios usted está proporcionando a usuario o objeto. Supongamos que usted wan para proporcionar acceso de moderador a algún usuario, por lo que sólo le proporcionará el acceso de los cuadros que él / ella necesita, en lugar de él probar el acceso de base de datos completa. Si usted tiene que proporcionar acceso a un sistema, su mejor crear espacios de tabla con particiones dentro de la base de datos y proporcionar acceso sólo a espacio de tabla específica. Esta técnica se reducir drásticamente la superficie de ataque.
 

Desactivar Shells

 

Muchas bases de datos ofrecen acceso a una consola a la base de datos que es esencialmente lo que un atacante o pirata informático necesidades. Debido a ello, tiene que cerrar esta brecha abierta. Cada proveedor de servicios tiene un método diferente para desactivar la ejecución de conchas en su base de datos. Así que consulte la documentación de su base de datos acerca de cómo deshabilitar el acceso shell para su base de datos o espacio de tabla en particular o concreto mesa.
 

Utilizar las herramientas de inyección SQL para comprobar vulnerabilidades

 

Por último, pero no menos importante, pensar como hackers. ¿Cómo un hacker puede hackear mi base de datos a través de Inyección SQL, qué herramientas y técnicas que puede utilizar para encontrar las lagunas. Siempre debe tener un simulacro de herramientas de hackeo de inyección SQL como SQLi, Haviz, SQL injectme etc. Más si se lo puede permitir escáner de vulnerabilidades retina luego de que sea demasiado buena. Como se compone de todas las vulnerabilidades más expuestos.

Muchas gracias. Espero que todos ustedes deben haber disfrutado. Por favor, dar comentarios para que podamos hacer más mejor.

 
 

28,922 visitas totales, 21 vistas hoy

Las dos fichas siguientes cambian el contenido a continuación.

Ashfaq Ansari

Investigador de Seguridad
Ashfaq Ansari es el fundador de HackSys equipo cuyo nombre en código "Panthera". Él es un investigador de seguridad con experiencia en diversos aspectos de la seguridad de la información. Es autor "HackSys Extreme Vulnerable Conductor" y "Shellcode de la Muerte". También ha escrito y publicado varios documentos técnicos sobre la explotación de software de bajo nivel. Su interés principal radica en "Bajo Explotación Nivel", "Ingeniería Inversa", "Programa de Análisis" y "Híbrido Fuzzing". Él es un fanático de la Inteligencia Artificial y Aprendizaje Automático. Él es el principal capítulo para nula Pune.

Deja un comentario

Su dirección de correo electrónico no será publicada. Los campos necesarios están marcados *