CSRF Protection: Should I use CSRF Tokens or API key?

General
1

Hi there.

I could use some help with the CSRF protection. Since the upgrade to v0.13, my Gnome Shell Extension for Syncthing cannot fetch the folder list from Syncthing any more. I opened a GitHub issue here.

Now my first question: Why is that? It only uses GET request, not a single POST. I thought that GET requests are not shielded by the CSRF protection.

Anyhow. If that is going to stay this way, I need to fix this. And for that there seem to be two possibilities:

  1. Read the API key from ~/.config/syncthing/config.xml and use that to issue the GET requests. This should be quite simple and I suppose this will just work.

  2. Use CSRF Tokens. I suppose this is what the official Web UI currently does? I don’t find much information about this in the docs. How would I do this?

And finally: Which of the two possibilities is the “right way” to do it?

Thank you.

2

There was a security issue around this (CORS wasn’t set up correctly, so someone could fetch the config from a different origin, parse the API key out of it, then use it to POST). The whole API was therefore secured as a precautionary measure.

If you’re using the API, you should be using the API key. This will also cover the case where someone has enabled authentication on Syncthing’s web UI.

If you’re starting Syncthing yourself, you can specify the API key to use on the command line. Otherwise I would suggest getting the user to copy the API key from Syncthing’s web interface and pasting it into some configuration for your shell extension. Parsing the config file is possible, but remember that 1) the user may have decided to put Syncthing’s home folder somewhere custom, and 2) the format may change at any time.

1 Like
3

Alright. I will try to read the API key from the config file and make an optional configuration option for the user to specify the API key by hand.

Thank you for the quick help.:+1:

Nevertheless… I am still interested how the CSRF Tokens work exactly, and why the WebUI is using them (if it actually is) if it is a better idea to use API keys.

4

The web ui has no way to get it’s hand on the API key. You could probably hit “/” and get the CSRF token from the cookie, and use that if thats easier for you.

5

See Wikipedia.

You’ve got it the wrong way around: an API key is arguably more secure than a CSRF token. The thing is, you can’t expect the user to input a code every time their browser makes a request (which can be several times as second), so alternatives have to be found :smile:

An API key is also a lot easier for an application to use.

This won’t work if the user’s enable authentication…?

6

True.

7

Also, see Proposal for hashing API keys.

Reading the API key out of the config probably won’t be supported for much longer, although there may be an alternative means to ask Syncthing to give you an API key, without requiring any user interaction.

8

Yes, I already noticed the thread about hashing API Keys. I will try to adapt to the new system once it’s there and it does some changes breaking my extension.