[community] from W3CŠ.Fwd: Proposal: "User" header field

[SitG Admin]

At 5:10 PM +0200 7/19/13, Torsten Lodderstedt wrote:
>How does the server ensure the caller is the user represented by this URL?

OpenID, presumably.

>So for example, how would you prevent an attacker from sending your 
>user id URL to the server (and in turn impersonating you on this 
>server)?

We wouldn't. Attackers can't be controlled. This is where "It SHOULD 
NOT be used as an insecure form of access protection." may require 
stronger wording; "insecure" implies that the problem is only one of 
HTTP vs HTTPS, and simple sites can rely on the presented URL if they 
use SSL to protect the connection. The user does have to be 
authorized previously (though the presented URL may initiate an 
OpenID process), and *I think* there should be at least one means of 
maintaining statefulness on that session *other than* the User field 
(even if it's just a cookie) unless the User field will be modified 
on the spot to include server-provided identifying information (in 
which case it would just be replicating cookie functionality) and 
then the "insecure" recommendation is sufficient because it prevents 
eavesdroppers on the network from stealing that token.

 From reading the cross-posted proposal, I gather that they're 
intending this to be used for auxiliary metadata, which implies 
discrepancy checks for suddenly vanishing/switching authorization or 
User fields. I believe, then, that a User field should *not* act like 
a cookie, since combining these just simplifies matters for an 
attacker (who only needs to steal one of them).

I'm unclear, however, how useful this metadata *would* be for invalid 
requests; sure, if the user goes away entirely, you can block based 
on User, but if they have over-active spiders running about "in the 
wild" with their User URI and their login credentials (it *sounds* 
unlikely, but their IDP could potentially circumvent even 
password-changes, for the sake of monetizing its userbase, and the 
user might be forced by circumstance into staying with that IDP to 
retain their social identity/reputation), how would the server block 
these (or feed them less information) while letting the *user* 
through? If the server supported minor changes to the URI (which 
would not affect resolution to its intended resource), and provided 
access to a user-configurable whitelist, then the user would have to 
keep track of non-memorable distinctions or lose access to the site, 
and any access-reset mechanism would be exploitable by the IDP to 
restore *its* spying. Simple servers wouldn't implement such complex 
controls anyway, and the feature seems out-of-scope for the proposed 
User field, so I'm curious about the exact use-cases they have in 
mind.

-Shade