2010-03-04 9 views
8

Duplicar posible:
Can I protect against SQL Injection by escaping single-quote and surrounding user input with single-quotes?¿Cómo se puede romper/explotar este código de consulta SQL con la entrada del usuario?

Tenemos una aplicación de legado que no hace consultas utilizando los parámetros de posición, y hay SQL en todas partes. Se decidió (antes de comenzar aquí) que dado que la entrada del usuario puede contener apóstrofes, cada entrada de cadena debe escaparse manualmente para esos apóstrofos.

Este es el código esencial original (no escrito por mí), traducido a C# para el consumo fácil:

private string _Escape(string input) 
{ 
    return input.Replace("'", "''"); 
} 

private bool _IsValidLogin(string userName, string password) 
{ 
    string sql = 
     string.Format 
     (
      @"SELECT COUNT(*) FROM UserAccounts 
       WHERE UserName = '{0}' AND Password = '{1}'", 
      _Escape(userName), 
      _Escape(password) 
     ); 
    // ... 
}

Esto realmente parece que se puede romper de alguna manera, pero estoy en una pérdida en cuanto a cómo podría ser explotado por la entrada del usuario. Suponga que la entrada del usuario no está filtrada hasta que llegue al _IsValidLogin, y olvide que las contraseñas parecen estar almacenadas en texto sin formato.

La solución para apuntalarlo definitivamente es obvio - use parámetros posicionales - pero necesito algo de munición para demostrarle a la administración por qué/cómo este código es inseguro para que time/$ pueda asignarse para que sea reparado.

Nota: Estoy asumiendo esto se puede romper, pero puede que ese no sea el caso. No soy una superestrella SQL.

Nota 2: He expresado esta pregunta como una base de datos independiente, pero si puede explotar este código para un determinado motor, agradezco su contribución.

+1

Merece la pena leerlo aquí si aún no lo has hecho: http://stackoverflow.com/questions/139199/can-i-protect-against-sql-injection-by-escaping-single-quote-and- usuario circundante –

+0

@Nick: gracias, no vi ese. Voy a cerrar esta pregunta como un duplicado. –

+0

Cerrado a petición del autor. –

Respuesta

3

Podría ser explicado por las barras diagonales inversas.

password = foo\' OR 1=1 -- 

se convierte en:

password = foo\'' OR 1=1 -- 

la consulta:

"SELECT COUNT(*) FROM UserAccounts 
       WHERE UserName = '{0}' AND Password = 'foo\'' OR 1=1 --'" 

-- es la marca comentario en este ejemplo.

La solución asume que el programa solo filtra (duplica) apóstrofes.

+0

No puedo decir para otras bases de datos, pero la barra invertida no parece ser un carácter de escape en MSSQL, y simplemente se usaría literalmente. Su ejemplo simplemente buscaría contraseñas de ''foo \' O 1 = 1 -' –

0

Bueno, no puedo ver una forma en que sea vulnerable. Entonces, vamos a argumentar una razón diferente por la que debería cambiarse, es bastante ineficaz. En MSSQL (y, creo, la mayoría de los demás servidores SQL de gama alta), las consultas se analizan y se diseña el plan de ejecución, y luego se almacenan la consulta y el plan. Si se solicita nuevamente una copia exact de la consulta, se utiliza el plan de ejecución guardado. El parámetro no afecta esto, por lo que si usa parámetros, reutilizará los planes; si incrusta el texto, nunca lo hará.

+0

Es vulnerable. El ejemplo no usa ningún enlace de parámetro. – erenon

Cuestiones relacionadas