2010-03-16 23 views
6

Digamos que tenemos un formulario donde el usuario escribe en diversa información. Validamos la información y encontramos que algo está mal. Falta un campo, correo electrónico no válido, etcétera.¿Es seguro mostrar la entrada del usuario como valores de entrada sin desinfección?

Al volver a mostrar el formulario al usuario, por supuesto, no quiero que tenga que escribir todo de nuevo, por lo que quiero rellenar los campos de entrada. ¿Es seguro hacer esto sin desinfección? Si no, ¿cuál es la desinfección mínima que debe hacerse primero?

Y para aclarar: Por supuesto, sería desinfectado antes de ser, por ejemplo, agregado a una base de datos o se muestra en otro lugar en el sitio.

+1

Ahem. ¡Creo que te refieres a ** desinfección ** en lugar de ** saneamiento **! –

+0

@John: Puede ser muy correcto en eso: p – Svish

+0

http://xkcd.com/327/ debería explicar este problema. –

Respuesta

8

No, no lo es. El usuario puede ser dirigido al formulario desde un sitio de terceros, o simplemente ingresar datos (inocentemente) que romperían el HTML.

Convierta cualquier carácter con un significado especial a su entidad HTML.

es decir & a &amp;, < a &lt;, > a &gt; y " a &quot; (suponiendo que delimite sus valores de atributos usando " y no '.

En Perl utiliza HTML::Entities, en el TT utilizar el html filter, en PHP use htmlspecialchars. De lo contrario, busque algo similar en el idioma que está utilizando.

+0

Mientras está en lo correcto, el OP no estableció el contexto, y solo en el contexto de los datos que se ingresan para poder ser vistos por * otra persona *, (o ser capaz de autopolarlo y redireccionar un archivo existente/ingresó, usuario a su página). Sin esto, solo estás haciendo XSS en ti mismo, lo cual es bastante inútil. –

+0

Un atacante podría producir un enlace, que simula el envío del formulario (GET-params), por lo que podría hacerse un ataque XSS a otra persona. – Mnementh

+0

Tenga cuidado al usar estas funciones que intentan proporcionar una ventanilla única para resolver todos los problemas de inyección. Ninguno de ellos que he visto en ningún idioma funciona en todas las áreas de una página HTML. (o al menos sin datos de interrupción). Aplicar solo PHP htmlspecialchars() mencionado aquí ciertamente no lo mantendrá a salvo en un valor de atributo. – Cheekysoft

0

Sí, es seguro, siempre que codifique el valor correcto ly.

Un valor que se coloca dentro de un atributo en un HTML debe codificarse en HTML. La plataforma del lado del servidor que está utilizando debe tener métodos para esto. En ASP.NET, por ejemplo, hay un método Server.HtmlEncode, y el control TextBox codificará HTML automáticamente el valor que pones en la propiedad Text.

+0

-1 no es seguro. – rook

+0

@Rook: Eso es incorrecto. Es seguro, dadas las circunstancias que dije en la misma oración. Si no puede molestarse en leer la respuesta completa, al menos debe leer la primera oración completa antes de votar negativamente. – Guffa

+0

"siempre que codifique el valor correctamente". fue de hecho la clave aquí. Es cierto que es una condición grande y complicada, pero es el punto importante. La fase importante aquí es la codificación de salida y no la validación de entrada. Mientras que la validación de entrada es, por supuesto, altamente deseable; es importante entender que el paso de codificación de salida es lo que protege de XSS. – Cheekysoft

1

No es seguro, porque si alguien puede obligar al usuario a enviar datos específicos a su formulario, lo dará como resultado y será "ejecutado" por el navegador. Por ejemplo, si el usuario se ve obligado a enviar '/><meta http-equiv="refresh" content="0;http://verybadsite.org" />, como resultado, se producirá una redirección no deseada.

+0

Si alguien me obliga a ingresarlo en un navegador y enviarlo, lo que el navegador hace a continuación es la menor de mis preocupaciones. –

+0

@Paul: sí, pensé en http://imgs.xkcd.com/comics/security.png –

+0

Como un mal ejemplo, dado que el formulario que se envía al formulario de inicio de sesión del OP debería estar en un sitio diferente. Entonces, el atacante simplemente los redireccionará a verybadsite.org directamente, no hay ventaja de ir a * otro * sitio. – DisgruntledGoat

1

No puede insertar datos proporcionados por el usuario en un documento HTML sin codificarlo primero. Su objetivo es garantizar que la estructura del documento no pueda modificarse y que los datos siempre se traten como valores de datos y nunca como marcas HTML o código JavaScript. Los ataques contra este mecanismo se conocen comúnmente como "scripting entre sitios", o simplemente "XSS".

Si inserta en un valor de atributo HTML, entonces debe asegurarse de que la cadena no puede hacer que el valor del atributo termine prematuramente. También debe, por supuesto, asegurarse de que la etiqueta en sí no se puede finalizar. Puede lograr esto mediante la codificación HTML de cualquier carácter que no esté garantizado.

Si escribe HTML para que el valor del atributo de la etiqueta aparezca dentro de un par de caracteres de comillas dobles o comillas simples, solo necesita asegurarse de que html-encode el carácter de comillas que eligió usar. Si es no citando correctamente sus atributos como se describe anteriormente, entonces debe preocuparse por muchos más caracteres, incluyendo espacios en blanco, símbolos, signos de puntuación y otros caracteres de control ascii. Aunque, para ser honesto, es sin duda más seguro codificar estos caracteres no alfanuméricos de todos modos.

Recuerde que un valor de atributo HTML puede aparecer en 3 diferentes contextos sintácticos:

valor entre comillas dobles atributo

<input type="text" value="**insert-here**" /> 

Sólo es necesario codificar el carácter de comillas dobles en HTML a una adecuada valor seguro como &quot;

Valor de atributo entre comillas simple

<input type='text' value='**insert-here**' /> 

Sólo es necesario para codificar el carácter comilla simple en un valor seguro para HTML adecuado, tal como &#145;

valor de atributo sin comillas

<input type='text' value=**insert-here** /> 

Usted debe nunca tener una etiqueta HTML valor de atributo sin comillas, pero a veces esto está fuera de tu control. En este caso, realmente debemos preocuparnos por el espacio en blanco, la puntuación y otros caracteres de control, ya que nos separarán del valor del atributo.

Con excepción de los caracteres alfanuméricos, escape todos los caracteres con valores ASCII menores que 256 con el formato &#xHH; (o una entidad con nombre si está disponible) para evitar el cambio del atributo. atributos no cotizados se pueden romper de con muchos personajes, incluyendo [space]%*+,-/;<=>^ y | (y más). [para levantado de OWASP]

Recuerde que las reglas anteriores solo se aplican a la inyección de control cuando se inserta en un valor de atributo HTML. En otras áreas de la página, se aplican otras reglas.

Consulte el XSS prevention cheat sheet at OWASP para obtener más información

+0

entonces en PHP sería suficiente con 'htmlspecialchars' siempre y cuando tenga los valores de sus atributos entre comillas dobles? Me gusta: 'name =" value "'. – Svish

+0

@Swish en la circunstancia exacta que indique, sí. ... hasta que comencemos a preocuparnos por ataques de personajes multibyte y ataques de caracteres multibyte malformados, pero eso es un poco complicado para aquí – Cheekysoft

Cuestiones relacionadas