Re: ASPNET User Problem in Shared Hosting Environment

From: Mr Snorkel (snorkelmeister@yahoo.com)
Date: 07/29/02 

From: snorkelmeister@yahoo.com (Mr Snorkel)
Date: 29 Jul 2002 04:17:29 -0700

Sounds good - I think it would be possible to lock things down enough
to bring risks within acceptable limits under the kind of controlled
conditions you're talking about. I'd be interested to hear exactly
what you've done with the ASPNET user's privileges & permissions.

I'm more concerned about the generic hosting companies. I've seen some
pretty serious business sites beginning to bubble up on shared hosting
services, and I don't imagine most of their owners understand how
vulnerable their content is. Some of the big hosting companies
*certainly* don't (poke around a bit, and you'll find their laxity
hair-raising). What bothers me is that if no-one tackles this very
soon, a big scandal will hit, and damage the image of ASP.NET as a
secure web application platform in the eyes of business. As a .NET
developer, that's the last thing I want to see.

"Arild Bakken" <arildb_@hotmail.com> wrote in message news:<#Gcx0UjNCHA.2368@tkmsftngp10>...
> Hi,
>
> I really didn't doubt it, it just slipped my mind that it was just the
> thread that was impersonated. I just did a test on this - everthing works
> fine when setting proper security and enabling impersonation, but if my code
> just issues a RevertToSelf(), it's running as the ASPNET account again.
>
> I've been able to strip down the rights allocated to the ASPNET account on
> the system so that it cannot access other customers' files, but it still
> needs read access on the Web.Config file, and that still poses a security
> issue. I'm sure if I dig even deeper there are more issues with the fact
> that it's just impersonation and not a separate process.
>
> But then again, the customers we are hosting are not allowed to add stuff
> themselves to the server, and all updates and fixes are run through our
> test-team before we deploy it to the servers, so if we just make sure that
> they do all kinds of security tests, and also check for imports of external
> dll methods, we might still be able to use this.
>
> Thanks for the input.
>
>
> Arild
>