Ajuda para adicionar includeSubDomains ao cabeçalho Strict-Transport-Security

Um cliente usou um scanner de segurança útil e agora acredita que o cabeçalho Strict-Transport-Security deve incluir ‘includeSubdomains’.

Adicionei ambos em 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

Nenhum deles parece funcionar. Executar o comando sed no segundo, dentro do contêiner, funciona e, após reiniciar o nginx, faz o que é solicitado.

Não entendo por que não funciona.

Além disso, isso costumava estar no template, mas parece que foi removido em 2014, mas algumas postagens recentes incluem cabeçalhos que mostram includeSubdomains lá.

Estou perplexo.

1 curtida

Hmm.. você não parece estar recebendo uma resposta aqui. Este tópico pertence a Dev ou Installation > Hosting? :thinking:

1 curtida

Bem, eu o movi para lá, mas o problema inicial é que alguém alegou que não definir includeSubDomains era uma questão de segurança.

Eu adoraria se alguém que soubesse e se importasse se ter includeSubDomains no cabeçalho STS era importante pudesse abordar a questão para que talvez eu pudesse dizer a essa pessoa que centenas de milhares de outros sites discordam e que talvez o script que alguém executou para encontrar essas “falhas de segurança” esteja errado.

Então, talvez eu devesse renomear isso para “falta de includeSubDomains no cabeçalho STS considerado prejudicial”.

2 curtidas

Eu chamaria isso de uma escolha de configuração em vez disso.

O fórum está em um domínio raiz ou não?

Eu sempre digo às pessoas que somos muito cautelosos ao definir cabeçalhos que afetam outros nomes de host em seu domínio e que, se quiserem ter HSTS nesses, devem definir os cabeçalhos nesses respectivos hosts em vez disso.

A única razão válida que consigo pensar é que eles não podem fazer isso, por exemplo, quando o fórum está em um domínio raiz e o cliente não consegue controlar os cabeçalhos HSTS em outros hosts hospedados externamente, por exemplo, eles também hospedaram shopify.example.com. Então, eles basicamente vêm até você porque você é o caminho de menor resistência :slight_smile:

2 curtidas

Não está.

É o que eu acho que pensei, embora não tenha conseguido articular.

Obrigado. Eu direi a eles que, como não é o domínio Apex, é uma Boa Prática que cada host aplique suas próprias regras.

Muito obrigado. Isso é uma grande ajuda. Pelo menos agora tenho certeza de que entendi.

2 curtidas

Este tópico foi fechado automaticamente 30 dias após a última resposta. Novas respostas não são mais permitidas.