xss: Suporte nativo a cross-site scripting no NGINX
Instalação
Você pode instalar este módulo em qualquer distribuição baseada em RHEL, incluindo, mas não se limitando a:
- RedHat Enterprise Linux 7, 8, 9 e 10
- CentOS 7, 8, 9
- AlmaLinux 8, 9
- Rocky Linux 8, 9
- Amazon Linux 2 e Amazon Linux 2023
dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install nginx-module-xss
yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install nginx-module-xss
Ative o módulo adicionando o seguinte no topo de /etc/nginx/nginx.conf:
load_module modules/ngx_http_xss_filter_module.so;
Este documento descreve o nginx-module-xss v0.6 lançado em 26 de dezembro de 2022.
## acessando /foo?callback=process dá a resposta
## corpo "process(...);" (sem aspas) onde "..."
## é o corpo da resposta original da localização /foo.
server {
location /foo {
# seu manipulador de conteúdo vai aqui...
xss_get on;
xss_callback_arg 'callback';
xss_input_types 'application/json'; # padrão
xss_output_type 'application/x-javascript'; # padrão
}
...
}
Descrição
Este módulo adiciona suporte a AJAX cross-site ao nginx. Atualmente, apenas GET cross-site é suportado. Mas o POST cross-site será adicionado no futuro.
O GET cross-site é atualmente implementado como JSONP (ou "JSON com preenchimento"). Veja http://en.wikipedia.org/wiki/JSON#JSONP para mais detalhes.
Diretrizes
xss_get
sintaxe: xss_get on | off
padrão: xss_get off
contexto: http, server, location, if location
Habilita o suporte a JSONP para requisições GET.
xss_callback_arg
sintaxe: xss_callback_arg <nome>
padrão: nenhum
contexto: http, http, location, if location
Especifica o nome da função de callback JavaScript usada nas respostas.
Por exemplo,
location /foo {
xss_get on;
xss_callback_arg c;
...
}
então
GET /foo?c=blah
retorna
blah(...);
xss_override_status
sintaxe: xss_override_status on | off
padrão: xss_check_status on
contexto: http, server, location, if location
Especifica se deve substituir os status 30x, 40x e 50x por 200 quando a resposta está realmente sendo processada.
xss_check_status
sintaxe: xss_check_status on | off
padrão: xss_check_status on
contexto: http, server, location, if location
Por padrão, ngx_xss apenas processa respostas com o código de status 200 ou 201.
xss_input_types
sintaxe: xss_input_types [mime-type]...
padrão: xss_input_types application/json
contexto: http, server, location, if location
Processa apenas as respostas dos tipos MIME especificados.
Exemplo:
xss_input_types application/json text/plain;
Limitações
- ngx_xss não funcionará com as interfaces de subrequisição do ngx_echo, devido às limitações subjacentes impostas pelo mecanismo de "cadeia adiada" das subrequisições no núcleo do nginx. O módulo padrão ngx_addition também se enquadra nesta categoria. No entanto, recomenda-se usar o ngx_lua como o manipulador de conteúdo para emitir subrequisições e ngx_xss para fazer JSONP, porque a interface ngx.location.capture() do ngx_lua não utiliza o mecanismo de "cadeia adiada", saindo assim dessa limitação. Estamos adotando essa abordagem em produção e funciona muito bem.
Solução de Problemas
Use o nível de log de erro "info" (ou inferior) para obter mais diagnósticos quando as coisas dão errado.
Veja Também
GitHub
Você pode encontrar dicas adicionais de configuração e documentação para este módulo no repositório do GitHub para nginx-module-xss.