We are getting somewhere. Brian, thanks for the sha1/hmac-sha1 explanation. It is now clear to me, I didn't consider a opensocial like platform.
On 9 dec 2008, at 19:51, Brian Eaton wrote: > On Tue, Dec 9, 2008 at 9:15 AM, John Hayes <[EMAIL PROTECTED] > > wrote: >> 1. Include HTTP entity headers: Content-Type, Content-Range, >> Content-MD5, >> Content-Language; they should be combined into a normalized base >> string, URL >> encoded to ascii and concatenated as a prefix with the body. The >> content >> flags can affect how the entity is interpreted >> 2. Exclude HTTP transfer encoding headers: Content-Length, TE, >> Content-Encoding > > Marc Worrell made a similar suggestion. My initial proposal was not > to bother with this, I would prefer not to include HTTP headers of any > type in the signature base string, because I don't see how it fits > into a realistic threat model. If an application is so sensitive that > the possibility of changing a content-range header creates an > unacceptable security risk, that application should probably be using > https instead of OAuth over http. > > Is there a realistic threat here? I can see a possible scenario where all of the following conditions are true: 1. The provider trusts the consumer completely (ie doesn't do any checks apart from the OAuth signature) 2. The provider performs instructions supplied in the request body (a programme script oid) 3. The consumer is tricked into sending a (say) programme script assuming it is a raw text or image 4. The Content-Type header is changed in transit and the provider now receives a programme script instead of a text (or image) >> 3. Specify exactly what will be hashed: I recommend after >> transforming the >> entity to bytes (no wide chars unless the endian is specified in the >> charset), but before transfer encoding. > > Definitely not. The HTTP entity body (raw octets, as defined in > section 7.2 of RFC 2616) should be hashed. No transformation should > ever be done. This matches the definition of content-md5 in section > 14.15 of RFC 2616. +1 I prefer signing the raw octets. Though, reading John's reply, I can see the problem where the application does not have access to the chuncked or compressed body. >> 4. Change parameter name to: oauth_entity_signature; slightly better >> indicator that oauth_signature_method applies > > This is not a signature, since we are not using an HMAC. > oauth_entity_hash would be fine by me. +1 (oauth_entity_hash) >> Normalizating HTTP headers is a lot trickier than query parameters >> because >> they may be rewritten by intermediate proxies and have multiple >> standard >> forms with multi-line or single line representations, case >> insensitivity and >> optional quotes. > > I agree normalizing HTTP headers is tricky. Given that it provides > negligible security benefit and is likely to cause interoperability > problems, we shouldn't do it. At least we can agree on which headers to normalize and hash. The generic case is quite hard, in the case of Content-Type, Content- Length, Content-Language and Content-Encoding (to name a few) it is quite doable. I propose the following normalisation: 1. Remove all whitespace characters (space, tab, cr, lf) 2. Translate to lowercase (assuming ANSI codes) And for Content-Type: 3. Split on ';', sort all parameters, reconcatenate using ';' How much is the content-type header affected in transit? - Marc Worrell --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
