Issues in locking down aspnet user security in shared environment

[John Dalberg]

I am trying to lock down file access of some sites in a shared hosting
environment so that different users can only access their own site's
directory with their asp.net code. However there's a problem with some
aspnet user access.

[I enabled identity impersonate in machine.config and made allowoveride =
false.]

After some experimenting with ntfs permissions, I noticed that any asp.net
enabled site *must* have asp.net user have read access on the folder above
the application folder plus have read access to the web.config file,
regardless whether the site is impersonating another user.

This means any asp.net site can list the files of any other asp.net enabled
site plus read someone else's web config file which might contain sensitive
non encrypted settings.

Does anyone see a security hole in this security model? In some cases you
can display or even download files by just looking at someone else's site
folder and typing the url + filename in a browser. Like an .mdb file if the
user didn't password protect their sensitive folder.

How can I plug this hole with better lockdown? I was going to look at the
<location.. > tag and trust levels and see if they help.
Is there any whitepaper on how to very securely lockdown asp.net sites in a
shared environment?

Thanks.

John

[Chance Hopkins]

Hi John,

I got these links, they're a nice start:
[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh19.asp[/url]

[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh20.asp[/url]

The second one sounds like it might have what you want.

You'll thoughts regarding directory transversal and reading of web.config files can be defeated with a proper structure of "wacky
directory names for users" and "their containing folder having proper NTFS permissions on the ASPNET process (like allow transversal
and deny all else)". This way, they can't list the folder with the "wacky names". The "wacky names" are like keys then. With out the
key, one can't transverse to that directory. And the key can't be gotten by the aspnet worker process. Place the users wwwroot
folders underneath the "wacky names" folder.

If they can't get the path. They can go to it.

Hope that helps, I just spent four days on it. I'm stuck on a problem where my impersonation works for the individual applications,
but my access database connections die.






"John Dalberg" <john_dd@hotmail.com> wrote in message news:1u0pgkcebnvrb$.fuu1z4710do1$.dlg@40tude.net.. .

> I am trying to lock down file access of some sites in a shared hosting
> environment so that different users can only access their own site's
> directory with their asp.net code. However there's a problem with some
> aspnet user access.
>
> [I enabled identity impersonate in machine.config and made allowoveride =
> false.]
>
> After some experimenting with ntfs permissions, I noticed that any asp.net
> enabled site *must* have asp.net user have read access on the folder above
> the application folder plus have read access to the web.config file,
> regardless whether the site is impersonating another user.
>
> This means any asp.net site can list the files of any other asp.net enabled
> site plus read someone else's web config file which might contain sensitive
> non encrypted settings.
>
> Does anyone see a security hole in this security model? In some cases you
> can display or even download files by just looking at someone else's site
> folder and typing the url + filename in a browser. Like an .mdb file if the
> user didn't password protect their sensitive folder.
>
> How can I plug this hole with better lockdown? I was going to look at the
> <location.. > tag and trust levels and see if they help.
> Is there any whitepaper on how to very securely lockdown asp.net sites in a
> shared environment?
>
> Thanks.
>
> John
>

[John Dalberg]

On Mon, 6 Oct 2003 15:41:23 -0400, Chance Hopkins wrote:

> Hi John,
>
> I got these links, they're a nice start:
> [url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh19.asp[/url]
>
> [url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh20.asp[/url]
>
> The second one sounds like it might have what you want.
>
> You'll thoughts regarding directory transversal and reading of web.config files can be defeated with a proper structure of "wacky
> directory names for users" and "their containing folder having proper NTFS permissions on the ASPNET process (like allow transversal
> and deny all else)". This way, they can't list the folder with the "wacky names". The "wacky names" are like keys then. With out the
> key, one can't transverse to that directory. And the key can't be gotten by the aspnet worker process. Place the users wwwroot
> folders underneath the "wacky names" folder.
>
> If they can't get the path. They can go to it.
>
> Hope that helps, I just spent four days on it. I'm stuck on a problem where my impersonation works for the individual applications,
> but my access database connections die.

I have read the articles you mentioned however they don't mention how to
lockdown aspnet user permissions. But your idea of using "wacky names" for
folder names seems a good one. You can only traverse a folder if you know
the folder name so if you don't, you won't be able to go there.

Thanks for the input

John

>
>
>
>
>
>
> "John Dalberg" <john_dd@hotmail.com> wrote in message news:1u0pgkcebnvrb$.fuu1z4710do1$.dlg@40tude.net.. .

>> I am trying to lock down file access of some sites in a shared hosting
>> environment so that different users can only access their own site's
>> directory with their asp.net code. However there's a problem with some
>> aspnet user access.
>>
>> [I enabled identity impersonate in machine.config and made allowoveride =
>> false.]
>>
>> After some experimenting with ntfs permissions, I noticed that any asp.net
>> enabled site *must* have asp.net user have read access on the folder above
>> the application folder plus have read access to the web.config file,
>> regardless whether the site is impersonating another user.
>>
>> This means any asp.net site can list the files of any other asp.net enabled
>> site plus read someone else's web config file which might contain sensitive
>> non encrypted settings.
>>
>> Does anyone see a security hole in this security model? In some cases you
>> can display or even download files by just looking at someone else's site
>> folder and typing the url + filename in a browser. Like an .mdb file if the
>> user didn't password protect their sensitive folder.
>>
>> How can I plug this hole with better lockdown? I was going to look at the
>> <location.. > tag and trust levels and see if they help.
>> Is there any whitepaper on how to very securely lockdown asp.net sites in a
>> shared environment?
>>
>> Thanks.
>>
>> John
>>