Uma varredura externa passiva. Cada achado traz a observação bruta feita pelo scanner
e um comando que você mesmo pode executar para reproduzi-lo - nada aqui é escrito por um modelo.
14 grupos de verificação:
Resolvendo DNS e verificando CAA · Verificando SPF e DMARC · Inspecionando o certificado TLS e as versões do protocolo · Testando o redirecionamento de HTTP para HTTPS · Lendo os cabeçalhos de segurança da resposta · Verificando os atributos dos cookies · Analisando a política CORS · Procurando banners de versão · Verificando os métodos HTTP permitidos · Verificando a página inicial em busca de conteúdo misto e formulários inseguros · Procurando arquivos de configuração e de controle de versão expostos · Verificando listagens de diretórios · Lendo robots.txt e security.txt · Verificando portas de serviço expostas
Iniciando…
0%
Sobre Verificação de Segurança de Site
Muitos scanners entregam uma nota em letra e uma lista de palavras assustadoras. Este também dá uma nota, mas cada ponto descontado está ligado a uma constatação que mostra a resposta que ele realmente recebeu e o comando de uma linha que devolve a mesma resposta, então uma constatação é algo que você pode confirmar, não algo em que precisa acreditar.
O que faz
Verifica DNS e CAA, SPF e DMARC, o certificado TLS e TLS 1.0/1.1, o redirecionamento para HTTPS, os cabeçalhos de segurança, os atributos dos cookies, CORS, banners de versão, métodos HTTP, conteúdo misto, 23 caminhos sensíveis, listagens de diretório, robots.txt, security.txt e 12 portas de serviço.
Cada resultado traz a observação bruta e um comando de shell para reproduzi-lo.
Verificações que não puderam ser executadas são reportadas como "não verificado", nunca silenciosamente como aprovadas.
Os relatórios são baixados em Markdown ou JSON.
Como funciona
1Informe um domínio pelo qual você é responsável.
2O escaneamento executa sondagens passivas - requisições comuns, sem exploração.
3Leia os resultados, cada um com sua evidência, e verifique os que importam.
Nenhum resultado é inventado
O scanner não contém nenhum modelo de linguagem. Gravidade, impacto e correção são fixos para cada verificação, e cada constatação é gerada a partir de uma observação real. O relatório na tela e os downloads em Markdown e JSON são montados a partir das mesmas constatações, sem nenhum modelo envolvido.
Como a nota é calculada
A pontuação começa em 100 e perde 34 pontos por constatação crítica, 13 por alta, 5 por média e 1,5 por baixa, com teto por gravidade (alta 45, média 22, baixa 9). Resultados informativos e aprovados não descontam nada. 90 ou mais é A, 75 é B, 60 é C, 40 é D e abaixo disso, F. Um único arquivo .env exposto ou uma porta de banco de dados acessível leva um site limpo de 100 para 66, um C; duas constatações assim dão 32, um F.
Como evita alarmes falsos
Antes de testar caminhos como /.git/HEAD ou /backup.sql, o scanner pede um endereço aleatório que não pode existir e registra como o site responde. Um caminho só é marcado como exposto se retornar HTTP 200, for diferente dessa resposta de referência e corresponder à assinatura do próprio arquivo, então um site que responde a qualquer URL com a página inicial não se enche de constatações críticas.
Um relatório limpo não é um certificado
Estas são verificações passivas contra um site em funcionamento. Elas não cobrem a lógica da aplicação, autenticação, controle de acesso, nem nada atrás de um login - os lugares onde violações reais geralmente começam. Verificações que não puderam ser concluídas são listadas como não verificadas exatamente por esse motivo: uma aprovação derivada de uma conexão falha é uma falsa segurança, e um escaneamento sem resultados significa que nada foi encontrado, não que nada exista.
Escaneie apenas o que é seu
Escaneie domínios que você possui ou para os quais tem permissão por escrito para testar. A ferramenta rejeita hosts que resolvem para endereços privados ou internos, e tem limite de taxa por IP, mas a autorização continua sendo sua responsabilidade.
Perguntas
Isso é um ataque ativo?
Não. Ele faz requisições GET, HEAD e OPTIONS comuns, handshakes TLS (incluindo tentativas com TLS 1.0 e 1.1), consultas DNS via DNS sobre HTTPS da Cloudflare e conexões TCP simples a 12 portas. Nada é explorado, nenhum formulário é enviado e nada é alterado.
Posso escanear qualquer site?
Apenas os que você possui ou está autorizado a testar. Escanear infraestrutura de terceiros sem permissão pode ser ilegal onde você estiver.
Por que uma verificação diz "não verificado"?
Porque não pôde ser concluída - geralmente porque nada respondeu naquela origem. Isso é reportado honestamente em vez de registrado como aprovado.
Posso exportar o relatório?
Sim, em Markdown ou JSON, durante uma hora: o relatório fica no cache do servidor por esse tempo para que os downloads funcionem e depois expira. Nenhuma exportação usa modelo. O registro de uso guarda o número de constatações e a nota, não o domínio.
Quais arquivos e portas ele testa?
Arquivos: 23 caminhos fixos, entre eles /.git/HEAD, /.git/config, /.env, /.env.local, /.env.production, /.aws/credentials, /id_rsa, /backup.zip, /backup.sql, /dump.sql, /wp-config.php.bak, /phpinfo.php, /server-status, /actuator/env, e cada um só é apontado quando a resposta bate com a assinatura própria daquele arquivo; /.well-known/security.txt conta a seu favor quando está publicado. Portas: uma conexão TCP simples, nunca uma tentativa de login, para 21 FTP, 23 Telnet, 25 SMTP, 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 9200 Elasticsearch, 3389 RDP, 5900 VNC, 11211 Memcached, 8080. Uma porta de banco de dados acessível (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch) ou Telnet é classificada como crítica.
O que as verificações de SPF e DMARC apontam?
Os dois registros são lidos do DNS público, mesmo para um site que não envia e-mail, porque sem eles qualquer pessoa pode enviar e-mails que dizem vir do seu domínio. Sem registro SPF é média; um SPF que contém +all, que autoriza qualquer servidor da internet, é alta. Sem registro DMARC em _dmarc é média; p=none (ou sem a tag p=) só monitora e é baixa; p=quarantine ou p=reject passa. Um domínio que não envia nenhum e-mail pode publicar v=spf1 -all.
Quais cabeçalhos de segurança são verificados e que valor passa?
Seis cabeçalhos na resposta da sua página inicial. Se faltarem, HSTS e Content-Security-Policy são alta, X-Content-Type-Options e X-Frame-Options média, Referrer-Policy e Permissions-Policy baixa. Strict-Transport-Security precisa de um max-age de pelo menos 15552000 (180 dias): menor é baixa e max-age=0 é média. Content-Security-Policy é marcada como enfraquecida (média) se script-src permite 'unsafe-inline', a política permite 'unsafe-eval' ou default-src ou script-src têm um curinga * isolado. X-Content-Type-Options deve ser exatamente nosniff. X-Frame-Options deve ser DENY ou SAMEORIGIN e não é necessário quando a CSP define frame-ancestors. Referrer-Policy só é apontada com unsafe-url ou no-referrer-when-downgrade. Permissions-Policy só precisa estar presente. Cada cabeçalho ausente ou fraco vem com um comando curl -sI para você conferir por conta própria.
Como ele verifica os atributos dos cookies (Secure, HttpOnly, SameSite)?
Ele lê cada cabeçalho Set-Cookie da resposta da sua página inicial (até 12 cookies) e verifica em cada um Secure, HttpOnly e SameSite. Faltar Secure ou HttpOnly é média; faltar só SameSite é baixa, e SameSite=None sem Secure é apontado porque os navegadores rejeitam esse cookie. Um cookie com os três atributos passa. A correção usual é Secure; HttpOnly; SameSite=Lax (no Django: SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY e SESSION_COOKIE_SAMESITE). A varredura não faz login, então cookies criados só depois do login não aparecem. Confira você mesmo com curl -sI https://your-site/ | grep -i set-cookie
Como funciona a verificação de CORS e quando ela é crítica?
Ele envia uma requisição GET para a sua página inicial com Origin: https://scanner-probe.example e lê Access-Control-Allow-Origin e Access-Control-Allow-Credentials na resposta. Sem cabeçalho Access-Control-Allow-Origin, ou com uma origem fixa que não repete a do teste, passa. Devolver a origem do teste junto com Access-Control-Allow-Credentials: true é crítico, porque qualquer site que um usuário logado visitar poderia ler as respostas dele. Devolver a origem sem credenciais é média. Um curinga * é baixa, ou média se credenciais também forem permitidas (os navegadores recusam essa combinação). Só a página inicial é testada e nenhuma requisição de preflight OPTIONS é enviada, então teste as rotas da sua API separadamente com curl -sI -H "Origin: https://scanner-probe.example" https://your-site/api/ | grep -i access-control
O que a verificação TLS testa (validade do certificado, TLS 1.0 e 1.1)?
Ela se conecta à porta 443 e valida a cadeia do certificado e o nome do host. Um certificado que não valida é de gravidade alta, um expirado também é marcado como crítico e um com menos de 15 dias restantes é médio; caso contrário, o titular, o emissor, a data de expiração e os nomes SAN aparecem como aprovado. O protocolo negociado deve ser TLS 1.2 ou TLS 1.3; qualquer versão mais antiga é alta. Em seguida tenta, separadamente, um handshake TLS 1.0 e um TLS 1.1: um servidor que aceite qualquer um deles recebe um achado médio, porque ambos foram descontinuados pela RFC 8996. Se o próprio OpenSSL do scanner não conseguir oferecer a versão antiga, nada é relatado em vez de um palpite. A correção no nginx é ssl_protocols TLSv1.2 TLSv1.3; Confira as datas você mesmo com echo | openssl s_client -connect your-site:443 -servername your-site 2>/dev/null | openssl x509 -noout -dates
Ele verifica se o HTTP redireciona para HTTPS?
Sim. Ele solicita http://your-site/ sem seguir redirecionamentos. Um 301 ou 308 para um endereço https:// é aprovado. Um 302, 303 ou 307 para HTTPS é baixo, porque os navegadores não memorizam um redirecionamento temporário e cada nova visita começa com uma requisição sem criptografia. Uma página servida por HTTP sem criptografia (resposta 2xx) é alta. Se a porta 80 não responder, é informativo, não uma falha. A correção no nginx é server { listen 80; return 301 https://$host$request_uri; }, e depois adicione Strict-Transport-Security. Confira você mesmo com curl -I http://your-site/
Quais métodos HTTP ele sinaliza (TRACE, PUT, DELETE)?
Ele envia uma única requisição OPTIONS para a sua página inicial e lê o cabeçalho Allow, ou Access-Control-Allow-Methods quando Allow não existe. TRACE, TRACK, PUT ou DELETE anunciado é médio; PATCH ou CONNECT sozinhos são baixos; apenas métodos de leitura padrão é aprovado. Se o servidor não enviar nenhum dos dois cabeçalhos, nada é informado. Anunciar um método não prova que ele funciona, então confirme antes de mudar qualquer coisa. TRACE pode devolver ao chamador os cabeçalhos da requisição, cookies incluídos (Cross-Site Tracing). O nginx recusa TRACE por padrão; no Apache, defina TraceEnable Off. Restrinja PUT e DELETE às rotas de API que precisam deles, com autenticação. Confira você mesmo com curl -X OPTIONS -i https://your-site/
Como ele detecta listagem de diretórios ("Index of /")?
Ele solicita 7 caminhos: /, /static/, /assets/, /uploads/, /images/, /files/ e /backup/. Um caminho que responde HTTP 200 com uma página cujo título ou cabeçalho principal começa com "Index of /" é sinalizado como médio (CWE-548), porque a listagem mostra arquivos que não têm link em lugar nenhum, como backups, exportações e versões antigas. Se nenhum fizer isso, a verificação é aprovada; se o site não puder ser acessado, ela aparece como não realizada. A correção no nginx é autoindex off; (o padrão, então procure um autoindex on explícito), no Apache Options -Indexes, e depois tire qualquer coisa sensível da raiz web. Confira você mesmo com curl -s https://your-site/uploads/ | head -20
Ele detecta conteúdo misto e formulários que enviam por HTTP?
Sim, na página inicial. Ele lê o HTML como é servido (nenhum JavaScript é executado) e lista cada tag script, link, iframe ou img cujo src ou href começa com http://. Se alguma for um arquivo .js ou .css, o achado é médio, porque um script ou folha de estilo trocado no caminho roda dentro da sua página HTTPS; só imagens e frames dão baixo; nenhuma é aprovado (CWE-311). Um formulário cujo action começa com http:// é classificado como alto (CWE-319), porque tudo o que se digita nele, senhas incluídas, vai sem criptografia. A correção é trocar essas URLs para https:// ou torná-las relativas e adicionar o cabeçalho Content-Security-Policy: upgrade-insecure-requests como rede de segurança. Confira você mesmo com curl -s https://your-site/ | grep -Eo "(src|href|action)=.http://[^ >]*"
O que ele verifica no robots.txt e no security.txt?
robots.txt: ele baixa /robots.txt e, se a resposta for HTTP 200 como arquivo de texto, lê as linhas Disallow dos primeiros 8000 caracteres. Um caminho Disallow que contém admin, internal, private, backup, config, staging, test, api, secret, dev é classificado como baixo (CWE-200): o robots.txt é público e só pede aos rastreadores bem-comportados que não entrem, então listar esses caminhos os anuncia. Proteja-os com login e use noindex para manter páginas fora da busca. security.txt: ele solicita /.well-known/security.txt, o local definido pela RFC 9116, e conta a seu favor quando o arquivo tem uma linha Contact:. Não ter o arquivo não tira pontos. A RFC 9116 também exige um campo Expires:, que a varredura não verifica, então publique os dois, por exemplo Contact: mailto:security@your-site, Expires: 2027-06-30T23:00:00Z. Confira você mesmo com curl -s https://your-site/.well-known/security.txt
O que a verificação de CAA procura e como adiciono um registro CAA?
Ela consulta os registros CAA (RFC 8659) do nome de host informado, via DNS sobre HTTPS da Cloudflare. Se encontrar algum, a verificação passa e a evidência mostra até 5 deles; se não encontrar nenhum, informa "No CAA record" com gravidade baixa, porque então qualquer autoridade certificadora pública pode emitir um certificado para esse nome. Um registro CAA lista as CAs que você realmente usa, por exemplo your-site. IN CAA 0 issue "letsencrypt.org", mais 0 iodef "mailto:security@your-site" para receber relatórios. Adicione uma linha issue para cada CA que você usa e uma linha issuewild se os certificados curinga (wildcard) devem vir de outra CA. Confira você mesmo com dig CAA your-site
Por que a análise de www ou de um subdomínio diz que não há CAA, SPF ou DMARC?
Cada verificação de DNS roda no nome exato informado, então www.example.com é consultado como www.example.com, não como example.com, e os três registros são herdados de formas diferentes. CAA: uma autoridade certificadora que não encontra registro CAA em www.example.com sobe para example.com e usa esse (RFC 8659, seção 3), então "No CAA record" em um subdomínio pode ser um alarme falso. DMARC: os destinatários recorrem à política do domínio organizacional, que pode definir uma política separada para subdomínios com sp= (RFC 9989, que torna obsoleto o RFC 7489), então a falta de registro em _dmarc.www.example.com costuma ser coberta por _dmarc.example.com. SPF: não há herança (RFC 7208), então "No SPF record" está correto para esse nome; um nome de host que não envia e-mail pode publicar v=spf1 -all. Uma consulta DNS que falha também aparece como registro ausente. Analise também o domínio sem www, ou confirme com dig CAA example.com e dig TXT _dmarc.example.com