¿Es htmlencoding una solución adecuada para evitar ataques de inyección SQL?

Question

He oído que afirma que la solución más simple para evitar ataques de inyección SQL es html codificar todo el texto antes de insertarlo en la base de datos. Luego, obviamente, decodifique todo el texto al extraerlo. La idea es que si el texto solo contiene signos de unión, comas y caracteres alfanuméricos, entonces no se puede hacer nada malicioso.

Mientras veo una serie de casos en los que esto puede parecer a trabajar, preveo los siguientes problemas en el uso de este enfoque:

• Se anuncia como una bala de plata. Posiblemente impida que los usuarios de esta técnica comprendan todos los posibles problemas relacionados, como los ataques de segundo orden.
• No evita necesariamente los ataques de segundo orden/carga demorada.
• Está utilizando una herramienta para un propósito diferente al que fue diseñado. Esto puede generar confusión entre futuros usuarios/desarrolladores/encargados del código. También es probable que esté lejos de ser óptimo en la ejecución del efecto.
• Añade un posible impacto de rendimiento a cada lectura y escritura de la base de datos.
• Hace que sea más difícil leer los datos directamente desde la base de datos.
• Aumenta el tamaño de los datos en el disco. (Cada personaje ahora siendo ~ 5 caracteres - A su vez esto también puede afectar a los requisitos de espacio de disco, paginación de datos, el tamaño de los índices y el rendimiento de los índices y más?)
• Hay problemas potenciales con los caracteres Unicode de alta gama y combinación de caracteres?
• Algunas rutinas/bibliotecas de codificación html [en | de] se comportan de forma ligeramente diferente (por ejemplo, algunas codifican un apóstrofo y otras no). Puede haber más diferencias.) Esto vincula los datos al código utilizado para leer &. . Si usa un código que [en | de] codifica de manera diferente, los datos pueden ser cambiados/corruptos.
• Potencialmente hace que sea más difícil trabajar con (o al menos eliminar errores) cualquier texto que ya esté codificado de manera similar.

¿Hay algo que me falta?
¿Es este realmente un enfoque razonable para el problema de la prevención de ataques de inyección SQL?
¿Hay algún problema fundamental para tratar de prevenir los ataques de inyección de esta manera?

Answer 1

Debe evitar la inyección sql mediante el uso de enlaces de parámetros (por ejemplo, nunca concatenar cadenas sql con la entrada del usuario, pero utilice marcadores de posición para sus parámetros y permita que el marco utilizado escape por la derecha). La codificación Html, por otro lado, se debe usar para evitar secuencias de comandos entre sitios.

Answer 2

¿Cómo se obtiene la idea de que el texto HTML sólo contiene los símbolos de unión, punto y coma y caracteres alfanuméricos después de la decodificación codificado?

Realmente puede codificar un "'" en HTML - y eso es una de las cosas que se necesitan para conseguir yo en problemas (ya que es un delimitador de serie en SQL).

Por lo tanto, sólo funciona si se pone el texto codificado HTML en la base de datos.

ENTONCES havequite algunos problemas con cualquier búsqueda de texto ... y presentación de texto legible por fuera (como en el administrador de SQL). Consideraría que una situación arquitectónica realmente mala ya que no se ha resuelto el problema, simplemente eliminó un vector de ataque obvio.

Los campos numéricos todavía son problemáticos, a menos que su manejo de HTML sea perfecto, lo cual no asumiría dado ese tipo de solución.

parámetros

Uso de SQL;)

Answer 3

El único carácter que permite la inyección de SQL es la cadena SQL descalcificador ', también conocido como hexadecimal o decimal 27 39.

Este carácter se representa de la misma manera en SQL y en HTML. Por lo tanto, una codificación HTML no afecta en absoluto los ataques de inyección SQL.

Answer 4

Absolutamente no.

Las inyecciones de SQL deben evitarse mediante consultas parametrizadas. O en el peor de los casos escapando del parámetro SQL para SQL, no HTML. Cada base de datos tiene sus propias reglas sobre esto, la API de mysql (y la mayoría de los marcos), por ejemplo, proporciona una función particular para eso. Los datos en sí en la base de datos no deberían modificarse cuando se almacenan.

El escape de entidades HTML evita ataques XSS y otros al devolver contenido web a los navegadores de los clientes.