Bugs y Exploits‎ > ‎Nivel Web‎ > ‎Inyección SQL‎ > ‎

Protegerse de un ataque SQL Injection

Existen ciertos principios a considerar para proteger nuestras aplicaciones de un SQL Injection:

  1. No confiar en la entrada del usuario.
  2. No utilizar sentencias SQL construidas dinámicamente.
  3. No utilizar cuentas con privilegios administrativos.
  4. No proporcionar mayor información de la necesaria.

A continuación veremos algunos ejemplos de como implementar dichos principios.

1. No confiar en la entrada del usuario significa:

  • Filtrar la entrada del usuario de caracteres SQL para limitar los caracteres involucrados en un SQL Injection.
Private Function string SafeSqlLiteral( _
ByVal inputSQL As String) As String
Return inputSQL.Replace("'", "''")
End Function
'...
Dim safeSQL As String = SafeSqlLiteral(Login.Text)
Dim myCommand As SqlDataAdapter = _
New 
SqlDataAdapter("SELECT au_lname, au_fname " & _
"FROM authors WHERE au_id = '" & safeSQL & "'", _
myConnection)
  • Proteger las instrucciones de búsqueda de modelos coincidentes (LIKE).
Private Function SafeSqlLikeClauseLiteral( _
ByVal
 inputSQL As String) As String
Dim As String = inputSQL
s = inputSQL.Replace("'", "''")
s = s.Replace("[", "[[]")
s = s.Replace("%", "[%]")
s = s.Replace("_", "[_]")
Return s
End Function
  • Verificar tanto el tamaño y como el tipo de los datos de las entradas de usuario:
    • Evitando los siguientes tipos caracteres de riesgo para el gestor de datos:
      • El delimitador de consultas: Punto y coma (;)
      • Delimitador de datos de tipo cadena de caracteres: Comilla sencilla (').
      • Delimitadores de cometario: Guión doble (--) y "/*..*/" en el caso de SQL Server.
  • Nota: En lugar de evitar los caracteres peligrosos, otro modo de protegernos es aceptar sólo los caracteres inofensivos.
    • Evitando las cadenas con el inicio de nombres de las tablas y los procedimientos del sistema: "sys" y "xp_" en el caso de SQL Server. Así como las siguientes palabras: AUX, CLOCK$, COM1, COM8, CON, CONFIG$, LPT1, LPT8, NUL y PRN
    • Utilizar de preferencia controles con valores predefinidos o discretos tales como cuadros de lista, cuadros combinados, de verificación, etc. en lugar de cuadros de texto.
  • Verificar cualquier tipo de entrada, no sólo lo introducido en los controles IU sino también aquellas que no son visibles, como parámetros de entrada y campos tipo hidden de las páginas web.
  • Realizar la verificación en todos los niveles y capas de la aplicación, ya que si sólo protegemos la capa de presentación somos vulnerables a que un atacante salte a la siguiente capa y realizar su ataque.

2. No utilizar sentencias SQL construidas dinámicamente. En lugar de ello:

  • Utilizar instrucciones SQL con Parámetros.
Dim myCommand As SqlDataAdapter = New SqlDataAdapter( _
"SELECT au_lname, au_fname FROM Authors " & _
"WHERE au_id= @au_id", myConnection)
Dim parm As 
SqlParameter = _
myCommand.SelectCommand.Parameters.Add("@au_id", _
SqlDbType.VarChar, 11)
parm.Value = Login.Text

Aunque de hecho es mejor utilizar Procedimientos Almacenados siempre que sea posible, así como también:

  • Utilizar Parámetros al llamar Procedimientos Almacenados.
Dim myCommand As SqlDataAdapter = _
New
 SqlDataAdapter("AuthorLogin", myConnection)
myCommand.SelectCommand.CommandType = _
CommandType.StoredProcedure
Dim parm As 
SqlParameter = _
myCommand.SelectCommand.Parameters.Add("@LoginId", _
SqlDbType.VarChar,11)
parm.Value = Login.Text

3. No utilizar cuentas con privilegios administrativos.

  • Ejecutar las sentencias SQL o invocar Procedimientos Almacenados con una cuenta con privilegios mínimos. Nunca emplear 'sa' en el caso de MS SQL Server. Pero de preferencia además...
  • Conceder permisos de ejecución únicamente a Procedimientos Almacenados propios desde los cuales, a manera de "wraper", se realicen las consultas a las Tablas de Usuario y llamados a los Procedimientos Almacenados del Sistema que se requieran en las aplicaciones, y negar el acceso directo a éstos últimos y a las Tablas de Usuario.

4. No proporcionar mayor información de la necesaria.

  • No exponer al usuario final los mensajes de error devueltos por el gestor de la base de datos, para no brindar mayor información que sea útil al atacante.
  • Implementar un sistema de gestión de errores que notifique del mismo únicamente a los administradores de la aplicación y el gestor de la base de datos. Por ejemplo, para el caso de una aplicación web, establecer en el archivo de configuración web (Web.Config) el valor del atributo debug del elemento compilation en False y el atributo mode del elemento customErrors en On o en su defecto en RemoteOnly.
<compilation defaultLanguage="vb" debug = "false" />
<customErrors mode="RemoteOnly" 
defaultRedirect="GenericErrorPage.htm">
</customErrors>

Conclusión.

Para prevenir un ataque SQL Injection, así como para realizar pruebas (Testing) de vulnerabilidad contra el mismo en nuestras aplicaciones, no debemos olvidar que cualquier aplicación que permita una "entrada" que sirva de parámetro para una consulta SQL es vulnerable a éste ataque. Por ello en éste artículo describimos brevemente de lo que se trata un SQL Injection, así como de los principios básicos a seguir para protegernos del mismo. Por último ejemplificamos algunas implementaciones de dichos principios. Medidas a tomar para protegerse de un ataque SQL Injection.

Fuente original: http://willyxoft.wordpress.com/articulos/sql-injection/  por Willy Mejia (WillyXoft)
Comments