John Palmieri wrote: > I've read the document and it is pretty well thought out. A couple of comments - for the JavaScript parts wouldn't that be better to setup as an included file which also pulls in a JS library? Just so people aren't copying and pasting? That way you will also be able to extend the functionality if need be and app developers would have to worry about one line of code instead of 10. > I mention that I'll be adding that to the Javascript BaseClient implementation, fedora.dojo.BaseClient.start_request(), that I've been working on. However, not everyone wants to use dojo so people are probably going to want to implement that for whatever Javascript framework they're using. This is the suckiness of Javascript not having a standard library on which these things can be built :-( > As for myfedora this is pretty straight forward as we can use the middleware layer to inject the javascript variables and do the hashing and double authentication. Most of our modification requests will be going over json so a javascript layer would work there too. We can then simply have our proxies pass the hash onto the ProxyClients. It is still a chain of trust where you trust our servers have implemented the protocol correctly and we aren't just hashing the cookie when it has to pass it to the proxy client. > Exactly :-) We are just fixing a hole that the same-origin policy leaves open in the browser's security model. A non-browser origin is virtually unaffected by this (it has to send more information but it has access to all the necessary pieces to generate that information). Since MyFedora is proxying the authentication tokens, it effectively becomes the client for the other apps. So those apps have to trust that MyFedora is doing the right thing and verifying the CSRF tokens that are submitted to it. We humans, can audit the code of course :-) > The only way to fix the man in the middle trust issue would be to have the client somehow sign the session hash, but even then, the client would have to register a public key on a server you trust. > There's several different trust issues wrapped up in the proxying server case and the one that this would solve is the least of our worries :-). It also isn't solvable while keeping the web pages fully accessible (because code would have to execute on the client's machine in order to sign the token). -Toshio > ----- "Toshio Kuratomi" <a.badger@xxxxxxxxx> wrote: > >> Greetings all, >> >> I've been researching the CSRF exploit and how it affects our web >> apps >> recently. The short story is that our code is pretty open to this at >> the moment. I've written up a proposal for fixing this but it will >> require a lot of coding so I'd love to have some more eyes on it to >> make >> sure I'm not making any stupid mistakes. >> >> The proposal is here:: >> https://fedorahosted.org/fas/wiki/CSRF >> >> The ticket for the overall CSRF fixing is here:: >> https://fedorahosted.org/fedora-infrastructure/ticket/992 >> >> I consider fixing this to be a fairly high priority so I'll be >> starting >> work on implementing this for a few pkgdb methods very soon. >> Assuming >> the technique works we'll need to port every method that can change >> data >> in every app to use this. >> >> -Toshio >> >> >> _______________________________________________ >> Fedora-infrastructure-list mailing list >> Fedora-infrastructure-list@xxxxxxxxxx >> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list >
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list