Prevenir problemas de inyección SQL
El umbral para la programación ASP es muy bajo, lo que facilita el comienzo para los principiantes. En un corto período de tiempo, los principiantes a menudo pueden compilar sitios web dinámicos que parecen ser relativamente perfectos en términos de funciones, y los principiantes también pueden hacer lo que pueden hacer los veteranos. Entonces, ¿no hay diferencia entre novatos y veteranos? La diferencia aquí es enorme, pero es difícil para un profano verla de un vistazo. La facilidad de interfaz, el rendimiento operativo y la seguridad del sitio web son los tres puntos principales que distinguen a los principiantes de los veteranos. En términos de seguridad, el problema que los principiantes pasan más fácilmente por alto son las vulnerabilidades de inyección SQL. Al usar NBSI
2.0 para escanear algunos sitios web ASP en Internet, puede encontrar que muchos sitios web ASP tienen vulnerabilidades de inyección SQL. Esta vulnerabilidad es más común en algunos sitios web de instituciones internas de universidades en la red educativa. Esto probablemente se deba a que la mayoría de estos sitios web están creados por estudiantes. Aunque todos son muy inteligentes, no tienen experiencia y todavía están aprendiendo, por lo que inevitablemente existen muchas lagunas. Este artículo habla principalmente sobre las medidas preventivas de la inyección SQL. Para comprender la utilidad de estas medidas preventivas, primero debe explicar en detalle el proceso de explotación de las vulnerabilidades de la inyección SQL. Los novatos entienden esto.
Un número considerable de programadores no juzgan la legalidad de los datos introducidos por el usuario cuando escriben código, lo que provoca riesgos de seguridad en las aplicaciones. Por ejemplo, si se trata de una URL normal mon\500-100.asp, cámbiela a
C:\WINDOWS\Help\iisHelp\common\500.htm. En este momento, no importa el error. ocurre durante la operación ASP, el servidor solo muestra el error HTTP 500.
Sin embargo, una desventaja de esta configuración es que cuando el código escrito por el programador comete un error, el servidor no muestra un mensaje de error detallado, lo que causará grandes inconvenientes al programador. Sin embargo, después de todo, el servidor no es un lugar para probar el código. La seguridad y la estabilidad deben ser la primera prioridad. De hecho, muchos mensajes de error del servidor se configuran de esta manera.
El administrador del servidor también debe establecer permisos de ejecución para cada sitio web en IIS, pero nunca otorgar permisos de "script y ejecutables" a otros sitios web estáticos. En circunstancias normales, es suficiente otorgar permiso de "script puro" para los directorios donde se almacenan los archivos cargados a través del centro de administración de backend del sitio web, sea más tacaño y establezca el permiso de ejecución en "Ninguno". un troyano ASP y establezca el permiso de ejecución en "Ninguno". Incluso si alguien carga un troyano ASP, no se ejecutará. En circunstancias normales, las vulnerabilidades de inyección SQL solo afectan la seguridad de un sitio web. Si alguien carga un troyano ASP a través de esta vulnerabilidad y lo ejecuta, todo el servidor se verá comprometido. Por lo tanto, los administradores de servidores responsables y con visión de futuro deberían ser muy tacaños a la hora de configurar los permisos de ejecución de IIS.
Se debe aplicar la misma actitud tacaña a la configuración de permisos de los usuarios de la base de datos. Por supuesto, la base de datos aquí se refiere a MS_SQL y ACCESS no tiene este paso de configuración de permisos de usuario. Si el permiso PÚBLICO es suficiente, nunca le otorgue permisos superiores, pero no le dé permisos de nivel SA a otros de manera casual. La llamada herramienta de detección de vulnerabilidades de seguridad de sitios web NBSI
2.0 tiene la función de inyección SQL entre bibliotecas. Si otorga permiso a SA a una biblioteca con vulnerabilidades de inyección SQL, ¡otras bibliotecas no estarán protegidas! Se produce un incendio en la puerta de la ciudad que afecta a los peces del estanque. Y las personas también pueden obtener la máxima autoridad del sistema llamando al comando xp_cmdshell. Para conocer pasos específicos, consulte el artículo "Exposición total a las vulnerabilidades de inyección SQL" mencionado anteriormente.
A continuación, hablemos de las medidas preventivas para programadores. El programa tiene que hacer principalmente dos cosas: la más importante es, por supuesto, detectar cuidadosamente los parámetros variables enviados por el cliente. Existen varios métodos para verificar las variables enviadas por el cliente para evitar la inyección de SQL. Busque en munity.csdn.net/ y podrá obtener mucha información útil. Aquí hay un método listo para usar. Otros ya han escrito el código de detección, por lo que puede usarlo sin tener que trabajar duro por su cuenta.
Es decir, "Maple Leaf SQL Universal Anti-Injection V1.0
versión ASP". Este es un fragmento de código que verifica los parámetros variables enviados por el usuario a través de la URL. por el cliente incluye "exec, al insertar, seleccionar, eliminar, de, actualizar, contar, usuario, xp_cmdshell, agregar, net, Asc" y otros caracteres comunes utilizados para la inyección SQL, inmediatamente dejará de ejecutar ASP y mostrará un mensaje de advertencia. o redirigir a una página de error. Puede buscar en línea, descargar este código, guardarlo como una página ASP, como checkSQL.asp, e incluir esta página en cada página ASP que necesite consultar la base de datos SQL con parámetros. Recuerde, simplemente agregue una línea como esta
file="checkSQL.asp"-->El código servirá.
Lo segundo que debe hacer el programador es cifrar la contraseña del usuario. Por ejemplo, utilice el cifrado MD5. MD5 no tiene un algoritmo inverso y no se puede descifrar. Incluso si alguien conoce la contraseña confusa que ha sido cifrada y almacenada en la base de datos, no tiene forma de saber la contraseña original. Sin embargo, las personas pueden usar el método ACTUALIZAR para reemplazar su contraseña por la suya propia, pero esta operación sigue siendo un poco problemática y las personas pueden darse por vencidas debido al problema. La llamada herramienta de detección de vulnerabilidades de seguridad de sitios web NBSI
2.0 no proporciona la función de operación ACTUALIZACIÓN, por lo que después de usar el cifrado MD5, las personas solo usan NBSI
2.0 sin operación manual. En este caso, será imposible obtener la contraseña de la cuenta del administrador del sitio web, lo que protegerá a muchos atacantes de nivel novato, ¡al menos aquellos jóvenes que no entienden ASP o SQL y son jóvenes no podrán hacer nada!
Este artículo ya es bastante largo. Originalmente quería tener una discusión racional sobre las llamadas herramientas de detección de vulnerabilidades de seguridad de sitios web como NBSI y otras herramientas de piratería, pero parece que es mejor rendirse. . Para mejorar la seguridad del sitio web, es necesario comprender los métodos de ataque. Sin embargo, el desarrollo de herramientas de piratería especiales para explotar las vulnerabilidades lo hace más fácil para aquellos que en realidad no tienen la tecnología de red ni los conocimientos de seguridad de red necesarios. Es decir, aquellos que no entienden ASP y no entienden ASP como se menciona en el artículo). Los jóvenes que no entienden SQL y son jóvenes pueden invadir fácilmente un sitio web. Además de causar problemas a muchos administradores de red, esto también tiene. ¿Cuál es el efecto de fortalecer la conciencia sobre la seguridad de la red y mejorar los niveles de seguridad de la red?