Re: Restrict FileSystemObject to it's virtual dir
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 10/28/04
- Next message: WenJun Zhang[msft]: "RE: ASP.NET XMLDOM applications crashing IIS6.0?"
- Previous message: Kristofer Gafvert: "Re: Question about Redirects..."
- In reply to: FKeller: "RE: Restrict FileSystemObject to it's virtual dir"
- Next in thread: Miriam Green: "RE: Restrict FileSystemObject to it's virtual dir"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 27 Oct 2004 23:54:21 -0700
Scripting.FileSystemObject does not support any such policy. Web Servers
implement such "rooted" policies, but it only applies to the Web Server and
not scripts run by the Web Server (same reasoning).
You will have to rely on NTFS ACLs to prevent mingling between apps.
In general, "app isolation" is done through NTFS ACLs (i.e. if directory1 is
ACLd only to user1 and directory2 is ACLd only to user2, an app running as
user2 can only access directory2 but not directory1).
You can do this on IIS6 in a couple of ways:
1. Creating an Application Pool for each application, with a unique AppPool
Identity and Anonymous User/Authentication. This effectively binds code run
by that AppPool to the configured AppPool/Anonymous identity(s).
2. Use unique AnonymousUser identity for every application for isolation.
This has a weakness in that if the script code can call "RevertToSelf", it
can gain access to the process identity, which by default already have
access to everything (you're relying on impersonation as isolation).
If you allow users to upload and run arbitrary code on the server, then you
must use Application Pools with unique AppPool Identity to isolate users
from each other. The users must execute code in separate processes or else
they'd share something in common.
-- //David IIS This posting is provided "AS IS" with no warranties, and confers no rights. // "FKeller" <Fritz Keller@discussions.microsoft.com> wrote in message news:A96D650B-CB7F-4D7D-A2B8-AC33BA528364@microsoft.com... Hello Dallo I wonder if you got it to work with the desired security? I did see that there is a very ingenious ASP-script going around. Even on big providers you can go with it to all drives, even C:\WINNT and \SYSTEM32 and read, change, delete or upload whatever you want. So as I did see even big providers have not the needed security and are in danger. How did you implement the security that users cannot go out of there root? Hackers event use file upload possibilities in websites to upload the tool and use it then. Thanks for help, Fritz Keller "Dallo" wrote: > Hi everybody, > i've to configure on a single win2003 machine a lot dinamic web site. > I'd like to protect each site from interference of other sites scripts that > uses, for example, filesystemobject method. > In other words, i dont want asp script using FSO of a site can access, > modify or delete files on other sites. > Is there a way to restrict FSO to it's virtual directory? > > > tnx to everyone > :) > > >
- Next message: WenJun Zhang[msft]: "RE: ASP.NET XMLDOM applications crashing IIS6.0?"
- Previous message: Kristofer Gafvert: "Re: Question about Redirects..."
- In reply to: FKeller: "RE: Restrict FileSystemObject to it's virtual dir"
- Next in thread: Miriam Green: "RE: Restrict FileSystemObject to it's virtual dir"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
