¡Echemos un vistazo a las vulnerabilidades web que los programadores front-end deben conocer!

Con el desarrollo de Internet, ya no se limita a simples páginas web o redes sociales, compras de comercio electrónico, transferencias bancarias, gestión empresarial, etc. La última vez que vi una noticia, después de que un programador de back-end renunció, aprovechó su puesto y siguió transfiriéndose dinero a sí mismo todos los días. Transferió dinero muchas veces antes de que lo descubrieran. O robar información comercial importante, por lo que la seguridad de la red también merece mucha atención.

¿Qué es la seguridad de la red?

Los piratas informáticos aprovechan las vulnerabilidades del sistema operativo de la red y las vulnerabilidades de inyección SQL del servidor web para controlar el servidor web, desde manipular, eliminar y agregar datos hasta robar información comercial importante y transferir fondos. se implanta en páginas web, lo que hace que el sitio web se vea comprometido de manera impredecible.

Los ataques comunes se pueden dividir en tres categorías: XSS, CSRF e inyección SQL.

Secuencias de comandos entre sitios Ataque de secuencias de comandos entre sitios, denominado XSS, para distinguirlo de CSS.

Los ataques maliciosos incorporan código de script malicioso en las páginas web. Cuando los usuarios navegan por la página web, se ejecutará el código de script incrustado en la página web, logrando así el efecto del ataque.

Para decirlo sin rodeos, los atacantes maliciosos agregan código de script malicioso en el cuadro de entrada. Cuando el usuario navega por la página web, el código de script se ejecutará, realizando así ataques maliciosos contra el usuario.

1.1 Peligros de XSS

1.2 Tipos de ataques XSS

Cuando se realiza una solicitud, el código XSS aparecerá en la URL y se envía la URL al servidor como entrada. Luego, el servidor lo envía de vuelta al navegador, que analiza el código XSS y lo ejecuta. Luego, el navegador analiza y ejecuta el código XSS. Este proceso se llama reflejo porque es como un reflejo condicionado.

Este tipo de ataque generalmente coloca el código de ataque XSS en la parte de transmisión de datos de la dirección de solicitud, por ejemplo:

El código XSS enviado se almacenará en el lado del servidor, como como base de datos, memoria o sistema de archivos, el código XSS no se enviará la próxima vez que se solicite la página de destino.

Los ataques XSS basados ​​en documentos no pasan por el servidor, sino que actúan como intermediario, secuestrando paquetes de red durante la transmisión de datos y luego modificando los documentos html dentro de ellos.

1.3 Medidas de defensa frente al XSS

Medida 1: Codificación.

Codificar datos en entidades html. Se requiere codificación de escape tanto en el lado del cliente como en el del servidor.

El código de escape es:

Colocarlo dentro del código anterior lo analizará automáticamente en el código anterior, así que déjelo afuera.

Acción 2: Filtrar.

Elimine los atributos DOM cargados por el usuario, como el error anterior.

Eliminar estilos, scripts y nodos de iframe subidos por el usuario.

Medida 3: Aprovechar CSP

La política de seguridad de contenido en el navegador determina qué recursos carga el navegador.

Falsificación de solicitudes entre sitios.

El atacante atrae a la víctima para que visite un sitio web de terceros, envía una solicitud entre sitios al sitio web atacado y utiliza las credenciales de registro que el atacante obtuvo en el sitio web atacado para evitar el back-back. autenticación del usuario final y robar al usuario la identidad del atacante se utiliza para realizar ciertas operaciones en el sitio web atacado.

Características de los ataques CSRF:

2.1: Daño de CSRF

2.2: Tipos de ataques CSRF

El uso de CSRF es muy simple. Solo se requiere una solicitud http.

Por ejemplo, si agrega un enlace a una imagen, iframe o script en la página, es más fácil completar un ataque CSFR y no es fácil de descubrir para los usuarios, por lo que es muy oculto.

Dado que la interfaz get es uno de los tipos más comunes de ataques CSRF, muchas interfaces importantes no son adecuadas para el método get. El uso de post puede prevenir ataques CSRF hasta cierto punto.

Este tipo de ataque SCRF normalmente utiliza el envío automático de formularios. En pocas palabras, falsifica un formulario de envío automático que se envía automáticamente una vez que visita la página.

Por ejemplo:

Este tipo de ataque de enlace es menos común que los dos primeros ataques. El usuario debe hacer clic en el enlace para desencadenar el ataque.

Por lo general, las imágenes publicadas en foros tienen enlaces maliciosos incrustados o trucos en forma de anuncios para atraer a los usuarios a hacer clic en ellas. Por eso, cuando veamos anuncios desordenados en nuestro buzón de correo, intentamos no hacer clic en ellos para evitar ataques de terceros.

Forja un nuevo tipo de método de ataque. El usuario piensa erróneamente que está iniciando sesión normalmente en el sitio web, de hecho, está usando su cuenta y contraseña para iniciar sesión en el sitio web del pirata informático. , el pirata informático puede monitorear todas las operaciones del usuario e incluso conocer la información de la cuenta del usuario.

2.3 Medidas de defensa frente a CSRF

Medida 1: Comprobar la información de referencia en el encabezado http

La información de referencia se incluye en el encabezado de la solicitud, indicando la página de la fuente de la interfaz de solicitud.

Al verificar la información de referencia, el servidor puede interceptar la solicitud cuando se descubre que proviene de un dominio externo. Esto puede evitar el acceso desde dominios externos desconocidos, reduciendo así los ataques hasta cierto punto.

Medida 2: utilizar tokens de un solo uso

Al utilizar tokens de un solo uso para la autenticación, los piratas informáticos no pueden obtener tokens de un solo uso en varios dominios, por lo que el servidor puede saber si llevan uno. -tokens de tiempo, excluyendo así a algunos operadores ilegales.

Medida 3: Utilice imágenes de verificación

El lado del servidor genera texto y números, guarda esta información en el lado del servidor y la muestra en el lado del cliente en forma de imágenes. para que el usuario La información se pueda completar legalmente, pero cuando el ataque CSRF no puede obtener el código de verificación, no puede proporcionar la información al servidor, lo que resulta en una falla de coincidencia e identificación como un atacante ilegal.

Esta es una aplicación muy común que requiere que rellenes un código gráfico de verificación al iniciar sesión.

La verificación de imágenes deslizantes también es muy común hoy en día.

La inyección SQL generalmente ocurre durante operaciones como registro, comentarios, agregados, etc., y solo es posible con la entrada del usuario.

La inyección SQL es una vulnerabilidad de seguridad web común que permite a un atacante explotar una vulnerabilidad potencial de la base de datos accediendo o modificando datos.

La llamada inyección SQL consiste en insertar comandos SQL en la cadena de consulta ingresada en el envío de un formulario web o en una solicitud de dominio o página, logrando en última instancia el propósito de inducir al servidor a ejecutar comandos SQL maliciosos. Específicamente, las aplicaciones existentes se aprovechan para inyectar comandos SQL (maliciosos) en el motor de base de datos backend para su ejecución. Al ingresar declaraciones SQL (maliciosas) en un formulario web, en lugar de ejecutar las declaraciones SQL como lo pretendía el diseñador, es posible obtener una base de datos de un sitio web con vulnerabilidades de seguridad. Por ejemplo, en el pasado, las contraseñas de membresía VIP de muchos sitios web de películas y televisión se filtraban principalmente al enviar caracteres de consulta a través de formularios web, y los formularios web son particularmente vulnerables a los ataques de inyección SQL.

3.1: Peligros de la inyección SQL

Cualquier cuenta puede iniciar sesión y se puede realizar cualquier operación.

3.2 Clasificación de la inyección SQL

Cuando el parámetro de entrada es un número entero, puede haber una vulnerabilidad numérica.

Cuando el parámetro de entrada es una cadena, puede existir una vulnerabilidad de inyección basada en caracteres.

La mayor diferencia entre la inyección numérica y la inyección de caracteres es que la inyección numérica no requiere un cierre de comillas simples, mientras que la inyección de caracteres generalmente requiere un cierre de comillas simples.

El punto más crítico de la inyección de caracteres es cómo cerrar la declaración SQL y comentar el código redundante.

De hecho, creo que sólo existen dos tipos de inyección SQL: numérica y de caracteres. Mucha gente puede decir que también existen inyección de cookies, inyección POST, inyección retrasada, etc.

Efectivamente.

Eso es cierto, pero este tipo de inyecciones son, en última instancia, manifestaciones diferentes de inyecciones numéricas y de caracteres, o inyecciones en diferentes lugares.

Las siguientes son algunas llamadas de inyección comunes:

3.3 Prevención de la inyección SQL

No importa dónde ingrese el usuario, debemos evitar que los piratas informáticos se entrometan y no Confíe en ellos crédulamente. Entrada del usuario. Por lo tanto, las medidas de defensa correspondientes son:

Después de separar el front-end y el back-end, el front-end estará expuesto a muchas interfaces todos los días. Algunas interfaces utilizarán el método get al enviar solicitudes de red. La forma más común de pasar parámetros es agregarlos directamente después de la dirección URL.

Al utilizar este método directamente para transmitir datos, si los datos son secuestrados o robados por herramientas después de ser capturados, se robarán directamente, lo cual es particularmente peligroso. Si utiliza cifrado de interfaz, se verá así:

La larga lista de símbolos poco claros que aparece arriba son los datos cifrados.

El cifrado de interfaz consiste en cifrar los parámetros pasados ​​en la llamada de solicitud de interfaz. El propósito es garantizar la seguridad de los parámetros pasados ​​en la solicitud de interfaz y los resultados devueltos. Generalmente, son datos relativamente confidenciales. como tarjetas de identificación y números de teléfono, cuentas, contraseñas, etc., todos deben estar encriptados.

Métodos de cifrado más utilizados:

Existen muchos métodos de cifrado y puede elegir uno según sus necesidades específicas y el idioma del proyecto.

Los datos cifrados son más seguros, entonces, ¿podemos cifrar todos los datos en la interfaz? El cifrado consume muchos recursos. Si se cifra una gran cantidad de datos, llevará más tiempo devolverlos, lo que afectará directamente la experiencia del usuario. Por lo tanto, al cifrar, solo necesitamos cifrar información importante y sensible.

Bien, aquí termina mi artículo de hoy. Este artículo no presentará la seguridad web. ¡Todos pueden comunicarse en el área de comentarios!