Permitir fragmentos de código en la entrada del formulario mientras se evitan los ataques de inyección XSS y SQL

Question

¿Cómo se puede permitir que se ingresen fragmentos de código en un editor (como lo hace stackoverflow) como FCKeditor o cualquier otro editor mientras se previene XSS, inyección SQL y ataques relacionados?

Answer 1

Parte del problema aquí es que desea permitir ciertos tipos de HTML, ¿verdad? Enlaces por ejemplo. Pero necesita desinfectar solo aquellas etiquetas HTML que pueden contener ataques XSS como etiquetas de script o incluso atributos de controlador de eventos o un href u otro atributo que comience con & Quot; javascript: & Quot ;. Por lo tanto, una respuesta completa a su pregunta debe ser algo más sofisticado que & Quot; reemplace los caracteres especiales & Quot; porque eso no permitirá enlaces.

La prevención de la inyección SQL puede ser algo dependiente de su elección de plataforma. Mi plataforma web preferida tiene una sintaxis incorporada para parametrizar consultas que evitarán principalmente la inyección de SQL (llamada cfqueryparam). Si está utilizando PHP y MySQL, existe una función nativa similar de mysql_escape (). (No estoy seguro de que la función PHP técnicamente cree una consulta parametrizada, pero me ha funcionado bien para prevenir intentos de inyección de sql hasta ahora, ya que he visto algunos que se almacenaron de forma segura en el db).

En la protección XSS, solía usar expresiones regulares para desinfectar la entrada por este tipo de razón, pero desde entonces me alejé de ese método debido a la dificultad que conlleva permitir tanto cosas como enlaces y al mismo tiempo eliminar el código peligroso. A lo que me he mudado como alternativa es XSLT. Nuevamente, la forma en que ejecuta una transformación XSL puede variar según su plataforma. Escribí un artículo para el ColdFusion Developer's Journal hace un tiempo sobre cómo hacer esto, que incluye una hoja de referencia XSL que puede usar y muestra cómo hacerla trabaje con CF utilizando la función nativa XmlTransform ().

La razón por la que elegí moverme a XSLT para esto es doble.

Primero, validar que la entrada está bien formada XML elimina la posibilidad de un ataque XSS utilizando ciertos trucos de concatenación de cadenas.

En segundo lugar, es más fácil manipular el paquete XHTML utilizando selectores XSL y XPath que con expresiones regulares porque están diseñados específicamente para trabajar con un documento XML estructurado, en comparación con las expresiones regulares que fueron diseñadas para la manipulación de cadenas sin formato. Por lo tanto, es mucho más limpio y fácil, es menos probable que cometa errores y si encuentro que he cometido un error, es más fácil de solucionar.

Además, cuando los probé, descubrí que los editores WYSIWYG como CKEditor (eliminó el F) conservan XML bien formado, por lo que no debería preocuparse por eso como un problema potencial.

Answer 2

Se aplican las mismas reglas para la protección: entrada de filtro, salida de salida.

En el caso de la entrada que contiene código, el filtrado solo significa que la cadena debe contener caracteres imprimibles, y tal vez tenga un límite de longitud.

Al almacenar texto en la base de datos, use los parámetros de consulta o salga de la cadena para asegurarse de que no tiene caracteres que creen vulnerabilidades de inyección SQL. El código puede contener más símbolos y caracteres no alfa, pero los que debe tener en cuenta con respecto a la inyección de SQL son los mismos que para el texto normal.

No intente duplicar la función de escape correcta. La mayoría de las bibliotecas de bases de datos ya contienen una función que corrige el escape para todos los caracteres que necesitan escapar (por ejemplo, esto puede ser específico de la base de datos). También debe manejar problemas especiales con conjuntos de caracteres. Simplemente use la función proporcionada por su biblioteca.

No entiendo por qué la gente dice " ¡usa procedimientos almacenados! " Los procesos almacenados no ofrecen protección especial contra la inyección SQL. Si interpola valores sin escape en cadenas de SQL y ejecuta el resultado, esto es vulnerable a la inyección de SQL. No importa si lo está haciendo en el código de la aplicación en lugar de en un proceso almacenado.

Al enviar a la presentación web, escape los caracteres HTML-especiales, como lo haría con cualquier texto.

Answer 3

Lo mejor que puede hacer para evitar ataques de inyección SQL es asegurarse de utilizar consultas parametrizadas o procedimientos almacenados al realizar llamadas a la base de datos. Normalmente, también recomendaría realizar un poco de desinfección de entrada básica, pero dado que necesita aceptar el código del usuario, esa podría no ser una opción.

En el otro extremo (al representar la entrada del usuario en el navegador), la codificación HTML de los datos hará que cualquier JavaScript malicioso o similar se represente como texto literal en lugar de ejecutado en el navegador del cliente. Cualquier marco decente de servidor de aplicaciones web debe tener la capacidad.

Answer 4

Yo diría que uno podría reemplazar todo < por & amp; lt ;, etc. (usando htmlentities en PHP, por ejemplo), y luego seleccione las etiquetas seguras con algún tipo de lista blanca. El problema es que la lista blanca puede ser demasiado estricta.

Aquí hay un ejemplo de PHP

$code = getTheCodeSnippet();
$code = htmlentities($code);
$code = str_ireplace("&lt;br&gt;", "<br>", $code); //example to whitelist <br> tags
//One could also use Regular expressions for these tags

Para evitar inyecciones SQL, puede reemplazar todos los caracteres 'y \ por un " innofensive " equivalente, como \ 'y \, de modo que la siguiente línea C

#include <stdio.h>//'); Some SQL command--

No tendría ningún resultado negativo en la base de datos.