Fixing CSRF exploits in Infrastructure

[Toshio Kuratomi]

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 at gmail.com> 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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-infrastructure-list/attachments/20081125/171535b1/attachment.sig>