CSRF Refer Header fails when enabling httpS (TLS)

[webmas...@gmail.com]

I'm running my own instance over here: https://reviews.melroy.org

I use Nginx as my reverse proxy together with the beanbag/reviewboard:4.0 docker image. I use Let's Encrypt to create a TLS certificate for this sub-domain. So far so good. However, I noticed I could not set HTTPS via environment variable (only setting host name, without protocol).

I need to change the setting to HTTPS, since otherwise I could not publish a review by pressing the button. Causing mixed content issues:

So I changed my server URL in the admin panel from http://reviews.melroy.org towards https://reviews.melroy.org (so with TLS).

However, now I can't login anymore, I will get a CSRF issue :(. I think I configured everything correctly.. See error:

(I enabled Debug so you get the help message as well)

I'm using my local Nginx server (with the same configuration as here: https://github.com/reviewboard/reviewboard/blob/master/contrib/docker/examples/nginx_templates/reviewboard.conf.template#L11). Of-course some changes to the port, location where required. But I did not change the Nginx "location" sections.

Regards, Melroy

[webmas...@gmail.com]

See attachment for the full size images!

Op zondag 13 februari 2022 om 00:31:56 UTC+1 schreef webmas...@gmail.com:

[webmas...@gmail.com]

Ps. The only way back was to go to my MySQL database.

Selecting the "siteconfig_siteconfiguration" table -> first record (ID: 1). And change the "site_domain_method" setting from "https" back to "http".

Restarting Reviewboard manually.

Op zondag 13 februari 2022 om 00:32:57 UTC+1 schreef webmas...@gmail.com:

[Christian Hammond]

That's strange. So, if that diagnostic message is correct, then the browser didn't send a Referer header in the request.

Can you re-enable debug and HTTPS, open the browser's developer tools -> Network tab, and then attempt a full login attempt using these steps:

1. Navigate to https://reviews.melroy.org

2. Click the Login link.

3. Attempt the login again.

See if you get the same error this time, and if so, show me what's in the Network tab's Request Headers for that POST operation.

Christian

--
Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups "Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/reviewboard/24f31104-1d84-4489-a094-989ea80d3c12n%40googlegroups.com.

--

Christian Hammond

President/CEO of Beanbag

Makers of Review Board

[webmas...@gmail.com]

> then the browser didn't send a Referer header in the request.

I'm pretty sure my browser is sending a referer header I think, since I did not disable that in Firefox. I also tried Chrome, same issue. I really think that Review board docker image can't handle HTTPS.

Anyway, I enable HTTP again as you asked (notice the https:// in the server url setting):

I'm now still logged in as admin, so far so good:

Now I logged OUT. And try to log-in again.... :( :( As expected, I can't login anymore (I will keep this configuration live now for your testing):

Op zondag 13 februari 2022 om 02:21:26 UTC+1 schreef Christian Hammond:

[webmas...@gmail.com]

See attachment of the HTTP POST login request in HAR format.

Op dinsdag 15 februari 2022 om 21:59:15 UTC+1 schreef webmas...@gmail.com:

[webmas...@gmail.com]

I did notice the no-referrer setting on the "referrer-policy" on the response headers. Maybe the nginx config is wrong??

Op dinsdag 15 februari 2022 om 22:01:28 UTC+1 schreef webmas...@gmail.com:

[webmas...@gmail.com]

Aha! In my global Nginx "security.conf" file (so out-side of the , I have the following setting ("add_header Referrer-Policy "no-referrer" always;"):

    [....]
    # Don't allow the browser to render the page inside an frame or iframe and avoid clickjacking
    add_header X-Frame-Options "SAMEORIGIN" always;
    # Enable the Cross-site scripting (XSS) filter built into most recent web browsers.
    add_header X-XSS-Protection "1; mode=block" always;
    # When serving user-supplied content, include a X-Content-Type-Options: nosniff header along with the Content-Type: header,
    # to disable content-type sniffing on some browsers.
    add_header X-Content-Type-Options "nosniff" always;
    # Referrer Policy will allow a site to control the value of the referer header in links away from their pages.
    add_header Referrer-Policy "no-referrer" always;
    [....]

This is for security reasons, I think I should override the referrer-policy for review board. Review board is the only app/website that breaks on this setting. I host GitLab, Nextcloud and much more services without any issues with the above Nginx settings.

Should I set it to "strict-origin"?

Op dinsdag 15 februari 2022 om 22:06:35 UTC+1 schreef webmas...@gmail.com:

[webmas...@gmail.com]

I set the reviewboard Nginx server config to:

   add_header Referrer-Policy "strict-origin-when-cross-origin";

I advice to also include this explicit "add_header" in all your Nginx templates & examples. (including the docker template).

I also advice to look for alternatives :). So the login can continue even without referrer header.

Op dinsdag 15 februari 2022 om 22:12:42 UTC+1 schreef webmas...@gmail.com:

[Christian Hammond]

Glad you found the cause! We'll make a note to update the docs.

Referrer headers are part of how CSRF checks operate. As part of CSRF checks, the server needs to make sure the request didn't come from a third-party server on behalf of the user. Some software is vulnerable to attacks involving removing the Referer header to bypass CSRF checks, but Review Board is strict about it (technically, Django is strict about it). For a CSRF check to pass, the user must have received a cookie from the page (which is one part of the check) and the request performing the operation must have also 1) come from the server issuing the cookie/serving the page, and 2) using HTTPS (to avoid a man-in-the-middle attack).

We will need to continue to require it for security purposes.

Christian

To view this discussion on the web visit https://groups.google.com/d/msgid/reviewboard/910de235-3b9c-4bf6-8338-a2e704f0ae39n%40googlegroups.com.