The FileSystemObject is a component often used to access the server's file system. For example, you can create files, read the contents of a file, determine whether or not a folder or file exists, iterate through the contents of a folder, or any other number of file-system related tasks.
February 21, 2001
You create an instance of the FileSystemObject component in an ASP (or other) page with code like this:
Dim objFSO
Set objFSO = Server.CreateObject ("Scripting.FileSystemObject")
Once you have created an instance of this component, you can access its many properties and methods. For example, if you wanted to output the contents of the text file C:\autoexec.bat then the following code could be used:
Const fsoForReading = 1
Dim objFSO
Set objFSO = Server.CreateObject ("Scripting.FileSystemObject")
Dim objTextStream
Set objTextStream = objFSO.OpenTextFile ("C:\autoexec.bat", fsoForReading)
Response.Write objTextStream.ReadAll
objTextStream.Close
Set objTextStream = Nothing
Set objFSO = Nothing
Ultimately, the FileSystemObject's purpose is to allow a server-executed application to have access to the machine's file system. Since ASP pages reside and are executed on the Web server, when using a FileSystemObject to access the file system, you are accessing the Web server's file system. You cannot access a client's file system when using the FileSystemObject in your ASP code.
Permissions
It is very important to keep file permissions in mind when using the FileSystemObject. In Windows NT there are three types of permissions: Read, Write and Full Access. Whenever an ASP page attempts to execute some file system command using a FileSystemObject, the anonymous Web user ID is used - IUSR_machine (so, if your Web server is named mango, then the user ID is IUSR_mango).
If IUSR_machine doesn't have permissions to read a particular directory, you cannot use FileSystemObject to read the contents of a file in that directory through an ASP page. If IUSR_machine doesn't have permissions to write for a particular directory, you cannot use FileSystemObject to write a file to that directory through an ASP page. Finally, if IUSR_machine doesn't have full access permissions for a particular directory, then you cannot use FileSystemObject to delete or move a file from that directory through an ASP page.
Here's precisely where a common problem occurs: in a desire to set the permissions correctly, a developer may often set the permissions to be full access - with the thought in the back of their mind that they will come back later and tighten up the security. Is it likely this will happen? Hmmm …
Users
Here's another problem: it is possible to use FileSystemObject to open or create a file on a remote computer - for example:
Set objTextStream = objFSO.OpenTextFile ("\\grapefruit\files\myfile.txt", fsoForReading)
Now, because the FileSystemObject runs as the anonymous user, clearly the anonymous user must be able to access the remote file. So, in our example above, IUSR_mango must have access to the files shared on the computer named grapefruit. What does this mean? Well - clearly, we will need an account for IUSR_mango on grapefruit, with the very same password. An MSDN article about this is online at http://support.microsoft.com/support/kb/articles/q197/9/64.asp?LNG=ENG&SA=PER.
Obviously this can potentially compromise our security. Our call to FileSystemObject might contain an error and our ASP code is dumped onto the user's Web browser screen for a computer name and path to be revealed. We may end up chaining all sorts of computers together with synchronized usernames and passwords. This involves many maintenance issues and creates a dependency between computers. If you do this, your administrator will hate you for it! Besides, you may find your purposes are much better served by using a database than manipulating text files and worrying about operating system permissions.
Here's a thought though: given what the FileSystemObject permits, imagine what vulnerabilities might be wrought should a user be able to add executable code to your Web server, of his or her own devising? This shows a further need to lock down a Web server to prevent hostile applications or commands being uploaded and executed.
David Williams is a computer consultant in Newcastle, Australia. Projects include an ASP-based task logging system for a University help desk environment, and 'hack-proofing' an evaluation version of a package to manage mobile phone shops.
