Re: ASPNET User Problem in Shared Hosting Environment
From: Mr Snorkel (snorkelmeister@yahoo.com)
Date: 07/26/02
- Next message: Christopher Zacharias: "Accessing the ACL of a file?"
- Previous message: Matt: "Re: restricting access by IP addresses"
- In reply to: Arild Bakken: "Re: ASPNET User Problem in Shared Hosting Environment"
- Next in thread: Arild Bakken: "Re: ASPNET User Problem in Shared Hosting Environment"
- Reply: Arild Bakken: "Re: ASPNET User Problem in Shared Hosting Environment"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: snorkelmeister@yahoo.com (Mr Snorkel) Date: 26 Jul 2002 06:58:50 -0700
Using impersonation is a good first step, true (note though that it
needs to be *forced* in machine.config via the allowOverride=false
attribute in a <location> element, or the impersonation settings can
just be overridden by anyone who so chooses).
This will secure against, for example, someone using the System.IO
classes to get at the contents of another site's files.
However, note that it is only the thread that is using the
impersonation token. The process is still using the aspnet user's
security token, and this (as you say) needs read access to all the
.NET app files.
Not wanting to contribute to an already dangerously insecure situation
becoming worse, I won't say much more, but it doesn't need too much
thought to see that there are several ways that code can act under the
aspnet user's token, thus gaining access to all files in the .NET web
app directories.
It is obvious that MS know this (note Ben Miller's very tight-lipped
reference above), but they still continue to push ASP.NET as if it
were generically ready for real business use now. It is not. Probably
fine on carefully-managed dedicated boxes, but certainly not for
shared use.
.NET in general has some great security infrastructure, and provides
the potential to create high-quality, secure, applications. But MS is
risking the reputation of what is still a young technology by keeping
quiet about this issue; and commercial hosters (who surely must
understand the issue) are risking much by toeing the line.
"Arild Bakken" <arildb_@hotmail.com> wrote in message news:<OuLXNxHNCHA.360@tkmsftngp13>...
> I'm not sure I aggree on this. It's actually just a matter of configuring
> the system.config file aswell as setting security options on the filesystem.
>
> We've done tests where one customer's ASP.NET application is unable to
> access anything outside it's own folderstructure. This is done by using the
> impersonate="true" option for all applications, and giving the aspnet
> account only read and listcontents permissions on the customers sites, and
> of course giving each customer their own IUSR account which has permissions
> on the customers' folderstructure, just as we did in the "old days" of ASP.
>
>
> Arild
>
> "Mr Snorkel" <snorkelmeister@yahoo.com> wrote in message
> news:bf7d325e.0207251320.49d8d21d@posting.google.com...
> > Exactly.
> >
> > It's time MS came clean about this. At present, it is not safe to run
> > ASP.NET applications in any shared hosting environment. It is
> > trivially easy to violate other sites' privacy if you're sharing a
> > server with them. I'm amazed that this has still not become more
> > widely known. Presumably MS are hoping that this will stay the case
> > until the problems are fixed with a later version of the framework.
> > But as things stand any business shared-hosting a .NET web application
> > is in my opinion being negligently foolish.
> >
> > "M. Shawn Dillon" <nollids@moc.ovc-erutrepa> wrote in message
> news:<ulbyvxgHCHA.1728@tkmsftngp09>...
> > > From this I gather that shared hosting is not supported or recommended
> > > unless you are willing to give all of your customers the ability to
> trash
> > > your machine or other customer's sites. Trustworthy computing indeed...
> > >
> > > "Ben Miller [MS]" <benmi@online.microsoft.com> wrote in message
> > > news:#vgSaOZHCHA.1712@tkmsftngp08...
> > > >
> > >
> http://www.msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetse
> > > > c/html/V1securitychanges.asp?frame=true
> > > >
> > > > Watch for URL wrap. This should give you an idea of what this is all
> about.
> > > >
> > > > Ben Miller
> > > > This post is provided "AS IS" and confers no rights or warranties.
> > > >
> > > > "Ely Lucas" <ely@cmconline.com> wrote in message
> > > > news:uhhpa6p7u09c2@corp.supernews.com...
> > > > > Hello,
> > > > >
> > > > > I am trying to setup a win2k server that will be used for shared
> hosting
> > > > > services, and am trying to figure out how asp.net is going to be
> able to
> run
> > > > > secure on the server.
> > > > >
> > > > > In the asp days, you would give each website its own IIS_User
> account to
> run
> > > > > under, and give that user RWXD permission to it's web root folder.
> You
> would
> > > > > remove the Everyone group and also give the admin group full
> permission
> on
> > > > > the folder. This would keep users who are developing apps that are
> going
> to
> > > > > be hosted on that machine from poking around in each others
> directories
> with
> > > > > the file scripting object, include files, etc...
> > > > >
> > > > > With asp.net, it seems like everything is ran under the ASPNET user
> account.
> > > > > The problem here being, the ASPNET account needs Read permission to
> every
> > > > > site on the server so it can monitor file changes and such for the
> > > > > framework.
> > > > >
> > > > > When a user runs an aspx page, it runs under the ASPNET account that
> has
> > > > > read permissions to everyone elses aspx pages. So anyone can do a
> <!--
> > > > > #Include File="c:\inetpub\site1\allmylovelypasswords.aspx" --> into
> someone
> > > > > elses directory and get their source code. And that is just the
> beginning...
> > > > >
> > > > > I have messed around the Impersonation, and set the machine.config
> up as
> > > > > follows:
> > > > >
> > > > > <identity impersonate="true" />
> > > > >
> > > > > And when this happens, it seems like it is working, because when I
> do a
> > > > >
> > > > > Response.write(WindowsIdentity.GetCurrent().Name)
> > > > >
> > > > > it returns my IIS_User for that particular site that I have setup in
> the
> IIS
> > > > > MMC. However, this site is still able to browse through and view any
> > > > > resource on the hard drive that the ASPNET user has access to
> (which,
> > > > > remember, has to be all the aspx pages on the entire server, the
> > > > > Microsoft.NET folder, and more).
> > > > >
> > > > > So, I guess what I am wondering is, what is the best practice for
> > > setting
> > > up
> > > > > asp.net in a shared hosting environment? What are all the big hosts
> doing
> > > > > out there? What does Microsoft have to say about this (there are no
> docs
> at
> > > > > all in their web hoster program)?
> > > > >
> > > > > Thanks,
> > > > > Ely
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
- Next message: Christopher Zacharias: "Accessing the ACL of a file?"
- Previous message: Matt: "Re: restricting access by IP addresses"
- In reply to: Arild Bakken: "Re: ASPNET User Problem in Shared Hosting Environment"
- Next in thread: Arild Bakken: "Re: ASPNET User Problem in Shared Hosting Environment"
- Reply: Arild Bakken: "Re: ASPNET User Problem in Shared Hosting Environment"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
