Uma noção importante para quem desenvolve ou utiliza soluções informatizadas é a de que não existe segurança absoluta contra ataques cibernéticos. Consegue-se, no máximo, estabelecer uma sensação de segurança (ou insegurança), dependendo das medidas de precaução tomadas.
Partindo dessa premissa, todos stakeholders envolvidos – desenvolvedores, fornecedores de infraestrutura, adquirentes – devem adotar medidas cabíveis para evitar prejuízos, muitas vezes milionários, causados por esses ataques. No que se refere à segurança de sites Web, a consultoria Watson Hall destaca dez mitos:
1. Os desenvolvedores já trabalham os aspectos necessários relativos à segurança.
2. Ninguém se interessa por atacar nosso site.
3. O site é seguro, uma vez que utiliza TSL/SSL.
4. Estamos seguros porque não estamos usando software da Microsoft.
5. O site está protegido, uma vez que temos um firewall.
6. Nós fazemos backups, então não há com o que se preocupar.
7. Nossos dados são cifrados.
8. É suficiente realizar um teste anual de penetração.
9. As estações de trabalho dos nossos usuários estão atualizadas com patches de segurança.
10. Temos um Acordo de Nível de Serviço (SLA) com nosso provedor.
Gestores que se contagiam com mitos dessa natureza podem sofrer do mal da acomodação. Analisar e implantar processos profiláticos, no entanto, não é trivial. Edificar defesas para sistemas disponibilizados via Web é um grande desafio por vários motivos, a começar por sua origem arquitetural.
A Internet (rede), assim como a Web (plataforma), não foi projetada para prover sistemas que realizam transações comerciais, financeiras, movimentar bens, entregar petições eletrônicas. A rede foi desenvolvida na década de 1960 pelo governo norte-americano com a finalidade de formar uma rede de comunicação tolerante a falhas.
A Web surgiu três décadas depois no CERN (Organização Europeia para a Pesquisa Nuclear) como um conjunto de tecnologias para universidades publicarem conteúdos em formato hipertexto, utilizando a Internet como sua estrutura de rede.
Foi com o advento da Web 2.0 (Web como plataforma de aplicação) que esse canal passou a ser utilizado para provimento de aplicativos de negócio. Surgiram então a computação em nuvem, a voIP, os aplicativos móveis e, agora, a Internet das Coisas, que utiliza transmissões wireless para se conectar com objetos e implementar a computação pervasiva.
Para prover segurança a toda essa gama de aplicações, firewalls, técnicas de testes, funções hash e algoritmos de criptografia foram aprimorados. Antivírus, protocolos como SSL, TSL e HTTPS e frameworks para aplicações seguras foram desenvolvidos. Autoridades certificadoras e de registro foram estabelecidas.
Tudo isso, e muitas outras iniciativas são importantes, porque as ameaças à confidencialidade, à integridade e à disponibilidade são constantes em uma rede que conecta bilhões de usuários em nível mundial.
Os agentes de ameaças (invasores) exploram fragilidades dos sistemas enviando dados não-confiáveis, tentando roubar contas de usuários, acessando funcionalidades e dados não autorizados, indisponibilizando serviços, redirecionando ações de outros usuários, disfarçando suas próprias ações.
Os ataques podem provocar impactos técnicos pequenos, moderados ou severos (queda/lentidão do serviço, abertura de portas não autorizadas, instalação de malwares, etc.) que, por sua vez, podem impactar o negócio (vazamento de informações sigilosas, indisponibilidade operacional, imagem corporativa, multas, processos, etc.).
Em acordo com o OWASP (Open Web Application Security Project), as dez principais fragilidades atuais de uma aplicação Web são:
A1. Injeção: “As falhas de Injeção, tais como injeção de SQL, de SO (Sistema Operacional) e de LDAP, ocorrem quando dados não confiáveis são enviados para um interpretador como parte de um comando ou consulta. Os dados manipulados pelo atacante podem iludir o interpretador para que este execute comandos indesejados ou permita o acesso a dados não autorizados.”
A2. Quebra de Autenticação e Gerenciamento de Sessão: “As funções da aplicação relacionadas com autenticação e gerenciamento de sessão geralmente são implementadas de forma incorreta, permitindo que os atacantes comprometam senhas, chaves e tokens de sessão ou, ainda, explorem outra falha da implementação para assumir a identidade de outros usuários.”
A3. Cross-Site Scripting (XSS): “Falhas XSS ocorrem sempre que uma aplicação recebe dados não confiáveis e os envia ao navegador sem validação ou filtro adequados. XSS permite aos atacantes executarem scripts no navegador da vítima que podem \'sequestrar’ sessões do usuário, desfigurar sites, ou redirecionar o usuário para sites maliciosos.”
A4. Referência Insegura e Direta a Objetos: “Uma referência insegura e direta a um objeto ocorre quando um programador expõe uma referência à implementação interna de um objeto, como um arquivo, diretório, ou registro da base de dados. Sem a verificação do controle de acesso ou outra proteção, os atacantes podem manipular estas referências para acessar dados não-autorizados.”
A5. Configuração Incorreta de Segurança: “Uma boa segurança exige a definição de uma configuração segura e implementada na aplicação, frameworks, servidor de aplicação, servidor web, banco de dados e plataforma. Todas essas configurações devem ser definidas, implementadas e mantidas, já que geralmente a configuração padrão é insegura. Adicionalmente, o software deve ser mantido atualizado.”
A6. Exposição de Dados Sensíveis: “Muitas aplicações web não protegem devidamente os dados sensíveis, tais como cartões de crédito, IDs fiscais e credenciais de autenticação. Os atacantes podem roubar ou modificar esses dados desprotegidos com o propósito de realizar fraudes de cartões de crédito, roubo de identidade, ou outros crimes. Os dados sensíveis merecem proteção extra como criptografia no armazenamento ou em trânsito, bem como precauções especiais quando trafegadas pelo navegador.”
A7. Falta de Função para Controle do Nível de Acesso: “A maioria das aplicações web verificam os direitos de acesso em nível de função antes de tornar essa funcionalidade visível na interface do usuário. No entanto, as aplicações precisam executar as mesmas verificações de controle de acesso no servidor quando cada função é invocada. Se estas requisições não forem verificadas, os atacantes serão capazes de forjar as requisições, com o propósito de acessar a funcionalidade sem autorização adequada.”
A8. Cross-Site Request Forgery (CSRF): “Um ataque CSRF força a vítima que possui uma sessão ativa em um navegador a enviar uma requisição HTTP forjada, incluindo o cookie da sessão da vítima e qualquer outra informação de autenticação incluída na sessão, a uma aplicação web vulnerável. Esta falha permite ao atacante forçar o navegador da vítima a criar requisições que a aplicação vulnerável aceite como requisições legítimas realizadas pela vítima.”
A9. Utilização de Componentes Vulneráveis Conhecidos: “Componentes, tais como bibliotecas, frameworks, e outros módulos de software quase sempre são executados com privilégios elevados. Se um componente vulnerável é explorado, um ataque pode causar sérias perdas de dados ou o comprometimento do servidor. As aplicações que utilizam componentes com vulnerabilidades conhecidas podem minar as suas defesas e permitir uma gama de possíveis ataques e impactos.”
A10. Redirecionamentos e Encaminhamentos Inválidos: “Aplicações web frequentemente redirecionam e encaminham usuários para outras páginas e sites, e usam dados não confiáveis para determinar as páginas de destino. Sem uma validação adequada, os atacantes podem redirecionar as vítimas para sites de phishing ou malware, ou usar encaminhamentos para acessar páginas não autorizadas.”
Percebe-se, por essa lista, a quantidade e a variedade de ameaças existentes. Os ataques devem ser prevenidos durante o ciclo de vida completo do produto, da concepção à implantação, minimizando, assim, probabilidades de ocorrência de incidentes e seus respectivos impactos no negócio.
Precauções devem ser tomadas em tudo que envolve hardware, software e comunicações: acesso físico, acesso lógico, características de segurança da aplicação, servidores, componentes, sistemas interoperantes, bancos de dados, sistemas de arquivos, sistemas operacionais, serviços de rede.
Deve-se avaliar os aspectos legais e as regulações concernentes – contratos, leis, normas, licenças de uso, direito aos dados, privacidade – analisando a confidencialidade, a integridade e a disponibilidade necessárias para as informações em trânsito e persistidas. Cada organização precisa elaborar seu próprio Plano de Ação em Segurança da Informação. Entretanto, algumas iniciativas sugeridas são:
1. Envolva todos os stakeholders necessários para realizar ações corretas de segurança: cliente, analistas de negócio, gestor do projeto, desenvolvedores, infraestrutura, rede.
2. Utilize frameworks de desenvolvimento que: a) garantam uma arquitetura de aplicação forte, com separação segura e eficaz entre componentes; b) cumpram os requisitos definidos no Padrão de Verificação de Segurança da Aplicação do OWASP (ASVS), áreas V2 (Autenticação) e V3 (Gerenciamento de Sessão).
3. Separe configurações de ambiente dos códigos a serem publicados.
4. Em ambientes de produção, realize as devidas configurações de segurança, restringindo acessos tanto quanto for possível para garantir a disponibilidade.
5. Se possível, utilize uma ferramenta de análise de vulnerabilidades de boa qualidade. Idealmente, integre-a ao mecanismo de integração contínua.
6. Mantenha dados não confiáveis separados dos comandos e consultas. Se puder, utilize uma API segura para realizar essa separação.
7. Cifre todos os dados sensíveis persistidos e em trânsito com algoritmos e chaves fortes, certificando-se de que gerenciamento de chaves está adequadamente implantado.
8. Não armazene dados sensíveis desnecessariamente. Descarte-os o mais rápido possível. Dados que você não tem não podem ser roubados.
9. Desabilite o autocompletar em formulários de coleta de dados sensíveis e desabilite o cache em páginas que contenham dados sensíveis.
10. Realize testes com dados de entrada que simulem injeções e XSS. Executa varreduras, realize auditorias e testes de penetração periódicos para detectar inconformidades, erros de configuração, vulnerabilidades potenciais ou presentes que podem comprometer aspectos da tríade confidencialidade, integridade ou disponibilidade.
* Roges Horacio Grandi é professor da Estácio do RS.