#992 CSRF
Closed: Fixed None Opened 12 years ago by toshio.


I've updated this page with information on how SSL Certificates are vulnerable to CSRF as well and a plan for fixing our web apps. Please review and let's discuss changes that we want to happen. Once we agree, we can ask a wider audience (I was thinking of infrastructure-list) for input and then start writing code.

There's a fair amount of code to write for this both in libraries and porting to the libraries. There's even more work involved in testing since it will affect anything that needs an identity.

Ricky gave feedback that's been incorporated into the proposal.

General call for feedback has been sent to fedora-infrastructure-list.

Note that the proposal is TG1-centric at the moment. mbonnet, dgilmore: do you have ideas for things we can do to fix koji? lmacken, johnp: Do you have ideas of changes that may need to be made to enable this for moksha/myfedora?

Updated https://fedorahosted.org/fas/wiki/CSRF with a method to CSRF protect the web pages that allows us to send out links via email and not have to go through full authentication if you're already logged in. The method also allows for CSRF protection of SSL Client Certificate Auth.

If you have concerns with this ping me or bring this up at FUDCon hackfest. I'm going to start implementing this there.

Most changes for non-AJAX apps are done.

Instructions on porting apps are written (but could do with some reorganization/editing):

  • Templates are in python-fedora-devel.
  • Controller methods for login()/logout() are in python-fedora-devel
  • Methods to enable the protection are in python-fedora-devel.
  • CSS is being merged into fedora-web (http://fedoraproject.org/static/css/fedora/css)

  • FAS has been ported to a prototype implementation; porting to python-fedora based templates underway

  • pkgdb has been ported for the non-AJAX portion.

  • koji has had protection added to close the holes.

  • work on Fedora community to close holes seems close to complete.

== TODO ==
* AJAX calls
* Template to pull the identity information from python into javascript
* Port Dojo BaseClient to use the csrf token
* Port pkgdb to Dojo BaseClient
* Figure out how to distribute this via python-fedora (or javascript-fedora?)

  • Call python-fedora integration done and make a new release
  • Get other apps ported over
  • More testing in the staging environment to ensure a smooth transition
  • FAS has been deployed.
  • Non-AJAX apps should have all the support they need.
  • New python-fedora has been released
  • AJAX calls can be done ad hoc -- template to pull identity information into javascript exists.
  • No modular Dojo BaseClient yet.

I'm working on getting pkgdb deployed.

https://fedorahosted.org/releases/p/y/python-fedora/doc/CSRF.html should have all the information needed for others to port their apps over as well.

I rewrote Moksha's CSRFProtection WSGI middleware last night, along with it's repoze.who CSRFMetadataProvider, which will be utilized by the Fedora Community application. I also threw together some basic test cases for it.


Code reviews encouraged :)

I looked at lmacken's middleware code at pycon. Looked good! If you want to get that into python-fedora, it will make porting existing servers to TG2 in the future easier. Maybe in a middleware directory?

pkgdb with CSRF protection is on staging: https://admin.stg.fedoraproject.org/pkgdb/

Still need to pull the middleware into python-fedora.

PackageDB-0.4.0 has been deployed with the CSRF fix. We need to get the rest of the TG1 apps ported over. Ping me if you'd like help.

We still need to pull the middleware from moksha into python-fedora for other TG2 applications. Unfortunately, there's a licensing issue because moksha and f-community are AGPLv3 and python-fedora is GPLv2. Luckily, the middleware hasn't changed since before the licensing change so we can copy the sources from then (It was GPLv2) to python-fedora. lmacken is going to take care of that copying. In the future we will be looking at our licensing options and try to get things under licenses where code can be shared again.

  • lmacken pulled the TG2 middleware in last night. I'll do a new release of python-fedora this week. (Thanks Luke!)
  • Someone needs to document how to use this so people who port to TG2 will have an easy time integrating it. Something like http://fedorahosted.org/releases/p/y/python-fedora/doc/CSRF.html
  • I ported the elections app to be CSRF fixed. The changes are checked into the master branch in git. Application is running in staging: https://admin.stg.fedoraproject.org/voting/
  • By my count, these apps still need to be fixed:
  • mirrormanager, bodhi
  • These apps have been fixed:
  • fas, koji, pkgdb, transifex, fedora-community, elections
  • These apps do not allow login
  • smolt
  • Apps that we are not upstream for have not been audited. Do we want to?
  • mediawiki, trac, zabbix, and wordpress are the ones I can think of

I'm working on the front end for bodhi now. lmacken will look into whether the changes break the backend/masher after that. (the communication uses ProxyClient so we may get lucky and things just work.)

mdomsch: How do you want to work the csrf protection for mirrormanager? It should be easy to implement using the stuff in python-fedora (elections was an hour last night of following instructions and three hours this morning debugging and fixing silly things) but I'm not sure if you want to rely on it. I see, for instance, that mirrormanager in git uses the sqlobject identity and visit providers rather than jsonfas1. CSRF protection will need to use jsonfas2 and to do it quickly will need to use the sample login/logout controllers and login template from python-fedora and update master.html with some pyhton-fedora code.

Add another application to the does-not-need-protection category:
* sigul, the signing server, is not interacted with via a web browser so there's no chance of a rogue web page directing a browser to do something malicious.

Replying to [comment:9 toshio]:

There is already a little bit of documentation in the docstrings, so we could just create a new rst with something like::

.. automodule:: fedora.wsgi.csrf
.. autoclass:: fedora.wsgi.csrf.CSRFProtectionMiddleware
.. autoclass:: fedora.wsgi.csrf.CSRFMetadataProvider

Someone still needs to hook this middleware up to a fresh TG2 quickstart and get it working, and fill in the gaps in the docs. The client-side javascript code needs to be documented as well.

Mirrormanager update. mirrormanager is in use by other projects that do not use fas. This menas that tying csrf protection to fas is not going to work for upstream mirrormanager. Options:

  • Port to TG2 and use the csrf middleware
  • This seems like the best long term solution
  • Port the sqlobject identity provider to have CSRF protection
  • This is flexible and helps out other TG1 projects. However, it makes us responsible for maintaining another identity provider. Those have some tricky bits because of TG's threading and are security sensitive as well. Not my favorite choice because of that.
  • Protect controller methods manually
  • Requires writing lots of code and auditing changes in code to make sure we never add a controller method without protecting it from atttack. This is my least favourite option.
  • Write a patch against vanilla upstream and include it in fedora infrastructure's rpm
  • Maybe the easiest solution. But it means we have to port changes with every mirrormanager release. It also doesn't help protect third party projects using mirrormanager.
  • Adapt python-fedora code to fail gracefully if we're using sqlobject. ie: no csrf protection but otherwise, the app works.
  • this could be the least work. That makes it attractive. May not be a good choice if we have to do much coding.

Replying to [comment:12 lmacken]:

Replying to [comment:9 toshio]:

There is already a little bit of documentation in the docstrings, so we could just create a new rst with something like::

.. automodule:: fedora.wsgi.csrf
.. autoclass:: fedora.wsgi.csrf.CSRFProtectionMiddleware
.. autoclass:: fedora.wsgi.csrf.CSRFMetadataProvider


Someone still needs to hook this middleware up to a fresh TG2 quickstart and get it working, and fill in the gaps in the docs. The client-side javascript code needs to be documented as well.

Also, someone needs to figure out what needs to happen to the moksha references in the docstrings. For instance, does "moksha.csrf_protection" have any effect? Should it be renamed since it's no longer in moksha? etc.

Replying to [comment:13 toshio]:

  • Port the sqlobject identity provider to have CSRF protection

I've done this and tested the provider against a quickstarted project. It seems to work fine. It's not as broad a divergence from the TurboGears sqlobject provider as jsonfas is so I think this will be acceptable. mdomsch, nothing I'm using will use this, though (Things I'm working on are SQLAlchemy, rather than SQLObject), so I may need help from you testing and reproducing problems in this provider if there are any.

Next week I'll work on getting mirrormanager ported to use the CSRF protection from python-fedora. It will use this sqlobjectcsrf identity provider in the mirrormanager git tree. On fedora infrastructure, we'll override it to use jsonfas2 instead. This does make mirrormanager dependent on python-fedora but I don't think that's an issue. Let me know if I'm wrong on that.

Mirrormanager code changes:

We now have code to fix csrf issues in our remaining web apps. I'll get a python-fedora release out with the sqlobjectcsrf identity provider this week. I'll work with Nigel to get a new fedora-elections package out.

lmacken looked at the bodhi changes today. I'll let him update how that went and when it can be ready to go live.

mdomsch will need to look at the mirrormanager changes to be sure that they're okay and estimate when we can deploy it.

Mirrormanager changes are in the 1.3.0 release which is deployed to the servers. We still need bodhi and elections fixes to be deployed.

Bodhi 0.6.9 with CSRF protection is now in production.

elections is all we have left. There's a round of elections scheduled for just after Thanksgiving so we really should be trying to get this done for F12.

elections is deployed! We're all set here. The only thing that's still to be done is documenting the CSRF middleware in python-fedora. I'll talk with lmacken at fudcon about pulling out the jsonfas middleware into python-fedora as well, quickstart an app, ask any questions, and then document at least a tutorial on using it in the python-fedora documentation. Closing this ticket as the code changes are all done.

Login to comment on this ticket.