Codeigniter xss_clean dilema

Sé que esta pregunta se ha formulado una y otra vez, pero todavía no he encontrado la respuesta perfecta para mi gusto, así que aquí va otra vez …

He estado leyendo muchos comentarios polarizadores sobre xss_filter de CI. Básicamente la mayoría dice que es malo. ¿Puede alguien explicar cómo es malo, o al menos dar el 1 escenario más probable donde se puede explotar? He visto la clase de seguridad en CI 2.1 y creo que es bastante buena, ya que no permite cadenas maliciosas como document.cookie, document.write, etc.

Si el sitio tiene básicamente una presentación que no sea html, ¿es seguro usar global xss_filter (o si realmente está afectando mucho el rendimiento, utilícelo por formulario) antes de insertarlo en la base de datos? He estado leyendo acerca de los pros y los contras acerca de si escapar en la entrada / salida con la mayoría dice que debemos escapar solo en la salida. Pero, de nuevo, ¿por qué permitir cadenas como Click Me para guardarse en la base de datos?

Lo único que no me gusta es javascript: y eso se convertirá en [removed] . ¿Puedo extender las matrices del núcleo de seguridad $_never_allowed_str del CI para que las cadenas nunca permitidas vuelvan vacías en vez de [removed] ?

El mejor ejemplo razonable de error de esto que he leído es si un usuario tiene una contraseña de javascript:123 se limpiará en [removed]123 que significa que una cadena como este document.write123 también pasará como la contraseña del usuario. Por otra parte, ¿cuál es la probabilidad de que eso suceda e incluso si sucede, no puedo pensar en ningún daño real que puede hacer para el sitio.

Gracias

Básicamente, XSS es un problema de salida, pero Codeigniter lo trata como un problema de ENTRADA.

¿Puede alguien explicar cómo es malo …

El problema es que xss_clean altera su ENTRADA, lo que significa que en algunos casos (como el problema de la contraseña que ha descrito) la entrada no es lo que se espera.

… o al menos dar el 1 escenario más probable donde se puede explotar?

Solo busca ciertas palabras clave, como “javascript”. Hay otras acciones de script que xss_clean no detecta, además de que no lo protegerá contra ningún “nuevo” ataque.

Lo único que no me gusta es javascript: y eso se convertirá en [eliminado]. ¿Puedo extender las matrices del núcleo de seguridad $ _never_allowed_str del CI para que las cadenas nunca permitidas vuelvan vacías en lugar de [eliminar]

Podrías hacer esto, pero solo estás poniendo un curita en una solución pobre.

He estado leyendo acerca de los pros y los contras acerca de si escapar en la entrada / salida con la mayoría dice que debemos escapar solo en la salida.

Esta es la respuesta correcta: escape TODA su salida, y tiene verdadera protección XSS, sin alterar la entrada.

OWASP explica más sobre XSS aquí

Vea un buen hilo del foro Codeigniter en XSS

Personalmente, mi enfoque para la protección XSS en Codeigniter es que no hago NINGUNA limpieza XSS en las entradas. Ejecuto un hook en _output, que limpia todos mis “view_data” (que es la variable que uso para enviar datos a las vistas).

Puedo alternar si no quiero que se ejecute XSS Clean insertando “$ view_data [‘clean_output’] = false” en mi controlador, que el enganche comprueba:

 if (( ! isset($this->CI->view_data['clean_output'])) || ($this->CI->view_data['clean_output'])) { // Apply to all in the list $this->CI->view_data = array_map("htmlspecialchars", $this->CI->view_data); } 

Esto me brinda protección XSS automática y completa en todo mi sitio, con solo un par de líneas de código y sin rendimiento.