Parent Paths

A parent path is when you reference a file with something like '../util/includes.asp' . This poses a possible security risk and any IIS admin with a clue will have parent paths disabled. Instead, make an absolute reference from your web root such as '/directory/util/includes.asp' .

Trying to use parent paths on a server with it disabled will return an error such as [code]Active Server Pages error 'ASP 0131'

Disallowed Parent Path

/maint/maint_includes.asp, line 10

The Include file '../util/includes.asp' cannot contain '..' to indicate the parent directory.[/code]

Please explain to those of us with less ASP experience how parent paths can pose a security risk?

The danger is that an evil programmer could upload and execute a script which could traverse up and down the directory tree, accessing files that they have no business accessing.

IIS 5 by default has parent paths enabled. The admin must purposefully turn it off.

IISLOCKD.EXE fortunately turns it off for most admins with enough clue to run the utility.

[quote author=Thing link=board=22;threadid=1475;start=0#msg11065 date=1054223808]
The danger is that an evil programmer could upload and execute a script which could traverse up and down the directory tree, accessing files that they have no business accessing.[/quote]So the danger is present only when the ASP writer is untrustworthy or fails to validate input from the user, correct? There is nothing inherently insecure in them if the writer disallows the user specifying directories and the writer can be trusted not to go poking about?

[quote author=Grok link=board=22;threadid=1475;start=0#msg11066 date=1054227269]
IISLOCKD.EXE fortunately turns it off for most admins with enough clue to run the utility.[/quote]
IISLOCKD.EXE is awesome but I don't think it disables parent paths.

[quote]There is nothing inherently insecure in them if the writer disallows the user specifying directories and the writer can be trusted not to go poking about?[/quote]
Even if you have trustworthy, competent users and programmers, the vulnerability is still there and needs to be resolved.

IIS is weird. I would normally have assumed that if you let a programmer upload and run ASP code on your server, then he can access all the files that the user you run his code as is allowed to access.

That's the way I think of things like our forum software - the programmer codes to prevent visitors of the site from getting access to things, but there's no system to prevent the programmer from accessing things if he wants to (or makes a bug to).

Apparently there is something to stop programmers from doing that... Do you do something special to prevent him from running arbitrary code on the server? What about all the ocxes and things he could CreateObject - say that he were to use the mail sending ocx and attach c:\<insert file outside tree here>?

I personally thought that parent paths had to do with accessing things outside the defined site using an url starting with a .. - allowing you to access c:\autoexec.bat by asking the site c:\inetpub\wwwroot for the url ../../autoexec.bat

/edit/I took this off because I'm doing something else with that IP address now.