Hi everyone:
Currently, the CSRF token for anonymous users are very predictable. This potentially allows someone to make CSRF attacks against non-logged in users. I would like to propose we change that. Since this is a sort of major change, I'd appreciate everyone's feedback.
There are multiple proposals on the bug - https://phabricator.wikimedia.org/T40417#2612673 . Its unclear which solution we should chose.
Personally, my preferred solution [0] [I might be biased in evaluating them] would be to base the CSRF token on a session cookie if one exists. If one does not exist, use a HMAC of the users IP addressed, keyed using a server side secret (The only state an Anon has is what IP address it is, so this should be safe). This way it will work for users without cookies (Maybe none exist, but I like the idea you can edit wikipedia without cookies) and for users who have rapidly changing IPs. It will also have minimal breakage, as you won't have to adjust any existing usages of tokens (For example, on special pages). It also ensures that users are not forced to skip varnish cache (from session cookie) unless they really need to.
Anyways, I'd appreciate everyone's comments. I would really like to settle on a specific implementation, and then go do it.
[0] https://phabricator.wikimedia.org/T40417#2034118
-- Bawolff
On Thu, Sep 29, 2016 at 4:00 PM, Brian Wolff bawolff@gmail.com wrote:
This way it will work for users without cookies (Maybe none exist, but I like the idea you can edit wikipedia without cookies)
There have been people who disabled cookies and still wanted to be able to use the sites.
and for users who have rapidly changing IPs.
Well, only after they manage to get a session cookie set. I see the patch there attempts to account for that by creating a session on token failure via HTMLForm, which is good, although there are other code paths that would need the same sort of thing (e.g. API token checks).
It will also have minimal breakage, as you won't have to adjust any existing usages of tokens (For example, on special pages).
Note it will affect scripts and API clients that expect to see "+" as the token as a sign that they're logged out, or worse assume that's the token and don't bother to fetch it.
On Thu, Sep 29, 2016 at 1:37 PM, Brad Jorsch (Anomie) <bjorsch@wikimedia.org
wrote:
On Thu, Sep 29, 2016 at 4:00 PM, Brian Wolff bawolff@gmail.com wrote:
This way it will work for users without cookies (Maybe none exist, but I like the idea you can edit wikipedia without cookies)
There have been people who disabled cookies and still wanted to be able to use the sites.
For the good of most, I think it would be acceptable to require a very few to enable cookies to *edit*.
It will also have minimal breakage, as you won't have to adjust any existing usages of tokens (For example, on special pages).
Note it will affect scripts and API clients that expect to see "+" as the token as a sign that they're logged out, or worse assume that's the token and don't bother to fetch it.
We had breaking API/frontend infrastructure changes before, this one seems less invasive and will break only badly written clients. In any case, most clients are intended for logged in users.
Dnia 29.09.2016 Max Semenik maxsem.wiki@gmail.com napisał/a:
Note it will affect scripts and API clients that expect to see "+" as the token as a sign that they're logged out, or worse assume that's the token and don't bother to fetch it.
We had breaking API/frontend infrastructure changes before, this one seems less invasive and will break only badly written clients. In any case, most clients are intended for logged in users.
Before this thread I believed that the "+" token was some kind of a bug (but it worked anyway, so I didn't bother digging futher).
Saper
On Thu, Sep 29, 2016 at 5:10 PM, Max Semenik maxsem.wiki@gmail.com wrote:
On Thu, Sep 29, 2016 at 1:37 PM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org
wrote: Note it will affect scripts and API clients that expect to see "+" as
the
token as a sign that they're logged out, or worse assume that's the token and don't bother to fetch it.
We had breaking API/frontend infrastructure changes before, this one seems less invasive and will break only badly written clients. In any case, most clients are intended for logged in users.
It still should be known that these will break and should be announced in the proper place (mediawiki-api-announce) and time.
On 2016-09-29 1:00 PM, Brian Wolff wrote:
Personally, my preferred solution [0] [I might be biased in evaluating them] would be to base the CSRF token on a session cookie if one exists. If one does not exist, use a HMAC of the users IP addressed, keyed using a server side secret (The only state an Anon has is what IP address it is, so this should be safe). This way it will work for users without cookies (Maybe none exist, but I like the idea you can edit wikipedia without cookies) and for users who have rapidly changing IPs. It will also have minimal breakage, as you won't have to adjust any existing usages of tokens (For example, on special pages).
Users with a rapidly changing IP will get an invalid csrf warning page before they get the session cookie they need in order to edit.
Krinkle's suggestion of having JS initiate the POST after fetching the edit token and initiating the session was an ingenious method of eliminating that notice for those users.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
wikitech-l@lists.wikimedia.org