Y ESO DE "INYECCIÓN SQL"..QUE COÑO ES?? SQL INJECTION!!!

De Juan Carlos García -
Inyección SQL es un método de infiltración de código intruso que se vale de una vulnerabilidad informática presente en una aplicación en el nivel de validación de las entradas para realizar consultas a una base de datos.
El origen de la vulnerabilidad radica en el incorrecto chequeo y/o filtrado de las variables utilizadas en un programa que contiene, o bien genera, código SQL. Es, de hecho, un error de una clase más general de vulnerabilidades que puede ocurrir en cualquier lenguaje de programación o script que esté embebido dentro de otro.
Se conoce como Inyección SQL, indistintamente, al tipo de vulnerabilidad, al método de infiltración, al hecho de incrustar código SQL intruso y a la porción de código incrustado.

Contenido

 Descripción

Se dice que existe o se produjo una inyección SQL cuando, de alguna manera, se inserta o "inyecta" código SQL invasor dentro del código SQL programado, a fin de alterar el funcionamiento normal del programa y lograr así que se ejecute la porción de código "invasor" incrustado, en la base de datos.
Este tipo de intrusión normalmente es de carácter malicioso, dañino o espía, por tanto es un problema de seguridad informática, y debe ser tenido en cuenta por el programador de la aplicación para poder prevenirlo. Un programa elaborado con descuido, displicencia o con ignorancia del problema, podrá resultar ser vulnerable, y la seguridad del sistema (base de datos) podrá quedar eventualmente comprometida.
La intrusión ocurre durante la ejecución del programa vulnerable, ya sea, en computadores de escritorio o bien en sitios Web, en éste último caso obviamente ejecutándose en el servidor que los aloja.
La vulnerabilidad se puede producir automáticamente cuando un programa "arma descuidadamente" una sentencia SQL en tiempo de ejecución, o bien durante la fase de desarrollo, cuando el programador explicita la sentencia SQL a ejecutar en forma desprotegida. En cualquier caso, siempre que el programador necesite y haga uso de parámetros a ingresar por parte del usuario, a efectos de consultar una base de datos; ya que, justamente, dentro de los parámetros es donde se puede incorporar el código SQL intruso.
Al ejecutarse la consulta en la base de datos, el código SQL inyectado también se ejecutará y podría hacer un sinnúmero de cosas, como insertar registros, modificar o eliminar datos, autorizar accesos e, incluso, ejecutar otro tipo de código malicioso en el computador.
Por ejemplo, asumiendo que el siguiente código reside en una aplicación web y que existe un parámetro "nombreUsuario" que contiene el nombre de usuario a consultar, una inyección SQL se podría provocar de la siguiente forma:
El código SQL original y vulnerable es:
consulta := "SELECT * FROM usuarios WHERE nombre = '" + nombreUsuario + "';"
Si el operador escribe un nombre, por ejemplo "Alicia", nada anormal sucederá, la aplicación generaría una sentencia SQL similar a la siguiente, que es perfectamente correcta, en donde se seleccionarían todos los registros con el nombre "Alicia" en la base de datos:
SELECT * FROM usuarios WHERE nombre = 'Alicia'; así es la consulta, tal cual..le estamos diciendo: Quiero realizar una consulta a ti Sql Server, desde la tabla usuarios donde el nombre de ese usuario es Alicia...bien, pues modifiquemos Alicia...
Pero si un operador malintencionado escribe como nombre de usuario a consultar:
"Alicia'; DROP TABLE usuarios; SELECT * FROM datos WHERE nombre LIKE '%"
(sin las comillas externas), se generaría la siguiente consulta SQL, (el color verde es lo que pretende el programador, el azul es el dato, y el rojo, el código SQL inyectado):
SELECT * FROM usuarios WHERE nombre = 'Alicia';
DROP TABLE usuarios;
SELECT * FROM datos WHERE nombre LIKE '%';
En la base de datos se ejecutaría la consulta en el orden dado, se seleccionarían todos los registros con el nombre 'Alicia', se borraría la tabla 'usuarios' y finalmente se seleccionaría toda la tabla "datos", que no debería estar disponible para los usuarios web comunes.
En resumen, cualquier dato de la base de datos puede quedar disponible para ser leído o modificado por un usuario malintencionado.
Nótese por qué se llama "Inyección" SQL. Si se observa el código malicioso, de color rojo, se notará que está insertado en el medio del código bueno, el verde. Así, el código rojo ha sido "inyectado" dentro del verde,hemos inyectado,insertadop entre medias del código de programación Sql,que es un Standard para casi todas las grandes bases de datos..Oracle, Sql Server...
La inyección SQL es fácil de evitar, por parte del programador, en la mayoría de los lenguajes de programación que permiten desarrollar aplicaciones web. En la siguiente sección se trata brevemente ese tema.

 Algunas formas de evitar la Inyección SQL

 Ruby on Rails

En el framework Ruby on Rails (RoR), las consultas son verificadas automáticamente por cualquiera de los métodos de búsqueda incluidos. Por ejemplo:
Project.find(:all, :conditions => ["name = ?", params[:name]])
 # o bien
 Project.find(:all, :conditions => {:name => params[:name]})
La única forma de que un usuario mal intencionado pueda usar una inyección de SQL en RoR es que mediante código se transforme la variable a tipo string y se utilice como argumento de la búsqueda directamente. Por ejemplo:
# NO SE DEBERÍA HACER ESTO
 Project.find(:all, :conditions => "name = '#{params[:name]}'")

 Perl

En lenguaje Perl DBI, el método DBI::quote filtra los caracteres especiales (asumiendo que la variable $sql contiene una referencia a un objeto DBI):
$query = $sql->prepare 
   ( 
         "SELECT * FROM usuarios WHERE nombre = " 
     . 
         $sql->quote($nombre_usuario) 
    );
O también se puede usar la característica placeholder (con comillado automático) como sigue:
$query = $sql->prepare("SELECT * FROM usuario WHERE nombre = ?"); 
 $query->execute($nombre_usuario);

 PHP

En el lenguaje PHP, hay diferentes funciones que pueden servir de ayuda para usar con distintos sistemas de gestión de bases de datos. Para MySQL, la función a usar es mysql_real_escape_string:
$query_result = mysql_query("SELECT * FROM usuarios WHERE nombre = \"" . mysql_real_escape_string($nombre_usuario) . "\"");

Java

En lenguaje Java, se puede usar la clase PreparedStatement
En lugar de:
Connection con = (acquire Connection) 
 Statement stmt = con.createStatement(); 
 ResultSet rset = stmt.executeQuery("SELECT * FROM usuarios WHERE nombre = '" + nombreUsuario + "';");
se puede usar parametrización o escape de variables, como se indica en los siguiente apartados.

 Parametrización de sentencias SQL

Connection con = (acquire Connection) 
 PreparedStatement pstmt = con.prepareStatement("SELECT * FROM usuarios WHERE nombre = ?"); 
 pstmt.setString(1, nombreUsuario); 
 ResultSet rset = pstmt.executeQuery();

 Escape de las variables a insertar en la sentencia SQL

Escapar el texto contenido en la variable reemplazando los caracteres especiales en SQL por su equivalente textual, de tal forma que SQL interprete todo el contenido de la variable como si fuera texto.
Connection con = (acquire Connection) 
 Statement stmt = con.createStatement(); 
 ResultSet rset = stmt.executeQuery("SELECT * FROM usuarios WHERE nombre = '" + nombreUsuario.replace("\\", "\\\\").replace("'", "\\'") + "';");
También se puede utilizar el método escapeSQL
de la clase StringEscapeUtils
procedente de la librería de Apache Commons Lang

Connection con = (acquire Connection) 
 Statement stmt = con.createStatement(); 
 ResultSet rset = stmt.executeQuery("SELECT * FROM usuarios WHERE nombre = '" + StringEscapeUtils.escapeSQL(nombreUsuario) + "';");

 En C#

En lenguaje C#, de la plataforma .NET (o su alternativa libre Mono), se tiene ADO.NET SqlCommand (para Microsoft SQL Server) o OracleCommand (para servidores de bases de datos Oracle). El ejemplo siguiente muestra cómo prevenir los ataques de inyección de código usando el objeto SqlCommand. El código para ADO.NET se programa de forma similar, aunque puede variar levemente según la implementación específica de cada proveedor.
En vez de:
using( SqlConnection con = (acquire connection) ) { 
     con. Open(); 
     using( SqlCommand cmd = new SqlCommand("SELECT * FROM usuarios WHERE nombre = '" + nombreUsuario + "'", con) ) { 
        using( SqlDataReader rdr = cmd.ExecuteReader() ){ 
            ... 
        } 
     }       
 }
se podría usar lo siguiente:
using( SqlConnection con = (acquire connection) ) { 
     con. Open(); 
     using( SqlCommand cmd = new SqlCommand("SELECT * FROM usuarios WHERE nombre = @nombreUsuario", con) ) { 
 
        cmd.Parameters.AddWithValue("@nombreUsuario", nombreUsuario); 
 
        using( SqlDataReader rdr = cmd.ExecuteReader() ){ 
            ... 
        } 
     }       
 }

 Véase también

Enlaces externos

Unsaludo Newbies

Duk3m4q

Entradas populares de este blog

SHELLCODES por un tubo ....

De Juan Carlos García -
SHELLCODES DATABASE Bueno, os dejo esta "pequeña colección de ShellCodes funcionales para que no tengais que dar muchas vueltas Tenéis de todo y para todos los gustos .. asi que por Shells que no sea ..  AIX Aix - execve /bin/sh - 88 bytes   by Georgi Guninski Alpha Alpha - /bin/sh - 80 bytes   by Lamont Granquist Alpha - execve() - 112 bytes   by n/a Alpha - setuid() - 156 bytes   by n/a BSD BSD/32bits - Passive Connection - 126 bytes   by Scrippie BSD/ppc - execve(/bin/sh) - 128 bytes   by Palante BSD/x86 - setreuid(geteuid(), geteuid()) and execve(/bin/sh, /bin/sh, 0)   by Jihyeog Lim BSD/x86 - setuid/execve - 30 bytes   by Marco Ivaldi BSD/x86 - setuid/portbind - 94 bytes   by Marco Ivaldi BSD/x86 - break chroot - 45 bytes   by Matias Sedalo BSD/x86 - cat /etc/master.passwd & mail root@localhost - 92 bytes   by Matias Sedalo BSD/x86 - execve(/bin/sh) & setuid(0) - 29 bytes   by Matias...
Leer más

Proteger ASP.NET de inyecciones SQL How T0? BEST PRACTICES

De Juan Carlos García -
Cómo: Proteger ASP.NET de inyecciones SQL Publicado: 21 de Diciembre de 2005 Post:eado:19 de  MARZO 2012 Motivo:   Aumento de Hacking en Aplicaciones Web de manera Brutal desde el 2005 y aumentando Este artículo se aplica a y a como securizar para evitar ser hackeado, si, o si !!! ASP.NET versión 1.1 ASP.NET versión 2.0 y para lo que habeís hecho desde el 2005, estudiarlo bien majetes porque seguís sin securizar el puto código de la parte servidor ... !!! Por dios, ya está bien de poner a los usuarios y trabajadores en peligro .. !! Es tan difícil poner un poquito de atención. Resumen: En este artículo se describen una serie de métodos que ayudan a proteger la aplicación ASP.NET de inyecciones SQL. Entre las distintas técnicas se incluyen la restricción de entradas, el uso de parámetros SQL con tipos seguros para el acceso a datos y el uso de una cuenta con menos privilegios que tenga permisos restringidos en la base de datos. La inyección SQL puede produc...
Leer más

CERTIFICACIONES DE SEGURIDAD

De Juan Carlos García -
Imagen
CERTIFICACIONES DE SEGURIDAD For Fun and Profit Nuevo curso, toca mirar todo lo que tenemos y más … Eso si, caro caro caro(..) Seguridad General—Nivel Basico Brainbench Basic Security Certifications : Ofrece varias certificaciones, un examen por certificación ·          Brainbench Firewall Administration Concepts ·          Brainbench Internet Security ·          Information Technology Security Fundamentals ·          ITAA Information Security Awareness ·          Brainbench Microsoft Security ·          Brainbench Network Authentication ·          Brainbench Network Security ·          Security Industry Knowledge (U.S.) ...
Leer más