Subject: [OAUTH-WG] [Fwd: Re: OAuth and HTTP caching]

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Sep 2009 11:29:54 -0600

Sorry, the list administrators mistakenly discarded this message from
the moderation queue...

-------- Original Message --------
Subject: Re: [OAUTH-WG] OAuth and HTTP caching
Resent-Date: Tue, 22 Sep 2009 17:10:21 +0000
Resent-From: [email-masked]
Date: Tue, 22 Sep 2009 10:09:16 -0700
From: Roy T. Fielding <[email-masked]>
To: John Panzer <[email-masked]>
CC: Eran Hammer-Lahav <[email-masked]>,	"[email-masked]"
<[email-masked]>,	"[email-masked] Group" <[email-masked]>
References:
<[email-masked]>
<[email-masked]>

On Sep 21, 2009, at 2:56 PM, John Panzer wrote:

> On the server side, one of the concerns in the past has been  
> security in shared hosting systems where e.g., basic auth data  
> should be handled by a secure container (Apache) and not passed on  
> in raw form to hosted CGI scripts.  So some of this comes back to  
> what minimum level of hosting should be targeted by the  
> specification -- and how much it should bend over backwards to deal  
> with "challenged" environments.

That is only a concern for Basic auth, AFAIK.  Apache could tweak it
to only forward unhandled non-Basic credentials to CGI or just a summary
of what has been validated, though some indication of what needs to be
forwarded would be useful.

> My $.02 is that we should follow the HTTP spec (Authorization: and  
> WWW-Authenticate:) and take a minimum distance path to route around  
> limited environments if necessary (X-Authorization: and X-WWW- 
> Authenticate:, with exactly the same content, would be my proposal).

Just follow the HTTP spec.  Someone will implement it.  If people try to
bypass HTTP extensibility mechanisms with stupid hacks that get shipped
in production software, Apache will add code to strip their information
from the stream before anyone sees it.

....Roy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Sep 2009 23:53:48 -0400

I am really confused about the security issues here.

If you are going to hand data off to a CGI script on a typical server,
you are going to have 'interesting' security issues such as code
injection. But I really don't see how not handing BASIC auth data to
the script helps there.

If an attacker has found a CGI hole that allows them to inject code,
then they are going to go to privilege escalation and rootshell the
machine anyway. Compartmentalization is not going to help.

Very early in the history of the Web it was common to have a single
Web site server shared by multiple users who would put scripts in
their home directory. That may still happen in some university
settings, but it is hardly typical commercial usage. Commercial
servers hosting 1000 web sites are hosting them on 1000 separate
domains. Each domain has unitary administration authority in at least
99% of cases.

I don't see how the single Web site with multiple script provider
issue can be safely handled unless the server design is dictatorial as
Roy suggests. It is at this point an edge case though.

On Tue, Sep 22, 2009 at 1:29 PM, Peter Saint-Andre <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/