2010-03-03 17 views
7

Si tengo campos que sólo alguna vez se muestran al usuario que entra en ellos, ¿hay alguna razón para desinfectar contra cross-site scripting?¿Hay alguna razón para desinfectar las entradas de los usuarios para evitar que se realicen scripts entre sitios?

Editar: Así que el consenso es claro, que debe ser desinfectado. Lo que estoy tratando de entender es por qué? Si el único usuario que jamás puede ver la secuencia de comandos que se insertan en el sitio es el propio usuario, entonces la única cosa que puede hacer es ejecutar la secuencia de comandos a sí mismo, que ya podía prescindir de mi sitio está involucrado. ¿Cuál es el vector de amenaza aquí?

Respuesta

4

En teoría: no. Si está seguro de que solo ellos verán esta página, permita que escriban lo que quieran.

El problema es que hay muchas maneras en que pueden hacer que otras personas vean esa página, formas en que no la controlas. Incluso pueden abrir la página en la computadora de un compañero de trabajo y hacer que la miren. Es innegablemente un vector de ataque extra.

Ejemplo: a pastebin sin almacenamiento persistente; publicas, obtienes el resultado, eso es todo. Se puede insertar un script que agregue discretamente un botón "donar" para vincularlo a su cuenta de PayPal. Póngalo en la computadora de la gente lo suficiente, espero que alguien done, ...

Estoy de acuerdo en que este no es el más impactante y realista de los ejemplos. Sin embargo, una vez que tiene que defender una decisión relacionada con la seguridad con "eso es posible pero tampoco suena malo", usted sabe que ha cruzado una línea determinada.

De lo contrario, no estoy de acuerdo con respuestas como "nunca confíes en la entrada del usuario". Esa afirmación no tiene sentido sin contexto. El punto es cómo definir la entrada del usuario, que fue la pregunta completa. ¿Confiar en cómo, semánticamente? Sintácticamente? A qué nivel; solo tamaño? ¿HTML correcto? ¿Subconjunto de caracteres Unicode? La respuesta depende de la situación. Un servidor web simple "no confía en la entrada del usuario", pero muchos sitios se piratean hoy, porque los límites de "entrada del usuario" dependen de su perspectiva.

En pocas palabras: evite que cualquier persona tenga influencia sobre su producto a menos que sea claro para un consumidor soñoliento y no técnico qué y quién.

Eso descarta casi todos los JS y HTML desde el primer momento.

P.S .: En mi opinión, el PO merece crédito por hacer esta pregunta en primer lugar. "No confíes en tus usuarios" no es la regla de oro del desarrollo de software. Es una mala regla general porque es demasiado destructiva; desvirtúa las sutilezas en la definición de la frontera de interacción aceptable entre su producto y el mundo exterior. Suena como el final de una lluvia de ideas, mientras que debería comenzar una.

En esencia, el desarrollo de software consiste en crear una interfaz clara desde y hacia su aplicación. Todo dentro de esa interfaz es Implementación, todo lo que está fuera es Seguridad. Hacer que un programa haga las cosas que quiere es tan preocupante que uno se olvida fácilmente de hacer que no haga nada más.

Imagine la aplicación que intenta crear como una bella foto o foto. Con el software, intentas aproximar esa imagen. Utiliza una especificación como boceto, por lo que ya aquí, cuanto más descuidada sea su especificación, más borroso será su boceto. Sin embargo, el perfil de su aplicación ideal es fino como una navaja. Intenta recrear esa imagen con código. Cuidadosamente llenas el contorno de tu boceto. En el núcleo, esto es fácil. Use pinceles anchos: boceto borroso o no, esta parte claramente necesita coloración. En los bordes, se vuelve más sutil. Esto es cuando te das cuenta de que tu dibujo no es perfecto. Si vas demasiado lejos, tu programa comienza a hacer cosas que no quieres, y algunas podrían ser muy malas.

Cuando ve una línea borrosa, puede hacer dos cosas: mire más de cerca su imagen ideal e intente refinar su boceto, o simplemente deje de colorear. Si haces esto último, es probable que no vayas demasiado lejos. Pero también solo hará una aproximación aproximada de su programa ideal, en el mejor de los casos. ¡Y aún podrías cruzar la línea accidentalmente! Simplemente porque no estás seguro de dónde está.

Tienes la bendición de mirar más de cerca esa línea borrosa e intentar redefinirla. Cuanto más cerca esté del límite, más seguro estará de que está, y menos probabilidades tendrá de cruzarlo.

De todos modos, en mi opinión, esta pregunta no era de seguridad, sino de diseño: ¿cuáles son los límites de su aplicación y cómo los refleja su implementación?

Si la respuesta es "nunca confíe en la entrada del usuario", su boceto es borroso.

(y si no está de acuerdo:?!. ¿Y si funciona para OP "testxsshere.com" boom jaque mate)

(alguien debería registrarse testxsshere.com)

0

, siempre desinfectar la entrada del usuario:

  1. entrada del usuario nunca confía en
  2. No se necesita mucho esfuerzo para hacerlo.

El punto clave es .

1

El hecho de que no muestran un campo para alguien, no quiere decir que un potencial Sombrero Negro no sabe que están allí. Si tiene un vector de ataque potencial en su sistema, tape el agujero. Va a ser realmente difícil explicarle a su empleador por qué no lo hizo si alguna vez lo explota.

0

Si la secuencia de comandos, o servicio, que la forma se somete a los valores está disponible a través de la Internet, entonces cualquier persona, en cualquier lugar, puede escribir un script que va a presentar valores a la misma. Entonces: , desinfecte todas las entradas recibidas.

El modelo más básico de la web de seguridad es bastante simple:

No confía en sus usuarios

Es también digno de ligarse a mi respuesta en otro post (Steps to become web-security savvy): Steps to become web security savvy.

No puedo creer que le respondí sin hacer referencia al título-pregunta:

¿Hay alguna razón para desinfectar la entrada del usuario para evitar que las secuencias de comandos en sitios cruzados sí mismos?

Estás no impide que el usuario 's estar entre sitios guión, que está protegiendo su sitio (o, más importante aún, usted es cliente ' sitio de s) de ser el víctima de secuencias de comandos entre sitios. Si no cierra los huecos de seguridad conocidos porque no se puede molestar, será muy difícil obtener un negocio nuevo. O buena publicidad boca a boca y recomendación de clientes anteriores.

Piense en ello menos como proteger a su cliente, piense en ello -si es útil- como protegiendo su negocio.

1

I don' Creo que esta pregunta ha sido respondida por completo. Él quiere ver un ataque XSS accuall si el usuario solo puede atacarse a sí mismo. Esto se hace realmente mediante una combinación de CSRF y XSS.

Con CSRF puede hacer que un usuario haga una solicitud con su carga útil. Entonces, si un usuario puede atacarse a sí mismo usando XSS, puede hacerlo atacarse a sí mismo (haga que haga una solicitud con su XSS).

Una cita de The Web Application Hacker’s Handbook:

mito común:

“No estamos preocupados acerca del error XSS de bajo riesgo. Un usuario podría explotarlo solo para atacarse a sí mismo. "

Incluso las vulnerabilidades aparentemente de bajo riesgo pueden, en las circunstancias adecuadas, allanar el camino para un ataque devastador. Adoptar un enfoque de defensa en profundidad de la seguridad implica eliminar todas las vulnerabilidades conocidas, por insignificantes que parezcan. Los autores incluso han utilizado XSS para colocar los cuadros de diálogo del buscador de archivos o los controles ActiveX en la respuesta de la página, lo que ayuda a salir de un sistema en modo kiosco vinculado a una aplicación web de destino. ¡Siempre asuma que un atacante será más imaginativo que usted en el diseño de formas de explotar errores menores!

Cuestiones relacionadas