.NET

8 ago, 2017

Segurança em aplicações Web .NET com o guia OWASP TOP 10

Publicidade

Objetivo

O objetivo deste artigo é auxiliá-los sobre os riscos e as vulnerabilidades encontradas nas aplicações web, e como podemos manter a segurança da nossa aplicação seguindo os conceitos de segurança do Top 10 OWASP. Portanto, embora o foco deste artigo seja uma abordagem mais afundo em segurança em aplicações web voltado para a plataforma .Net, muitos dos conceitos apresentados aqui podem ser implementados em quaisquer outras plataformas. Tenham uma ótima leitura!

Introdução

De acordo com as estatísticas, durante o ano de 2017, houve um grande aumento em ciberataques, sendo 86,2% Cyber Crime, 4,6% Hacktivismo e 9,2% em Cyber Espionagem. Conforme o gráfico abaixo, o Cyber crime lidera o hancking de ataques. No site Hackmagedon, é apresentado todos os cronogramas de estatísticas referentes ataques cibernéticos a cada ano.

Fonte: hackmageddo

Cibercrime são crimes que envolvem um computador ou uma rede. O crime cibernético ou cibercrime, pode ser considerado de diversas formas como: roubo, pornografia infantil, lavagem de dinheiro dentre outros. De acordo com a Wikipédia:

“O termo “cibercrime” surgiu depois de uma reunião, em Lyon, na França, de um subgrupo das nações do G8, que analisou e discutiu os crimes promovidos via aparelhos eletrônicos ou pela disseminação de informações para a internet. Isso aconteceu no final da década de 90, período em que Internet se expandia pelos países da América do Norte.” (Wikipédia).

  • Cyber Espionage: o atacante pode ser uma pessoa, organização ou empresa que tem como objetivo coletar dados tendo como foco alvos militares, diplomáticos, de terrorismo ou crime organizado.
  • Hacktivism: é outra forma que o ser humano achou para protestar contra governos, empresas, grupos etc. com objetivo de transpor sua liberdade de expressão, ideias, visão. Um bom exemplo de site que mantém fortemente o conceito sobre o hacktivismo é o site do Wikileaks, uma organização sem fins lucrativos que publica em seu site documentos, fotos, e informações confidenciais vazadas pelos governos e políticos.
  • Cyber Warfare: é uma guerra onde os conflitos não ocorrem com armas físicas e sim com meios eletrônicos e informáticos chamado de ciberespaço.

 

Já no inicio de deste ano, podemos notar o aumento de ataques cibernéticos que afetou empresas do mundo inteiro envolvendo 74 países, dentre eles o vírus ramsomware, um tipo de software que bloqueia informações e exige dinheiro como resgate, para poder destravá-las.

“Uma onda de ciberataques aparentemente coordenados atingiu nesta sexta (12) computadores de empresa e órgãos governamentais em pelo menos 74 países incluindo o Brasil. Os hackers usaram ferramentas da NSA, a agência de segurança nacional americana e brechas de proteção identificadas pelo governo dos EUA e vazadas. (Folha UOL – 2017)”.

“Uma onda de ataques de ransomware atingiu hoje empresas e hospitais do mundo todo, principalmente da Europa. Dentre as principais instituições vitimadas estão 16 hospitais de atendimento público do Reino Unido, e as empresas de telefonia móvel Telefônica, da Espanha e Portugal Telecom. (Olhar Digital – 2017)”.

Infelizmente, do mesmo modo que há pessoas que criam ferramentas ou maneiras de manter a segurança contra estes tipos de ataques, há sempre outro tipo de pessoa que vai encontrar milhares de maneiras para tentar invadir e roubar informações. Embora eu esteja escrevendo este artigo com foco em segurança em aplicações web, vale a pena lembrar que não basta manter somente a segurança nas aplicações, é necessário manter a segurança em infraestrutura e orientar pessoas manter uma cultura de prevenção e segurança dentro da empresa.

Segurança é um dos temas mais discutidos no mundo corporativo, mas, embora as empresas estejam se prevenindo e gastando milhões com segurança em suas aplicações, ainda há vulnerabilidades sendo explorada por criminosos.

Agora, vamos estudar principais falhas descritas neste artigo e como podemos manter a segurança em nossas aplicações, utilizando o conceitos de segurança da organização OWASP.

OWASP

A OWASP (Open Application Security Project) é uma organização de caridade sem fins lucrativos e foi fundada no EUA em 2004. O fato de ser livre de pressões comerciais permite fornecer questões de segurança imparcial, ou seja, não é afiliada a nenhuma tecnologia. A OWASP por ser uma comunidade aberta online, cria e disponibiliza de forma gratuita artigos, metodologias, documentação, ferramentas e tecnologias no campo da segurança de aplicações web.

Os estudos e documentos da OWASP são disponibilizados para toda a comunidade internacional, e adotados como referência por entidades como U.S. Defense Information System Agency (DISA), U.S. Federal Trade Commission, várias empresas e organizações mundiais das áreas de Tecnologia, Auditoria e Segurança, e também pelo PCI Council. Mantendo sempre o mesmo objetivo, orientar e auxiliar desenvolvedores, arquitetos, analistas, organizações, para que os mesmos concebam, adquiram, operem e mantenham aplicativos que possam ser confiáveis.

A fundação OWASP possui quatro valores que mostram todo o compromisso da organização em prol da segurança de software do mundo. São eles:

  • Aberto e Gratuito – tudo na OWASP é radicalmente transparente de nossas finanças para o nosso código;
  • Inovação a OWASP – encoraja e apoia inovações e experiências para soluções para desafios de segurança de software;
  • Global – qualquer pessoa ao redor do mundo é encorajado a participar da comunidade OWASP;
  • Integridade a OWASP – é uma comunidade global honesta e verdadeira, neutra do fornecedor.

OWASP TOP 10

O TOP 10 tem como objetivo sensibilização sobre seguranças em aplicações, através de alguns riscos mais críticos enfrentados pelas organizações. Tem o foco também de educar desenvolvedores, projetistas, arquitetos, gestores e organizações sobre as consequências das mais importantes vulnerabilidades de segurança de aplicações web. Os membros do projeto incluem uma variedade de especialistas em segurança em todo o mundo que compartilham seus conhecimentos para produzir a lista.

O último documento disponível para consulta é o Top 10 – 2013, no qual apresentarei aqui. O Top 10 – 2017 serão lançados em agosto deste ano e trouxe duas novas categorias sendo elas: A7 – Insufficient Attack Protection e A10- Underprotected APIs. A empresa IBLISS Digital Security foi a única organização brasileira que contribuiu para a nova versão do Top 10 – 2017. Em seu site publicou uma nota dizendo:

“A edição 2017 do Top 10 foi baseada em 11 grandes conjuntos de dados de empresas especializadas em aplicações de segurança, incluindo três fornecedores de produtos e oito empresas de consultoria. Os dados revelam vulnerabilidades de segurança encontradas em centenas de empresas e mais de 20 mil aplicações e APIs do mundo. A iBLISS contribuiu com o envio de dados anônimos do último ano de vulnerabilidades encontradas no ambiente de dezenas de empresas brasileiras, os quais foram selecionados e priorizados em combinação com estimativas de consenso dos especialistas do OWASP em termos de exploração, detecção e impacto para o negócio. (iBLISS Digital Security)”.

Na versão traduzida para o português, a imagem abaixo mostra o que são riscos em segurança de aplicações:

Imagem do pdf – OWASP Top 10 2013 PT-BR.pdf

A1. Injeção

Ataque

Ocorre quando o atacante envia ataques simples baseado em texto que exploram a sintaxe do interpretador alvo. Os dados manipulados pelo atacante podem iludir o interpretador, para que este execute comandos indesejados ou permita o acesso a dados não autorizados.

Exemplo de cenários de ataques:

String query = "SELECT * FROM accounts WHERE custID='" + 
request.getParameter("id") + "'";

Um outro exemplo de ataque de injeção referenciado pelo artigo sobre SQL Injection Marcelo Farias descreve um outro cenário de ataque, via comando injection.

A técnica mais simples de injeção de SQL consiste em burlar formulários de login. Considere o seguinte código-fonte de uma aplicação:

SQLQuery = "SELECT usuario FROM usuarios WHERE usuario = '"&
       strUsuario & "'AND senha = '" & strSenha & "'"
  strAutorizado = GetQueryResult(SQLQuery)
       IF strAutorizado == "" Then
	boolAutenticado = False
       ELSE
	boolAutenticado = True

Analisamos o que acontece quando o usuário submete um login e senha. A consulta vai até a tabela usuários verificar se existe uma linha de onde usuário e senha corresponde aos valores informados pelo usuário. Se tal linha é encontrada, o nome do usuário é armazenado na variável strAutorizado, indicando que o usuário deve ser autenticado. Se não houver uma linha que corresponda aos dados informados pelo usuário, a variável strAutorizado ficará em branco e o usuário não será autenticado (Injeção de SQL em aplicações Web Causas e prevenção – Marcelo Bukowski de Farias).

Como se prevenir?

  • Utilizar APIs seguras que evitem o uso do interpretador inteiramente ou forneça uma interface parametrizada;
  • Utilize ASP.NET Identity, além de manter a segurança na aplicação, facilidade de conexão com perfil do usuário, autenticação com AD etc;
  • Validação de lista branca;
  • Validação de dados de entrada;
  • Utilize parametrização nos comandos de SQL.

A2. Quebra de autenticação e gerenciamento de sessão

Ataque

O atacante usa vazamentos ou falhas nas funções de autenticação ou gerenciamento de sessão (por exemplo, contas expostas, senhas, IDs de sessão) para assumir a identidade de outro usuário. Essas falhas normalmente são encontradas em funcionalidades de gerenciamento de senhas, como: “Esqueci minha senha”, ou do tipo “Lembrar-me”.

Como se prevenir?

  • Ter uma interface simples para os desenvolvedores. Considere a o ESAPI Authenticator e User APIs como bons exemplos para simular, usar ou construir como base;
  • Sempre validar entrada de dados no servidor;
  • Validação de entrada: verificar o content-length (bytes dos parâmetros + dados) no cabeçalho HTTP ajuda a descobrir modificações em requisições via método POST;
  • Proteção nos cookies de autenticação devem possuir as opções de “Security” e “HTTP Only” ativos;
  • Utilizar tokens ou chaves de sessão com tempo menores de expiração.

A3. Cross-Site Scripting (XSS)

Ataque

O atacante envia ataques de scripts baseado em texto que exploram o interpretador no navegador. Quase qualquer fonte de dados pode ser um vetor de ataque, incluindo fontes internas como dados do banco de dados.

Como se prevenir?

  • A opção apropriada é filtrar adequadamente todos os dados não confiáveis com base no contexto HTML (corpo, atributo, JavaScript, CSS ou URL) no qual os dados serão colocados. Veja o OWASP XSS Prevention Cheat Sheet para detalhes sobre os requisitos das técnicas de filtro de dados;
  • Para conteúdo rico, considere bibliotecas de auto-sanitização como OWASP’s AntiSamy ou o Java HTML Sanitizer Project;
  • Alteração do código HTML do aplicativo (visível somente do lado do cliente);
  • Não inserir dados não confiáveis em determinados lugares do código;
  • Definir a propriedade da model com o atributo AllowHtml.

A4. Referência insegura e direta a objetos

Ataque

De acordo com o OWASP, uma referência insegura e direta a objetos é quando uma aplicação expõe alguma referência de implementação interna de objeto, como arquivos, diretórios, ou informações do banco de dados, sem nenhum controle de acesso. Essas falhas permitem que informações da aplicação sejam expostas para pessoas não autorizadas.

Como se prevenir?

  • Verificar o acesso. Cada utilização de uma referência direta a objeto de uma origem não confiável deve incluir uma verificação de controle de acesso para garantir que o usuário está autorizado para o objeto requisitado;
  • Uso de referência indiretas a objetos por usuário ou sessão. Isso impede que o atacante atinja diretamente os recursos não autorizados.

A5. Configuração incorreta de segurança

Ataque

Atacante acessa contas padrão, páginas não utilizadas, falhas não corrigidas, arquivos e diretórios desprotegidos etc para obter acesso não autorizado ou conhecimento do sistema. Atacantes descobrem que a listagem de diretórios não está desativada, podendo, assim, invadir e alterar arquivos.

Como se prevenir?

  • Ambientes configurados de forma idêntica com acessos diferentes;
  • Criar processos para manter atualizados os produtos necessários;
  • Criar varreduras periódicas para evitar futuros erros de configuração e produtos desatualizados.

A6. Exposição de dados sensíveis

Ataque

Os atacantes, normalmente, não quebram diretamente a criptografia. O atacante monitora a rede para roubar o cookie de sessões de site que não tem SSL em todas as páginas, e obter dados dos usuários. Sem a devida proteção, esses dados podem ser roubados com o propósito de fraudes e outros crimes.

Como se prevenir?

  • Usar SSL em todas as páginas;
  • Criptografar os dados da aplicação e manter sempre atualizado para as mais atuais formas de criptografia;
  • Uma arquitetura de aplicação forte que forneça a separação segura e eficaz entre os componentes;
  • Não utilizar dados sensíveis desnecessariamente, sempre os descarte. 

A7. Falta de função para controle do nível de acesso

Ataque

O atacante pode forçar a navegação pelas URLs, navegando pelas telas que não tem autenticação, podendo assim acessar telas de administrador. O atacante pode usar “action” que não estão aplicadas permissões por papéis.

Como se prevenir?

  • Criar módulo de autenticação que seja chamado por todas as funções;
  • Criar processo para gerenciar os papéis periodicamente;
  • Verificar as permissões do usuário durante execuções de funções.

A8. Cross-Site Request Forgery (CSRF)

Ataque

O usuário se loga em um site www.exemplo.com, usando uma autenticação de formulário. O servidor autentica o usuário e a resposta da autenticação inclui um cookie de autenticação. Sem se deslogar, o usuário visita um site malicioso que contém o seguinte código escondido.

Em outras palavras, esse tipo de ataque CSRF força o navegador da vítima logada a enviar requisições HTTP forjada, permitindo que o atacante force o navegador da vítima a gerar requisições que a aplicação vulnerável pensa ser legítima.

Como se prevenir?

  • O token único pode ser incluído na URL ou em parâmetros da URL. Contudo, tal posicionamento ocorre um risco maior, já que a URL será exposta ao atacante, comprometendo, assim, o token secreto;
  • A opção preferida consiste em incluir um token único em um campo oculto. Isso faz com que o valor seja enviado no corpo da requisição HTTP, evitando a sua inserção na URL, que é mais propensa a exposição. Exigir que o usuário autenticasse novamente, ou provar que são realmente um usuário (por exemplo, através de CAPTCHA) também pode proteger contra CSRF.

A9. Utilização de componentes vulneráveis conhecidos

Ataque

Vulnerabilidades de componentes tais como bibliotecas, estrutura e tais outros módulos do software, podem causar qualquer tipo de risco imaginável, variando do malware trivial ao sofisticado, desenvolvido para atingir uma organização específica. Se um componente vulnerável é explorado, tal ataque pode facilitar perda de dados ou de controle do servidor.

Como se prevenir?

  • Monitorar a segurança desses componentes em banco de dados públicos, listas de e-mail de projetos e segurança e mantê-los atualizados;
  • Estabelecer políticas de segurança que definem o uso do componentes, assim como exigir certas práticas de desenvolvimento de software, passando em testes de segurança e licenças aceitáveis;
  • Monitorar a segurança desses componentes em banco de dados públicos, listas de e-mail de projetos e segurança, e mantê-los atualizados.

A10. Redirecionamentos e encaminhamentos inválidos

Ataque

O atacante aponta para um redirecionamento inválido e engana as vítimas para que cliquem nele. As vítimas são mais propensas a clicar, já que o link aponta para um site válido. O atacante visa um encaminhamento inseguro para evitar verificações de segurança.

Como se prevenir?

  • Simplesmente evitar usá-los;
  • Se forem usados, evitar parâmetros de destino. Normalmente, isto pode ser feito;
  • Se os parâmetros de destino não podem ser evitados, tenha certeza que o valor fornecido é válido, e autorizado pelo usuário.

Microsoft Threat Modeling Tool

Microfost Threat Modeling Tool é uma ferramenta da Microsoft que permite fazer a modelagem de ameaças, trazendo orientações sobre como criar modelos de ameaças. De acordo com a Microsoft, “como parte da fase de design do SDL, a modelagem de ameaças permite que os arquitetos de software identifiquem e atenuem eventuais problemas de segurança com antecedência, quando são relativamente fáceis e econômicos de serem resolvidos. Portanto, ajuda a reduzir o custo total do desenvolvimento.” (Microsoft – Ciclo do desenvolvimento de segurança).

A ferramenta de modelagem de ameaças SDL permite que qualquer desenvolvedor ou arquiteto de software:

  • Comunique-se sobre o design de segurança de seus sistemas;
  • Analise esses projetos para possíveis problemas de segurança usando uma metodologia comprovada;
  • Sugerir e gerenciar mitigações para questões de segurança.

No site da Microsoft, podemos encontrar melhores informações sobre esta ferramenta, na qual se difere da abordagem em duas áreas-chave:

  • É projetado para desenvolvedores e centrado no software

Muitas estratégias de modelagem de ameaças se concentram em ativos ou atacantes. Em contraste, a abordagem SDL para modelagem de ameaças é central de software. Esta nova ferramenta baseia-se em atividades que todos os desenvolvedores e arquitetos de software estão familiarizados, como desenhar imagens para arquitetura de software.

  • Está focado em análise do projeto

O termo “Modelagem de Ameaças” pode se referir a um requisito ou a uma técnica de análise de projeto. Ás vezes, ele se refere a uma mistura complexa dos dois. Abordagem SDL da Microsoft para modelagem de ameaças é uma técnica de análise de projeto focada (Fonte: https://www.microsoft.com/en-us/sdl/adopt/threatmodeling.aspx).

Modelagem de ameaças

A modelagem de ameaças é uma técnica de engenharia utilizada para identificar ameaças, vulnerabilidades e mitigações em uma aplicação, essa técnica faz parte do ciclo de desenvolvimento de software e tem como objetivo:

  • Criar modelos de ameaças;
  • Aprender como estimar modelos de ameaças e usar o modelo DREAD;
  • Decompor uma arquitetura de aplicação e descobrir suas vulnerabilidades;
  • Identificar ameaças de documentos relevantes a sua aplicação;
  • Aplica-se na Web.

(Fonte: https://technet.microsoft.com/pt-br/library/dd569893.aspx)

Conclusão

Criar uma aplicação cem por cento segura, é um desafio para toda organização e, para isso, é necessário o apoio e o trabalho de toda a equipe, para que juntos possam encontrar soluções e possíveis ameaças, vulnerabilidades encontradas no ciclo de desenvolvimento do software, como falhas que podem ser exploradas facilmente por usuários maliciosos.

Nota: O .NET framework possui um sistema de autenticação e autorização conhecido como ASP.NET Identity. Nele, é possível realizar as implementações dos procedimentos de segurança que vimos anteriormente. Ao criar um projeto do tipo ASP.NET MVC 5, é possível instalar via Nuget o ASP.NET Identity e utilizar suas classes.

Referências