Trac CSRF exploit

If you were logged into the targeted web site, and your browser executes the javascript in the onload of the targeted iframe, it will cause you (as your authenticated account) to post a note to the relevant ticket saying I got burned by this exploit., elevating the priority to high, severity to critical, and adding the security keyword if none exists already.

Things to note about this exploit:

• the iframe itself is irrelevant. i enclose it in an iframe so that you can read this text and consider it. I could have made the link you clicked on to get here go directly to the contents of the iframe, and the results would be the same.
• the fact that the exploit is triggered with javascript is nearly as irrelevant. The only thing the javascript does is submit a form. Had i been able to convince you to click any link or image on a site i control, that link or image could have been a camouflaged submit button for the same form.
• I am only doing a simple TICKET_APPEND with the form at the moment. Since this is a POST submission that is triggered, there is nothing stopping me from doing a range of other attacks based on your authenticated privilege level on the targeted trac installation. If you have permission TICKET_ADMIN i could have used it to remove whatever ticket i wanted, WIKI_DELETE i could have deleted wiki pages, etc.

  I believe is all possible even in spite of changeset 1701, which was a good first pass at at some earlier CSRF vulnerabilities.

• The only proper way that i can see to avoid this is a bit cumbersome to implement, but shouldn't be noticed by the typical user. It takes a couple steps:
  1. Generate a secret (or secrets) on the trac server, and store them in the database. You may want to make a rotating stack of secrets, so that you can expire them smoothly as they grow old.
  2. Each time a form is presented to an authenticated user, take a strong hash of the concatenation of the user's current authentication token (probably their session cookie) with the most recent secret, and emit the hash as a hidden variable in the generated form.
  3. Upon receipt of a POST that requires an authenticated user: in addition to checking the user's cookie, check that a valid hash is present that matches that user's auth token and one of the active server-side secrets.
• A possible shortcut for the near term would simply be to require that HTTP_REFERER is set to the hostname (at least!) of the originating site, if not the full path for the expected form page where this was generated. This is not a complete solution, because some browsers muck around with referrers (e.g. always set the referrer identical to the requested page, or always pass an empty referrer). Since HTTP doesn't require HTTP_REFERER (and those values are generated from the client's browser) this is not trustworthy data anyway.

You can contact me about this exploit at dkg-trac (at) fifthhorseman.net, or at the ticket i filed about this on trac's own trac installation.

More details about CSRF attacks:

• Security Tips for Web Developers
• Foiling Cross-Site attacks (latter half of the page).