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

From: M. M. Rafferty (mmr_at_vistagrande.com)
Date: 09/08/05

  • Next message: Scott: "Freeware ssl-ftp client wrapper available"
    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
    >
    >
    >


  • Next message: Scott: "Freeware ssl-ftp client wrapper available"

    Relevant Pages

    • RE: Ariba password exposure vulnerability
      ... Ariba's "Spend management" software is a suite of web based applications ... password of the user to the server via the URL in plain text". ... Ariba's "Configuration Guide" documentation is very clear that the ... safeguards in place to prevent the use of http in production unless the ...
      (Bugtraq)
    • Re: Users with ADMIN profile
      ... > Hi Adam, ... > does it have to be on local machines, or on the server etc. ... You would do this from their workstation, running the applications ... having permission issues. ...
      (microsoft.public.security)
    • Re: Mailsmith
      ... now a freeware product, and is available from <http ... You don't have permission to access / on this server. ...
      (comp.sys.mac.comm)
    • Software Developer Lead for New Mobile Device Product
      ... with a client in Austin who has the following opening. ... is in need of a Passionate Software Developer who is hands-on to lead ... commercial work experience in both web and server side applications. ...
      (comp.lang.java.programmer)
    • Re: Can AlbertCos tables be accessed?
      ... You don't have to learn the server side stuff. ... Access is a true RAD web development tool just like ... When you publish report in access web services, you actually wind up with a SQL server report definition report. ... And, even more interesting is this stuff designed around Microsoft's cloud computing initiative, which thus means massively scalable numbers of users for those applications. ...
      (comp.databases.ms-access)