Cómo prevenir mejor los ataques de piratas informáticos. ¡Me gustaría dar mi opinión personal! En primer lugar, los programas gratuitos no deben utilizarse de forma gratuita. Dado que se puede compartir el código original, los atacantes también pueden analizar el código. Si prestas atención a los detalles, la seguridad de tu sitio mejorará enormemente. Incluso si se produce una vulnerabilidad como la inyección SQL, es imposible que un atacante elimine su sitio de inmediato.
Debido a la conveniencia y facilidad de uso de ASP, cada vez más programas en segundo plano de sitios web utilizan el lenguaje de secuencias de comandos ASP. Sin embargo, debido a que el propio ASP tiene algunas vulnerabilidades de seguridad, los piratas informáticos pueden aprovecharlas si no tienen cuidado. De hecho, la seguridad no es sólo una cuestión de administradores de red, los programadores también deben prestar atención a ciertos detalles de seguridad y desarrollar buenos hábitos de seguridad; de lo contrario, traerá enormes riesgos de seguridad a sus sitios web. En la actualidad, la mayoría de los programas ASP en sitios web tienen agujeros de seguridad de un tipo u otro, pero si se presta atención al escribir programas, aún se pueden evitar.
1. El nombre de usuario y la contraseña están descifrados.
Principio de ataque: el nombre de usuario y la contraseña suelen ser lo que más interesa a los piratas informáticos. Si el código fuente se ve de alguna manera, las consecuencias serán graves.
Habilidades de prevención: los programas que involucran nombres de usuario y contraseñas se encapsulan mejor en el lado del servidor y aparecen lo menos posible en archivos ASP. Los nombres de usuarios y contraseñas que involucran conexiones de bases de datos deben recibir los permisos mínimos. Los nombres de usuario y las contraseñas que aparecen con frecuencia se pueden escribir en un archivo de inclusión oculto. Si implica conectarse a la base de datos, lo ideal es que solo le dé permiso para ejecutar procedimientos almacenados. Nunca le dé permiso directamente al usuario para modificar, insertar o eliminar registros.
2.
Principio de ataque de omisión de verificación: la mayoría de los programas ASP que necesitan ser verificados ahora agregan una declaración de juicio al encabezado de la página, pero esto no es suficiente para que los piratas informáticos omitan la verificación e ingresen directamente.
Habilidades de prevención: las páginas ASP que deben verificarse pueden rastrear el nombre del archivo de la página anterior. Solo las sesiones transferidas desde la página anterior pueden leer esta página.
3. Problema de fuga de archivos Inc.
Principio de ataque: cuando la página de inicio con ASP se está produciendo y no se ha finalizado antes de la depuración, algunos motores de búsqueda pueden agregarla automáticamente como objeto de búsqueda. Si alguien utiliza un motor de búsqueda para buscar estas páginas web en este momento, obtendrá la ubicación de los archivos relevantes y podrá ver los detalles de la ubicación y la estructura de la base de datos en el navegador, revelando así el código fuente completo.
Consejos de prevención: los programadores deben depurar minuciosamente las páginas web antes de publicarlas; los expertos en seguridad deben proteger los archivos ASP para que los usuarios externos no puedan verlos. Primero, cifre el contenido del archivo .inc. En segundo lugar, también puede usar el archivo .asp en lugar del archivo .inc para que los usuarios no puedan ver directamente el código fuente del archivo desde el navegador. El nombre del archivo inc no debe utilizar el valor predeterminado del sistema ni un nombre con un significado especial que sea fácil de adivinar para los usuarios. Intente utilizar letras inglesas irregulares.
4. Principio de ataque de descarga de copia de seguridad automática
: en algunas herramientas para editar programas ASP, al crear o modificar un archivo ASP, el editor crea automáticamente un archivo de copia de seguridad. Por ejemplo, UltraEdit realizará una copia de seguridad de un archivo .bak si lo crea o lo modifica. Al modificar some.asp, el editor generará automáticamente un archivo llamado some.asp.bak. Si no elimina este archivo bak, el atacante puede descargar directamente el archivo some.asp.bak, de modo que el programa fuente de some.asp. se descargará.
Consejos de prevención: revise su programa cuidadosamente antes de cargarlo y elimine los documentos innecesarios. Tenga especial cuidado con los archivos con el sufijo BAK.
5.
Principio del ataque de caracteres especiales: el cuadro de entrada es un objetivo para los piratas informáticos. Pueden causar daños al cliente del usuario al ingresar un lenguaje de script; si el cuadro de entrada implica una consulta de datos, utilizarán declaraciones de consulta especiales para obtener más datos de la base de datos. o incluso toda la mesa. Por lo tanto, el cuadro de entrada debe filtrarse. Sin embargo, si la verificación de validez de la entrada solo se realiza en el cliente para mejorar la eficiencia, aún así se puede omitir.
Habilidades de prevención: en programas ASP que manejan cuadros de entrada, como tableros de mensajes y BBS, es mejor bloquear las declaraciones HTML, JavaScript y VBScript. Si no hay requisitos especiales, puede limitar la entrada de letras y números solo a letras y. números y bloquear caracteres especiales. Al mismo tiempo, la longitud de los caracteres de entrada es limitada. Y no sólo se debe realizar la verificación de validez de la entrada en el lado del cliente, sino que también se deben realizar verificaciones similares en el programa del lado del servidor.
6.
Principio del ataque de vulnerabilidad de descarga de la base de datos: cuando se utiliza Access como base de datos backend, si alguien conoce o adivina la ruta y el nombre de la base de datos de Access del servidor a través de varios métodos, también puede descargar el archivo de la base de datos de Access, lo cual es muy peligroso. . de.
Consejos de prevención:
(1) Asigne a su archivo de base de datos un nombre complejo y poco convencional y colóquelo en varios directorios. Los llamados "no convencionales", por ejemplo, si hay una base de datos que quiere guardar información sobre libros, no le dé el nombre "book.mdb", sino un nombre extraño, como d34ksfslf. y colóquelo en varios directorios como ./kdslf/i44/studi/, de modo que será aún más difícil para los piratas informáticos obtener su archivo de base de datos de Access adivinando.
(2) No escriba el nombre de la base de datos en el programa. A algunas personas les gusta escribir DSN en el programa, por ejemplo:
DBPath = Server.MapPath("cmddb.mdb")
conn.Open "driver={Microsoft Access Driver (*.mdb)};dbq=" & DBPath
Si alguien obtiene el programa fuente, el nombre de su base de datos de Access será visible de un vistazo. Por lo tanto, se recomienda configurar la fuente de datos en ODBC y luego escribir esto en el programa:
conn.open "shujiyuan"
(3) Utilice Access para codificar y cifrar el archivo de la base de datos. Primero, seleccione la base de datos (como: empleado.mdb) en "Herramientas → Seguridad → Cifrar/descifrar base de datos" y luego haga clic en Aceptar. Luego aparecerá la ventana "Guardar base de datos cifrada como". Puede guardarla como: "empleador1. .mdb".
Cabe señalar que la acción anterior no establece una contraseña para la base de datos, solo codifica el archivo de la base de datos. El propósito es evitar que otros usen otras herramientas para ver el contenido del archivo de la base de datos.
A continuación, ciframos la base de datos. Primero, abra el empleado1.mdb codificado. Al abrirlo, seleccione el modo "exclusivo". Luego seleccione "Herramientas → Seguridad → Establecer contraseña de base de datos" en el menú y luego ingrese la contraseña. De esta manera, incluso si alguien más obtiene el archivo empleado1.mdb, no podrá ver el contenido de empleado1.mdb sin la contraseña.
7. Prevenir ataques de inyección remota.
Este tipo de ataque debería ser un método de ataque relativamente común en el pasado, como el ataque POST. El atacante puede cambiar el valor de los datos que se enviará a voluntad para lograr el propósito del ataque. Falsificación de COOKIES, que vale más la pena. Esto llama la atención del programador o del webmaster. No utilice COOKIES como método de autenticación de usuario. De lo contrario, le está dejando la clave a un ladrón.
Por ejemplo:
Si trim(Solicitud. cookies). uname"))=" fqy" y Request.cookies("upwd") ="fqy#e3i5.com" luego
……..más…………
Termine si
creo que todos los webmasters o amigos a quienes les gusta escribir programas no deben cometer este tipo de error. Es realmente imperdonable. Hemos estado falsificando COOKIES durante muchos años. Si todavía las usa, no puede culpar a otros por robarlas. contraseña Implica Cuando se trata de contraseñas de usuario o inicio de sesión de usuario, será mejor que utilice sesión, que es la más segura. Si desea utilizar COOKIES, agregue una información más a sus COOKIES, su valor aleatorio es. 64 bits. Debes adivinarlo. Imposible. Ejemplo:
si no (rs.BOF o rs.eof), entonces.
iniciar sesión = "verdadero"
Sesión("nombre de usuario"&ID de sesión) = Nombre de usuario
Sesión("contraseña"& ID de sesión) = Contraseña
'Response.cookies("nombre de usuario")= Nombre de usuario
'Response.cookies("Contraseña") = Contraseña
Hablemos de cómo prevenir ataques de inyección remota. El ataque general consiste en arrastrar el archivo de envío del formulario único al local y apuntar el formulario ACTION="chk.asp" a su servidor. procesamiento. Los archivos de datos son suficientes. Si todo su filtrado de datos está en una sola página de tabla, entonces felicidades, habrá sido atacado por un script.
¿Cómo puede evitar este tipo de ataques remotos? siguiente: Cuerpo del programa ( 9)
＜%
server_v1=Cstr(Request.ServerVariables("HTTP_REFERER"))
server_v2=Cstr(Request.ServerVariables("SERVER_NAME"))
si mid(server_v1,8,len(server_v2))＜＞server_v2 entonces
respuesta.escribir "＜br＞＜br＞＜centro>"
respuesta.escribir " "
Response.write "La ruta que envió es incorrecta. Está prohibido enviar datos desde fuera del sitio. ¡No cambie los parámetros!"
respuesta.escribir "
"
respuesta.fin
terminar si
%>
'Personalmente, creo que el filtrado de código anterior no es muy bueno. Algunos envíos externos aún pueden llegar abiertamente, así que escribí otro
'Este efecto de filtrado es muy bueno, se recomienda usarlo
si instr(request
..servervariables("http_referer")," http://"&request.servervariables("host ") )<1 luego respuesta.write "Se produjo un error en el servidor al procesar la URL.
Si está atacando el servidor por cualquier medio Entonces deberías tener suerte de que todas tus operaciones hayan sido registradas por el servidor. Notificaremos a la Oficina de Seguridad Pública y al Departamento de Seguridad Nacional lo antes posible para investigar tu IP "
response.end
.
terminar si
El cuerpo del programa (9)
pensó que todo estaría bien con esto y agregó algunas restricciones en la página del formulario, como longitud máxima, etc. Pero Dios es tan cruel que cuanto más le tienes miedo a algo, más probable es que suceda. No lo olvides, el autor del ataque puede romper el límite de longitud del cuadro de entrada durante los ataques de inyección SQL. ¿Escribir un programa SOCKET para cambiar HTTP_REFERER? No lo haré. Un artículo de este tipo se publicó en línea:
------------len.reg-----------------
Editor del Registro de Windows Versión 5.00
[HKEY_CURRENT_USERSoftwareMicrosoftInternet ExplorerMenuExtExtensiones]
@="C:Documentos y configuracionesAdministradorEscritoriolen.htm"
"contextos"=dword:00000004
----------fin---------------------
----------len.htm------------------
----------end----------------------
Uso: Primero importe len.reg al registro (tenga en cuenta la ruta del archivo)
y luego copie len.htm en el lugar especificado en el registro.
Abra la página web, coloque el cursor en el cuadro de entrada donde se va a cambiar la longitud y haga clic derecho. Si ve una opción llamada extensión,
haga clic en ¡Listo! : Se puede hacer lo mismo.
¿Cómo lidiar
con los scripts que restringen el contenido de entrada ?¿Se salvaron nuestras limitaciones y se desperdiciaron todos nuestros esfuerzos? No, levanta el teclado y di no. Volvamos al filtrado de caracteres de script. La inyección que realizan no es más que ataques de script. Pongamos toda nuestra energía en las páginas después de ACCIÓN. En la página chk.asp, filtramos todos los caracteres ilegales. Solo dimos un tiro en falso frente a nosotros y les pedimos que cambiaran el registro. Sólo cuando terminen los cambios se darán cuenta de que lo que han hecho es en vano.
8.
Hemos hablado aquí sobre el caballo de Troya ASP y me gustaría recordar a todos los webmasters del foro que tengan cuidado al cargar archivos: ¿por qué el host también está ocupado por atacantes después de que se rompe el programa del foro? La razón es... ¡correcta! Troyano ASP! Una abominación absoluta. ¿Virus? No. Simplemente coloca el archivo en el programa de tu foro y siempre podrás buscarlo. Sería extraño no vomitar sangre. ¿Cómo podemos evitar que se carguen troyanos ASP en el servidor? El método es muy simple. Si su foro admite la carga de archivos, configure el formato de archivo que desea cargar. No estoy de acuerdo con el uso de formatos de archivo modificables. Bloquearlos directamente desde el programa. Completo Sí, dejar más comodidad para usted también dejará más comodidad para los atacantes. ¿Cómo determinar el formato? He recopilado uno aquí y he modificado uno. Puede echarle un vistazo:
Cuerpo del programa (10)
'Juzgar si el tipo de archivo está calificado. Función privada CheckFileExt (fileEXT).
subir foro tenue
Foroupload="gif,jpg,bmp,jpeg"
Subir foro=split(Subir foro,",")
para i=0 a ubound(Forumupload)
si lcase(fileEXT)=lcase(trim(Forumupload(i))) entonces
CheckFileExt=verdadero
Función de salida
demás
CheckFileExt=falso
terminar si
próximo
Función final
'Verificar la legalidad del contenido del archivo
establecido MyFile = server.CreateObject ("Scripting.FileSystemObject")
set MyText = MyFile.OpenTextFile (sFile, 1) ' Leer archivo de texto sTextAll = lcase(MyText.ReadAll): MyText.close
'Determinar operaciones peligrosas en archivos de usuario sStr = "8 .getfolder .createfolder .deletefolder .createdirectory
.eliminardirectorio"
sStr = sStr & " .saveas wscript.shell script.encode"
sNoString = dividir(sStr," ")
para i = 1 a sNoString(0)
si instr(sTextAll, sNoString(i)) ＜＞ 0 entonces
sFile = Upl.Path y sFileSave: fs.DeleteFile sFile
Response.write "＜center＞＜br＞＜big＞"& sFileSave &"El archivo contiene comandos relacionados con directorios operativos, etc."&_
"＜br＞＜font color=red＞"& mid(sNoString(i),2) &"＜/font＞, por razones de seguridad, ＜b＞ no se puede cargar. ＜b＞"&_"＜/big＞＜ /centro＞＜/html＞"
Respuesta.fin
terminar si
SiguienteAgréguelos
seguridad
de su programa de carga mejorará enormemente.
¿Todavía estás preocupado? Encuentre su carta de triunfo y pídale ayuda a su proveedor de servicios de alojamiento web. Inicie sesión en el servidor y cambie el nombre o elimine los elementos "shell.application" y "shell.application.1" en el ID de PROG. Luego cambie el nombre o elimine tanto el elemento "WSCRIPT.SHELL" como "WSCRIPT.SHELL.1". Jaja, puedo decir con valentía que probablemente más de la mitad de los servidores virtuales en China no han cambiado. Sólo puedo alegrarme de que sus usuarios sean muy cooperativos, de lo contrario... eliminaré, eliminaré, eliminaré, eliminaré, eliminaré...