Personalizar cabeçalhos de resposta de segurança HTTP com o AD FS 2019
Os Serviços de Federação do Active Directory (AD FS) 2019 adicionam a funcionalidade para personalizar os cabeçalhos de resposta de segurança HTTP enviados pelo AD FS. Essas ferramentas ajudam os administradores a se protegerem contra vulnerabilidades de segurança comuns e permitem que eles aproveitem os mais recentes avanços nos mecanismos de proteção baseados em navegador. Esse recurso vem da introdução de dois novos cmdlets: Get-AdfsResponseHeaders e Set-AdfsResponseHeaders.
Observação
A funcionalidade para personalizar os cabeçalhos de resposta de segurança HTTP (exceto cabeçalhos CORS) usando cmdlets: Get-AdfsResponseHeaders e Set-AdfsResponseHeaders voltou a ser suportada no AD FS 2016. Você pode adicionar a funcionalidade ao AD FS 2016 instalando o KB4493473 e o KB4507459.
Esse artigo discute os cabeçalhos de resposta de segurança comumente utilizados para demonstrar como personalizar os cabeçalhos enviados pelo AD FS 2019.
Observação
O artigo pressupõe que o AD FS 2019 tenha sido instalado.
Cenários
Os cenários a seguir demonstram a necessidade que os administradores podem ter para personalizar os cabeçalhos de segurança.
- Um administrador habilitou o HTTP Strict-Transport-Security (HSTS) para proteger os usuários que podem acessar o aplicativo Web usando o HTTP de um ponto de acesso Wi-Fi público que pode ser hackeado. O HSTS força todas as conexões a usar a criptografia HTTPS. Eles gostariam de reforçar ainda mais a segurança habilitando o HSTS para subdomínios.
- Um administrador configurou o cabeçalho da resposta X-Frame-Options para proteger as páginas da Web contra clickjacking. X-Frame-Options impede a renderização de qualquer página da Web em um iFrame. No entanto, eles precisam personalizar o valor do cabeçalho devido a um novo requisito de negócios para exibir os dados (no iFrame) de um aplicativo com uma origem diferente (domínio).
- Um administrador habilitou o X-XSS-Protection para higienizar e bloquear a página se o navegador detectar ataques de cross scripting. A proteção X-XSS evita ataques de cross scripting. Entretanto, eles precisam personalizar o cabeçalho para permitir que a página seja carregada após a higienização.
- Um administrador precisa habilitar o Compartilhamento de Recursos entre Origens (CORS) e precisa definir a origem (domínio) no AD FS para permitir que um aplicativo de página única acesse uma API da Web com outro domínio.
- Um administrador habilitou o cabeçalho da Política de Segurança de Conteúdo (CSP) para evitar ataques de cross-site scripting e injeção de dados, não permitindo solicitações entre domínios. No entanto, devido a um novo requisito de negócios, eles precisam personalizar o cabeçalho para permitir que a página da Web carregue imagens de qualquer origem e restrinja a mídia a provedores confiáveis.
Cabeçalhos de resposta de segurança HTTP
O AD FS inclui os cabeçalhos de resposta na resposta HTTP da saída enviada por um navegador da Web. Você pode listar os cabeçalhos utilizando o cmdlet Get-AdfsResponseHeaders, conforme mostrado na captura de tela a seguir.
O atributo ResponseHeaders na captura de tela identifica os cabeçalhos de segurança incluídos pelo AD FS em cada resposta HTTP. O AD FS envia os cabeçalhos de resposta somente se ResponseHeadersEnabled estiver definido como True (valor padrão). O valor pode ser definido como False para impedir que o AD FS inclua qualquer um dos cabeçalhos de segurança na resposta HTTP. Entretanto, essa configuração não é recomendada. Você pode definir ResponseHeaders como False com o comando a seguir:
Set-AdfsResponseHeaders -EnableResponseHeaders $false
HSTS (HTTP Strict-Transport-Security)
O HTTP Strict-Transport-Security (HSTS) é um mecanismo de política de segurança da Web que ajuda a mitigar ataques de downgrade de protocolo e sequestro de cookies para serviços que possuem pontos de extremidade HTTP e HTTPS. Permite que os servidores web declarem que os navegadores Web, ou outros agentes de usuário compatíveis, só devem interagir com ele usando HTTPS e nunca através do protocolo HTTP.
Todos os pontos de extremidade do AD FS para o tráfego de autenticação na Web são abertos exclusivamente via HTTPS. Como resultado, o AD FS reduz efetivamente as ameaças que o mecanismo de política HTTP Strict Transport Security oferece. Normalmente, não há downgrade para HTTP, pois não há ouvintes em HTTP. O cabeçalho pode ser personalizado definindo os seguintes parâmetros:
- max-age=<expire-time>. O tempo de expiração (em segundos) especifica por quanto tempo o site deverá ser acessado somente usando HTTPS. O valor padrão e recomendado é 31.536.000 segundos (um ano).
- includeSubDomains. Esse parâmetro é opcional. Se especificada, a regra HSTS também se aplica a todos os subdomínios.
Personalização HSTS
Por padrão, o cabeçalho está habilitado e max-age está definido como um ano; no entanto, os administradores podem modificar max-age (não é recomendável reduzir o valor da idade máxima) ou habilitar o HSTS para subdomínios através do cmdlet Set-AdfsResponseHeaders.
Set-AdfsResponseHeaders -SetHeaderName "Strict-Transport-Security" -SetHeaderValue "max-age=<seconds>; includeSubDomains"
Exemplo:
Set-AdfsResponseHeaders -SetHeaderName "Strict-Transport-Security" -SetHeaderValue "max-age=31536000; includeSubDomains"
Por padrão, o cabeçalho está incluído no atributo ResponseHeaders; no entanto, os administradores podem remover o cabeçalho através do cmdlet Set-AdfsResponseHeaders.
Set-AdfsResponseHeaders -RemoveHeaders "Strict-Transport-Security"
X-Frame-Options
O AD FS, por padrão, não permite que aplicativos externos utilizem iFrames ao realizar uma entrada interativa. Essa configuração impede determinados estilos de ataques de phishing. A entrada não interativa pode ser realizada através do iFrame devido à segurança de nível de sessão anterior que foi estabelecida.
Entretanto, em alguns casos raros, você pode confiar em um aplicativo específico que exija uma página de entrada interativa do AD FS com capacidade para iFrame. O cabeçalho X-Frame-Options é utilizado para essa finalidade.
Esse cabeçalho de resposta de segurança HTTP é usado para se comunicar com o navegador, se puder renderizar uma página em um <quadro>/<iframe>. O cabeçalho pode ser definido como um dos valores a seguir:
- negar. A página em um quadro não é exibida. Essa é a configuração padrão e recomendada.
- sameorigin. A página só é exibida no quadro se a origem for a mesma que a origem da página da web. A opção não é útil a menos que todos os ancestrais também estejam na mesma origem.
- allow-from <origem especificada>. A página só será exibida no quadro se a origem (por exemplo,
https://www.".com) corresponder à origem específica no cabeçalho. Alguns navegadores podem não ter suporte para essa opção.
Personalização do X-Frame-Options
Por padrão, o cabeçalho está definido para negar; no entanto, os administradores podem modificar o valor através do cmdlet Set-AdfsResponseHeaders.
Set-AdfsResponseHeaders -SetHeaderName "X-Frame-Options" -SetHeaderValue "<deny/sameorigin/allow-from<specified origin>>"
Exemplo:
Set-AdfsResponseHeaders -SetHeaderName "X-Frame-Options" -SetHeaderValue "allow-from https://www.example.com"
Por padrão, o cabeçalho está incluído no atributo ResponseHeaders; no entanto, os administradores podem remover o cabeçalho através do cmdlet Set-AdfsResponseHeaders.
Set-AdfsResponseHeaders -RemoveHeaders "X-Frame-Options"
X-XSS-Protection
Esse cabeçalho de resposta de segurança HTTP é usado para impedir o carregamento de páginas da Web quando os navegadores detectam ataques de cross-site scripting (XSS). Essa abordagem é chamada de filtragem de XSS. O cabeçalho pode ser definido como um dos valores a seguir:
- 0 desabilita a filtragem de XSS. Não recomendado.
- 1 habilita a filtragem de XSS. Se um ataque de XSS for detectado, o navegador higienizará a página.
- 1; mode=block habilita a filtragem de XSS. Se um ataque de XSS for detectado, o navegador impedirá a renderização da página. Essa é a configuração padrão e recomendada.
Personalização da proteção X-XSS
Por padrão, o cabeçalho é definido como 1; mode=block;. Entretanto, os administradores podem modificar o valor através do cmdlet Set-AdfsResponseHeaders.
Set-AdfsResponseHeaders -SetHeaderName "X-XSS-Protection" -SetHeaderValue "<0/1/1; mode=block/1; report=<reporting-uri>>"
Exemplo:
Set-AdfsResponseHeaders -SetHeaderName "X-XSS-Protection" -SetHeaderValue "1"
Por padrão, o cabeçalho é incluído no atributo ResponseHeaders; no entanto, os administradores podem remover o cabeçalho através do cmdlet Set-AdfsResponseHeaders.
Set-AdfsResponseHeaders -RemoveHeaders "X-XSS-Protection"
Cabeçalhos CORS (Compartilhamento de Recurso entre Origens)
A segurança do navegador da Web impede que uma página da Web faça solicitações entre origens iniciadas de dentro de scripts. Entretanto, talvez você queira acessar recursos em outras origens (domínios). O CORS (Compartilhamento de Recursos entre Origens) é um padrão W3C que permite ao servidor relaxar a política de mesma origem. Ao usar o CORS, um servidor pode permitir explicitamente algumas solicitações entre origens e rejeitar outras.
Para entender melhor uma solicitação CORS, o seguinte cenário percorre uma instância em que um aplicativo de página única (SPA) precisa chamar uma API Web com um domínio diferente. Além disso, considere que tanto o SPA quanto a API estão configurados no AD FS 2019 e que o AD FS tem o CORS habilitado. O AD FS pode identificar cabeçalhos CORS na solicitação HTTP, validar os valores do cabeçalho e incluir cabeçalhos CORS apropriados na resposta. Para obter mais detalhes sobre como habilitar e configurar o CORS no AD FS 2019, consulte a seção Personalização do CORS. O fluxo do exemplo a seguir orienta você pelo cenário:
Um usuário acessa o SPA através do navegador do cliente e é redirecionado para o ponto de extremidade de autenticação do AD FS para autenticação. Como o SPA está configurado para o fluxo de concessão implícito, a solicitação retorna um token Access + ID para o navegador após a autenticação bem-sucedida.
Após a autenticação do usuário, o JavaScript de front-end incluído no SPA faz uma solicitação para acessar a API Web. A solicitação é redirecionada para o AD FS com os seguintes cabeçalhos:
- Opções: descreve as opções de comunicação para o recurso de destino.
- Origem - inclui a origem da API Web.
- Access-Control-Request-Method: identifica o método HTTP (por exemplo, EXCLUIR) a ser usado quando uma solicitação real for feita.
- Access-Control-Request-Headers: identifica os cabeçalhos HTTP a serem utilizados quando uma solicitação real é feita.
Observação
Uma solicitação CORS é semelhante a uma solicitação HTTP padrão. Entretanto, a presença de um cabeçalho de origem indica que a solicitação de entrada está relacionada ao CORS.
O AD FS verifica se a origem da API Web incluída no cabeçalho está listada nas origens confiáveis configuradas no AD FS. Para obter mais informações sobre como modificar as origens confiáveis, consulte Personalização do CORS. Então, o AD FS responde com os seguintes cabeçalhos:
- Access-Control-Allow-Origin: valor igual ao do cabeçalho de Origem.
- Access-Control-Allow-Method: valor igual ao do cabeçalho Access-Control-Request-Method.
- Access-Control-Allow-Headers: valor igual ao do cabeçalho Access-Control-Request-Headers.
O navegador envia a solicitação real, incluindo os cabeçalhos a seguir:
- Método HTTP (por exemplo, EXCLUIR).
- Origem – inclui a origem da API Web.
- Todos os cabeçalhos incluídos no cabeçalho da resposta Access-Control-Allow-Headers.
Depois de verificado, o AD FS aprova a solicitação incluindo o domínio da API Web (origem) no cabeçalho de resposta Access-Control-Allow-Origin.
A inclusão do cabeçalho Access-Control-Allow-Origin permite que o navegador chame a API solicitada.
Personalização do CORS
Por padrão, a funcionalidade CORS não está habilitada; entretanto, os administradores podem habilitá-la por meio do cmdlet Set-AdfsResponseHeaders.
Set-AdfsResponseHeaders -EnableCORS $true
Depois de ativado, os administradores podem enumerar uma lista de origens confiáveis utilizando o mesmo cmdlet. Por exemplo, o comando a seguir permite solicitações CORS das origens https://example1.com e https://example1.com.
Set-AdfsResponseHeaders -CORSTrustedOrigins https://example1.com,https://example2.com
Observação
Os administradores podem permitir solicitações CORS de qualquer origem incluindo "*" na lista de origens confiáveis, embora essa abordagem não seja recomendada devido a vulnerabilidades de segurança e uma mensagem de aviso seja fornecida se eles optarem por isso.
CSP (Política de Segurança de Conteúdo)
Esse cabeçalho de resposta de segurança HTTP é usado para evitar cross-site scripting, clickjacking e outros ataques de injeção de dados, impedindo que os navegadores executem inadvertidamente um conteúdo malicioso. Os navegadores que não têm suporte para a Política de Segurança de Conteúdo (CSP) ignoram os cabeçalhos de resposta da CSP.
Personalização do CSP
A personalização do cabeçalho CSP envolve a modificação da política de segurança que define os recursos que o navegador tem permissão para carregar para a página da Web. A política de segurança padrão é:
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:;
A diretiva default-src é usada para modificar as diretivas -src sem listar cada diretiva explicitamente. Portanto, no exemplo a seguir, a política 1 é igual à política 2.
Política 1
Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "default-src 'self'"
Política 2
Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "script-src 'self'; img-src 'self'; font-src 'self';
frame-src 'self'; manifest-src 'self'; media-src 'self';"
Se uma diretiva estiver explicitamente listada, o valor especificado substituirá o valor fornecido para default-src. No exemplo a seguir, img-src assume o valor '*' (permitindo que as imagens sejam carregadas de qualquer origem), enquanto outras diretivas -src assumem o valor 'self' (restringindo à mesma origem da página da Web).
Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "default-src 'self'; img-src *"
As seguintes fontes podem ser definidas para a política default-src:
- 'self': a especificação dessa fonte restringe a origem do conteúdo a ser carregado à origem da página da Web.
- 'unsafe-inline': a especificação dessa fonte na política permite o uso de JavaScript e CSS embutidos.
- 'unsafe-eval': a especificação dessa fonte na política permite o uso de mecanismos de texto para JavaScript, como o eval.
- 'none': a especificação dessa fonte restringe o carregamento do conteúdo de qualquer origem.
- dados: - especificação de dados: os URIs permitem que os criadores de conteúdo incorporem pequenos arquivos embutidos nos documentos. Uso não recomendado.
Observação
O AD FS usa o JavaScript no processo de autenticação e, portanto, habilita o JavaScript, incluindo fontes "não seguras embutidas" e "unsafe-eval" na política padrão.
Cabeçalhos personalizados
Além dos cabeçalhos de resposta de segurança listados anteriormente (HSTS, CSP, X-Frame-Options, X-XSS-Protection e CORS), o AD FS 2019 permite que você defina novos cabeçalhos.
Por exemplo, você poderia definir um novo cabeçalho "TestHeader" e "TestHeaderValue" como o valor.
Set-AdfsResponseHeaders -SetHeaderName "TestHeader" -SetHeaderValue "TestHeaderValue"
Após a definição, o novo cabeçalho é enviado na resposta do AD FS, conforme mostrado no trecho do Fiddler a seguir:
Compatibilidade do navegador da Web
Use a tabela e os links a seguir para determinar quais navegadores da Web são compatíveis com cada um dos cabeçalhos de resposta de segurança.
| Cabeçalhos de Resposta de Segurança HTTP | Compatibilidade do navegador |
|---|---|
| HSTS (HTTP Strict-Transport-Security) | Compatibilidade do navegador HSTS |
| X-Frame-Options | Compatibilidade do navegador X-Frame-Options |
| X-XSS-Protection | Compatibilidade do navegador X-XSS-Protection |
| CORS (Compartilhamento de Recurso entre Origens) | Compatibilidade do navegador CORS |
| CSP (Política de Segurança de Conteúdo) | Compatibilidade do navegador CSP |