Page MenuHomePhabricator

SecurePoll should reject votes with CSRF issues
Open, Needs TriagePublic

Description

Cross-site request forgery is a risk to SecurePoll for reasons described in that link. However, the signal could be caused by benign issues like token timeouts, and this leads to confusion for scrutineers (see the recent task T426370, but it has certainly come up before).

I would recommend implementing a check for CSRF and just rejecting the vote immediately, asking the user to re-submit. This assumes CSRF is flagged immediately on submission of the vote and I'm not sure if that is the case.

See also work done in the recent past on this and other SecurePoll issues: T392341: CVE-2025-53483, CVE-2025-53484, CVE-2025-53485: SecurePoll is vulnerable to XSS, CSRF, and lack of authorisation

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

I think we can make this ticket public. The fact that securepoll can detect csrf abnormalities is not a secret and can be found in our public source code. And i don't think there's an exploit here, just a proposal to get rid of a not very helpful scrutineering signal by changing/improving the design.

I think we can make this ticket public. The fact that securepoll can detect csrf abnormalities is not a secret and can be found in our public source code. And i don't think there's an exploit here, just a proposal to get rid of a not very helpful scrutineering signal by changing/improving the design.

I'm personally fine with this being public.

Yep fine with me. I was just being overly cautious :)

Catrope changed the subtype of this task from "Security Issue" to "Task".
Catrope changed the visibility from "Custom Policy" to "Public (No Login Required)".
Catrope changed the edit policy from "Custom Policy" to "All Users".