¿Cómo se puede anular esta función de desinfectante de entrada?

10

Hay una aplicación ASP clásica en mi trabajo que es (creo) altamente vulnerable a la inyección de SQL. Quiero demostrar a la administración que este código no es seguro, pero todo lo que puedo hacer es insertar registros de registro "SQLINJ" en la base de datos:

Public function preventSQLInjection(lstr)

    BlackList = Array("--", ";", "'", "/*", "*/", "@@", "@",_
                      "alter ", "begin ", "create ", "cursor ",_
                      "declare ", "delete ", "drop ", " end", "exec ",_
                      "execute ", "fetch ", "insert ", "kill ", "open ",_
                      "select ", "sysobjects", "syscolumns",_
                      "table ", "update ", "=")

    preventSQLInjection = lstr

        For Each s in BlackList      
        If ( InStr (lstr, s) <> 0 ) Then
            execSqlQuery "INSERT INTO AccesLogs (datetime,ip,action,comments) VALUES ('" & formatDate(date) & " " & formatTime(time) & "','" & request.ServerVariables("REMOTE_ADDR") & "','SQLINJ','" & replace(lstr,"'","''") & "')",connectionstring
            preventSQLInjection = "DONOTUSEIT"
            exit for
        End If  
    Next

end function

Según tengo entendido, el ataque más fácil sería en la propia tabla AccessLogs , debido a que replace(lstr,"'","''") "desinfecta" el intento de inyección de SQL y lo registra.

SÉ que este código debe descartarse y todo el ejecutable SQL debe ejecutarse con comandos y parámetros reales. Odio las cadenas concatenadas con pasión.

Quiero demostrar a la administración que la página es muy vulnerable, como, sysobjects está en la lista negra, pero no sys.objects , por lo que si puedo inyectar SQL ejecutable, debe ser posible obtener el esquema completo de la base de datos sin sudar. p>

¿Cómo se puede desactivar esta función de, digamos, los campos username y password en la página login.asp ? ¿O estoy inventando todo esto y este código es perfectamente seguro?

    
pregunta Mathieu Guindon 10.02.2014 - 21:07
fuente

2 respuestas

5
  

Quiero demostrarle a la administración que este código no es seguro

Podrías pasar el resto de tu (quizás corta) carrera haciéndolo, una y otra vez a medida que se agregan a la lista negra. Sugiero tratar de educarlos en su lugar.

Lea la OWASP SQL Injection Cheat Sheet y las hojas relacionadas a las que hace referencia en él, y luego podrá presentarlas Los tomadores de decisiones y responden a las preguntas de manera racional: OWASP es una fuente de gran reputación.

Lea también Por qué no deberíamos rodar los nuestros , en particular, el ejemplo de Phil Zimmerman es un ejemplo. , de un criptógrafo muy conocido, de por qué "bueno, no puedo derrotarlo" no significa que "es seguro".

Si debe intentar proporcionar un ejemplo, intente jugar con varias codificaciones; el hexadecimal está claramente permitido, así que levante su Tabla ASCII para usar con 0x y CHAR (), y quizás también juegue con caracteres de escape HTML o Unicode (UCS-2, para SQL Server).

Mira si puedes usar 'quoted_identifier desactivado' también.

Como dijo kiBytes, intente con mayúsculas y minúsculas: las intercalaciones más comunes de SQL Server no distinguen entre mayúsculas y minúsculas.

Si algo funciona, deberás volver a informarles de que solo porque hay N hoyos no significa que no queden X hoyos, algunos de los cuales no encontrarás antes de que lo hagan los atacantes.

    
respondido por el Anti-weakpasswords 11.02.2014 - 03:53
fuente
3

No puedo probarlo, pero la documentación indica que la función " InStr" distingue entre mayúsculas y minúsculas, así que creo que puedes usar cualquier token pero los símbolos en mayúsculas:

    
respondido por el kiBytes 10.02.2014 - 21:29
fuente

Lea otras preguntas en las etiquetas