Decidimos repetir o trabalho de pesquisa em larga escala de 2015 e analisamos a segurança dos recursos da Web dos principais bancos do mundo. Desde então, o banco on-line tornou-se não apenas mais difundido, mas também generalizado. Na verdade, é rápido e conveniente, mas quão seguro? Os bancos seguem as melhores práticas?

Como na última vez , no processo de pesquisa, enviamos consultas HTTP e DNS comuns sem interferir nos bancos. Ou seja, todos os dados são coletados como um usuário normal poderia fazer visitando um recurso. Para análise, selecionamos 200 bancos russos e 400 estrangeiros. Sob trechos cortados do estudo. O texto completo pode ser encontrado em nosso site.

Desta vez, expandimos o campo de pesquisa adicionando recursos online de bancos estrangeiros ao escopo. Isso permite comparar a atitude em relação à segurança da Web na Rússia e em outros países do mundo.

No futuro, lamentamos observar que os métodos clássicos de aumentar o nível de segurança são frequentemente ignorados pelos bancos, embora não exijam recursos financeiros e técnicos globais. Perder oportunidades é voluntário, mas é completamente diferente usá-las incorretamente. Por exemplo, no caso da Política de Segurança de Conteúdo, um quinto de todos os recursos considerados possui configurações e quase todos eles apresentam erros de configuração. Como parte do estudo, tentamos considerar em detalhes como trabalhar com esse tipo de configuração corretamente e quais erros são cometidos com mais frequência.

Objetivo da pesquisa

O principal objetivo do estudo é avaliar o nível de segurança dos recursos bancários publicamente disponíveis: o site oficial e o RBS, de acordo com as melhores práticas para configurar recursos da web. Selecionamos vários pontos, cuja conformidade pode ser verificada, excluindo qualquer dano técnico e sem interferir no trabalho do banco. É importante observar que todas as informações que coletamos estão disponíveis ao público e a manipulação desses dados não requer habilidades detalhadas: se você desejar, qualquer usuário interessado poderá obter esses resultados.

Objeto de estudo

Para o teste, pegamos os 200 maiores bancos da Rússia. A lista completa pode ser encontrada em: http://www.banki.ru/banks/ratings/ (dados atuais em março de 2019).

Na primeira etapa, identificamos todos os sites oficiais e recursos da Internet da RB para pessoas físicas e jurídicas. Em seguida, para cada banco, foram feitas verificações usando várias solicitações padrão usando os protocolos HTTP / HTTPS / DNS, semelhantes às solicitações usuais de clientes bancários. Lista agrupada:

1. Configurações de SSL - oferecem a oportunidade de implementar um dos muitos ataques relacionados ao SSL;
2. Configurações de DNS - permitem obter informações sobre subdomínios da empresa.

A seguir, é apresentada uma descrição e resultados de algumas verificações. Damos especial atenção à seção dedicada à Política de Segurança de Conteúdo: nela, tentamos destacar os principais erros e dizer como eles podem ser evitados. Uma descrição completa e os resultados de todas as verificações estão no estudo .

Teste

SSL / TLS

Um dos pontos mais importantes é verificar as configurações SSL / TLS, como Hoje, esses protocolos criptográficos são o método mais popular de fornecer troca segura de dados pela Internet. A principal ameaça em potencial é o uso de ataques de interceptação de tráfego.
As seguintes verificações foram selecionadas:

Classificação

O SSL / TLS possui um grande número de configurações e recursos que, em um grau ou outro, afetam a segurança da conexão em si e de seus participantes como um todo. Para realizar uma avaliação geral dessa configuração, usamos a funcionalidade fornecida pela Qualys (www.ssllabs.com). Permite, com base em vários parâmetros, criar uma classificação geral de A a F, onde “A +” é o melhor resultado que pode ser alcançado em termos de segurança. Muito poucas empresas, mesmo as maiores corporações da Internet, o possuem. Consequentemente, "F" é o pior resultado. Pode ser obtido se o servidor estiver exposto a qualquer vulnerabilidade crítica, suportar protocolos desatualizados e tiver outros problemas. Assim como a classificação “A +”, o pior resultado é raro e está associado principalmente a funcionários não profissionais.

A porcentagem de classificações abaixo de "A" é exibida no cartão. Quanto maior esse percentual, pior a situação com a segurança da web no país.

Cabeçalhos HTTP

Os cabeçalhos na resposta do servidor da web permitem determinar o comportamento do navegador em determinadas situações. A presença deles ajuda a evitar alguns ataques ou complicar sua conduta, enquanto a adição de um cabeçalho não requer ações ou configurações complexas. No entanto, algumas configurações, por exemplo, CSP, são distinguidas por muitas opções, cujo uso incorreto pode criar a ilusão de segurança ou até danificar algumas funcionalidades do site. Revisamos os seguintes títulos:

Se os dez primeiros títulos são de natureza "positiva" e é desejável (corretamente!) Usá-los, os três últimos "informam" ao invasor quais tecnologias são usadas. Naturalmente, esses títulos devem ser descartados.

Classificação

A combinação correta de cabeçalhos HTTP permite garantir a segurança do site, enquanto não é difícil configurá-los. Coletamos dados sobre o uso de cabeçalhos HTTP e, com base neles, compilamos uma classificação de segurança para recursos da Web.
Pelo cumprimento dos seguintes parâmetros, atribuímos ou pontuamos pontos:

Classificação de "D" a "A +", onde "A +" é o melhor resultado que pode ser alcançado em termos de segurança. O pior resultado foi bastante raro, no entanto, como o melhor.

Distribuição de classificação

A porcentagem de classificações abaixo de "A" é exibida no cartão. Quanto maior esse percentual, pior a situação com a segurança da web no país.

Política de Segurança de Conteúdo

Uma “Política de proteção de conteúdo” ou CSP é uma das principais maneiras de reduzir os riscos associados à exploração de ataques XSS. Essa ferramenta permite ao administrador do site determinar quais recursos da Web são permitidos para uso nas páginas - fontes, estilos, imagens, scripts JS, SWF e assim por diante. Descubra quais navegadores suportam CSP aqui .

Graças ao CSP, você pode impedir completamente o navegador de carregar, por exemplo, objetos flash ou ajustar a lista branca de domínios - nesse caso, o navegador exibirá apenas os SWFs localizados no domínio permitido. Outra vantagem que a política de CSP fornece é a capacidade de aprender rapidamente sobre a aparência do novo XSS na vastidão de um recurso controlado. Ao usar a opção "report-uri", o navegador do atacante ou o usuário vítima envia um relatório para o URL especificado assim que o CSP é acionado.

Entre os principais erros relacionados à política de CSP, podemos distinguir as seguintes categorias:

1. Configuração incorreta
   
   • Diretivas ausentes (script-src | objeto-src | default-src | base-uri)
   • Opções redundantes (unsafe-inline | unsafe-eval | https: | data: | *)
2. Fraquezas de hosts e lista de permissões
   
   • Capacidade de carregar arquivos JS arbitrários
   • Retornos de chamada
   • Gadgets de script em mecanismos de modelo angular e similares
3. Ataques sem JS ("sem script")
   
   • Vazamento por tags não fechadas
   • Implementar formulários de phishing

Informações mais detalhadas, exemplos específicos de erros e formas de evitá-los podem ser encontrados no texto completo do estudo .

O principal objetivo do CSP é reduzir a probabilidade de exploração de ataques XSS, mas, como a pesquisa mostrou, poucos gerenciam essa política corretamente: apenas 3% usam o CSP.
O gráfico mostra os erros mais comuns nos sites CSP revisados.

Segurança estrita do transporte

A política de segurança HSTS (HTTP Strict Transport Security) permite que você estabeleça uma conexão segura em vez de usar o protocolo HTTP. Para fazer isso, use o cabeçalho Strict-Transport-Security, que força o navegador a forçar o uso de HTTPS. Isso evita alguns ataques MITM, em particular ataques com menor grau de proteção e roubo de cookies. O princípio do mecanismo é o seguinte: na primeira vez em que você visita um site usando o protocolo HTTP (S), o navegador recebe o cabeçalho Strict-Transport-Security e lembra que, com novas tentativas de conexão com este site, somente HTTPS deve ser usado.
Isso impedirá um cenário em que um invasor, interceptando solicitações HTTP, redirecione o usuário para a página do clone para obter seus dados.

Porcentagem de bancos que usam o cabeçalho HTTP Strict-Transport-Security

Definir cookie

Após receber a solicitação HTTP, o servidor pode enviar o cabeçalho Set-Cookie junto com a resposta.
Os cookies com o sinalizador Seguro são enviados ao servidor apenas se a solicitação for realizada por SSL e HTTPS. No entanto, dados importantes nunca devem ser transmitidos ou armazenados em um cookie, pois seu mecanismo é muito vulnerável e o sinalizador Seguro não fornece medidas adicionais de criptografia ou segurança. Os cookies com o sinalizador HTTPonly não podem ser acessados ​​no JavaScript por meio das propriedades da API Document.cookie, o que ajuda a evitar o roubo do cookie do cliente no caso de um ataque XSS. Esse sinalizador deve ser definido para cookies que não precisam ser acessados ​​via JavaScript. Em particular, se os cookies forem usados ​​apenas para suportar a sessão, em JavaScript eles não serão necessários e você poderá usar o sinalizador HTTPOnly. Sem os sinalizadores HTTPOnly e Secure no cabeçalho de resposta HTTP, você pode roubar ou processar uma sessão e cookies de aplicativos da web.

As bandeiras Secure e HTTPonly neste cabeçalho não são encontradas com mais frequência do que em todos os segundos sites oficiais do banco na Bósnia e Herzegovina, Japão, China, Brasil, Bulgária, Luxemburgo, Finlândia, Israel, França, Grã-Bretanha e Espanha.
Entre DBO para físico. pessoas - China, Irlanda, Israel e Japão.
Entre a RBS para jur. pessoas - Bósnia e Herzegovina, Brasil e China.

Entre os bancos russos, as estatísticas são as seguintes:
Site oficial do banco - 42%;
RBS para físico. pessoas - 37%;
RBS para legal pessoas - 67%.

Cabeçalho do servidor

Esse cabeçalho informa em qual software o servidor da web está sendo executado e pode ter o seguinte significado, por exemplo:

Server:Apache/2.4.12 (Unix) mod_wsgi/3.5 Python/2.7.5 OpenSSL/1.0.1l 

A divulgação dessas informações não representa uma ameaça direta, mas pode reduzir o tempo do ataque. Em vez de procurar uma vulnerabilidade específica, você pode começar imediatamente a procurar dados em uma versão específica do software. Por exemplo, durante o estudo, foram encontrados os seguintes dados:

O estudo mostrou que 64% dos sites dos bancos relatam uma versão de servidor, enquanto 24% desses servidores estão vulneráveis.

Conclusão

Tendo recebido uma idéia geral da segurança dos recursos da web do banco, chegamos à conclusão principal: muitos bancos negligenciam até as dicas mais comuns e fáceis de implementar para melhorar a segurança de seus recursos da web.

As vulnerabilidades e erros que descobrimos permitem que os invasores implementem ataques a recursos sem gastar muito esforço. Mas as conseqüências desses ataques são bastante graves: perdas de caixa de clientes, perdas financeiras e de reputação do banco, inclusive a longo prazo. Poucos confiam seu dinheiro em um banco cuja reputação é manchada por incidentes de segurança.

Obviamente, seguir a prática padrão de aumentar o nível de segurança - pesquisar e fechar vulnerabilidades - está compensando e minimizando os riscos. No entanto, a maioria dos desenvolvedores de aplicativos Web bancários esquece as recomendações e métodos mais simples que podem reduzir significativamente o risco ou complicar a exploração de vulnerabilidades (como, por exemplo, ocultar os cabeçalhos do servidor com informações sobre o software usado ou instalar o CSP). Os benefícios do uso de tais tecnologias não são imediatamente visíveis, mas podem não ser óbvios: ao encontrá-los, um invasor não poderá realizar um ataque e suas ações permanecerão fora da vista dos responsáveis ​​pela segurança.

Depois de examinar os recursos da Web dos bancos russos de diferentes ângulos, descobrimos que ainda existem vulnerabilidades e problemas de segurança bastante conhecidos. Isso permite que os invasores conte com a implementação bem-sucedida de ataques a essas instituições financeiras. E quanto mais problemas, maiores os riscos financeiros e de reputação dos bancos.
A situação no mundo como um todo não é particularmente diferente. Entre os que estão claramente atrasados ​​em termos de segurança, podem ser identificados os recursos bancários online dos seguintes países: China, Japão, Brasil, Israel, Espanha. Paradoxalmente, na maioria dos casos, os bancos estrangeiros prestam mais atenção à segurança de suas páginas principais do que ao sistema bancário. Vale ressaltar que a parcela de análise dos bancos estrangeiros no estudo não é tão extensa e é, antes, familiarização.