I've recently become responsible for administering my company's corporate Web server. After reviewing the configuration, I've suggested disabling parent paths because of security concerns. The company's developers complain that disabling the paths would be overly restrictive and cause them to lose the portability of relative pathnames. IIS requires that if I disable parent paths, I change all instances of file references from relative pathnames (e.g., ../../images/ image.jpg) to absolute pathnames (e.g.,/graphics/pictures/images/image.jpg). I'm not a developer—could you explain this feature and its impact?
You're right that parent paths are best disabled. (Note that parent paths are enabled by default.) Parent paths refers to the ability to use a double period (i.e., ..) in the pathname to refer to a folder above the current folder so that you can move up the folder tree without knowing the folder name or where you are in the hierarchy. The security risk of parent paths is that intruders can upload and run a script to move up the folder tree. When the script reaches the root, it can move down from there into known folders that might have elevated privileges (e.g., C:\wwwroot\inetpub\scripts, which has Everyone Full Control permission by default, or C:\winnt\system32).
To locate the Enable Parent Paths option, open a Web site's Properties dialog box, click the Home Directory tab, then click Configuration to access the Application Configuration dialog box. (Note that the Configuration button is enabled only if you've created an application in the Web site. You can also create an application in this way for directories and virtual directories.) Click the App Options tab, which Figure 2 shows, to reveal the configuration choices. You can configure these settings for a virtual directory or directory as well as for a Web site.
Your developers are correct that they'll need to rework some code. However, doing so might not be as bad as they make it seem. If they're using server-side include (SSI) files, they need to change
"include file="
in the code to
"include virtual=/xxx"
with a full absolute root path. You don't need to change relative hyperlinks as long as they point to a location inside the Web site structure. Fortunately, Web site content is often located directly beneath the Web site home folder.
If you have a database or other resource outside the Web structure, your developers won't be able to use ../ or ..\ to point to it from Web pages or the global.asa file. Your developers must use an absolute full pathname with a drive letter. The Server.MapPath method won't work with ..\ or ../, either.
Your developers can use variables to construct the absolute pathname and implement relative paths in their code. One method is to use Server .MapPath in the global.asa file to get the physical path up to the Web root, then assign the resulting path to an application variable. Developers can then add this variable to the path necessary for constructing the absolute path.
For example, let's say that D:\inet pub\wwwroot\yourwebroot is the path to your Web root, but your database and upload folder don't reside in the Web root but in D:\inetpub\ wwwroot\database and D:\inetpub\ wwwroot\upload, respectively. Because you've disabled parent paths, you must reference the absolute location. To work with this setup, you assign the Web root path to a temporary variable, then create an application-level variable called PathRoot to serve as the base for your relative paths. Listing 1 shows the syntax for the necessary code. In this way, you can implement addressing outside the Web root without having to hard-code your locations. For more information about parent paths, see the Microsoft articles "Err Msg: Active Server Pages, ASP 0131 Disallowed Parent Path" (http://support.microsoft.com/support/kb/articles/q226/4/74.asp) and "AspEnable ParentPaths MetaBase Property Should Be Set to False" (http://support.microsoft.com/support/kb/articles/q184/7/17.asp). Many thanks to Carl Reiss for the answer to this question.
)
)
Register
I think the real answer (however unpalatable to web admins) is to lock down the system so that malicious scripts simply can't work on the basis of Windows permissions alone. It means gaining a full understanding of the security issues and overriding a default Windows installation. But why should this be a problem? It appears to be "taking the easy way out" at the expense of the developer and, more importantly, the application.
I hope this is food for thought.
Alan
Alan Shanahan October 20, 2003