Use a token for CSRF protection, not referer.

[omeryagmurlu]

Suggestion

Currently qBittorrent checks referer to make sure no CSRF occurs. This is fine for most cases, but completely disallows using qBittorrent behind an HTTP proxy like nginx in a secure (regarding CSRF) manner. You either have to drop the referer to bypass qbt’s csrf protection, or disable it in qbt preferences altogether, which is bad, in order to proxy qbt.

Transmission uses tokens for csrf protection with the header X-Transmission-Session-Id:

2.3.1 CSRF protection

Most Transmission RPC servers require a X-Transmission-Session-Id header to be sent with requests, to prevent CSRF attacks.

When your request has the wrong id -- such as when you send your first request, or when the server expires the CSRF token -- the Transmission RPC server will return an HTTP 409 error with the right X-Transmission-Session-Id in its own headers.

So, the correct way to handle a 409 response is to update your X-Transmission-Session-Id and to resend the previous request

from https://github.com/transmission/transmission/blob/9bf2918ad09ee6c89e105adfb865d9130f987bed/docs/rpc-spec.md#231-csrf-protection

By passing this header through the proxy, one can use Transmission behind a proxy with working CSRF protection. I would like to see qBittorrent switch to token based csrf protection too.

See also this question from stackoverflow: https://stackoverflow.com/questions/1413930/is-checking-the-referrer-enough-to-protect-against-a-csrf-attack

Use case

Security is important

Extra info/examples/attachments

No response

[Chocobo1]

There is a Server domains: text input box in Options. Doesn't it help?

This is fine for most cases, but completely disallows using qBittorrent behind an HTTP proxy like nginx in a secure (regarding CSRF) manner.

Not true, as long as you provide X-Forwarded-Host & X-Forwarded-For correctly it should work fine, see: https://github.com/qbittorrent/qBittorrent/wiki/NGINX-Reverse-Proxy-for-Web-UI

[omeryagmurlu]

That only works as long as you directly enter the url and navigate to it directly. If you want to use a dashboard or something similar, it fails and shows unauthorized.

[Chocobo1]

That only works as long as you directly enter the url and navigate to it directly. If you want to use a dashboard or something similar, it fails and shows unauthorized.

Yes that is intended. Embedding built-in webUI into other pages is specifically not supported use case, and you should disable related webui protections if you want to go that way.

[omeryagmurlu]

I'm not talking about embedding anything, the webui shows unauthorized if linked to from another page. Nothing is embedded anywhere, it's just a single link, which affects the referer (qbittorrent and where I'm linking from are on different Subdomains) and trips csrf protection unnecessarily

…

On Wed, Aug 24, 2022, 12:35 Chocobo1 ***@***.***> wrote: That only works as long as you directly enter the url and navigate to it directly. If you want to use a dashboard or something similar, it fails and shows unauthorized. Yes that is intended. Embedding built-in webUI into other pages is specifically not supported use case, and you should disable related webui protections if you want to go that way. — Reply to this email directly, view it on GitHub <#17598 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6SKSHEJPBHGH2S23RKSUTV2X3IPANCNFSM57NI3DOQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[KonRay]

+1. Remote Torrent Adder didn't work for me until I disabled CSRF protection.

[coanghel]

Just chiming in that I see the same issue: directly accessing the WebUI reverse proxy at qbittorrent.my.domain works fine, but if I try to hit a link with the same embedded in a dashboard it trips the CSRF. That definitely feels unintended.