¿Qué son los ataques web? ¿Cómo proteger?

1. Los ataques DoS y DDoS (DoS (Denial of Service), es decir, denegación de servicio, provocando que el servidor remoto niegue el servicio se denomina ataque DoS. Su finalidad es impedir el funcionamiento del ordenador o de la red. de proporcionar servicios normales. Los ataques DoS más comunes incluyen ataques de ancho de banda de redes informáticas y ataques de conectividad)

Prevención: (1) Anti-spoofing: verifique la exactitud de la dirección y el puerto del paquete de datos, y realice. Detección inversa al mismo tiempo. (2) Análisis del patrón de comportamiento de la pila de protocolos: cada tipo de paquete de datos debe cumplir con las regulaciones RFC, es decir, cada paquete de datos debe tener una vestimenta completa y estandarizada, siempre que no cumpla con las especificaciones, se identificará y filtrará automáticamente. afuera. (3) Protección de aplicaciones específicas: el tráfico ilegal siempre tiene algunas características específicas, es decir, incluso si se mezcla con el grupo de clientes, su comportamiento seguirá revelando sus motivos, como hacerle al empleado la misma pregunta repetidamente. y aun así llamarás la atención. (4) Control de ancho de banda: cuando los datos de acceso reales son demasiado grandes, el flujo de salida máximo se puede limitar para reducir la presión sobre el sistema de red aguas abajo.

2. CSRF (Cross Site Request Forgery) es un ataque web común, pero muchos desarrolladores no están familiarizados con él. CSRF es también uno de los ataques que más se pasan por alto en la seguridad web.

Prevención: (1) Código de verificación. Durante la interacción entre la aplicación y el usuario, especialmente en pasos centrales como las transacciones de la cuenta, el usuario se ve obligado a ingresar un código de verificación para completar la solicitud final. En circunstancias normales, los códigos de verificación son lo suficientemente buenos como para contener ataques CSRF. Sin embargo, agregar códigos 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, los códigos de verificación solo se pueden utilizar como medio auxiliar para establecer códigos de verificación en puntos comerciales clave. (2) Verificación del árbitro. HTTP Referer es parte del encabezado. Cuando el navegador envía una solicitud al servidor web, generalmente trae la información del Referer para indicarle al servidor desde qué página está vinculado, de modo que el servidor pueda obtener cierta información para procesar. Los ataques CSRF se pueden defender comprobando el origen de la solicitud. El referente para solicitudes normales tiene ciertas reglas. Por ejemplo, el referente para enviar un formulario debe ser una solicitud iniciada en esa página. Por lo tanto, al verificar si el valor del referente del encabezado http es esta página, podemos determinar si se trata de un ataque CSRF. Pero en algunos casos, como al saltar de https a http, el navegador no enviará el referente por razones de seguridad y el servidor no podrá verificar. Si otros sitios web en el mismo dominio que este sitio web tienen vulnerabilidades XSS, los atacantes pueden inyectar scripts maliciosos en otros sitios web. Las víctimas que ingresen dichas URL en el mismo dominio también serán atacadas. Por las razones anteriores, no se puede confiar completamente en Referer Check como el medio principal para prevenir CSRF. Sin embargo, la aparición de ataques CSRF se puede monitorear a través de Referer Check. (3) Token anti-CSRF. La solución relativamente completa actual es agregar Anti-CSRF-Token, es decir, agregar un token generado aleatoriamente en forma de parámetro a 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 valor del 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. En caso contrario, la solicitud se considerará ilegal y se rechazará el servicio. Este método es mucho más seguro que la verificación del Referer. El token se puede generar después de que el usuario inicia sesión y se coloca en la sesión o cookie. Luego, el servidor saca el token de la sesión o cookie en cada solicitud y lo compara con el token en. esta petición. Haz una comparación.

Debido a la existencia del token, el atacante ya no puede construir una URL completa para implementar ataques CSRF. Sin embargo, cuando se trata de problemas de almacenamiento de varias páginas, cuando una determinada página consume el token, los formularios de otras páginas aún guardan el token consumido y se producirán errores de token cuando se envíen los formularios de otras páginas.

3. XSS (Cross Site Scripting), ataque de scripts entre sitios. Para distinguirlo de las hojas de estilo en cascada (CSS), los scripts entre sitios se denominan "XSS" en el campo de seguridad.

Prevención: (1) Filtrado de entradas. Nunca confíe en la entrada del usuario y realice ciertos filtrados en los datos ingresados ​​por el usuario. Por ejemplo, si los datos ingresados ​​se ajustan al formato esperado, como formato de fecha, formato de correo electrónico, formato de número de teléfono, etc. Esto puede proporcionar una defensa preliminar contra las vulnerabilidades XSS. Las medidas anteriores solo restringen el lado web. Los atacantes aún pueden eludir las restricciones de entrada del front-end utilizando herramientas de captura de paquetes como Fiddler y modificar la solicitud para inyectar scripts de ataque. Por lo tanto, el servidor backend necesita filtrar o escapar de los caracteres especiales peligrosos después de recibir los datos ingresados ​​por el usuario y luego almacenarlos en la base de datos. (2) Codificación de salida. La salida de datos del servidor al navegador se puede codificar o escapar utilizando las funciones de seguridad del sistema para evitar ataques XSS. En PHP, hay dos funciones htmlentities() y htmlspecialchars() que pueden cumplir con los requisitos de seguridad. El método de codificación JavaScript correspondiente puede utilizar JavascriptEncode. (3) Codificación de seguridad. El desarrollo debe intentar evitar la reescritura, redirección u otras operaciones confidenciales de documentos del cliente web, y evitar el uso de datos del cliente. Estas operaciones deben implementarse en el lado del servidor utilizando páginas dinámicas tanto como sea posible. (4) Cookie HttpOnly. El método de defensa más eficaz para evitar que los ataques XSS roben las cookies de los usuarios. Cuando una aplicación web configura una cookie, establecer su atributo en HttpOnly puede evitar que JavaScript malicioso en el lado del cliente robe la cookie de la página web y proteger la información de la cookie del usuario. (5) WAF (Web Application Firewall), firewall de aplicaciones web, su función principal es prevenir ataques de vulnerabilidad web comunes, como troyanos web, XSS y CSRF. Desarrollado por empresas de terceros, es popular en entornos corporativos.

4. Inyección SQL (Inyección SQL): cuando la aplicación transfiere SQL (lenguaje de consulta estructurado, lenguaje de consulta estructurado) a la base de datos backend, el atacante inserta el comando SQL en el formulario web para enviar o ingresar el nombre de dominio o La cadena de consulta de la solicitud de página finalmente engaña al servidor para que ejecute comandos SQL maliciosos.

Prevención: (1) Prevenir la fuga de información sensible del sistema. Configure la opción php.ini display_errors=off para evitar que se muestren errores de información confidencial en la página web después de que se produzca un error en el script php, dando a los atacantes la oportunidad de aprovecharse. (2) Escape de datos. Configure la opción php.ini magic_quotes_gpc=on, que agregará automáticamente \ delante de todas las '(comillas simples), "(comillas dobles), \(barra invertida), caracteres en blanco, etc. en las variables enviadas. O use mysql_real_escape () o la función addlashes() realiza el escape de los parámetros de entrada. (3) Agregar verificación de lista negra o lista blanca generalmente se refiere a verificar si la entrada del usuario se ajusta al tipo, longitud, rango de valores u otros formatos esperados. La verificación significa que si la entrada del usuario contiene contenido malicioso obvio, la solicitud del usuario será rechazada. Cuando se utiliza la verificación de la lista blanca, generalmente se usa la verificación de la lista negra.

5. Las vulnerabilidades de carga fueron explotadas de manera más desenfrenada por los piratas informáticos en la era DVBBS6.0. Al utilizar las vulnerabilidades de carga, puede obtener WEBSHELL directamente. Las vulnerabilidades de carga también son vulnerabilidades comunes en la actualidad. intrusiones. Esta vulnerabilidad permite a los usuarios cargar archivos arbitrarios, lo que potencialmente permite a un atacante inyectar contenido peligroso o código malicioso y ejecutarlo en el servidor.

Prevención: (1) Compruebe si el servidor ha determinado el tipo y el sufijo del archivo cargado. (2) Defina una lista blanca de tipos de archivos cargados, es decir, solo se permiten archivos de los tipos de la lista blanca. (3) El directorio de carga de archivos prohíbe el análisis de scripts para evitar ataques secundarios por parte de atacantes. Vulnerabilidad de información. La vulnerabilidad de información significa que CGI envía los parámetros de entrada a la página tal como están. El atacante puede engañar al usuario modificando los parámetros de entrada.