Except you are in control of your web server so you know you put it there and where it came from right?
On May 28, 2010, at 3:35 PM, Eran Hammer-Lahav wrote: > That’s the same thing (in a header or in the attached signed blob). > > EHL > > From: Kris Selden [mailto:[email protected]] > Sent: Friday, May 28, 2010 3:21 PM > To: Brian Eaton > Cc: Eran Hammer-Lahav; [email protected]; OAuth WG ([email protected]) > Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP > authentication scheme > > Can't you always have the front end web server preserve the original URI in a > header or something before the rewrite engine or application framework mangle > it, right? > > For example, this Nginx conf that preserves original parts of the request > that get changed when the request is proxied to the upstream web server: > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header X-Forwarded-Proto https; > proxy_set_header Host $http_host; > > Or even writing a module that validated the signature and intended target > directly in the web server before the app framework. > > > I guess this makes in hard to write a complete drop-in solution just on the > app framework but that doesn't seem like a good idea anyways. Seems like > libraries that do different modular pieces OAuth are a lot more useful rather > than "plugin" library deciding something like you should write a nonce to a > MySQL DB table every request. > > On May 28, 2010, at 11:02 AM, Brian Eaton wrote: > > > On Thu, May 27, 2010 at 10:51 PM, Eran Hammer-Lahav <[email protected]> > wrote: > > Cool. Glad we can put Roy's security concern to rest, at least. > > I disagree. Your signature proposal makes matching worse, but moves the > "canonicalization problem" to the server side. You just flipped the problem. > The client gets much simpler but the server gets potentially less secure > (as a likely result of poor implementation). > > You raise a bunch of really good points in your response, and I'm > going to ignore almost all of them for now. =) > > I want to get to the heart of the "potentially less secure" statement. > > In OAuth 1.0, in order to be secure, the server had to check a signature. [1] > > Under the proposal I made earlier, the same server will need to check > a signature, and it will also need to check the intended target of the > signed message. > > That is *not unusual* in authentication protocols. OpenID, SAML, and > others all have the exact same requirement. It's documented in their > security recommendations. And there are compliance tests that verify > that servers do check this. If someone fails to make this check, it > will be revealed as soon as anyone looks at their code or tests their > server. > > Cheers, > Brian > > [1] Aside: secure servers actually need to do lots more than check > signatures. They need good user management, and key management, and > XSS-prevention, and XSRF-prevention, and patch management, and > physical security, and so on. But that's out of scope for an > authentication protocol. > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
