Azuracast: nginx header change recommendations

[amavarick]

As you know I've been doing some security testing. Here are some recommended additions to the nginx header. I've tested these for impact and I haven't seen any issues. The only one I'd say needs more thought would be the X-Frame-Options. If you're uncomfortable with implementation outright, consider parameterizing these in the site settings page for the user to enable/disable. The only ones that wouldn't be a toggle yes/no would be Referrer-Policy and X-Frame-Options.

This is a good site for background on recommended header changes:
https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Headers
This is a great site to perform your own header testing:
https://securityheaders.io

Location:
/etc/nginx/sites-enabled/00-azuracast

# Highly Recommended - Sanitizes vulnerable XSS code without blocking entire page
add_header X-XSS-Protection 1;
# Controls how referrer information is handled
add_header Referrer-Policy no-referrer-when-downgrade;
# Prevents the browser from MIME-sniffing a response away from the declared content-type
add_header X-Content-Type-Options nosniff;

This next change may need some consideration regarding potential impact. I provided both options below. I am using sameorigin with no issues but I have not tested using embeded code from AzuraCast site to another site. Consider allowing user options to enable this in site settings either sameorigin or allow-from with an area to enter FQDN. If you parameterize, there are some caveats... https://tools.ietf.org/html/rfc7034#section-2.3.2.3

# Used only if not using embedded player from this site on other domains
add_header X-Frame-Options "SAMEORIGIN";
# OR
add_header X-Frame-Options "ALLOW-FROM https://subdomain.example.com/";

Consider appending the following to remove nginx version from header. Another consideration is to remove the server header altogether. Primary security benefit from this is if installed version of nginx is vulnerable in the future, the public would not be able to use a generic scanner to readily identify vulnerability.

Location:
/etc/nginx/nginx.conf
Remove '#' from existing setting
server_tokens off;

Although I have tested all of these both by:
nginx -t -c /etc/nginx/nginx.conf before implementing and by browsing the site and using the radio with the browser debugger, please don't take my word for it.

PS: Sent you another coffee...

_Thank you for re-enabling the single email address account issue. I'll be submitting another ticket for recommended php.ini settings and and another usability ticket regarding non-media uploads to station. I'm also working on a CSP recommendation but having to do ALOT of tweaking with it. I'll also be sending you an email regarding our emails from Sunday but everything looks generally very good from that testing after false-positives validated._

[SlvrEagle23]

@amavarick Thank you for the coffee! Coincidentally, a nice dose of coffee this morning has fueled a big project of mine, where I'm implementing LetsEncrypt support on the Docker installations, a hugely requested feature.

Along with those implementations, I've also added your recommended headers to both the Docker and Traditional installs. The only header I'm hesitant on is X-Frame-Options, because of the embeddability of some parts of the site, so I will leave that off for now and evaluate it later.

[amavarick]

I performed a brand new installation of traditional Ubuntu AzuraCast. I validated the headers and have questions about two of the items:

Looks like X-Frame-Options set to DENY which would disable any framing on the website altogether. Did you evaluate this further that there isn't any framing taking place to feel safe setting it to DENY?
SAMEORIGIN would be a more relaxed and recommended setting to at least allow framing from within the website. Originally it wasn't set at all.

Did you decide not to set server_tokens off to remove the nginx version?

All the other header changes look great. Attached is validation showing both http and https.

[SlvrEagle23]

@amavarick Actually, the X-Frame-Options header is being sent on a per-page basis, with a vast majority of the internal pages outright denying framing (as they should, for security purposes) and only the public-facing embeddable pages allowing it.

As for the header update, new installations will have the proper setting, and Docker installs have the updated header. It's not super practical to retroactively update that setting for existing traditional installs, and it's not a huge deal.

[amavarick]

Oh awesome! You went above and beyond by setting on a per-page basis! WOW!

Not sure I understood the response for the server_tokens? I used a brand new installation to get the validation photos above and they show 1.10.1 in the header for nginx. I think this will not close any exploits but could stop these sites from showing up in a dragnet security scan if later the installed version of nginx becomes vulnerable. A type of defense in depth by not revealing more information than we have to?

[SlvrEagle23]

@amavarick Just to let you in on my overall philosophy here: I heavily deprioritize the traditional install, as it's been nothing but a thorn in my side over the time I've been maintaining this software. A vast majority of errors that require Github issues come from the traditional installs and weird interactions with other software on the system, and were it not for a small segment of "power users" I would abandon it entirely for Docker.

With that in mind, I prioritize improvements like this on the Docker platform, as it's meant to be a "out of the box" secure and reliable solution that people can just run on their machines without any hassle or setup trouble. I want your average new user to be on the Docker platform, as I can just rebuild entire packages of software configured exactly as it needs to be for AzuraCast to work, and have people update it seamlessly any time they need to.

That's why you'll only notice the majority of these updates apply to either both or Docker only. The server_tokens update was mostly a Docker only thing, as it isn't a vulnerability at all, but rather (frankly) a "security through obscurity" thing meant to improve security by simply not saying what version of the software is running.

[amavarick]

That helps me greatly, I'll work on switching to docker install and testing with that instead.