IIS6 - Directory Traversal in Active Server Pages - FSO

Hello

I'm just doing some checks on the system, and we found out that directory
traversal is possible with classic .asp. It is possible using the
filesystemobject.

Then i tried to add specific permissions to the application pool of this
website, but it still was possible to access other directories. I have the
feeling that IIS will not use that account for active server pages, but only
for .net and other isapi filters? or am i wrong?

Are there any settings? solutions.

My current hotfix was to disable the FileSystemObject with
regsvr32 scrrun.dll /u

but it's not really what I want, as some websites still use the FSO

Thanks for your input

Re: IIS6 - Directory Traversal in Active Server Pages - FSO

On Oct 22, 6:39 am, "Patrick" wrote:
> Hello
>
> I'm just doing some checks on the system, and we found out that directory
> traversal is possible with classic .asp. It is possible using the
> filesystemobject.
>
> Then i tried to add specific permissions to the application pool of this
> website, but it still was possible to access other directories. I have the
> feeling that IIS will not use that account for active server pages, but only
> for .net and other isapi filters? or am i wrong?
>
> Are there any settings? solutions.
>
> My current hotfix was to disable the FileSystemObject with
> regsvr32 scrrun.dll /u
>
> but it's not really what I want, as some websites still use the FSO
>
> Thanks for your input


The only way to constrain FSO in a shared environment is with
FileSystem ACLs. Unlike Managed Code, there is no sandboxing for
Native code like FSO. NTFS ACLs is it.

In the context of ASP pages running on IIS6, the most secure way to do
this is to:
1. Create one Application Pool per website
2. Create unique Windows user for each Application Pool
3. Assign this Windows user as both Custom Application Pool Identity
and Anonymous user identity for the website
4. ACL files on Filesystem to the Windows user for all files the
website should have access to

If you want to understand the rationale, read the following blog
entries:
http://blogs.msdn.com/david.wang/archive/2005/06/29/IIS_User _Identity_to_Run_Code_Part_2.aspx
http://blogs.msdn.com/david.wang/archive/2005/10/14/HOWTO_II S_6_Request_Processing_Basics_Part_1.aspx

Basically, you force each Website to run as a unique Windows user
(both process and anonymous authenticated identities), which forces
all FSO usage to also run as that Windows user. You then apply NTFS
ACLs for the Windows user as appropriate.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Re: IIS6 - Directory Traversal in Active Server Pages - FSO

Hi David

Thanks for your help. Was exact what I was looking for. I just overseen step
3 ;-) Thanks, really great help

Patrick

"David Wang" schrieb im Newsbeitrag
news:1193107679.998058.56710@v23g2000prn.googlegroups.com...
> On Oct 22, 6:39 am, "Patrick" wrote:
>> Hello
>>
>> I'm just doing some checks on the system, and we found out that directory
>> traversal is possible with classic .asp. It is possible using the
>> filesystemobject.
>>
>> Then i tried to add specific permissions to the application pool of this
>> website, but it still was possible to access other directories. I have
>> the
>> feeling that IIS will not use that account for active server pages, but
>> only
>> for .net and other isapi filters? or am i wrong?
>>
>> Are there any settings? solutions.
>>
>> My current hotfix was to disable the FileSystemObject with
>> regsvr32 scrrun.dll /u
>>
>> but it's not really what I want, as some websites still use the FSO
>>
>> Thanks for your input
>
>
> The only way to constrain FSO in a shared environment is with
> FileSystem ACLs. Unlike Managed Code, there is no sandboxing for
> Native code like FSO. NTFS ACLs is it.
>
> In the context of ASP pages running on IIS6, the most secure way to do
> this is to:
> 1. Create one Application Pool per website
> 2. Create unique Windows user for each Application Pool
> 3. Assign this Windows user as both Custom Application Pool Identity
> and Anonymous user identity for the website
> 4. ACL files on Filesystem to the Windows user for all files the
> website should have access to
>
> If you want to understand the rationale, read the following blog
> entries:
> http://blogs.msdn.com/david.wang/archive/2005/06/29/IIS_User _Identity_to_Run_Code_Part_2.aspx
> http://blogs.msdn.com/david.wang/archive/2005/10/14/HOWTO_II S_6_Request_Processing_Basics_Part_1.aspx
>
> Basically, you force each Website to run as a unique Windows user
> (both process and anonymous authenticated identities), which forces
> all FSO usage to also run as that Windows user. You then apply NTFS
> ACLs for the Windows user as appropriate.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>