¿está bien "XS" limpiar "repetidamente" los datos en CodeIgniter?

Question

Las siguientes son formas de datos XSS-limpias en CodeIgniter:

• conjunto global_xss_filtering en config para TRUE
• uso xss_clean()
• uso xss_clean como una regla de validación
• ajustar el segundo parámetro para TRUE en $this->input->post('something', TRUE)

¿Está bien usar todos o más de uno de ellos en una sola pieza de datos?

Por ejemplo, ¿estaría bien si todavía Solía ​​$this->input->post('something', TRUE) incluso si los datos ya se ha limpiado por global_xss_filtering y xss_clean regla de validación?

Answer 1

Sí. Supongamos que su entrada es 'A'. Entonces, digamos que ejecuta una xss_clean para obtener el contenido XSS-safe:

B = xss_clean(A) 

Ahora, digamos que lo hago de nuevo para obtener C:

C = css_clean(B) 

Ahora, si B y C difieren, entonces debe significar que B tenía algún contenido xss-inseguro. Lo que significa claramente que xss_clean está roto ya que no limpió A correctamente. Por lo tanto, siempre que suponga que la función devuelve contenido xss-safe, está listo para continuar.

Un argumento que se puede hacer es ¿qué pasa si la función modifica incluso el contenido xss-safe? Bueno, eso apestaría y aún significaría que la función está rota, pero ese no es el caso (diciendo simplemente por mi experiencia, ya que nunca lo había visto comportarse así).

El único inconveniente que veo es la sobrecarga de procesamiento adicional, pero hacerlo dos veces está bien (una vez con filtrado global y otra vez explícitamente, en caso de que el filtrado global se apague en algún momento), y es una bonita ok gastos generales para la garantía de seguridad.

Además, si puedo agregar, codeigniters xss clean realmente no analiza el HTML y suelta las etiquetas y esas cosas. Simplemente convierte < y > en < y >. Entonces, con eso en mente, no veo nada que pueda salir mal.

Answer 2

No va a doler, pero definitivamente no tiene sentido.

Hay una gran posibilidad de que eventualmente llegue a un punto en el que el filtro global XSS sea engorroso. Dado que no se puede desactivar por controlador sin hacks extensos, y el acceso a los datos $_REQUEST sin procesar será imposible, tendrá que desactivarlo globalmente. Esto sucederá en el momento en que desee procesar una única pieza de datos de confianza o datos que no sean HTML y deben permanecer intactos.

Usarlo como una regla de validación de formulario es inútil y potencialmente destructivo también. Imagine cómo sería este sitio si cada vez que escribiera <script> fuera reemplazado por [removed], sin forma de revertirlo en el futuro.Para otro ejemplo, ¿qué sucede si un usuario usa contenido "XSS" en su contraseña? Su aplicación terminará alterando la entrada en silencio.

Simplemente use el filtro XSS donde lo necesite: en su salida de HTML, lugares donde se puede ejecutar javascript.

Answer 3

Usar xss_clean incluso una vez es malo en lo que a mí respecta. Esta rutina intenta desinfectar sus datos eliminando partes o reemplazando partes. Es con pérdida y no garantiza devolver el mismo contenido cuando se ejecuta varias veces. También es difícil de predecir y no siempre actuará de manera adecuada. Dada la cantidad de cosas que hace para tratar de desinfectar una cadena, hay un golpe de rendimiento masivo para usar esto en la entrada. Incluso la parte más pequeña de entrada como a = b causará una ráfaga de actividad para xss_clean.

Me gustaría decir que nunca se debe usar xss_clean pero de forma realista no puedo decir eso. Este sistema está hecho para desarrolladores sin experiencia que no saben cómo administrar de forma segura el contenido del usuario. Soy un desarrollador con experiencia, así que puedo decir que ningún proyecto en el que esté trabajando debería usar xss_clean. Sin embargo, el hecho es que los problemas de corrupción serán menos problemáticos para los desarrolladores inexpertos con un uso más simple y, en última instancia, probablemente harán su código más seguro incluso si deberían hacer que su código sea más seguro por sí mismos en lugar de depender de ataques rápidos y sucios. Por otro lado, xss_clean no garantiza que tu código sea completamente seguro y, por último, puede empeorar las cosas al dar una falsa sensación de seguridad. En su lugar, se recomienda estudiar realmente para asegurarse de que entiende exactamente todo lo que hace su código para que pueda hacerlo realmente seguro. xss_clean no compensa los errores de código, compensa los errores del codificador.

Lo ideal es que xss_clean solo se realice en la salida (y quiere ser reemplazado por htmlentities, etc.) pero la mayoría de la gente no se molestará con esto ya que es más simple violar la pureza de los datos filtrando todas las entradas en vez algo se puede ingresar una vez, pero la salida diez veces). De nuevo, un desarrollador indisciplinado no puede poner xss_clean para uno de esos diez casos de salida.

De manera realista, sin embargo, la única manera real decente es codificar correctamente todo en la vista en el momento en que se mostrará en una página. El problema con la codificación preventiva es que usted almacena datos que podrían estar codificados incorrectamente y puede doblar los datos codificados si se ingresan, luego se envían a un formulario y luego se ingresan de nuevo. Si piensas en algo así como un cuadro de edición, puedes tener serios problemas con el crecimiento de los datos. No todo el saneamiento elimina el contenido. Por ejemplo, si agrega pestañas esto agregará contenido. Si tiene una barra en su contenido cada vez que ejecuta addslashes, se agrega una nueva barra, lo que hace que crezca. Aunque existe una buena posibilidad de que sus datos terminen integrados en HTML, tampoco siempre se puede saber dónde terminarán los datos. De repente, obtienes un nuevo requisito que se aplica a los datos anteriores y eso es todo, estás jodido porque aplicaste un filtro con pérdida a los datos entrantes antes del almacenamiento. Por lossy, en este caso, eso podría significar su trabajo después de corromper todos los datos de usuario en su base de datos. Sus datos suelen ser lo más valioso para una aplicación web. Este es un gran problema con la codificación preventiva. Es más fácil trabajar con él si siempre sabe que sus datos son puros y puede escapar de acuerdo con la situación en la que se encontraba, pero si sus datos pueden estar en cualquier condición más adelante, esto puede ser muy problemático. El filtrado también puede causar algunas roturas lógicas ocasionales. Como la desinfección puede eliminar contenido, por ejemplo, dos cadenas que no coinciden pueden combinarse.

Muchos de los problemas con xss_clean de entrada son iguales o similares a los de magic_quotes: http://en.wikipedia.org/wiki/Magic_quotes

Resumen: Usted no debe usar, pero en lugar de bloquear los malos datos de entrada del usuario y escapar correctamente en la salida. Si desea desinfectar los datos del usuario, debe ocurrir en el cliente (navegador, validación del formulario) para que el usuario pueda verlo. Nunca debe tener alteraciones de datos invisibles. Si debe ejecutar xss_clean. Solo debe ejecutarlo una vez, en la salida.Si va a usarlo para la validación de la entrada, ¡$ $ data_data! == xss_clean ($ posted_data) y luego rechace.