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

• Previous message: Tom Kaminski [MVP]: "Re: NTLM"
• In reply to: David Wang [Msft]: "Re: Access Control Best Practices for shared hosting seem at odds with Web Site Starters"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Wed, 7 Sep 2005 22:20:59 -0700

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/archive/2005/08/20/Why_can_I_upload_a_file_without_IIS_Write_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
>
>
>

• Previous message: Tom Kaminski [MVP]: "Re: NTLM"
• In reply to: David Wang [Msft]: "Re: Access Control Best Practices for shared hosting seem at odds with Web Site Starters"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]