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 <e...@hueniverse.com> > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
