RE: Security issues with Asp.Net in Shared Hosting Environments

[Mark Burnett <mb () xato net>]

> > Further, many of the things you talk about can be restricted in
> > other ways. When I run your ANSA application against any of my
> > servers using
> > my standard build procedure, ALL of the tests fail, not just
> > because of my ASP.NET configuration, but because I take the
> > proper steps in securing the file system, the registry, WSH, FSO
> > WMI, etc.
> That is interesting, even the unmanaged calls?
> Did ANSA run in FullTrust?

I take that back, I ran the tests again and there was one call that 
succeeded, that was the WinExec API. However, it ran with a limited 
security context and wouldn't be able to do anything of consequence. 
FSO and WSH can be restricted with file ACLs and registry keys. On FSO 
I use registry permissions to have more granular control over which 
objects people can access (fso and dictionary). You can also set ACLs 
on WMI namespaces using the WMI admin tool (wmimgmt.exe). Cmd.exe is 
not available to anonymous users and even if they provide their own, 
the file ACLs on everything are so tight you really can't do much with 
it. The anonymous users can't even get dir listings for most of the 
system. And even the SYSTEM account needs to give itself permissions 
to perform some actions (to prevent most automated attacks). This is 
all standard stuff on my IIS lockdown procedure, although my procedure 
is obviously that standard.

As for the ODBC issue, what I have always done is set strict 
permissions (file and registry) on the specific drivers and removed 
any unused drivers. I also tighten some of the settings in the 
registry (such as sandbox mode). I haven't looked into this in enough 
depth yet, but I am pretty sure that just about everything you want to 
do you can accomplish by giving full trust and securing the system 
with file, registry, WMI, COM+ and other permissions.


Mark Burnett