¿Cuáles son las preguntas de la entrevista para ingenieros de redes?
Los ingenieros de redes pueden dedicarse al diseño, construcción, operación y mantenimiento de sistemas de información informáticos. A continuación se muestran las preguntas de la entrevista para ingenieros de redes que recopilé para usted. Espero que le resulten útiles
1.
p>
Principio de ataque: los nombres de usuario y las contraseñas 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.
Consejos 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 otorgarle solo el permiso para ejecutar procedimientos almacenados. Nunca le dé directamente al usuario el permiso para modificar, insertar o eliminar registros.
2. Se omite la verificación
Principio de ataque: 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 y puede ser pirateado. Ingrese directamente, sin pasar por la verificación.
Habilidades de prevención: las páginas ASP que requieren verificación 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 final, se puede agregar automáticamente como objeto de búsqueda mediante algunos motores 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 y, por lo tanto, revelar 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. Se descarga la copia de seguridad automática
Principio de ataque: en algunas herramientas para editar programas ASP, cuando se crea o modifica un archivo ASP, el editor crea automáticamente un archivo de copia de seguridad, como por ejemplo. : UltraEdit realizará una copia de seguridad de un archivo .bak. Si crea o modifica algún.asp, el editor generará automáticamente un archivo llamado some.asp.bak. Si no elimina este archivo bak, el atacante puede descargarlo directamente. .bak, para que se descargue el programa fuente de some.asp.
Consejos de prevención: Verifique cuidadosamente antes de cargar el programa y elimine los documentos innecesarios. Tenga especial cuidado con los archivos con el sufijo BAK.
5. Caracteres especiales
Principio de ataque: el cuadro de entrada es un objetivo utilizado por los piratas informáticos. Pueden causar daños al cliente del usuario al ingresar lenguaje de secuencia de comandos. Para las consultas, utilizarán declaraciones de consulta especiales para obtener más datos de la base de datos, o incluso la tabla completa. 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. Bloquee únicamente letras y números. 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. Vulnerabilidad de descarga de la base de datos
Principio de ataque: 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, entonces También puede descargar este archivo de base de datos de Access, que es muy peligroso.
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, como por ejemplo:
DBPath = Server.MapPath(?cmddb.mdb?)
conn.Open ?driver={Microsoft Access Driver ( * .mdb)}; dbq=? amp; 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) Usar Access para codificar y cifrar el archivo de 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á una ventana para "Guardar la base de datos después del cifrado como". Puede guardarlo como: "employer1.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, abrimos el archivo empleador1.mdb codificado. Al abrirlo, seleccionamos 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 otras personas obtienen el archivo empleador1.mdb, no podrán ver el contenido de empleador1.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. Propósito del ataque Otro ejemplo: falsificación de COOKIES. Esto es más digno de atención del programador o webmaster. No utilice COOKIES como método de autenticación de usuario, de lo contrario será lo mismo que dejar la clave a un ladrón.
Por ejemplo:
If trim(Request. cookies (?uname?))=?fqy? y Request.cookies(?upwd?) =?fqy#e3i5.com? entonces
...¿más?
Fin
Creo que todos los webmasters o amigos a quienes les gusta escribir programas no deben cometer tales errores. Es realmente imperdonable. Las COOKIES falsificadas existen desde hace muchos años. Si aún las usa, no puede culpar a otros por robar su contraseña. Cuando se trata de contraseñas de usuario o inicios de sesión de usuario, será mejor que use la sesión, que es la más segura. desea utilizar COOKIES, simplemente agregue un dato más a sus COOKIES, SessionID. Su valor aleatorio es de 64 bits. Es imposible adivinarlo. Ejemplo:
si no (rs.BOF o rs. eof) entonces
p>
Inicio de sesión=?true?
Sesión(?nombre de usuario?amp; ID de sesión) = Nombre de usuario
Sesión(?contraseña? amp; sessionID) = Contraseña
?Response.cookies(?username?)= Nombre de usuario
?Response.cookies(?Password?)= Contraseña
hable sobre cómo prevenir ataques de inyección remota. El ataque general es arrastrar el archivo de envío de una sola tabla al local y apuntar Form ACTION=?chk.asp? al archivo que procesa los datos en su servidor. En la página de la tabla única, felicitaciones, el script lo habrá atacado.
¿Cómo prevenir este tipo de ataques remotos? Es fácil de manejar. Consulte el código de la siguiente manera: Cuerpo del programa (9).
Personalmente, creo que el código anterior El filtrado no es muy bueno y algunos envíos externos aún pueden llegar abiertamente, así que escribí otro
. Este efecto de filtrado es muy. bueno, se recomienda utilizar
if instr(request .servervariables(? Explorer\MenuExt\Extensions(amp;E)]
@=?C:\Documents and Settings. \Administrador\Escritorio\len.htm?
?contexts? =dword: 00000004
fin?-
len.htm
?-end
Uso: Primero importe len.reg a la tabla de registro (tenga en cuenta la ruta del archivo)
Luego copie len.htm al lugar especificado en el registro. >
Abra la página web, haga clic derecho en el cursor en el cuadro de entrada para cambiar la longitud. ¿Ha visto demasiadas opciones llamadas extensiones?
Haga clic para hacerlo. Postscript: ¡Lo mismo puede ser! hecho para lidiar con scripts que restringen el contenido de entrada
¿Qué hacer? Nuestras limitaciones se salvan y todos nuestros esfuerzos son en vano. 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 la página después de ACCIÓN. En la página chk.asp, filtramos todos los caracteres ilegales. ¿Cuál es el resultado? Simplemente hacemos un tiro falso al frente y les pedimos que cambien el registro. los cambios se darán cuenta de que lo que han hecho es en vano.
8. Troyano ASP
Ahora que hemos hablado de ello, me gustaría recordar a todos los webmasters del foro que tengan cuidado al cargar archivos: ¿Por qué el host también es atacado después del foro? ¿El programa está roto? o lo ocupa. ¡La razón es correcta! ¡Troyano ASP! ¡Una cosa absolutamente abominable! ¿Es un virus? No. Simplemente coloque el archivo en el programa de su foro y podrá buscarlo. Sería extraño no vomitar sangre. ¿Cómo puede 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 acepto el uso de formatos de archivo modificables y bloquéelos directamente desde. el programa. Sólo los formatos de archivos de imagen y los archivos comprimidos son suficientes. Cuanto más comodidad dejes para ti, más comodidad tendrás para los atacantes.
¿Cómo determinar el formato? He recopilado uno aquí y modificado. Puedes echar un vistazo:
Cuerpo del programa (10)
. p>
Función privada CheckFileExt (fileEXT)
dim Forumupload
Forumupload=?gif, jpg, bmp, jpeg
Forumupload=split(Forumupload? ,? ,?)
para i=0 a ubound(Forumupload)
si lcase(fileEXT)=lcase(trim(Forumupload(i))) entonces
CheckFileExt=true
función de salida
else
CheckFileExt=false
finaliza si
siguiente
Función final
?Verificar la legalidad del contenido del archivo
set MyFile = server.CreateObject (?Scripting.FileSystemObject?)
set MyText = MyFile.OpenTextFile (sFile, 1) ? Leer archivos de texto
sTextAll = lcase(MyText.ReadAll): MyText.close
Determinar operaciones peligrosas en archivos de usuario
p >sStr =?8 .getfolder .createfolder .deletefolder .createdirectory
.deletedirectory
sStr = sStr amp; /p>
p>
sNoString = split(sStr, )
para i = 1 a sNoString(0)
if instr(sTextAll, sNoString(i) ) lt; gt; 0 entonces
sFile = Upl.Path amp; sFileSave： fs.DeleteFile sFile
Response.write ?amp; ;?El archivo contiene comandos relacionados con directorios operativos, como ?amp;_
?amp; Por razones de seguridad, no se puede cargar. ?amp;_?
?
Respuesta.end
end if
siguiente
Cuerpo del programa ( 10)