Before this get's lost in the other noise on this thread, I wanted to address the MediaWiki specific pieces.
On Fri, Aug 16, 2013 at 5:04 PM, Zack Weinberg zackw@cmu.edu wrote:
All cookies should be tagged both Secure and HttpOnly (which renders them inaccessible to accidental HTTP loads and to page
They are (if you login over https). Except for a generic one which indicates you should be redirected to HTTPS if it's received on an HTTP connection.
JavaScript); now would also be a good time to prune your cookie requirements, ideally to just one which does not reveal via inspection whether or not someone is logged in.
I'm not sure what attack you're preventing here. Can you elaborate? If they are logging in over HTTPS, their cookies shouldn't be visible to a network-based attacker. If their cookies are visible to a network-based attacker, then the attacker can probably get their username from their login. Also, since edits show up in the history, correlating any edit action to the editor's name is trivial, even without the cookies.
You should also do Content-Security-Policy, as strict as possible. I know this can be a huge amount of development effort, but the benefits are equally huge - we don't know exactly how it was done, but there's an excellent chance CSP on the hidden service would have prevented the exploit discussed here: https://blog.torproject.org/** blog/hidden-services-current-**events-and-freedom-hostinghttps://blog.torproject.org/blog/hidden-services-current-events-and-freedom-hosting
A strong CSP is #3 on my most-wanted list of security features (after https and better password hashing). However, that would likely limit things like editors adding css into their edits, which is pretty controversial.