Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

["Richard L. Barnes" <[e-mail]>]

> Then there's the question of checking to see if the data in the  
> envelope is consistent with data outside the envelope.  A good way  
> to do this is to ignore the data outside the envelope and only use  
> the verified, enveloped data.

This is precisely the problem.  But think about what "only using the  
data inside the envelope" means in the context of OAuth -- stuffing  
all the relevant parts of the HTTP request inside the envelope.  I  
admit that I'm not up to speed on the latest OAuth specs, but in  
earlier versions, there were several parts of the HTTP request that  
were included under the OAuth signature, so this would amount to a lot  
of duplication.

The alternative is to somehow ensure that the data outside the  
envelope are the same as the data inside the envelope.  Which brings  
us back to the two mechanisms we were talking about before for doing  
that:
1. Send the enveloped data and checking that the inside matches the  
outside
2. Just send the envelope (not the data) and reconstruct the data from  
the request based on the outside information.

Just using a JSON token / Magic Signature object that includes all the  
relevant fields requires that you do (1), which has the risk that the  
recipient can skip the check.  You can do (2) with a "meta-MagicSig"  
where the content is included by reference (e.g., to field names) and  
the actual enveloped data structure is built and verified by the  
recipient.

As far as a specific attack vector, I think the idea is that a  
recipient could get a request like the following (again, with made-up  
syntax)...

POST /malevolent.php HTTP/1.1
Authorization: oauth { method: "GET", path: "innocuous.jpg", sig:  
valid_sig }

... and based on the validity of the signature, go ahead and grant the  
request.

--Richard