One obvious (but somewhat wasteful) solution is to repeat the headers being signed. If you take the headers, "normalize them together" (for example, Base64 them), then hash that and include both the hash and the Base64 value, you can easily verify it, and compare it to the received HTTP header.
Another is to decide which headers are actually important (content type and encoding come to mind) and include those as new oauth_ parameters (oauth_conent_type, etc.). This way the server can compare to the HTTP header, or even completely ignore the HTTP headers and only use the OAuth signed view. EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Martin Atkins > Sent: Thursday, April 02, 2009 9:35 PM > To: [email protected] > Subject: [oauth] Re: Header Integrity > > > Krishna Sankar (ksankar) wrote: > > I will byte ;o) > > > > @all, I am thinking of developing a header integrity proposal - a > header hash taking lead from Brian's body hash. > > > > First, is there anybody attempting this ? I am sure Brian is not. > > > > Second, while I think this is inevitable - one form or another, I > also do not want to rush in. My thought is to start simple and then add > complexity as and when needed. > > > > I think we should have a selective header hash or if that turns out > to be problematic, sign a list of prescriptive headers if that makes it > easier. > > > > I will unearth old discussions on this topic and find common ground. > > > > Is this a good idea or better left alone ? > > > > It is definitely something that would be useful for APIs that make full > use of HTTP's features, but it'll certainly be trickier than the body > hash because the header isn't just an opaque bytestream like the body > is. > > Intermediate proxies are allowed to fiddle with or remove some existing > header fields and add new ones, for example. The most obvious examples > are Proxy-Authorization and the conditional request headers. > > Sometimes HTTP client libraries themselves make changes to the "bits on > the wire" behind their header abstraction, too. > > Also, you'd need to figure out what to do with the Authorization: OAuth > header field, since it contains the signature but you don't know the > signature until you've > > I'm not sure what the solution is. Hashing a subset of the more > "interesting" header fields that proxies don't touch would perhaps be > feasible, but still tricky. If you enumerate which header fields are > included, an attacker may still be able to introduce new headers that > change the meaning of the request. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
