Protezione del database di accesso Microsoft

Quindi, supponendo che il database sia inteso solo per essere accessibile dal codice ASP e non dai client dell'applicazione Web, un'alternativa migliore alla conservazione del database in una directory "casuale" sotto la radice web, sarebbe mantenere il database al di fuori del webroot del tutto. In questo modo non sarebbe possibile per un utente malintenzionato indirizzare direttamente il database tramite il sito Web (senza un altro problema di sicurezza che consenta di farlo).

Se intendi che i client del sito web scarichino direttamente o accedano al file MDB, nascondere il database potrebbe non essere un controllo molto affidabile. Un utente malintenzionato può essere in grado di trovare la posizione guardando il traffico di altri clienti o trovando un riferimento ad esso in altre parti del sito.

Un'alternativa più solida qui sarebbe quella di limitare l'accesso al database solo agli utenti autenticati. Anche se non hai una completa configurazione del sistema di appartenenza per il tuo sito, potresti usare qualcosa come l'autenticazione del digest HTTP per limitare l'accesso degli utenti. Di per sé non è una soluzione perfetta, ma è meglio che affidarsi esclusivamente a un utente malintenzionato che non trova un URL.

Ecco un elenco di azioni di mitigazione che è possibile eseguire per evitare di rivelare il percorso del database:

Internet Information Services & Server

• Assicurati di non elencare il contenuto C: \ inetpub \ wwwroot, altrimenti potrebbe essere in grado di navigare attraverso tutte le cartelle
• Disattiva qualsiasi tipo di FTP e usa semplicemente SSH (se necessario). Inutile dire che l'FTP non è sicuro.
• Tieni aggiornato il tuo server per eliminare nuove vulnerabilità

ASP

• Assicurati che la tua applicazione sia protetta da "Directory Traversal Attacks" che potrebbe consentire a un utente malintenzionato di visualizzare fondamentalmente file e cartelle concessi all'utente dell'applicazione (ad esempio IIS_IUSRS, IUSR, DefaultAppPool, ASP.NET v4.0 ...). Esempio:

GET http://www.vunerablesite.com/show.asp?view=../../../../../Windows/system.ini HTTP/1.1

• Anche contro "Iniezione lato server (SSI)" che consente lo sfruttamento di un'applicazione Web iniettando script in pagine HTML o eseguendo codici arbitrari da remoto. Può essere sfruttato attraverso la manipolazione di SSI in uso nell'applicazione o forzarne l'utilizzo attraverso i campi di input dell'utente. Esempio:

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

• Errori VBScript potrebbero perdere il percorso completo del database a seconda di come lo si accede. Ti suggerisco di usare OLEDB invece di codificare hard la connessione.

Accesso MS

• SQL Injection può restituire informazioni privilegiate o generare errori che rivelano le informazioni del DB come il percorso completo.