si estoy desinfectando mis inserciones de base de datos y también escapo del código HTML que escribo con htmlentities($text, ENT_COMPAT, 'UTF-8')? ¿Hay algún punto para filtrar también las entradas con xss_clean? ¿Qué otros beneficios ofrece?CodeIgniter: ¿por qué usar xss_clean
xss_clean() es extenso, y también tonto. El 90% de esta función no hace nada para evitar xss. Como buscar la palabra alert pero no document.cookie. Ningún pirata informático va a utilizar alert en su exploit, van a secuestrar la cookie con xss o leer un token CSRF para hacer un XHR.
Sin embargo, ejecutar htmlentities() o htmlspecialchars() es redundante. Un caso en el que xss_clean() corrige el problema y htmlentities($text, ENT_COMPAT, 'UTF-8') falla es el siguiente:
<?php
print "<img src='$var'>";
?>
A poc simple es:
http://localhost/xss.php?var=http://domain/some_image.gif '% 20onload = alerta (/ XSS /)
Este agregará el controlador de eventos onload= a la etiqueta de imagen. Un método para suspender esta forma de xss es htmlspecialchars($var,ENT_QUOTES); o en este caso xss_clean() también lo evitará.
Sin embargo, citando la documentación xss_clean():
Nada es 100% a prueba de tontos, de supuesto, pero no he podido conseguir nada pasado el filtro.
Dicho esto, XSS es un output problemno un input problem. Por ejemplo, esta función no puede tener en cuenta que la variable ya está dentro de una etiqueta <script> o controlador de eventos. Tampoco detiene DOM Based XSS. Debe tener en cuenta cómo está usando los datos para utilizar la mejor función. Filtrar todos los datos en la entrada es una mala práctica . No solo es inseguro sino que también daña datos que pueden dificultar las comparaciones.
Gracias. Supongo que el punto importante es realmente "¿qué estás haciendo con los datos?". El trabajo en el que estaba trabajando cuando surgió era un bloque de texto editable, donde no quería ninguna etiqueta HTML activa, por lo que mi solución funciona en ese caso. La salida se descarga en un DIV, y con todas las etiquetas HTML codificadas, no veo cómo se podría insertar nada malicioso allí. Por supuesto, si quisiera permitir algo de HTML en la entrada que complicaría las cosas. Aún así, no estoy muy contento con la idea de codificar todo en la entrada, prefiero manejarlo según sea necesario en la salida (mientras protejo el db por supuesto). –
@Dan Searle si quiere un subconjunto seguro de html, entonces debe finalizar la descarga htmlpurifier.org – rook
XSS * es * un problema de salida y no de entrada, por lo que algo como 'xss_clean()' puede * nunca * ser un enfoque confiable para resolver problemas XSS (y 'xss_clean()' en sí mismo es una implementación ridículamente terrible incluso por los bajos y bajos estándares de las herramientas anti-XSS). Estoy muy sorprendido de que parezca respaldarlo como una alternativa preferible al escape a nivel de salida en su primera oración. – bobince
Sí, todavía debe usarlo, generalmente lo uso como regla en entrada pública, es decir, cualquier entrada a la que cualquiera pueda acceder y enviar.
En general, la desinfección de la entrada para las consultas DB parece un efecto secundario ya que el verdadero propósito de la función es evitar Cross-site Scripting Attacks.
No voy a entrar en los detalles esenciales de cada paso que toma xss_clean, pero le diré que hace más que los pocos pasos que mencionó, tengo pastied the source of the xss_clean function para que pueda ver usted mismo, está completamente comentado
Recomendaría usar http://htmlpurifier.org/ para hacer la purificación de XSS. Estoy trabajando para extender mi clase de entrada CodeIgniter para comenzar a aprovecharla.
En su caso, "stricter methods are fine, and lighter weight". Los desarrolladores de CodeIgniter pretenden xss_clean() para un caso de uso diferente, "un sistema de comentarios o foro que permite etiquetas HTML 'seguras'".Esto no está claro en la documentación, donde se muestra xss_clean aplicado a un campo de nombre de usuario.
Hay otra razón para nunca usar xss_clean(), que no se haya resaltado en stackoverflow hasta el momento. xss_clean() se rompió durante 2011 y 2012, y es imposible de arreglar por completo. Al menos sin un rediseño completo, que no sucedió. At the moment, it's still vulnerable to strings like this:
<a href="j&#x41;vascript:alert%252831337%2529">Hello</a>
La implementación actual de xss_clean() se inicia mediante la aplicación efectiva urldecode() y html_entity_decode() para toda la cadena. Esto es necesario para que pueda usar una verificación ingenua para cosas como "javascript:". Al final, devuelve la cadena decodificada.
Un atacante simplemente puede codificar su exploit dos veces. Será decodificado una vez por xss_clean(), y pasará como limpio. Luego tiene un exploit codificado individualmente, listo para ser ejecutado en el navegador.
Llamo a estos controles "ingenuos" y no se pueden corregir porque dependen en gran medida de expresiones regulares. HTML no es un lenguaje normal. You need a more powerful parser to match the one in the browser; xss_clean() no tiene nada de eso. Tal vez sea posible incluir en la lista blanca un subconjunto de HTML, que lee limpiamente con expresiones regulares. Sin embargo, el actual xss_clean() es en gran medida una lista negra.
Si desea que el filtro se ejecute automáticamente cada vez que encuentre datos POST o COOKIE, puede habilitarlo abriendo su archivo application/config/config.php y estableciendo esto: $ config ['global_xss_filtering'] = TRUE;
Puede habilitar la protección csrf abriendo su archivo application/config/config.php y estableciendo esto: $ config ['csrf_protection'] = TRUE;
para obtener más información, consulte el siguiente enlace.
https://ellislab.com/codeigniter/user-guide/libraries/security.html
'htmlentities ($ texto, ENT_COMPAT, 'UTF-8')' no es un buen método para detener XSS, nadie debe utilizar esto. – rook
'htmlentities' es absolutamente una prueba contra la inyección de HTML, aunque se necesita' ENT_QUOTES' en lugar de 'ENT_COMPAT' si alguna vez utiliza delimitadores de atributos de comillas simples. 'htmlspecialchars' es generalmente preferible a' htmlentities', ya que tiene menos posibilidades de estropear el conjunto de caracteres. El 'xss_clean' de CodeIgniter es una zona de desastre de programación de cultos sin valor, llena de malentendidos erróneos sobre lo que constituye el manejo de cadenas. – bobince