Cómo eliminar los riesgos de seguridad de su sitio web
Cómo eliminar los siete riesgos principales de la seguridad de un sitio web
Antes de mejorar
Una empresa de pruebas de seguridad profesional externa realiza pruebas y la lista de cuestiones clave es el siguiente:
Problema 1: Vulnerable a ataques de inyección SQL
Riesgo: un atacante puede enviar comandos de base de datos a través de la aplicación, y estos comandos serán ejecutados por el servidor. Esto se puede utilizar para tener control total sobre la base de datos. Estas vulnerabilidades de inyección SQL se pueden determinar insertando "and?7?=?7?-" o "and?8?=?9?-" en uno de los campos y comparando los resultados.
Análisis: Los ataques de inyección SQL son causados por una verificación insuficiente de parámetros por parte del servidor, lo que permite al atacante obtener información confidencial. Por lo tanto, es necesario utilizar consultas parametrizadas para garantizar que los atacantes no puedan manipular las declaraciones de consulta SQL de la base de datos. Por ejemplo, si una aplicación requiere un nombre, solo debe aceptar caracteres alfabéticos, espacios y apóstrofes, y ningún otro carácter. Es decir, implemente tecnología de listas blancas del lado del servidor para todos los campos de entrada de su aplicación. En particular, todos los campos de entrada utilizados en declaraciones SQL que requieren espacios deben estar entre comillas.
Mejora: Identificar uno por uno todos los lugares del programa que aceptan parámetros externos para filtrar caracteres peligrosos. Por ejemplo, si define una "lista de cadenas prohibidas" en una función global, esta tabla enumera las cadenas que pueden incluirse en el código de ataque SQL que se filtrará.
y?|exec?|insertar?|seleccionar?|eliminar?|actualizar?|contar?|?*?|chr?|mid?|master?|truncar?|char?|declarar?| <|>|'|(|)|{|}
//Por supuesto, puedes mejorar y modificar esta lista según las características del sitio web
Luego haz lo siguiente :
Problema 2: Vulnerable a ataques de secuencias de comandos entre sitios
Riesgo: esta vulnerabilidad se puede aprovechar para obtener cookies de autenticación, atacar cuentas de administrador o permitir que los usuarios de la aplicación ataquen a otros. servidores y sistemas. Esta vulnerabilidad se puede determinar insertando "" en un área determinada.
Análisis: Esto también requiere la implementación de tecnología de listas blancas del lado del servidor en todos los campos de entrada de este sitio web. Si se requieren caracteres especiales, se deben convertir a una forma más segura. Por ejemplo, transcodificación HTML aplicable a varios idiomas:
& debe convertirse a?&;
"debe convertirse a";
' debe convertirse a&39 ;
> debe convertirse a >;
< debe convertirse a <.
Mejora: además de estas transcodificaciones HTML estándar, también se requiere una inspección y conversión mejoradas de cadenas sospechosas, y se realizan las siguientes operaciones: (1) Inspección mejorada de los parámetros de entrada de cada página ( 2) Para los parámetros que originalmente solo se juzgaban en el lado del cliente, se fortalece aún más la inspección en el lado del servidor (3) Finalmente, se proporcionan funciones de filtrado y transcodificación global; Por supuesto, esto requiere una consideración equilibrada del rendimiento, la escalabilidad y la seguridad.
Problema 3: Archivo CrossDomain.XML no seguro
Riesgo: Para resolver el problema entre dominios en el sistema Flash/Flex, el archivo de política entre dominios crossdomain.xml se propone. Aunque puede resolver el problema entre dominios, también conlleva el riesgo de ataques maliciosos. Si el archivo de política permite el acceso a cualquier dominio, puede permitir la falsificación de solicitudes entre sitios y ataques de secuencias de comandos entre sitios en el servidor de red. Por ejemplo, las aplicaciones Flash no seguras pueden acceder a datos locales y registros de páginas web guardados por el usuario, e incluso propagar virus y códigos maliciosos.
Análisis: considere cómo garantizar que solo se permitan dominios confiables que proporcionen recursos seguros.
Mejora: después de la investigación, se encontró que la configuración en el archivo crossdomain.xml en el directorio del programa es la siguiente:
La entidad permitir-acceso-desde? en el archivo está configurado como estrella. Establezca el número para permitir el acceso desde cualquier dominio, cámbielo a ?
Pregunta 4: ¿El parámetro de Flash AllowScript-Access? se ha configurado en siempre
Riesgo: cuando AllowScriptAccess es siempre, indica que el archivo Flash de terceros integrado puede ejecutar código. Un atacante ahora puede utilizar esta falla para incrustar cualquier archivo Flash de terceros y ejecutar código malicioso.
Análisis: El parámetro AllowScriptAccess puede ser "siempre", "mismoDominio" o "nunca". De los tres valores opcionales, "siempre" significa que el archivo Flash puede comunicarse con la página HTML en la que está incrustado, incluso si el archivo Flash proviene de un dominio diferente al de la página HTML. Cuando el parámetro es "sameDomain", el archivo Flash puede comunicarse con la página HTML sólo si proviene del mismo dominio que la página HTML en la que está incrustado. Este valor es el valor predeterminado de AllowScriptAccess?. Cuando AllowScriptAccess es "nunca", el archivo Flash no podrá comunicarse con ninguna página HTML.
Por lo tanto, debe configurar el parámetro AllowScriptAccess en "sameDomain" para evitar que los archivos Flash de un dominio accedan a secuencias de comandos en páginas HTML de otro dominio.
Mejora
name="allowScriptAccess"?value="always"?/> Cambiado a name="allowScriptAccess"?value="sameDomain"?/> Problema 5: la administración del backend del sitio web se implementa a través de enlaces no seguros Análisis: SSL no se aplica para el acceso de administración. Para evitar la interceptación de datos, se debe aplicar HTTPS (SSL3.0) para el acceso de administración. Mejora: Operación y mantenimiento han realizado ajustes de configuración en el servidor, y la configuración separada admite el acceso SSL3.0 al backend de administración. Problema 6: el enlace de verificación se puede omitir. Riesgo: cuando los usuarios publican información, aunque hay un código de verificación en la página para evitar publicaciones maliciosas automáticas, aún así se puede omitir. para envío automático. Una forma de evitarlo es utilizar software de filtrado e identificación, y la otra es utilizar cookies o información de sesión para evitar el código de verificación. Análisis: El mecanismo de distorsión de la imagen en sí no es particularmente fuerte y puede identificarse fácilmente utilizando un software de reconocimiento y filtrado disponible públicamente. Las imágenes generadas también son predecibles, dado que el conjunto de caracteres utilizado es simple (solo números), se recomienda implementar un sistema de captcha más robusto. ¿Existe una laguna en el procesamiento de información de sesión o cookies que hace que se omita el código de verificación? Asegúrese de que cada enlace solo pueda obtener un código de verificación único y asegúrese de que cada solicitud genere y requiera un nuevo código de verificación. . Mejora: aumente la complejidad del código de verificación según sea necesario, no solo un dígito. Después del análisis, se descubrió que el código de verificación estaba almacenado en la sesión y el desarrollador olvidó borrar el valor del código de verificación en la sesión después del envío, lo que resultó en que el código de verificación estuviera disponible dentro de la sesión. tiempo de vencimiento, que puede ser Aproveche múltiples confirmaciones. Por lo tanto, la operación de borrar el código de verificación a tiempo se agrega después del envío. Problema 7: Divulgación de información confidencial Riesgo: esta información solo puede usarse para ayudar a explotar otras vulnerabilidades y no puede usarse directamente para dañar aplicaciones. Se puede obtener información sobre directorios confidenciales en el archivo robots.txt del sitio web, lo que puede permitir a un atacante obtener información adicional sobre las partes internas de la aplicación, que puede usarse para explotar otras vulnerabilidades. Análisis: robots.txt no debería proporcionar información de la interfaz de administración. Si el archivo robots.txt expone la estructura del sitio web, el contenido confidencial debe moverse a una ubicación aislada para evitar que los robots de los motores de búsqueda rastreen este contenido. Mejora: Por supuesto, el archivo robots.txt debe procesarse de acuerdo con los requisitos de SEO, pero también se debe prestar atención a la seguridad. Por ejemplo: disallow:/testadmin/, donde testadmin es el fondo de gestión, está expuesto. Puede decidir si es necesario eliminar el archivo robots.txt o configurar el directorio confidencial por separado para prohibir las búsquedas en los motores de búsqueda según la situación real. Resumen de otros problemas Además, existen muchos otros problemas relativamente menos dañinos, que se analizan a continuación. Problema: Es posible enumerar nombres de usuario a través de la página de inicio de sesión porque el mensaje de error es diferente dependiendo de si la cuenta existe. Contramedidas: Modifique el mensaje de error para que no aparezca, como "¡La dirección de correo electrónico o la contraseña que ingresó son incorrectas!" Y si excede un cierto número de veces, la IP se bloqueará. Problema: se detectaron archivos redundantes que pueden filtrar información confidencial o usarse de manera maliciosa, como archivos de prueba, archivos bak y archivos temporales. Contramedida: Eliminar los archivos correspondientes del servidor. Problema: se encontró información potencialmente confidencial, como un archivo llamado pedido que puede asociarse fácilmente con los pedidos de los usuarios. Contramedidas: evite incluir palabras confidenciales completas en los nombres de los archivos o no almacene información confidencial en archivos que sean fáciles de adivinar, ni restrinja el acceso a ellos. Problema: Se descubrió una fuga de información interna. Contramedidas: Eliminar direcciones IP internas faltantes, organización interna, información relacionada con el personal, etc. en el código. *** Análisis de causas Entre los problemas descubiertos, el 71% fueron problemas de seguridad relacionados con las aplicaciones. Los problemas de seguridad relacionados con las aplicaciones se pueden modificar porque son causados por fallas en el código de la aplicación. El 29% son problemas de seguridad de infraestructura y plataforma que un administrador de red o sistema puede solucionar porque estos problemas de seguridad son causados por configuraciones incorrectas o fallas en productos de terceros. Las razones principales incluyen, entre otras, los siguientes tres aspectos. Aspectos de procedimiento Los caracteres peligrosos no se limpian correctamente con la entrada del usuario; Se toman consideraciones de seguridad insuficientes al utilizar cookies y sesiones; Los comentarios HTML o los formularios ocultos contienen información confidencial; La información de error proporcionada a los usuarios contiene información confidencial; La información de depuración del programador en la página web no se elimina a tiempo. La programación o configuración de aplicaciones web no es segura; Aspecto de configuración Los archivos redundantes que quedan en el directorio web no se limpian a tiempo; El servidor web o el servidor de aplicaciones está configurado de forma insegura. Los documentos de especificaciones de seguridad no son lo suficientemente completos y los desarrolladores no tienen suficiente capacitación; Los desarrolladores no tienen suficiente experiencia ni conciencia de seguridad relacionadas con la seguridad. La solución a estos problemas - más allá de la tecnología La solución al problema de seguridad en sí puede que sólo sea caso por caso, pero para evitar más problemas potenciales Introducción, mejoras en aspectos distintos a la tecnología no se pueden ignorar: 1.? Proporcionar a los desarrolladores capacitación en desarrollo de seguridad en las primeras etapas del proyecto para fortalecer la conciencia sobre la seguridad. 2. Establecer una plataforma para compartir experiencias de seguridad y formar una Lista de verificación de experiencias como documento guía de seguridad. 3. Extraiga los resultados del código maduro en módulos de seguridad pública para su uso futuro. Después de esta mejora, se han resumido algunos principios de seguridad básicos de uso común para su referencia; consulte "Principios de seguridad para el desarrollo de sitios web no oficiales e incompletos". Sobre el autor: Chao Xiaojuan, actualmente responsable de la gestión de proyectos en una empresa de Internet. Editor de la comunidad SOA del sitio web chino InfoQ, tiene muchos años de experiencia en gestión de desarrollo web, centrándose en gestión de proyectos, arquitectura y productos. (Este artículo proviene de la revista "Programmer", Número 02, 2013)