Hulp bij het toevoegen van includeSubDomains aan de Strict-Transport-Security header

Installatie Hosting
1

Een klant heeft een handige beveiligingsscanner gebruikt en gelooft nu dat de Strict-Transport-Security header ‘includeSubDomains’ moet bevatten.

Ik heb beide toegevoegd aan de app.yml:


  after_ssl:
    - replace:
        filename: /etc/nginx/conf.d/outlets/server/20-https.conf
        from: "max-age=31536000;"
        to:  "max-age=31536000; includeSubDomains;"
    - replace:
        filename: /etc/nginx/conf.d/outlets/discourse/20-https.conf
        from: "max-age=31536000;"
        to:  "max-age=31536000; includeSubDomains;"

- exec: sed -i "s/add_header Strict-Transport-Security 'max-age=31536000';/add_header Strict-Transport-Security \"max-age=31536000; includeSubDomains\" always;/" /etc/nginx/conf.d/outlets/discourse/20-https.conf /etc/nginx/conf.d/outlets/server/20-https.conf

Geen van beide lijkt te werken. Het uitvoeren van het sed commando in de tweede op de container werkt en na het herstarten van nginx, doet wat gevraagd wordt.

Ik begrijp niet waarom het niet werkt.

Ook zat dit vroeger in de template, maar het lijkt erop dat het in 2014 is verwijderd, maar sommige recente posts bevatten headers die de includeSubDomains erin laten zien.

Ik ben er stomverbaasd over.

1 like
2

Hmm.. you don’t seem to be getting an answer here. Does this topic belong in Dev or Installation > Hosting? :thinking:

1 like
3

Well,l I moved it there, but the initial issue is that someone claimed that not setting includeSubDomains was a security issue.

I’d love it if someone who knew and cared about whether having IncludeSubDomains in the the STS header was important could address the issue so perhaps I could tell this person that hundreds of thousands of other sites disagree and that perhaps the script that someone ran to find these “security flaws” is wrong.

So maybe I should rename this “missing includeSubDomains in STS header considered harmful”

2 likes
5

I would call it a configuration choice instead.

Is the forum on an apex domain or not?

I always tell people that we are very cautious of setting headers that affect other hostnames on their domain, and if they want to have HSTS on those, they should set the headers on those respective hosts instead.

The only valid reason I can think of is they cannot do that, e.g. when the forum is on an apex domain and the client is not able to control the HSTS headers on other externally hosted hosts, e.g. they have hostedshopify.example.com as well. Then they basically come to you because you’re the path of least resistance :slight_smile:

2 likes
6

It is not.

That’s what I think I thought, though I wasn’t able to articulate it.

Thanks. I’ll tell them that since it’s not the Apex domain it’s Best Practice to have each host enforce its own rules.

Thanks so very much. This is a big help. At least now am pretty sure thatI understand.

2 likes
7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.