Inyección de SQL a través de Unicode

Question

Inyección de SQL a través de Unicode

#1 de Gumbo (5 votos)
#2 de Adam Zuckerman (2 votos)
#3 de jmoreno (2 votos)
#4 de Anorov (2 votos)

4

Mi equipo actualmente usa ASP.NET con MS SQL Server para nuestro software. La seguridad solo ha adquirido importancia desde que empecé, en la que hay vulnerabilidades de inyección en todas partes.

Debido a la integración actual con Oracle y MS SQL, la decisión empresarial nunca fue utilizar consultas parametrizadas. Esto, por supuesto, ha sido un problema.

La implementación de Buscar y reemplazar junto con la inclusión en la lista blanca de parámetros ha reducido este problema en gran medida.

Mi único problema es que he leído mucho sobre Unicode y otras codificaciones que son la causa de la inyección de SQL. No entiendo muy bien esto. Actualmente desinfectamos todo esto:

        Const pattern As String = "^[a-zA-Z0-9.=,:\s\\/\']*$"
        term = term.Replace("'", "''")

        If Not Tools.ValidString(term, pattern) Then
            term = String.Empty
        End If 

    Public Shared Function ValidString(ByVal source As String, ByVal pattern As String) As Boolean
        If source = String.Empty Then Return True

        Dim params As Text.RegularExpressions.RegexOptions = Text.RegularExpressions.RegexOptions.None
        Dim regex As New Text.RegularExpressions.Regex(pattern, params)
        Dim match As Text.RegularExpressions.Match = regex.Match(source, pattern, params)
        Return match.Success
    End Function

¿Alguien tiene un ejemplo en el que se pueda usar unicode / inyección codificada, o simplemente un ejemplo en el que esta expresión regular no pueda evitar la inyección de sql?

Gracias

ACTUALIZAR

¿Puedo por favor no tener respuestas relacionadas con la inyección estándar de SQL? Ya estoy muy familiarizado con esto. TAMBIÉN por favor deja de publicar diciendo que no uses desinfección de cuerdas. No hay recursos en la compañía para cambiar todas las consultas a consultas parametrizadas con ADO.NET, mientras que también se construye la lógica para que use ODP.NET si el cliente usa oracle. OWASP menciona el uso de la lista blanca de caracteres si la parametrización está fuera de cuestión, por lo que como en la expresión regular, solo se permiten unos pocos caracteres. No estoy en la lista negra de personajes, ya que esto es estúpido.

No se requiere el cumplimiento de los datos que tenemos. La seguridad es para la integridad de la base de datos, ya que sería una pesadilla si se cambiara el contenido.

Nuestro software es una aplicación de nube muy grande CMS y DMS en una, donde el 99% del software se usa internamente, y solo una minoría es externa y solo se usa para la revisión pública y comentarios de los documentos.

De mi nueva comprensión de la inyección de Unicode. Solo puede ocurrir si los datos se están codificando antes de colocarlos en la consulta y, por lo tanto, la inyección Unicode solo ocurre realmente en aplicaciones con globalización de datos. Estoy pasando los campos de cadena sin procesar directamente a la consulta de cadena después de la desinfección anterior.

¿Puedo por favor solo recibir una respuesta de un experto en inyecciones, quién puede respaldar mi afirmación de que Unicode no se aplicará en mi caso?

sql-injection asp.net unicode sql-server injection

pregunta Cyassin 03.04.2014 - 00:38

fuente

4 respuestas

2

Lo que más necesita para detener la inyección de SQL es un punto y coma (;). Sin embargo, no siempre es sencillo simplemente eliminarlos. Tendrá situaciones en las que se utiliza un punto y coma en un campo de texto como un carácter, no como un terminador de comando SQL.

Hay muchos artículos que se detallan sobre cómo inyectar y prevenir SQL en tus consultas.

Si escribe salida de texto en una página web, codifíquela con HttpUtility.HtmlEncode. Haga esto si el texto proviene de una entrada del usuario, una base de datos o un archivo local.

Esto trae a la mente uno de los métodos utilizados para protegerse de la inyección de SQL: codificar caracteres que causarán problemas con los que no pueden.

Específicamente para Unicode en comparación con cualquier otra codificación, aún tendrá que usar las mismas técnicas para encontrar y eliminar o reemplazar los caracteres ofensivos en sus cadenas.

ACTUALIZAR

Si codifica cadenas Unicode a algo como / u0000, puede dejar la cadena codificada y colocarla en su base de datos de forma segura sin preocuparse por la inyección de SQL. Sin embargo, tendrá que escribir la rutina que realiza el saneamiento, ya que no está integrado en SQL Server.

respondido por el Adam Zuckerman 03.04.2014 - 01:22

fuente

2

Si está viendo cómo se puede explotar Unicode, consulte esta pregunta , si está buscando una solución, en realidad solo hay dos que pueden considerarse realmente seguras: consultas parametrizadas y codificación de todas sus entradas en hex o base64 o alguna otra codificación que no deje abierta la posibilidad de cambiar la contexto del valor.

Reconsideraría seriamente el uso de consultas parametrizadas. De hecho, son muy fáciles de usar, aunque no conozco su código base. En general, es bastante fácil cambiar. Particularmente desde la introducción de los métodos de extensión.

respondido por el jmoreno 03.04.2014 - 07:16

fuente

2

Por favor, por favor, por favor, no use una expresión regular hecha a mano para prevenir la inyección de SQL. Nunca debe escribir sus propias funciones de escape, filtrado o desinfección para evitar la inyección de SQL, XSS, inyección de shell o similares. Estas son cosas en las que confía las bibliotecas integradas y vetadas.

Donde pueda evitarlo, ni siquiera use una función de escape de biblioteca estándar. Utilizar consultas parametrizadas.

Por un lado, ese escape no ayudará si está utilizando un valor entero sin comillas al final de una consulta. En pseudocódigo:

check ValidString(input)
query("SELECT * FROM table WHERE id=" + input)

El usuario puede ingresar fácilmente 1 OR 1=1 para ver todas las filas en table .

... O pueden ingresar 1 UNION ALL SELECT password,1,1 FROM password_table o similar. Y ahora la salida contiene todas las contraseñas de los usuarios.

¿Está diciendo que es imposible volver y convertir todo el código SQL para usar consultas paramaterizadas? Si es así, supongo que es mejor que esté 100% seguro de que siempre cita los valores de SQL y nunca hace comparaciones o inserciones de enteros ...

Si fuera usted, solo convencería a su gerencia y / o equipo de que si se desea la seguridad en lo más mínimo, entonces se necesita tiempo para volver a escribir el código de manera segura.

respondido por el Anorov 03.04.2014 - 11:58

fuente

Lea otras preguntas en las etiquetas sql-injection asp.net unicode sql-server injection

Almacenar contraseñas recuperables en una aplicación ¿Cisco / Juniper IOS hacking? [cerrado]

score 5 · Accepted Answer

Hay casos de Inyecciones de SQL que aprovechan la conversión implícita de Unicode homoglyphs desde tipos de cadenas de caracteres Unicode (NCHAR, NVARCHAR) a tipos de cadenas de caracteres (CHAR, VARCHAR). Un personaje como ʼ (U + 02BC) en NVARCHAR puede deslizarse a través de la rutina de escape y obtenga traducción a ' (U + 0027) en VARCHAR , lo que puede resultar en una Inyección de SQL cuando se usa una cadena de este tipo para construir una declaración SQL de forma dinámica.

Sin embargo, su validación es bastante estricta (solo los caracteres del bloque de Latin Unicode básico y caracteres de espacio en blanco Unicode ) y no puedo pensar en ningún caso en el que esto pueda fallar.