IIS Server Security - Access Control Best Practices for shared hosting seem at odds with Web Site Starters

Author

Access Control Best Practices for shared hosting seem at odds with Web Site Starters

M. M. Rafferty

2005-09-05, 10:41 pm

The MS Shared Hosting Deployment Guide lists among best practices:
Ensure strong permissions are used on Web content
Use separate anonymous (IUSR) accounts for each Web site
Never allow anonymous user (IUSR) Write permission

The document also describes Isolated Shared Web Hosting where each customer
has their own application pool with a unique identity. It states that the
host should "Ensure that the Customer-specific identity has the minimal
necessary permissions to system resources" but exactly what that means in
terms of ACLs apparently has been left as an exercise for the reader.

And therein lies the problem. Or at least part of it.

We are looking at the web site starter kits -- DotNetNuke and the Community
Server. It appears that both require write access for the application pool
identity below the web root. This has also come up in a few other
applications such as shopping carts we have encountered. Usually, the
requirement is to allow content management features, generally image
uploads, via the browser.

How is this not anonymous write access? Why would Microsoft recommend this
to its hosting partners?

Also, another quirk that appears to be the case, at least from what we
encountered in some experiments with the Community Server applications, is
that one seems to require the application pool identity have list permission
starting at the root of the drive all the way down to the web folder. This
seems like a bit of a privacy breach at best since it would rely only on
security through obscurity in our folder naming.

Can someone explain this apparent contradiction?

Ideally, can someone lay out the recommended ACLs for this scenario for a
web host to have in place so that customers' sites are secured and
isolated... and still able to run real ASP.NET applications?

Thanks,

Mary M. Rafferty

Jeff Cochran

2005-09-06, 2:52 am

On Mon, 5 Sep 2005 17:53:26 -0700, "M. M. Rafferty"
<mmr@vistagrande.com> wrote:

>The MS Shared Hosting Deployment Guide lists among best practices:
> Ensure strong permissions are used on Web content
> Use separate anonymous (IUSR) accounts for each Web site
> Never allow anonymous user (IUSR) Write permission
>
>The document also describes Isolated Shared Web Hosting where each customer
>has their own application pool with a unique identity. It states that the
>host should "Ensure that the Customer-specific identity has the minimal
>necessary permissions to system resources" but exactly what that means in
>terms of ACLs apparently has been left as an exercise for the reader.

Of course it's left to the reader. My users may need write
permissions because the app requires it or I use an Access database.
Yours may not. Permissions would be different for both our users, but
I only need MODIFY access, not FULL CONTROL as my minimum.

>And therein lies the problem. Or at least part of it.
>
>We are looking at the web site starter kits -- DotNetNuke and the Community
>Server. It appears that both require write access for the application pool
>identity below the web root. This has also come up in a few other
>applications such as shopping carts we have encountered. Usually, the
>requirement is to allow content management features, generally image
>uploads, via the browser.
>
>How is this not anonymous write access? Why would Microsoft recommend this
>to its hosting partners?

First off, neither DotNetNuke nor Community Server is Microsoft
product. Best practices will rarely be the actual practices. All
security is a balance between security and functionality.

>Also, another quirk that appears to be the case, at least from what we
>encountered in some experiments with the Community Server applications, is
>that one seems to require the application pool identity have list permission
>starting at the root of the drive all the way down to the web folder. This
>seems like a bit of a privacy breach at best since it would rely only on
>security through obscurity in our folder naming.
>
>Can someone explain this apparent contradiction?

Only if you install Community Server in a folder directly off the
root. It's an anomaly with the Windows file system.

>Ideally, can someone lay out the recommended ACLs for this scenario for a
>web host to have in place so that customers' sites are secured and
>isolated... and still able to run real ASP.NET applications?

Take a look at the Microsoft shared hosting environment. Keep in mind
that running .NET apps does not require anonymous write access. Some
apps may require write access to specific folders for the identity
they're running under, but that's not necessarily anonymous. Also, if
you can't actually run code under an identity that has access, then
that identity have certain permissions really isn't a risk.

If you're uncomfortable running an app because of the required
permissions, don't run it.

Jeff

M. M. Rafferty

2005-09-06, 2:52 am

Hi Jeff,

Thanks for your comments. However, they don't really address my questions.

The practical implementation of security measures is an exercise for the
reader -- but best practices is not.

For what it is worth, we have not allowed anonymous modify/write under the
web root. Access database files for instance, can be put outside the web.
By removing anonymous access from the admin or management folder, a site
owner could then authenticate as they would with FrontPage or FTP and upload
content via their browser. Usually, with the ASP applications, we have had
alternatives which meet the guidelines.

I don not understand what you mean by
> Only if you install Community Server in a folder directly off the
> root. It's an anomaly with the Windows file system.

With respect to DotNetNuke and the Community Server, yes, these are not
Microsoft products. However MS has recommended them to shared hosting
providers.

Since I am attempting to administrate a shared hosting server, I cannot be
dependent on the code that the clients bring to be written securely. We
also must isolate clients so that they can not gain access to another's code
or even know who else is hosted on that box. I'd rather take extra time up
front to work with clients on finding a securely configured solution than
hours later sorting out an exploited application.

I'm not writing these apps nor am I the one picking them. I'm just tying to
make sure that we are following best practices with our IIS 6 config and
will be able to make appropriate decisions about the requests our hosting
clients make. If there is a subtle distinction between the anonymous write
which is not to be allowed and the anonymous write which appears to be
needed for the community server apps and so forth, I would like to have that
spelled out so I cannot mistake one for the other.

mmr

"Jeff Cochran" <jeff.nospam@zina.com> wrote in message
news:43220efd.216431625@msnews.microsoft.com...
> On Mon, 5 Sep 2005 17:53:26 -0700, "M. M. Rafferty"
> <mmr@vistagrande.com> wrote:
>
customer[vbcol=seagreen]
the[vbcol=seagreen]
>
> Of course it's left to the reader. My users may need write
> permissions because the app requires it or I use an Access database.
> Yours may not. Permissions would be different for both our users, but
> I only need MODIFY access, not FULL CONTROL as my minimum.
>
Community[vbcol=seagreen]
pool[vbcol=seagreen]
this[vbcol=seagreen]
>
> First off, neither DotNetNuke nor Community Server is Microsoft
> product. Best practices will rarely be the actual practices. All
> security is a balance between security and functionality.
>
is[vbcol=seagreen]
permission[vbcol=seagreen]
This[vbcol=seagreen]
>
> Only if you install Community Server in a folder directly off the
> root. It's an anomaly with the Windows file system.
>
>
> Take a look at the Microsoft shared hosting environment. Keep in mind
> that running .NET apps does not require anonymous write access. Some
> apps may require write access to specific folders for the identity
> they're running under, but that's not necessarily anonymous. Also, if
> you can't actually run code under an identity that has access, then
> that identity have certain permissions really isn't a risk.
>
> If you're uncomfortable running an app because of the required
> permissions, don't run it.
>
> Jeff

David Wang [Msft]

2005-09-07, 5:54 pm

I think you misunderstand what "anonymous write" means:
http://blogs.msdn.com/david.wang/ar...Permission.aspx

How the two types of "write" differ is this.

In the case of HTTP PUT, it means that anyone who can send a PUT request to
the server can write a file somewher. This is clearly dangerous if
authentication is not required or unprivileged user is authorized to send
PUT, and it is the "anonymous write" that is clearly warned.

In the case of HTTP POST or any other request to a server-side application
who subsequently decides to write a file, this is less dangerous because it
is up to the server-side application to decide how read/write works. IIS has
very little say in this instance, if you read and understand my blog post.
Security depends on the application itself.

Yes, there is risk in allowing IUSR Write ACLs in the URL namespace, but
that is something for the hoster to decide for their web applications.
Personally, security is not absolute, and best practices are not perfect --
from a security perspective, I would never make it into a series of
check-boxes -- I would seek to understand the web app and then make my
choices.

Security is NOT absolute. It is relative and a balance between functionality
and risk. There is no way that a single check list of Best Practices is
going to functionally apply to all situations; no way. For the same reason,
the list of recommend ACLs that you are asking for also does not exist and
needs to be generated by yourself for your situation.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"M. M. Rafferty" <mmr@vistagrande.com> wrote in message
news:OxSbv0nsFHA.912@TK2MSFTNGP11.phx.gbl...
The MS Shared Hosting Deployment Guide lists among best practices:
Ensure strong permissions are used on Web content
Use separate anonymous (IUSR) accounts for each Web site
Never allow anonymous user (IUSR) Write permission

The document also describes Isolated Shared Web Hosting where each customer
has their own application pool with a unique identity. It states that the
host should "Ensure that the Customer-specific identity has the minimal
necessary permissions to system resources" but exactly what that means in
terms of ACLs apparently has been left as an exercise for the reader.

And therein lies the problem. Or at least part of it.

We are looking at the web site starter kits -- DotNetNuke and the Community
Server. It appears that both require write access for the application pool
identity below the web root. This has also come up in a few other
applications such as shopping carts we have encountered. Usually, the
requirement is to allow content management features, generally image
uploads, via the browser.

How is this not anonymous write access? Why would Microsoft recommend this
to its hosting partners?

Also, another quirk that appears to be the case, at least from what we
encountered in some experiments with the Community Server applications, is
that one seems to require the application pool identity have list permission
starting at the root of the drive all the way down to the web folder. This
seems like a bit of a privacy breach at best since it would rely only on
security through obscurity in our folder naming.

Can someone explain this apparent contradiction?

Ideally, can someone lay out the recommended ACLs for this scenario for a
web host to have in place so that customers' sites are secured and
isolated... and still able to run real ASP.NET applications?

Thanks,

Mary M. Rafferty

M. M. Rafferty

2005-09-08, 2:51 am

Hi David,

I understand the HTTP PUT. And that it is different. (An IIS thing rather
than NTFS.)

However, the full context of the bullet I quoted appears to be the HTTP POST
situation. Here is the longer version:
"Never Allow Anonymous User (IUSR) Write Permission
Do not allow anonymous user (IUSR) to have write permission. Allowing
write permission means that if the attacker can gain a method to upload the
content to the server, then they can write anything onto the server. Guest
books and forum software/Web pages are typical applications that require
anonymous write access. More secure alternatives are applications that store
data in an external database such as Microsoft SQL Server, rather than in
database files stored in the Web content directory. There are many free or
inexpensive guest books and forums that support using a database in this
way."

I always thought "Best Practices" were sort of like a 10 for a gymnast --
the ideal one strives to achieve -- not the practical reality one accepts
because that is all they can manage under the circumstances.

As the server administrator, I must assume that an application will be
insecure. Attempting to make a decision to the contrary on a case by case
situation is not a scalable solution. And it is basically impossible with
ASP.NET applications where only the DLLs are uploaded.

As far as I can tell, in order to run most web applications, we need Full
Trust allowed. (Database access and a few other things required it?) I
don't grasp what that means in terms of what the application pool users can
do. Just because I can't do more than the first "hello world" sample in
ASP.NET doesn't mean someone else can't create an application that uses
features of Windows I didn't even realize existed. So I am worried that if
we were to loosen up security for these sorts of applications, there could
be unpleasant results.

For instance, if a client application (unintentionally) allows visitors to
upload anything to any place on the website, what then? Other than burning
CPU and disk space with the traditional uses of compromised sites (warez,
file sharing, spamming) will the risks be confined to that Application pool
and the associated web structure? Is there enough isolation built into
ASP.NET so that the OS and other users' code and data will be protected? Or
can DLLs in this configuration do damage that was impossible with the older
ASP scripts?

I've read the information in the Resource Kit and several other documents,
but I just don't know enough to jump to a conclusion from that data.
Especially when the supporting evidence seems to be pointing in two
different directions. I don't want to open a Pandora's box unknowingly
while I'm just at the beginner level with ASP.NET skills.

mmr

"David Wang [Msft]" <someone@online.microsoft.com> wrote in message
news:OqA2gT7sFHA.1168@TK2MSFTNGP10.phx.gbl...
> I think you misunderstand what "anonymous write" means:
>
http://blogs.msdn.com/david.wang/ar...Permission.aspx
>
> How the two types of "write" differ is this.
>
> In the case of HTTP PUT, it means that anyone who can send a PUT request
to
> the server can write a file somewher. This is clearly dangerous if
> authentication is not required or unprivileged user is authorized to send
> PUT, and it is the "anonymous write" that is clearly warned.
>
> In the case of HTTP POST or any other request to a server-side application
> who subsequently decides to write a file, this is less dangerous because
it
> is up to the server-side application to decide how read/write works. IIS
has
> very little say in this instance, if you read and understand my blog post.
> Security depends on the application itself.
>
>
> Yes, there is risk in allowing IUSR Write ACLs in the URL namespace, but
> that is something for the hoster to decide for their web applications.
> Personally, security is not absolute, and best practices are not
perfect --
> from a security perspective, I would never make it into a series of
> check-boxes -- I would seek to understand the web app and then make my
> choices.
>
> Security is NOT absolute. It is relative and a balance between
functionality
> and risk. There is no way that a single check list of Best Practices is
> going to functionally apply to all situations; no way. For the same
reason,
> the list of recommend ACLs that you are asking for also does not exist and
> needs to be generated by yourself for your situation.
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "M. M. Rafferty" <mmr@vistagrande.com> wrote in message
> news:OxSbv0nsFHA.912@TK2MSFTNGP11.phx.gbl...
> The MS Shared Hosting Deployment Guide lists among best practices:
> Ensure strong permissions are used on Web content
> Use separate anonymous (IUSR) accounts for each Web site
> Never allow anonymous user (IUSR) Write permission
>
> The document also describes Isolated Shared Web Hosting where each
customer
> has their own application pool with a unique identity. It states that the
> host should "Ensure that the Customer-specific identity has the minimal
> necessary permissions to system resources" but exactly what that means in
> terms of ACLs apparently has been left as an exercise for the reader.
>
> And therein lies the problem. Or at least part of it.
>
> We are looking at the web site starter kits -- DotNetNuke and the
Community
> Server. It appears that both require write access for the application
pool
> identity below the web root. This has also come up in a few other
> applications such as shopping carts we have encountered. Usually, the
> requirement is to allow content management features, generally image
> uploads, via the browser.
>
> How is this not anonymous write access? Why would Microsoft recommend
this
> to its hosting partners?
>
> Also, another quirk that appears to be the case, at least from what we
> encountered in some experiments with the Community Server applications, is
> that one seems to require the application pool identity have list
permission
> starting at the root of the drive all the way down to the web folder.
This
> seems like a bit of a privacy breach at best since it would rely only on
> security through obscurity in our folder naming.
>
> Can someone explain this apparent contradiction?
>
> Ideally, can someone lay out the recommended ACLs for this scenario for a
> web host to have in place so that customers' sites are secured and
> isolated... and still able to run real ASP.NET applications?
>
> Thanks,
>
> Mary M. Rafferty
>
>
>