> Anybody have a real web app that relies on the integrity > of content headers for security?
There have been various attacks using the UTF-7 charset (eg an XSS attack against Google in 2005). The attack works when the body of an HTTP response is misinterpreted by browsers as UTF-7, instead of UTF-8 or US-ASCII. The charset is specified in the Content-Type header. Another potentially relevant attack, named GIFAR, was reported a BlackHat USA this year. A single file (HTTP body) can easily be interpreted as a (harmless) GIF image or (potentially malicious) Java code (JAR file). One reason the attack worked was because a Java Virtual Machine (JVM) ignored the image/gif Content-Type. If the solution was for the JVM to care about the Content-Type, not protecting its integrity could undo the solution. Both of these are real attacks. They might not be absolutely directly applicable to this OAuth body signing situation -- but they are close. P.S. DKIM (DomainKeys Identifier Mail) [RFC 4871] defines a signature mechanism that covers header fields and the body of an email (that are very similar to header fields and the body of an HTTP message). It offers "simple" and "relaxed" canonicalization rules to cope with the complications of headers. It might be worth a look. James Manger [EMAIL PROTECTED] Identity and security team — Chief Technology Office — Telstra ---------- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Eaton Sent: Wednesday, 10 December 2008 1:25 PM To: [EMAIL PROTECTED] Cc: Marc Worrell; Louis Ryan; [email protected]; Scott Seely Subject: [oauth] Re: [opensocial-and-gadgets-spec] Re: body signing for oauth and opensocial On Tue, Dec 9, 2008 at 5:52 PM, Krishna Sankar (ksankar) <[EMAIL PROTECTED]> wrote: > Have been watching this discussion. Something is puzzling me - the spec > [1] talks about integrity of the body nothing else. The only thing it > says is that the body has not been altered since it left the consumer. > As the header also has relevance to the body, we should guarantee the > integrity of the headers as well, which means sign the header too. > > Looking from another perspective, whatever threat model requires a > signature of the body also requires signature of the headers as well. > > Possible I am missing something obvious. No, you're not. In theory protecting the headers is vitally important for security. In practice it doesn't seem to matter. No one has been able to point to a single real web application whose security would be negatively impacted by a bad guy who tampers with content headers but not the body. Several people, OTOH, have suggested reasons why trying to sign headers will be complicated. If it doesn't give security, but it does make things complicated, I don't think we should do it. Anybody have a real web app that relies on the integrity of content headers for security? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
