Let's say I have a website which is written in ASP and I keep my .mdb database in a random directory like /asd8asd/dkdgk32/asdmv/askdasd/kasldk.mdb

Can an attacker find database's location without guessing/brute forcing?

2 Answers 2


So assuming here that the database is only intended to be accessible by the ASP code and not clients of the web application a better alternative to keeping the database in a "random" directory under the web root, would be to keep the database outside of the webroot altogether. That way it would not be possible for an attacker to directly address the database via the website (without another security issue allowing them to).

If you're intending website clients to directly download or access the MDB file, hiding the database may not be a very robust control. An attacker may be able to find the location by watching the traffic of other clients or by finding a reference to it in other parts of the site.

A more robust alternative here would be to restrict access to the database to authenticated users only. Even if you've not got a full membership system set-up for your site, you could use something like HTTP digest authentication to restrict user access. On its own that's not a perfect solution, but it's bettern than relying solely on an attacker not finding a URL.


Here a list of mitigation actions you can perform to avoid disclosing the database's path:

Internet Information Services & Server

  • Make sure you do not list the C:\inetpub\wwwroot content, otherwise s/he might be able to navigate through all folders
  • Disable any kind of FTP and just use SSH (if needed at all). Needless to say that FTP is insecure.
  • Keep your server updated in order to eliminate new vulnerabilities


  • Ensure your application is protected against "Directory Traversal Attacks" which could permit an attacker to basically see files and folders granted to application user (e.g. IIS_IUSRS, IUSR, DefaultAppPool, ASP.NET v4.0...). Example:

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

  • Also against "Server-Side Includes (SSI) Injection" which allows the exploitation of a web application by injecting scripts in HTML pages or executing arbitrary codes remotely. It can be exploited through manipulation of SSI in use in the application or force its use through user input fields. Example:


  • VBScript errors could leak the full path of your database depending on how you access it. I suggest you to use OLEDB instead of hard coding the connection.

MS Access

  • SQL Injection can return insider information or generate errors disclosing your DB information such as the full path.
  • I don't really see how you're answering the question Commented Aug 1, 2015 at 21:46
  • It is a comprehensive list of ways an attacker can get access to the DB's path. Hopefully with adjustments I did you can see it better ;-) @NeilSmithline
    – user69377
    Commented Aug 1, 2015 at 22:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .