💾 Archived View for alexey.shpakovsky.ru › gemlog › fixing-csrf-in-polls.gmi captured on 2024-08-18 at 17:14:45. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Fixing CSRF in polls (3 votes)

2022-02-12 (3 votes)

(3 votes)

Thanks to whoever anonymously posted a direct link to vote for one of options in one of my polls to geddit, and to @lykso for sending that link to me and suggesting protecting the vote links with CSRF tokens. Their post on the subject: (3 votes)

use csrf tokens (3 votes)

(3 votes)

For those who doesn't know it: CSRF stands for Cross-Site Request Forgery and is exactly what's happening here: my site (capsule) expects that only those tho have red the poll page will click the vote links, but apparently anyone else can post these links on their websites (or on geddit), with their own explanation of why you should click the link. To protect against it, CSRF tokens are used. (3 votes)

(3 votes)

Someone else can probably explain it better, but basically CSRF tokens are small random pieces of data which are generated for every visitor of this page (or any page with a poll) and appended to vote links. When you click a vote link - the voting server receives the token and checks it. This aims to ensure that only someone who really visited a page with a poll can vote in it. (3 votes)

(3 votes)

Note that I don't want to enforce using client certificates for voting for two reasons. First, my server doesn't support them. Second, I believe it will greatly decrease number of people who vote. Personally, I wouldn't show my client certificate "identity" to some random capsule just so it could record my "vote" in its silly "poll". Would you? (3 votes)

(3 votes)

Implementation details (3 votes)

(3 votes)

Tokens are 8 bytes (64 bits) output of `/dev/urandom` written in hex (so 16 characters). (3 votes)

(3 votes)

Each token is linked to the IP which opened this page (or any page with poll). When you reload this page, it keeps your old one, instead of giving you a new one. All people / devices / browsers behind the same IP get the same token. (3 votes)

(3 votes)

Above is correct for 24 hour periods (from midnight to midnight CET). Each day your IP gets a new token, which is valid for that and the following day - effectively, tokens expire 24~48 hours after being created, and your IP might have two tokens at the same time. (3 votes)

(3 votes)

One vote per IP which requested a token, voting again with same token (or a different token linked to the same IP) overwrites your previous vote. So all people behind the same IP share one vote, like before. (3 votes)

(3 votes)

I do *not* check that voting IP is the same as the one for which the token was generated (when loading the poll page) - in case some client switched from IPv4 to IPv6, or a phone reconnected from WiFi to mobile data while reading a page - they still can happily vote. (3 votes)

(3 votes)

Now a question to readers: can you find any issues / vulnerabilities here? You might notice that tokens are not invalidated and voting IP is not checked, but please try to think of a possible scenario where it can be (ab)used. (3 votes)

(3 votes)

So if an attacker gets a voting link and shares it - the link will include a token. First two days all clicks will count as a single vote, after that the token becomes invalid. (3 votes)

(3 votes)

The only attack I can imagine is an attacker asking strangers to fetch the page for them, so the attacker can vote using their tokens. I guess it's simpler just to vote through multiple TOR / VPN / IPv6 addresses, but it would require a different kind of anti-fraud system. (3 votes)

(3 votes)

Update (3 votes)

(3 votes)

I made up an imaginary attack against permanent tokens, so they are valid for two days only. In this scenario, an attacker travels around the world, connects to Internet from numerous places (using different IPs), and from each of them fetches a voting page on my capsule. After returning home attacker has a bunch of forever-valid tokens to vote in any of my polls, attributing the votes to these places. (3 votes)

(3 votes)

With tokens being valid for two days only, the attacker will have to travel around the world every two days. (3 votes)

(3 votes)

End of update (3 votes)

(3 votes)

Poll: your opinion? (3 votes)

(3 votes)

Your explanation of CSRF tokens is bad (2 votes) (3 votes)

Your explanation of CSRF tokens is good (5 votes) (3 votes)

You're doing it right (3 votes) (3 votes)

You're doing it wrong (4 votes) (3 votes)

Your poll "security" is weak (3 votes) (3 votes)

Your poll security is strong (2 votes) (3 votes)

Consider this poll hacked (1 vote) (3 votes)

Your polls are unhackable (0 votes) (3 votes)

I don't use client certificates at all (4 votes) (3 votes)

I don't use client certificates for random capsules (0 votes) (3 votes)

You're wrong, client certificates are the only proper way! (1 vote) (3 votes)

Right now I'm travelling around the world, voting for this option from each city I'm visiting (6 votes) (3 votes)

(3 votes)

Privacy warning: your IP is already logged. You can change your vote by voting second time. To remove your IP from logs or vote for multiple items, write me an email. (3 votes)