2009-10-18 14 views
8

Sé que puedo utilizar el método de ayuda ActionView strip_tags en mis puntos de vista para desinfectar la salida, pero ¿cuál es la mejor manera de desinfectar la entrada del usuario antes de que yo persisto a mi db? ¿Debería encontrar una manera de incluir el asistente de visualización en mi controlador y volver a utilizar el método strip_tags? Pensé que los rieles tendrían algo disponible globalmente para hacer algo como esto.Esterilice XSS de entrada y de entrada HTML en los carriles

Respuesta

4

¿Qué pasa con el complemento xss_terminate?

+3

2 años después y dos votos a la baja sin comentarios: los comentarios al menos ayudarían a que los demás usuarios tuvieran una idea más clara. Nota: en el momento de la respuesta estábamos usando Rails 2 y ¡las cosas no eran tan buenas como lo son ahora! –

-1

¿Por qué necesita desinfectar la entrada del usuario?

Normalmente, todo lo que se necesita es una codificación/escape riguroso y sensible al contexto de la entrada del usuario siempre que lo imprima o lo incruste en un bloque de salida mayor.

+0

No tiene sentido dejar el código malicioso solo sentado en su base de datos. Múltiples vectores de ataque en aplicaciones web ya son un lugar común y esto simplemente parece una cosa fácil de arreglar, IMO. Defensa en profundidad, ¿sabes? – phreakre

+0

Rails 3 toma el enfoque correcto. Automáticamente se escapa html de todo (incluidos los datos ingresados ​​por el usuario) que se envía al html, excepto aquellos elementos específicos que el programador indica que ya son html-safe. Rails 3 hace defensa en profundidad, y lo hace de la manera correcta y rigurosa, con datos que se escapan en el lugar correcto y en el momento correcto. – yfeldblum

-1

¿Por qué quieres para desinfectar las entradas de usuario? ¡Eso ni siquiera tiene sentido! Siempre desea desinfectar (escapar) las salidas, no las entradas, porque el significado de sanitización depende del contexto en el que está usando el contenido. No existe una cadena segura en ningún contexto. No quiere un montón de cadenas alteradas en su base de datos que son "seguras" en cualquier escenario en el que su aplicación las esté utilizando hoy, porque mañana, quizás quiera hacer algo diferente con ellas. Si su capa de presentación está haciendo lo correcto (escapando contenido según el contexto), entonces está bien, no importa cuántas comillas, barras diagonales inversas o declaraciones DROP TABLE contengan.

+0

En algunos casos, tiene sentido "desinfectar" la entrada del usuario antes de almacenarla en la base de datos. Por ejemplo, si un usuario ingresa su apellido como "

Smith

", no tiene sentido almacenar la etiqueta html en la base de datos. En este caso, es bueno quitar la etiqueta html antes de guardar el apellido en la base de datos. –

+0

La pregunta original relacionada con la inyección (XSS y HTML), en cuyo caso sostengo que la desinfección es * siempre * worng. Pero incluso si de alguna manera tiene basura en la cadena, ¿cuáles son sus posibilidades de que la desinfección encuentre la basura? Es difícil para un algoritmo averiguar qué parte es y no es un nombre. Por ejemplo, ¿cuándo es parte de un sello y una entidad HTML, y cuándo es parte de un nombre como "Smith & Wesson"? Muy pronto, terminas con esto: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ – Enno

Cuestiones relacionadas