Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add basic CSRF protection to built-in HTTP server #164

Merged
merged 1 commit into from
Feb 11, 2024

Conversation

jpovixwm
Copy link
Contributor

@qu1ck
Copy link
Member

qu1ck commented Feb 11, 2024

This is a very weak barrier, all one has to do to circumvent it is to pass another content-type header. If someone knows the port and request path to attack, they will set the header too.

I think what is more worth protecting are the /post and /torrentget paths because it's possible to trigger large downloads and clog the app resources with them.

This can be prevented by generating a random key on every app startup that the backend will send to frontend via event system. Frontend then should pass it back with every request for verification. It's impossible to protect /args the same way because in that case different processes are communicating.

@jpovixwm
Copy link
Contributor Author

This is a very weak barrier, all one has to do to circumvent it is to pass another content-type header.

Hence the "basic" in the title, but the idea is that browsers will automatically issue a preflight request if Content-Type is set to anything other than application/x-www-form-urlencoded, multipart/form-data or text/plain. The preflight request will fail due to CORS, and the actual POST request will not be sent by the browser at all.
Of course this won't have any effect for attacks not originating from a web browser, such as another process running locally, or for same-origin requests (i.e. if there was an XSS vulnerability in the frontend or when using TrguiNG as a web interface while simultaneously hosting transmission-daemon behind a reverse proxy together with another XSS-vulnerable or malicious web app).

But I'd say "visiting a random website" has by far the largest attack surface, and just validating the Content-Type is quite effective. This StackOverflow question, among others, has some further info: https://stackoverflow.com/questions/11008469/are-json-web-services-vulnerable-to-csrf-attacks

I agree that a proper CSRF token is eventually the way to go, but for the time being this is better than nothing.

@qu1ck qu1ck merged commit ea69a07 into openscopeproject:master Feb 11, 2024
3 checks passed
@qu1ck
Copy link
Member

qu1ck commented Feb 11, 2024

You are right, I didn't think about potential attacks from other sites being weeded out due to preflight request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants