If I visit www.evil.example.com and it posts a form submission to http://localhost:8080/delete-all-my-repos-api-call, will syncthing ignore it?
1 Like
It won’t, if no authentication is used, or if the user has authenticated in the same browser sessions. I think this is really CSRF, possible enabled by an XSS vulnerability on the attacker site. I wasn’t clear on the difference myself–which is usually a bad sign–and sure enough syncthing seems vulnerable against both.
This needs to be fixed.
I’m going to add a “standard” CSRF protection mechanism; when initially loading the GUI a cookie is set with a random token. This random token must be passed back to the REST interface for the request to be accepted.
@Nutomic I’ll also add an API key like thing for use by machines, such as the Android UI and for using curl from the terminal etc. I’m thinking an <apikey>ABCDEFG...</apikey> thing in the <gui> section of the config, that you would set when initially generating the config. Thereafter, REST requests with an X-API-Key: ABCDEFG... header would be allowed without further authentication.
Generating a new API key will be possible from within the settings dialog. I’m not sure what to about that for the Android case, it’s just one of those things that’s perhaps not recommended for the user to change…?
So the API key is generated by the Android app on first start? Then why would there be a setting to generate it from the settings, too? What length/characters would you use for the key?
Also, I’m currently implementing a native gui using the Rest API, so the web interface won’t usually be used. And the new API key will only be checked for on restart, right?
Because the Android app is not the only consumer. For someone that wants to be able to POST data in with curl or from another site, they need to be able to easily generate and see the API key.
As for length etc, I imagine something like 40 characters of base64 or so.
Sounds cool. You’ll need to add the API key header to each request.
Right, though it could be readonly (with a “generate” button if it doesn’t exist).
Yeah of course.
Read only as in the only way to change it (in the GUI) is the “Generate” button, sure. But the user needs to be able to regenerate at will (to invalidate any existing things that might use it, for example).
Alright, but I don’t really care as long as it’s only applied on startup (I would read it from config.xml before starting).