Erros fatais de segurança do site: o que aprendemos a partir das estatísticas do scanner de vulnerabilidades ao longo do ano.

Há cerca de um ano, lançamos na DataLine serviço um serviço para busca e análise de vulnerabilidades em aplicações de TI. A base do serviço é a solução em nuvem Qualys, sobre a qual já falamos. Em um ano de operação com a solução, realizamos 291 varreduras para diferentes sites e acumulamos estatísticas sobre as vulnerabilidades mais comuns em aplicações web. 

No artigo abaixo, vou mostrar quais brechas de segurança dos sites estão escondidas por trás de diferentes níveis de criticidade. Vamos ver quais vulnerabilidades o scanner encontrou com mais frequência, por que elas podem surgir e como se proteger. 

A Qualys classifica todas as vulnerabilidades das aplicações web em três níveis de criticidade: baixo, médio e alto. Olhando a distribuição por 'gravidade', parece que não é tão ruim. Há poucas vulnerabilidades de alto nível de criticidade, a maioria é não crítica: 

Mas não críticas não significam inofensivas. Elas também podem causar danos sérios. 

As principais vulnerabilidades 'não críticas'

1. Vulnerabilidades relacionadas a conteúdo misto.

   O padrão de segurança para sites é a transmissão de dados entre o cliente e o servidor via protocolo HTTPS, que suporta criptografia e protege a informação de interceptação. 

   Alguns sites usam conteúdo misto: transmitindo parte dos dados pelo protocolo não seguro HTTP. Frequentemente, isso é usado para transmitir conteúdo passivo – informações que afetam apenas a exibição do site: imagens, estilos CSS. Mas às vezes também é transmitido conteúdo ativo: scripts que controlam o comportamento do site. Nesse caso, com o uso de software especial, é possível analisar as informações recebidas do servidor com conteúdo ativo, modificar suas respostas em tempo real e fazer a máquina funcionar de maneira diferente do que seus criadores pretendiam. 

   Os navegadores de versões mais recentes alertam os usuários de que sites com conteúdo misto não são seguros e bloqueiam o conteúdo. Os desenvolvedores de sites também recebem avisos do navegador no console. Por exemplo, assim é como isso aparece em Firefox: 

   
   
   Quão perigoso é: Criminosos usam o protocolo não seguro para interceptar informações do usuário, substituir scripts e enviar solicitações ao site em seu nome. Mesmo que o visitante do site não tenha inserido dados, isso não o protege de phishing – a extração de informações confidenciais por métodos fraudulentos. Por exemplo, um script pode redirecionar o usuário para um site inseguro que se disfarça como um site familiar. Em alguns casos, o site malicioso pode parecer até melhor que o original, e o usuário pode acabar preenchendo um formulário e divulgando informações confidenciais. 

   O que o desenvolvedor web deve lembrar: Mesmo que o administrador do site tenha instalado e configurado o certificado SSL/TLS, uma vulnerabilidade pode surgir devido a fatores humanos. Por exemplo, se em algumas páginas foi utilizado um link absoluto com http, em vez de um relativo, e, além disso, redirecionamentos de http para https não foram configurados. 

   Detectar conteúdo misto em um site pode ser feito através do navegador: verificando o código-fonte da página, lendo as notificações no console do desenvolvedor. No entanto, o desenvolvedor terá um trabalho longo e tedioso para vasculhar o código. O processo pode ser acelerado com ferramentas de análise automatizadas, como: SSL Check, o software livre Lighthouse ou o software pago Screaming Frog SEO Spider.

   Além disso, a vulnerabilidade pode ocorrer devido a problemas com código legado – código que foi herdado. Por exemplo, se parte das páginas é gerada por um antigo modelo que não considera a transição dos sites para https.    

2. Cookies sem as flags "HTTPOnly" e "secure".

   Atributo "HTTPOnly" protege os arquivos de cookies de serem processados por scripts que invasores usam para roubar dados dos usuários. A flag "secure" não permite a transmissão de cookies em texto claro. A troca de dados será permitida apenas se os cookies forem enviados usando o protocolo seguro HTTPS. 

   Ambos os atributos são especificados nas propriedades do cookie:

   Set-Cookie: Secure; HttpOnly

   Quão perigoso é: Se o desenvolvedor do site não especificou esses atributos, um invasor pode interceptar as informações do usuário nos cookies e explorá-las. Se os cookies forem utilizados para autenticação e autorização, ele poderá sequestrar a sessão do usuário e realizar ações no site em seu nome. 

   O que o desenvolvedor web deve lembrar: Normalmente, em frameworks populares, esses atributos são configurados automaticamente. Mas ainda assim, verifique a configuração do servidor web e defina a flag: Set-Cookie HttpOnly; Secure.

   Nesse caso, o atributo "HTTPOnly" tornará os cookies invisíveis também para o seu próprio JavaScript.  

3. Vulnerabilidades Baseadas em Caminho.

   O scanner informa sobre essa vulnerabilidade quando encontra um arquivo ou diretório do site que esteja publicamente acessível e com potencial para conter informações confidenciais. Por exemplo, ele pode descobrir arquivos separados de configuração do sistema ou acesso total ao sistema de arquivos. Essa situação pode ocorrer se as permissões de acesso no site estiverem configuradas incorretamente.

   Quão perigoso éSe o sistema de arquivos estiver 'exposto', um invasor pode acessar a interface do sistema operacional e tentar encontrar pastas com senhas, se elas forem armazenadas em formato aberto (não faça isso!). Ou pode roubar hashes de senhas e tentar adivinhar a senha, além de tentar elevar suas permissões no sistema e avançar na infraestrutura.  

   O que o desenvolvedor web deve lembrarNão se esqueça das permissões de acesso e configure a plataforma, o servidor web, o aplicativo web, para que não seja possível 'sair' do diretório web.

4. Formulários para inserção de dados confidenciais com a função de preenchimento automático ativada.

   Se um usuário preenche frequentemente formulários em sites, seu navegador salva essas informações por meio da função de preenchimento automático. 

   Formulários em sites podem incluir campos com informações confidenciais, como senhas ou números de cartão de crédito. Para esses campos, vale a pena desativar a função de preenchimento automático no próprio site. 

   Quão perigoso éSe o navegador do usuário salvar informações confidenciais, um invasor pode interceptá-las mais tarde, por exemplo, por meio de phishing. Essencialmente, o desenvolvedor web que esquece desse detalhe expõe seus usuários. 

   O que o desenvolvedor web deve lembrarNesse caso, temos um conflito clássico: conveniência vs segurança. Se o desenvolvedor web estiver pensando no conforto do usuário, ele pode optar conscientemente pelo preenchimento automático. Por exemplo, se for importante seguir... Diretrizes de Acessibilidade de Conteúdo Web – recomendações de acessibilidade de conteúdo para usuários com deficiências. 

   Para a maioria dos navegadores, desativar o preenchimento automático pode ser feito através do atributo autocomplete="off", por exemplo:

    <body>
       <form action="/pt/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit">
         <div>
           <input type="text" placeholder="Primeiro Nome">
         </div>
         <div>
           <input type="text" id="lname" placeholder="Sobrenome" autocomplete="on">
         </div>
         <div>
           <input type="number" placeholder="Número do cartão de crédito">
         </div>
         <input type="submit">
       <input type="hidden" name="trp-form-language" value="pt"/></form>
     </body>

   Mas para o Chrome isso não funciona. Isso é contornado com JavaScript; uma variação da solução pode ser encontrada... aqui. 

5. No código do site, o cabeçalho X-Frame-Options não está definido. 

   Este cabeçalho afeta as tags frame, iframe, embed ou object. Com ele, é possível proibir totalmente a incorporação do seu site dentro de um frame. Para isso, é necessário definir o valor X-Frame-Options: deny. Ou pode-se especificar X-Frame-Options: sameorigin, então a incorporação em iframe estará disponível apenas no seu próprio domínio.

   Quão perigoso é: A ausência desse cabeçalho pode ser usada em sites maliciosos para clickjacking. Para esse tipo de ataque, o criminoso cria um frame transparente sobre os botões e engana o usuário. Por exemplo: golpistas inserem em um frame na página do site páginas de redes sociais. O usuário pensa que está clicando em um botão neste site. Em vez disso, o clique é interceptado e envia a solicitação do usuário para a rede social, onde há uma sessão ativa. Assim, os criminosos espalham spam em nome do usuário ou inflacionam seguidores e curtidas. 

   Se essa possibilidade não for proibida, o criminoso pode colocar o botão do seu aplicativo em um site malicioso. Ele pode estar interessado no seu programa de afiliados ou em seus usuários.  

   O que o desenvolvedor web deve lembrar: Uma vulnerabilidade pode surgir se X-Frame-Options for definido com um valor conflitante no servidor web ou no balanceador de carga. Nesse caso, o servidor e o balanceador sobrescreverão simplesmente o cabeçalho, pois têm prioridade mais alta em relação ao código da parte de backend.  

   Os valores deny e sameorigin do cabeçalho X-Frame-Options podem interferir no funcionamento do webvisor do Yandex. Para permitir o uso de iframe para o webvisor, é necessário escrever uma regra separada nas configurações. Por exemplo, para nginx, pode-se configurar assim:

   http{
   ...
    map $http_referer $frame_options {
    "~webvisor.com" "ALLOW-FROM http://webvisor.com";
    default "SAMEORIGIN";
    }
    add_header X-Frame-Options $frame_options;
   ...
   }
   
   

6. Vulnerabilidades PRSSI (Importação de estilos relativos ao caminho).  

   Essa é uma vulnerabilidade nos estilos do site. Ela ocorre quando links relativos são usados para acessar arquivos de estilo, como href="/somefolder/styles.css/". O criminoso irá explorá-la se encontrar uma forma de redirecionar o usuário para uma página maliciosa. A página usará um link relativo em sua URL e imitará a chamada aos estilos. O que resultará em uma solicitação como badsite.ru/…/somefolder/styles.css/, que sob o pretexto de ser um estilo pode realizar ações maliciosas. 

   Quão perigoso é: Um golpista pode explorar essa vulnerabilidade se encontrar outra falha de segurança. Como resultado, é possível roubar dados do usuário a partir de cookies ou tokens.

   O que o desenvolvedor web deve lembrar: Defina o cabeçalho X-Content-Type-Options: nosniff. Nesse caso, o navegador verificará o tipo de conteúdo para estilos. Se o tipo diferir de text/css, o navegador bloqueará a solicitação.

Vulnerabilidades críticas

1. A página com campo para senha é transmitida do servidor através de um canal não seguro (HTML form containing password field(s) is served over HTTP).

   A resposta do servidor por um canal não criptografado é vulnerável a ataques do tipo ‘homem no meio’. Um invasor pode interceptar o tráfego e se intrometer entre o cliente e o servidor, quando a página vai do servidor para o cliente. 

   Quão perigoso é: O golpista pode substituir a página e enviar ao usuário um formulário para dados confidenciais, que serão enviados ao servidor do invasor. 

   O que o desenvolvedor web deve lembrar: Alguns sites, em vez de enviar uma senha, enviam um código de uso único por e-mail/telefone. Nesse caso, a vulnerabilidade não é tão crítica, mas o mecanismo complicará a vida dos usuários.

2. Envio de formulário com login e senha por canal não seguro (Login Form Is Not Submitted Via HTTPS).

   Nesse caso, o usuário envia um formulário com login e senha ao servidor por um canal não criptografado.

   Quão perigoso é: Ao contrário do caso anterior, esta já é uma vulnerabilidade crítica. Interceptar dados confidenciais é mais fácil, pois não é necessário escrever código para isso. 

3. Uso de bibliotecas JavaScript com vulnerabilidades conhecidas.

   Durante a varredura, a biblioteca mais utilizada se tornou o jQuery, com um amplo conjunto de versões. Em cada uma das versões, há pelo menos uma, se não mais, vulnerabilidades conhecidas. O impacto pode ser bastante variável – depende da natureza da vulnerabilidade.

   Quão perigoso é: Para vulnerabilidades conhecidas, existem exploits, como estes:

   
   
   O que o desenvolvedor web deve lembrar: Volte regularmente ao ciclo: pesquisa de vulnerabilidades conhecidas – correção – verificação. Se você estiver usando bibliotecas obsoletas de forma consciente, por exemplo, para suporte a navegadores antigos ou para economizar orçamento, procure maneiras de corrigir a vulnerabilidade conhecida. 

4. Scripts entre sites (XSS). 
   Cross-Site Scripting (XSS), ou scripts entre sites, são ataques a aplicativos web que resultam na inserção de código malicioso no banco de dados. Se a Qualys detectar tal vulnerabilidade, significa que um potencial invasor pode ter injetado ou já injetou seu script js no código do site para realizar ações maliciosas.

   XSS armazenados (Stored XSS) são mais perigosos, pois o script é injetado no servidor e executado sempre que a página atacada é aberta no navegador.

   XSS refletidos (Reflected XSS) são mais simples de realizar, pois um script malicioso pode ser injetado na solicitação HTTP. O aplicativo receberá a solicitação HTTP, não validará os dados, os empacotará e enviará imediatamente. Se o invasor interceptar o tráfego e inserir um script do tipo

   /*+algo+ruim+*/ 

   então um pedido malicioso será enviado em nome do cliente.

   Um exemplo claro de XSS: js sniffers que simulam páginas para inserir CVC, data de validade do cartão, e assim por diante. 

   O que o desenvolvedor web deve lembrar: No cabeçalho Content-Security-Policy, use o atributo script-src para que o navegador do cliente carregue e execute apenas o código de fontes confiáveis. Por exemplo, script-src 'self' coloca na lista branca todos os scripts apenas do nosso site. 
   A melhor prática é considerar o código Inline: permita apenas javascript inline utilizando o valor unsafe-inline. Esse valor permite o uso de js/css inline, mas não proíbe a inclusão de arquivos js. Em combinação com script-src 'self', proibimos a execução de scripts externos.

   Certifique-se de registrar tudo utilizando report-uri e fique atento às tentativas de injeção no site.

5. Injeções SQL.
   A vulnerabilidade indica a possibilidade de injetar código SQL no site, que se comunica diretamente com o banco de dados do site. A injeção SQL é possível se os dados do usuário não forem escapados: não forem validados e forem usados diretamente na solicitação. Por exemplo, isso acontece se um formulário no site não verificar a conformidade da entrada com o tipo de dado. 

   Quão perigoso é: Se um invasor inserir uma consulta SQL nesse formulário, ele pode derrubar o banco de dados ou revelar informações confidenciais. 

   O que o desenvolvedor web deve lembrar: Não confie no que vem do navegador. É necessário se proteger tanto do lado do cliente quanto do lado do servidor. 

   Do lado do cliente, escreva uma validação dos campos usando JavaScript. 

   As funções integradas em frameworks populares também ajudam a escapar de caracteres suspeitos no servidor. No servidor, é recomendável usar consultas parametrizadas aos bancos de dados.

   Identifique onde exatamente ocorre a interação com o banco de dados no aplicativo web. 

   A interação ocorre quando obtemos alguma informação: uma solicitação com id (mudança de id), criação de um novo usuário, um novo comentário — novas entradas no banco. Aqui podem ocorrer injeções SQL. Mesmo se excluirmos uma entrada do banco, é possível que haja uma injeção SQL.

Recomendações gerais

Não reinvente a roda – use frameworks testados. Em geral, frameworks populares são mais seguros. Para .NET – ASP.NET MVC e ASP.NET Core, para Python – Django ou Flask, para Ruby – Ruby on Rails, para PHP – Symfony, Laravel, Yii, para JavaScript – Node.JS - Express.js, para Java – Spring MVC.

Fique atento às atualizações do fornecedor e atualize regularmente. A vulnerabilidade será descoberta, depois um exploit será escrito, publicado publicamente e tudo se repetirá. Inscreva-se para atualizações de versões estáveis do software do fornecedor.

Verifique os direitos de acesso. Do lado do servidor, trate sempre seu código como se ele todo, da primeira até a última letra, tivesse sido escrito pelo seu inimigo mais desprezado, que deseja quebrar seu site e comprometer a integridade dos seus dados. Especialmente porque às vezes isso realmente acontece.

Use clones, ambientes de teste, e só então implemente na produção. Isso ajudará, em primeiro lugar, a evitar erros e problemas no ambiente produtivo: o ambiente produtivo gera dinheiro, e o tempo de inatividade do ambiente produtivo é crítico. Ao adicionar, corrigir ou resolver qualquer problema, é necessário trabalhar em um ambiente de teste, depois verificar a funcionalidade e as vulnerabilidades encontradas, e então planejar as atividades no ambiente produtivo. 

Proteja o aplicativo web utilizando Web Application Firewall e integre com relatórios do scanner de vulnerabilidades. Por exemplo, na DataLine, os serviços utilizados são Qualys e FortiWeb.

Fonte: habr.com