Re: [AC] Helping server admins not making mistakes

* Jonas Sicking wrote:
>First of all it is very possible that the server itself, or the scripts 
>running on the server, performs actions that the server administrator is 
>not aware of. For example an administrator might not realize that the 
>server supports the PUT action such that other sites can't just POST to 
>a CGI script, but also replace the script using PUT.
>
>Second, even if the administrator is aware of the server performing a 
>harmful action for certain headers or methods, it can be very hard to 
>change this. The current spec has an all-or-nothing approach. To enable 
>cross-site POST you also are forced to deal with all other methods, 
>weather you want them or not.

Well, let's first be clear about the setup here, to use the PUT example:

         +---------------+                 +------------------+
         |   Attacker    |-----------------| Compromised site |
         +---------------+                 +------------------+
                 |                        /         |
            [Can't PUT]    +->> trusts >>+          |
                 |        /               \         |
         +---------------+                 +------------------+
         | Victim server |<---[Can PUT!]---| Privileged User  |
         +---------------+                 +------------------+

So the victim server would already be configured to tell Privileged User
and Attacker apart, otherwise the attacker could PUT directly and would
not care about cross site requests. It can't be enough to compromise the
other site as otherwise the attacker could PUT directly aswell (e.g. the
site stores username and password in a cookie, attacker reads out cookie
and uses them to authenticate with the victim server), and the authenti-
cation method needs to work with both POST and PUT without the adminis-
trator specifically configuring that. The last point rules out Cookies
and most custom authentication methods, so we'd be stuck with HTTP Auth,
client certificates and simply IP address or host name of the client.

In this version of the specification, as I understand it, only the host
name and the internet protocol address could be used, so the server
allows PUT for some client addresses but not for others, and the admin
of the server somehow does not know about it. I consider that somewhat
unlikely, and would hope that the other authentication methods, if added
in future versions, require additional measures to work. I do not think
this really requires an additional feature such as the one you propose.
As for configuring the server in this particular scenario, this does not
seem difficult to configure at all. Could you give a specific example?

An example for the header case would also be useful, it is easy to con-
figure the server to do different things based on some header, but it is
difficult to see how you could deliberately do this here with some harm-
ful effect and not be blamed for it. The really "dangerous" headers are
already filtered, and if your script does weird things if certain header
fields have certain values for a method you wish to allow, you should at
least be aware of that fact. And indeed could easily have the server re-
ject requests with the dangerous header field values.

The important Apache configuration features here are <LimitExcept> along
with deny, allow, order, and mod_rewrite (in fact, mod_rewrite could be
used to emulate most of the other features). I am certainly not saying
the problems here can be ignored, the more features are added the higher
the risk that we'll see "too many" cross site request enabling technolo-
gies, and the higher the risk that developers get confused and misconfi-
gure their servers, so we better understand very well the issues before
addressing them through additional complexity.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Friday, 16 May 2008 22:21:57 UTC