Remove security issue: host injection warning (by adding ALLOWED_HOSTS)

[vmario89]

I was warned by a Pen Tester:

"Hello there, I found a Host Header Injection security hole, in simple terms Host Header Injection is a weakness where users can change or redirect to any host, this will have an impact if the website has features such as Password Reset, Registration, and features that send emails or the like, My advice for the future when developers create web applications, do validation on the Host header so that it cannot be manipulated.

Title: Host Header Poisoning Type: Injection / Missconfiguration

Proof of concept

1. I did subdomain enumeration and got the owc website subdomain
2. When making a GET request to the website I intercept the request using the Burp Suite tool and then change the Host header to evil.com
3. Then the website redirects to the evil.com website, and all source domains change to evil.com

• https://portswigger.net/web-security/host-header
• https://hackerone.com/reports/1098948"

[niccokunzmann]

Thanks!

I am checking:

• [x] What is the error on the user-side when you open it with another domain?

• [x] How to configure multiple hosts? Do we need .split(",")?

• [x] Is the default behaviour changed now? What if the environment variable is not given?

  I will contribute a few changes:

• [x] default value is None or empty string at the moment, should be "localhost:5000" or anything that helps develop it

• [x] change documentation for hosting

• [x] change docker example

• [x] change dev setup

• [x] increase version number to '2.0' if this is a major API change

• [x] mention this in the changelog

• [x] Change the hosted version to include the hostname

• [x] How can we test this? - Answer: Just not do it at the moment.

[niccokunzmann]

Tests run.

[niccokunzmann]

Cool!

[niccokunzmann]

I wonder: Would it be best to set a default value and alert hosters to set a proper value? The default should be safe, I think. What is your take on this?

[niccokunzmann]

@vmario89 Thank you very much! I released your changes with modification to the documentation! They should be live soon.

[gary600]

Just checking, was it intended for this change to make the official host for this project (https://open-web-calendar.hosted.quelltext.eu/) show the 403 Forbidden message? Just clicking on the link in the readme shows it, and all of my embeds of it do too.

[niccokunzmann]

I corrected that... I still do not know which host is actually in use:

The request goes through the nginx-proxy-manager to the open-web-calendar

[mikitsu]

I'd like to question the applicability of this. The first sentence of the linked info page under "How to prevent..." says

To prevent HTTP Host header attacks, the simplest approach is to avoid using the Host header altogether in server-side code.

As far as I can tell, the Host header isn't used anywhere.

That aside, a typical setup will probably have a properly-configured reverse proxy in front which (as it routes based on virtual hosts) should only forward traffic with a correct Host header.

[niccokunzmann]

That aside, a typical setup will probably have a properly-configured reverse proxy in front which (as it routes based on virtual hosts) should only forward traffic with a correct Host header.

That is true, I think.

As far as I can tell, the Host header isn't used anywhere.

Thanks for looking though the code and being reassured :)

I do not judge how people use the Open Web Calendar (OWC) though. Maybe, this is a use-case for some people. I.e. if the OWC is the first service to go up on a Raspberry Pi in a local network. Also, I tested this and the submitted code only works on localhost for me: #371and https://github.com/riad-azz/flask-allowedhosts/issues/2

The default at the moment is to ignore this configuration possibility.