Помощь в добавлении includeSubDomains в заголовок Strict-Transport-Security

Поддержка Самостоятельное хостинг
1

Клиент использовал полезный сканер безопасности и теперь считает, что заголовок Strict-Transport-Security должен включать параметр «includeSubdomains».

Я добавил оба этих пункта в 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

Ни один из вариантов не работает. Выполнение команды sed из второго блока внутри контейнера работает, и после перезапуска nginx результат соответствует ожидаемому.

Я не понимаю, почему это не срабатывает.

Кроме того, это ранее присутствовало в шаблоне, но, похоже, было удалено в 2014 году, однако в некоторых недавних публикациях встречаются заголовки, где указан includeSubdomains.

Я в тупике.

1 лайк
2

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

1 лайк
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 лайка
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 лайка
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 лайка
7

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