Fixing CSRF exploits in Infrastructure

[Till Maas]

On Wed November 26 2008, Toshio Kuratomi wrote:
> Till Maas wrote:

> > How big the regression is if users have to log in for every external link
> > they click on, depends on how often this happens. I believe that links to
> > FAS are not exchanged very often, therefore it will not hurt very much. I
> > guess there is also not so often a need to use FAS with tabs. But maybe
> > there are people who have to use FAS more often. With Bodhi it is
> > contrary, because there it is normal to get mails with links if someone
> > added a comment to a package or for testers to exchange links to Bodhi
> > updates. Also links to Bodhi updates are used in Bugzilla comments. There
> > it would have a much bigger impact on the efficiency of testing new
> > package updates imho.
>
> Pretty much agreed on this analysis.  My one note is that in my usage,
> at least, I already have to login most of the time when clicking on a
> link in bugzilla or email due to my session having expired already.

But in the future you would have to do this for every link everytime, even if 
you use many of them in a short timeframe.

> > Regarding the time needed for auditing applications: There may still be a
> > lot of other vulnerabilites in these applications which cannot be fixed
> > automatically. Therefore they still need to be written carefully. But
> > maybe a compromise would be to require the token for all requests by
> > default and then whitelist the ones, that are not meant to change state,
> > e.g. requests like:
> >
> > https://admin.fedoraproject.org/updates/pstreams-devel-0.6.0-6.fc10
>
> I thought of doing this but it still allows things to be insecure if
> what a method does gets changed and the whitelisting isn't updated.

What it am apllication writer does not require authentication for some action 
that should require authentication? With this reasoning you could also 
require that every request has to be authenticated.
Also do the actions behind a certain request / URL really change that often?

> OTOH, if a whitelist of methods isn't updated when a form goes from
> merely showing information to changing data, you lose the CSRF protection.

If you also do not add proper authentication if a method gets updated to show 
confidential information, you lose the protection of the confidential 
information.

Is it maybe possible to modify the functions behind the API that are used to 
change state to require a valid token? Then the author of the webapplication 
needs to activly work agains the CSRF protection instead of accidently 
forgetting it.

> > Another way would be to not change the session id if a user needs to
> > supply the username/password again only because the token was missing. It
> > would probably be enough to ask the user only to click a link that
> > contains the matching token in case the token is missing.
>
> Not changing the token can have security ramifications as it allows the
> browser to specify what the visit key will be once the user is
> authenticated.  I can't think of any way for javascript to manipulate
> this ATM but there could be something that I'm not thinking of or
> browser security holes could introduce something in this area.

How is it different to keep the same session id after sending a valid session 
id and token to the server than to keep it after sending a valid session and 
a username / password combination?

> > On the
> > downside it has a high impact on usability
>
> This is the one I don't know about.  It will change my usage a bit since
> I'll need to start clicking on links to the other apps in present app
> pages to open new tabs.  But when I usually open links from external
> sources I'm already used to having to re-login due to the session
> expiring.  So we need feedback here, do you often click on multiple
> things in close proximity and wouldn't be able to change to clicking
> within the app?  Are you able to

If I send you a bunch of links that point to Bodhi updates and your job is to 
add one comment to each update, then you have to provide your username and 
password once for each link. Currently you would only login once for the 
first link and open the others afterwards. I use as often as possible direct 
links from mails or bookmarks, because clicking through the webapp to get to 
a certain location takes a lot more time.

> > or makes the automatic CSRF
> > protection a lot more complicated.
>
> This one's untrue as seen in the revised proposal.

The revised proposal is not yet as usable as the current situation.

> > Also securing all requests may cost a lot
> > of performance, because more requests need to be made.
>
> This one is probably not correct either.  If the token and the tg-visit
> match, there's no extra request.  If the token and tg-visit do not
> match, there's one extra request from FAS to the database.  There are no
> extra json calls.

If one has to click through the webapp instead of clicking directly on a link, 
there are also a lot more requests. Also if one can have multiple valid 
session ids, then more need to be stored on the server.

> Or best of all, can we add some other check that allows us to preserve
> the present usability and still refuse state-changing events if they
> haven't been marked as such.

Imho this is not possible, because to refuse state-changing events, you need 
to be able to distinguish them from other events. If you have an algorithm 
for this, you can use it to mark thes events.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20081126/13bd5234/attachment.bin