Changelog: O Projeto Top 10 OWASP

Os aplicativos da Web explodiram em complexidade na última década. Eles evoluíram de contêineres simples para formulários de contato e pesquisas em aplicativos completos. Podemos compará-los aos aplicativos de desktop pesados, tanto em tamanho quanto em desempenho. Com um aumento acentuado na complexidade e um número crescente de aplicativos ricos em recursos, tornou-se uma necessidade investir muito tempo e cuidado para tornar todos os componentes de aplicativos o mais seguros possível. O aumento maciço de usuários da Internet tornou ainda mais importante abordar a questão da proteção dos dados e dos usuários de aplicativos. Há um vasto conjunto de ameaças tentando se infiltrar e causar fortes dores de cabeça a todos os envolvidos.

Em 2001, uma nova organização entrou em cena. Seu objetivo era combater os problemas de segurança que afetam sites e aplicativos. Foi apropriadamente chamado de Open Web Application Security Project (OWASP). Atualmente, publica recursos, organiza conferências e propõe padrões sobre segurança da web e de aplicativos. Um padrão de fato para segurança de aplicativos da Web é o OWASP Top Ten Project. Ele lista as dez ameaças de segurança mais prevalentes. Fatores influentes na decisão do que entra foram uma grande quantidade de dados e feedback da comunidade. No final de 2017, houve uma atualização do projeto. Vários novos problemas críticos para muitos aplicativos da Web modernos receberam seu lugar, enquanto alguns escaparam da lista.

Este artigo complementa a lista original e ilustra as alterações mais recentes na lista. Ele descreve as ameaças, tenta fornecer exemplos claros para facilitar o entendimento e propõe formas de combater as ameaças à segurança.

Problemas removidos da lista dos 10 principais do OWASP

Antes da atualização de 2017, a lista de 2013 era a mais recente. Considerando as mudanças nas formas como os aplicativos da Web são construídos e consumidos, fazia sentido fazer uma revisão completa. Os microsserviços estão levando seu pedaço do bolo, e novas estruturas legais e brilhantes estão substituindo o equipamento de batalha de código vanilla. Esses fatos significam que algumas das ameaças listadas anteriormente foram removidas e algumas novas foram substituídas.

Vamos nos certificar de refrescar nossa memória dos problemas há muito esquecidos neste artigo, bem como apresentar os novos lobos maus. Aprender sobre a história é a única maneira segura de não repetir os mesmos erros.

Falsificação de solicitação entre sites

A falsificação de solicitação entre sites (CSRF) é um dos “perdedores” na recente iteração do projeto. Ele desapareceu porque muitos frameworks web modernos incluem mecanismos de defesa CSRF. A probabilidade de expor seus aplicativos à ameaça diminui rapidamente.

Independentemente do CSRF sair da lista, ainda é bom refrescar a memória. Vamos garantir que não volte mais forte do que nunca.

Em essência, o CSRF é um exploit que parece uma bomba de fumaça. Um invasor engana um usuário desavisado para executar uma solicitação ou ação indesejada em um aplicativo da web. Simplificando, um invasor força sua vítima a enviar uma solicitação para um aplicativo de terceiros, e a vítima não sabe que a solicitação foi enviada. A solicitação pode ser uma solicitação HTTP GET para recuperar um recurso ou, pior ainda, uma solicitação HTTP POST que altera um recurso sob o controle da vítima. Durante o ataque, a vítima pensa que está tudo bem, na maioria das vezes sem nem perceber que algo está acontecendo em segundo plano. Depois que o ar clareia, o estrago está feito ou algo está faltando, e ninguém sabe o que aconteceu.

A autenticação de usuário anterior bem-sucedida no aplicativo de destino é o que permite que a interceptação seja efetiva. O usuário em algum momento antes do ataque entrou em um aplicativo. O aplicativo enviou à vítima um cookie para lembrá-la. Depois que o navegador da Web envia a solicitação maliciosa, o cookie é enviado automaticamente junto com qualquer carga útil em potencial e o aplicativo não se opõe a servir a solicitação a um usuário que já conhece.

Um dos exemplos mais famosos é enganar um usuário para transferir dinheiro de sua conta para a que um invasor controla. Um usuário entra em um sistema de e-banking para verificar o saldo de sua conta. Depois disso, eles visitam um fórum online para verificar as avaliações de um novo celular. Um invasor, pescando com dinamite, publica uma revisão incluindo uma imagem com um hiperlink de imagem aparentemente quebrado. Em vez de um hiperlink real, o invasor usa um hiperlink que o sistema de e-banking usa internamente para transferir dinheiro da conta A para a conta B: https://payments.dummybank.com?receiver=attacker&amount=100 . O sistema bancário torna o usuário autenticado o remetente e o valor do parâmetro “receptor” o destinatário dos fundos. Obviamente, o invasor especifica sua conta offshore como receptora.

Como o navegador carrega imagens automaticamente ao renderizar a página, a solicitação acontece em segundo plano. Se o sistema de pagamento do banco implementar transferências de dinheiro usando uma solicitação HTTP GET, nada impedirá que o desastre aconteça. Observe que o exemplo é simples e provavelmente as transferências não são tratadas via HTTP GET. No entanto, o invasor pode, com um pouco mais de dificuldade, conseguir alterar o atributo “ação” no formulário de postagem de mensagens HTML do fórum. O navegador então envia a solicitação para o sistema de pagamento do banco, em vez do back-end do fórum.

Roubar dinheiro é apenas um dos muitos exemplos por aí. Alterar os endereços de e-mail dos usuários ou fazer compras não intencionais também se enquadra nessa categoria. Como muitas vezes acontece, a engenharia social e algum conhecimento técnico são uma alavanca eficaz contra um erro de engenharia de software.

Ao projetar seus sistemas, tenha em mente o seguinte:

• Não use solicitações HTTP GET para encapsular ações que modificam um recurso. Você só deve usar essas solicitações para recuperar informações. Lembre-se, a regra geral é tornar as solicitações GET idempotentes.
• Do , ao transferir dados internamente usando solicitações HTTP POST, tendem a enviar os dados em JSON, XML ou algum outro formato que não seja a codificação dos parâmetros como uma string de consulta. O uso de um formato de dados não trivial reduz o perigo de alguém criar um formulário HTML falso que enviará os dados ao seu serviço.
• Certifique -se de criar e incluir um token exclusivo e imprevisível em seus formulários HTML. Esses tokens também devem ser exclusivos para cada solicitação. A verificação da presença e correção de tais tokens reduzirá os riscos de ocorrência de ameaças. Para descobrir o token e usá-lo em suas solicitações falsas, os invasores precisariam acessar seu sistema e obter um token diretamente de lá. Como os tokens são de uso único, eles não podem reutilizá-los no código malicioso.

Essa vulnerabilidade tem um efeito ainda pior quando combinada com scripts entre sites (XSS). Se um invasor puder injetar código malicioso em um site ou aplicativo favorito, o escopo do ataque se tornará muito mais significativo e perigoso. Ainda mais crítico, os invasores podem contornar alguns dos mecanismos de proteção contra CSRF se os ataques XSS forem possíveis.

Tenha em mente que o CSRF não desapareceu, apenas não é tão comum quanto costumava ser.

Redirecionamentos e encaminhamentos não validados

Muitos aplicativos, após finalizarem uma ação, redirecionam ou encaminham um usuário para outra parte do mesmo, ou mesmo algum outro aplicativo. Por exemplo, entrar com êxito em um aplicativo aciona um redirecionamento para a página inicial ou para a página que o usuário visitou inicialmente. Muitas vezes, o destino faz parte da ação do formulário ou do endereço de links. Se o componente que manipula o redirecionamento ou encaminhamento não se certificar de que o endereço de destino é realmente aquele que foi gerado pelo aplicativo, surge uma ameaça potencial. Esta é uma vulnerabilidade de segurança chamada “redirecionamentos e encaminhamentos não validados”.

As duas principais razões pelas quais redirecionamentos e encaminhamentos não validados seriam considerados perigosos são phishing e sequestro de credenciais. Um invasor pode alterar o local de destino de redirecionamento/encaminhamento e enviar um usuário para um aplicativo malicioso quase indistinguível do original. Um usuário desavisado revela suas credenciais e informações confidenciais a terceiros mal-intencionados. Antes que eles percebam o que aconteceu, já é tarde demais.

Como exemplo, os aplicativos da Web geralmente implementam o login com suporte para redirecionamentos para a última página visitada. Para poder fazer isso facilmente, o atributo de ação de um formulário HTML pode ser algo como http://myapp.example.com/signin?url=http://myapp.example.com/puppies . Você é um grande admirador de filhotes, então fez sentido instalar uma extensão de navegador que substitui os favicons do site pelas miniaturas de seus filhotes favoritos. Infelizmente, é um mundo de cachorro-come-cachorro. O autor da extensão do navegador decidiu lucrar com seu amor incondicional e introduzir um “recurso” adicional. Cada vez que você visita seu site de fãs de cachorro favorito, ele substitui o parâmetro “url” no atributo action do formulário por um link para seu próprio site. Como o site parece exatamente o mesmo, quando você fornece os detalhes do seu cartão de crédito para comprar cartas de baralho para filhotes, na verdade você está financiando um invasor malicioso, não seu hobby.

Resolver a vulnerabilidade envolve verificar o local de destino, certificando-se de que é o pretendido. Se uma estrutura ou biblioteca faz o redirecionamento completo ou a lógica de encaminhamento, é benéfico verificar a implementação e atualizar o código, se necessário. Caso contrário, você precisa fazer verificações manuais para se proteger contra o ataque.

Existem vários tipos de verificações que você pode fazer. Para obter a melhor proteção, use uma combinação de várias abordagens em vez de ficar com apenas uma delas.

• Valide a URL de saída certificando-se de que ela esteja apontando para o domínio que você controla.
• Em vez de usar endereços explícitos, codifique-os no front-end e, em seguida, decodifique-os e valide-os no back-end.
• Prepare uma lista de permissões de URLs confiáveis. Permite encaminhamentos e redirecionamentos apenas para os locais da lista de permissões. Prefira essa abordagem para manter uma lista negra. As listas negras geralmente são preenchidas com novos itens apenas quando algo ruim acontece. As listas de permissões são mais restritivas.
• Empregue uma abordagem usada pelo LinkedIn e alguns outros aplicativos: apresente aos seus usuários uma página solicitando que eles confirmem um redirecionamento/encaminhamento, deixando claro que estão deixando seu aplicativo.

Problemas mesclados

A maioria dos problemas na lista pode ser rotulada como defeitos na implementação, seja por falta de conhecimento ou investigação insuficientemente profunda de possíveis ameaças. Ambos os motivos podem ser atribuídos à falta de experiência e a solução para considerá-los no futuro é fácil - apenas certifique-se de aprender mais e ser mais completo. Um especialmente complicado depende de uma combinação do traço perigoso (mas muito humano) de fazer muitas suposições juntamente com a dificuldade de desenvolver e manter sistemas de computador complexos. Uma vulnerabilidade que se encaixa nessa categoria é o “controle de acesso quebrado”.

Controle de acesso quebrado

Uma vulnerabilidade é causada pela falta de autorização e controle de acesso inadequados ou completos para determinadas partes do aplicativo. Nas iterações anteriores do Projeto OWASP Top Ten, havia dois problemas: referências de objetos diretos inseguros e controle de acesso em nível de função ausente. Eles agora são fundidos em um devido à sua semelhança.

Referências de objetos diretos

As referências diretas a objetos são frequentemente usadas em URLs para identificar recursos que estão sendo operados. Por exemplo, quando um usuário faz login, ele pode visitar seu perfil clicando em um link que contém seu identificador de perfil. Se esse mesmo identificador estiver armazenado no banco de dados e for usado para recuperar informações de perfil, e o aplicativo assumir que as pessoas podem acessar a página de perfil apenas por meio de uma página de entrada, a alteração do identificador de perfil na URL expõe as informações de perfil de outro usuário.

Um aplicativo que define a URL do formulário de perfil de exclusão http://myapp.example.com/users/15/delete deixa claro que há pelo menos 14 outros usuários no aplicativo. Descobrir como chegar ao formulário de exclusão de outros usuários não é ciência de foguetes neste caso.

A solução para esse problema é realizar verificações de autorização para cada recurso sem assumir que apenas determinados caminhos podem ser usados ​​para chegar a algumas partes do aplicativo. Além disso, remover referências diretas e usar referências indiretas é outro passo à frente, pois dificulta que usuários mal-intencionados descubram como a referência é criada.

Durante o desenvolvimento, por precaução, escreva um diagrama simples de máquina de estado. Permita que os estados representem páginas diferentes em seu aplicativo e transfiram as ações que os usuários podem realizar. Isso torna mais fácil listar todas as transições e páginas que precisam de atenção especial.

Controle de acesso em nível de função ausente

O controle de acesso em nível de função ausente é muito semelhante a referências de objetos diretos inseguros. Nesse caso, os usuários modificam a URL ou algum outro parâmetro para tentar acessar partes protegidas do aplicativo. Se não houver um controle de acesso adequado examinando os níveis de acesso, um usuário pode obter acesso privilegiado aos recursos do aplicativo ou pelo menos algum conhecimento de sua existência.

Tomando emprestado o exemplo para referências diretas a objetos, se um aplicativo assume que um usuário que visita o formulário de exclusão é um superusuário apenas porque os superusuários podem ver o link para o formulário de exclusão, sem fazer nenhuma autorização adicional, uma enorme falha de segurança é aberta. Contar com a disponibilidade de algum elemento de UI não é um controle de acesso adequado.

O problema é resolvido sempre certificando-se de realizar verificações em todas as camadas do seu aplicativo. A interface front-end pode não ser a única maneira de usuários mal-intencionados acessarem sua camada de domínio. Além disso, não confie nas informações passadas pelos usuários sobre seus níveis de acesso. Execute o controle de sessão adequado e sempre verifique novamente os dados recebidos. Só porque o corpo da solicitação diz que o usuário é um administrador, isso não significa que ele seja.

O controle de acesso quebrado agora combina todos os problemas relacionados ao controle de acesso insuficiente, seja no nível do aplicativo ou no nível do sistema, como uma configuração incorreta do sistema de arquivos.

Novos problemas na lista dos 10 principais do OWASP

O advento de novas estruturas de front-end e a adoção de novas práticas de desenvolvimento de software mudaram as preocupações de segurança para tópicos completamente novos. As novas tecnologias também conseguiram resolver alguns problemas comuns com os quais estávamos lidando manualmente antes. Portanto, tornou-se benéfico revisar a lista e ajustá-la de acordo com as tendências modernas.

Entidades Externas XML

O padrão XML oferece uma ideia pouco conhecida chamada entidade externa, que faz parte da definição de tipo de dados (DTD) do documento. Ele permite que os autores de documentos especifiquem links para entidades externas que podem ser referenciadas e incluídas no documento principal. Um exemplo bem simples seria:

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY> <!ENTITY bar "baz"> ]> <foo> &bar; </foo>

Durante a análise, uma referência &bar; é substituído pelo conteúdo da entidade definida, gerando assim <foo>baz</foo> .

Se o aplicativo recebesse entrada externa e a incluísse, sem nenhuma verificação, diretamente na definição do documento XML, uma ampla gama de vazamentos de dados e ataques se tornaria possível.

O mágico é que a entidade não precisa ser uma simples string — pode ser uma referência a um arquivo no sistema de arquivos. O analisador XML terá prazer em pegar o conteúdo do arquivo especificado e incluí-lo na resposta gerada, potencialmente revelando informações confidenciais do sistema. Conforme ilustrado pelo OWASP, seria muito fácil obter informações sobre os usuários do sistema definindo a entidade como

 <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

Um “recurso” especialmente problemático dessa vulnerabilidade é a possibilidade de executar facilmente um ataque de negação de serviço. Uma maneira fácil de fazer isso seria listar o conteúdo de um arquivo infinito como /dev/random . A outra é criar uma sequência de entidades, cada uma referenciando a anterior muitas vezes. Isso transforma a referência final em uma raiz de uma árvore potencialmente muito ampla e profunda cuja análise pode esgotar a memória do sistema. Este ataque é ainda conhecido como Billion Laughs. Conforme mostrado na Wikipedia, uma série de entidades fictícias são definidas, produzindo uma oportunidade para um invasor incluir um bilhão de lols no documento final.

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>

A prevenção de explorações de entidades externas XML pode ser feita usando um formato de dados menos complexo. O JSON é um bom substituto, desde que também sejam tomadas algumas precauções devido a possíveis ataques contra ele. A atualização de bibliotecas XML é obrigatória, juntamente com a desativação do processamento de entidades externas e DTD. Como sempre, valide e higienize os dados provenientes de fontes não confiáveis ​​antes de usá-los ou incluí-los em seus documentos.

Desserialização insegura

Ao escrever o código, os desenvolvedores têm o poder de controlar os sistemas que estão desenvolvendo usando o código que escrevem. Quão incrível seria controlar o comportamento de sistemas de terceiros escrevendo apenas um pouco ou até mesmo nenhum código? Graças ao fato de que as pessoas não são perfeitas e que as bibliotecas têm falhas, isso é definitivamente possível.

O estado e a configuração do aplicativo geralmente são serializados e armazenados. Às vezes, os navegadores servem como mecanismos de armazenamento se os dados serializados estiverem fortemente acoplados ao usuário atual. Um aplicativo tentando ser inteligente e economizar tempo de processamento pode usar um cookie para marcar que um usuário fez login. Como o cookie só pode ser criado após o login ser bem-sucedido, faz sentido armazenar o nome de usuário no cookie. Um usuário é então autenticado e autorizado com base na existência e conteúdo do cookie. Se as pessoas não fossem mal intencionadas, nada poderia dar errado. Para ser honesto, eles também não devem ser curiosos.

Se um usuário curioso encontrasse um cookie em sua máquina, ele poderia ver algo assim:

 {"username": "joe.doe", "expires": "2018-06-01 10:28:16"}

Um dicionário Python perfeitamente válido serializado para JSON, nada de especial nisso. O usuário sempre curioso pode alterar a data de expiração para impedir que o aplicativo force a saída. Um usuário ainda mais curioso pode tentar modificar o nome de usuário para "jane.doe" . Se esse nome de usuário existisse, abriria um mundo totalmente novo para o usuário desavisado que agora tem acesso a dados privados.

Um exemplo simples de serialização de dados em JSON e manter tudo transparente está longe de ser a pior coisa que pode acontecer com você. Se um invasor conseguir modificar alguns dados serializados, ele poderá modificá-los de uma maneira que force seu sistema a executar código arbitrário.

Digamos que você esteja criando uma API REST que permite que as pessoas escrevam seus próprios modelos de aprendizado de máquina em Python e os carreguem em seu serviço. O serviço avaliará os modelos carregados e os treinará usando seus conjuntos de dados. Isso permite que as pessoas usem seus recursos de computação e uma grande quantidade de conjuntos de dados disponíveis para construção de modelos rápida e fácil.

O serviço não armazena o código em formato de texto simples. Os usuários selecionam seu código, criptografam-no usando sua chave privada e o enviam para a API para treinamento. Quando o serviço precisa executar um modelo, ele descriptografa o código, descompacta-o e o executa. A parte complicada é que o protocolo de picles não é seguro. O código pode ser construído de forma a permitir a execução de código malicioso arbitrário durante a desserialização.

O protocolo pickle do Python permite que as classes definam um método __reduce__ , que retorna informações sobre como desserializar um objeto personalizado. Um dos valores de retorno suportados é uma tupla de dois argumentos: um callable e uma tupla de argumentos a serem passados ​​para o callable. Levando em consideração que seu sistema de treinamento de modelo de ML visa fornecer o máximo de flexibilidade da estrutura do código, é possível escrever o seguinte código:

 class Algo(object): def run(self): pass def __reduce__(self): import itertools return (list, (itertools.count(1), ))

Uma vez que o objeto precisa ser desserializado (unpickled), uma list de funções é chamada com apenas um argumento. A função list é um construtor de lista em Python, e a função itertools.count produz um iterador infinito de valores, começando com o parâmetro passado. Transformar um iterador infinito em uma lista finita pode ter consequências desastrosas para o desempenho e a estabilidade do seu sistema.

A única cura real para esse tipo de vulnerabilidade é optar por não desserializar dados provenientes de fontes externas. Caso isso não seja possível, sugere-se o uso de um checksum ou assinatura digital para evitar a desserialização de dados potencialmente modificados por um usuário mal-intencionado. Além disso, tente configurar um ambiente de sandbox desacoplado de seu sistema principal para limitar os efeitos de problemas que possam surgir.

Ao usar bibliotecas externas para desserializar dados, por exemplo, de XML ou JSON, tente escolher aquelas que permitem fazer verificações de tipo de objeto antes que um procedimento de desserialização real seja executado. Isso pode capturar tipos de objetos inesperados cujo único objetivo é prejudicar seu sistema.

Assim como em todas as outras ações que seu aplicativo executa, imponha o registro e o monitoramento extensivos. Desserializações acontecendo com frequência ou falhando mais do que o normal são sinais de que algo ruim está acontecendo. Pegue os problemas cedo.

Registro e monitoramento insuficientes

Quanto tempo você gasta para certificar-se de registrar todos os avisos e erros que acontecem em seu aplicativo? Você armazena apenas erros que acontecem no código ou também registra erros de validação? O que acontece quando as regras de negócios do seu domínio não são atendidas? A falha em persistir todas as atividades errôneas e suspeitas em seu aplicativo representa um comprometimento da segurança e dos dados.

Imagine o seguinte cenário. Seu aplicativo contém uma página de login, como a maioria faz. O formulário tem dois campos, um para inserir um e-mail e outro para uma senha. Se um usuário tentar entrar e fornecer uma senha incorreta, ele poderá tentar novamente. Infelizmente, o número de tentativas incorretas não é limitado, portanto, a página de login não será bloqueada após N tentativas malsucedidas. Um invasor pode utilizar essa oportunidade e, com um e-mail correto, continuar inserindo senhas de uma tabela de arco-íris até que uma combinação finalmente seja bem-sucedida. Desde que seu aplicativo seja seguro o suficiente e você faça o hash das senhas antes de inseri-las em um banco de dados, esse ataque específico não funcionará. No entanto, você tem um mecanismo para identificar intrusões?

Só porque esta tentativa falhou em abrir sua página de login, isso não significa que outra não o fará. A página de login provavelmente não é o único backdoor em potencial que você tem. Se não for por outra coisa, alguém pode tentar usar o controle de acesso quebrado contra você. Mesmo aplicativos perfeitamente criados devem saber que alguém está tentando atacá-los, mesmo que isso não seja possível. É sempre isso, no entanto.

Para fazer o seu melhor para se proteger contra tais ataques, siga os seguintes passos:

• Registre todas as falhas e avisos que ocorrem no aplicativo, sejam exceções lançadas no código ou erros de controle de acesso, validação e manipulação de dados. Todas as informações armazenadas devem ser replicadas e mantidas por tempo suficiente para que seja possível a inspeção e análise retrospectiva.
• Determinar o formato e a camada de persistência é importante. Ter um arquivo enorme com formato de texto arbitrário é fácil de realizar; processá-lo mais tarde não é. Escolha uma opção de armazenamento que facilite o armazenamento e a leitura dos dados e um formato que permita uma (des)serialização fácil e rápida. Armazenar JSON em um banco de dados permitindo acesso rápido facilita o uso. Mantenha o banco de dados pequeno fazendo backup regularmente.
• Se você estiver lidando com dados importantes e valiosos, mantenha um rastro de ações que podem ser seguidas para auditar o estado final. Implemente um mecanismo para evitar a adulteração de dados.
• Faça com que os sistemas em segundo plano analisem os logs e o alertem se algo acontecer. As verificações — que são tão simples quanto testar se um usuário tenta acessar repetidamente uma parte protegida do aplicativo — ajudam. No entanto, não sobrecarregue o sistema com verificações fictícias. Os sistemas de monitoramento devem ser executados como serviços separados e não devem afetar o desempenho do sistema principal.

Ao resolver o problema, tome cuidado especial para não vazar logs de erros para usuários externos. Deixar de fazer isso o torna suscetível à exposição de informações confidenciais. O registro e o monitoramento devem ajudá-lo a resolver problemas, não os invasores a fazer seu trabalho com mais eficiência.

Próximos passos

Estar ciente das possíveis ameaças e vulnerabilidades em aplicativos da Web é importante. É ainda mais importante começar a identificá-los em seus aplicativos e aplicar os patches para removê-los.

A atenção à segurança do aplicativo é uma parte importante de todas as etapas do projeto de desenvolvimento de software. Arquitetos de software, desenvolvedores e testadores devem incorporar procedimentos de teste de software em seus fluxos de trabalho. É benéfico utilizar listas de verificação de segurança e testes automatizados nas etapas apropriadas do processo de desenvolvimento de software para reduzir o risco de segurança.

Esteja você analisando um aplicativo existente ou desenvolvendo um novo, você deve examinar o Projeto Padrão de Verificação de Segurança de Aplicativos OWASP (ASVS). O objetivo do projeto é desenvolver um padrão para verificação de segurança de aplicativos. O padrão enumera testes e requisitos para o desenvolvimento de aplicativos Web seguros. Os testes são atribuídos níveis de um a três, onde um significa a menor quantidade de perigo e três significa a maior ameaça potencial. A classificação permite que os gerentes de aplicativos decidam quais das ameaças são mais prováveis ​​e importantes. Não é necessário incluir cada teste em cada aplicativo.

Projetos de aplicativos da Web novos e existentes, especialmente aqueles que seguem os princípios do Agile, se beneficiam do planejamento estruturado de esforços para proteger seus aplicativos. O planejamento dos testes OWASP ASVS é mais fácil se você decidir usar o OWASP Security Knowledge Framework. É um aplicativo para gerenciar sprints orientados a testes de segurança, que vem com um conjunto de exemplos de como resolver problemas comuns de segurança e listas de verificação fáceis de seguir baseadas em OWASP ASVS.

Se você acabou de começar a explorar a segurança de aplicativos da Web e precisa de um playground seguro, use uma implementação de aplicativo da Web do OWASP—WebGoat. É uma implementação intencionalmente insegura de um aplicativo da web. O aplicativo orienta você pelas lições, com cada lição concentrada em uma ameaça à segurança.

Durante o desenvolvimento do aplicativo, certifique-se de:

• Identifique e priorize ameaças. Defina quais ameaças podem acontecer de forma realista e representam um risco para seu aplicativo. Priorize as ameaças e decida quais merecem o maior esforço de desenvolvimento e teste. Não há muito sentido em se esforçar muito para resolver o registro e o monitoramento insuficientes se você estiver atendendo a um blog estático.
• Avalie a arquitetura e o design do seu aplicativo. Algumas vulnerabilidades são muito difíceis de resolver durante as fases posteriores do desenvolvimento de aplicativos. Por exemplo, se você pretende executar código de terceiros e não tem planos de usar um ambiente de sandbox, será muito difícil se defender contra desserialização insegura e ataques de injeção.
• Atualizar o processo de desenvolvimento de software. O teste contra ameaças de aplicativos da Web deve, tanto quanto possível, ser um processo automatizado. É benéfico aumentar seus fluxos de trabalho de CI/CD com testes automatizados tentando encontrar falhas de segurança. Você pode até mesmo utilizar seu sistema de teste de unidade existente para desenvolver testes de segurança e executá-los periodicamente.
• Aprenda e melhore. A lista de problemas e vulnerabilidades não é estática e definitivamente não se limita a dez ou quinze ameaças. Novas funcionalidades e ideias abrem as portas para novos tipos de ataques. É importante ler sobre as tendências atuais no mundo da segurança de aplicativos da Web para se manter atualizado. Aplique o que você aprende; caso contrário, você está perdendo seu tempo.

Conclusão

Embora, como o nome sugere, o OWASP Top Ten Project liste apenas dez vulnerabilidades de segurança, existem milhares de possíveis armadilhas e backdoors que ameaçam seus aplicativos e, mais importante, seus usuários e seus dados. Certifique-se de estar atento e atualizar constantemente seu conhecimento, porque as mudanças e melhorias nas tecnologias têm vantagens e desvantagens.

Ah, e não se esqueça, o mundo não é preto e branco. As vulnerabilidades de segurança não vêm sozinhas; muitas vezes estão entrelaçados. Estar exposto a um geralmente significa que um monte de outros está ao virar da esquina, esperando para mostrar suas cabeças feias e, às vezes, mesmo que não seja sua culpa, como desenvolvedor de segurança do sistema, você ainda deve corrigir brechas para conter cibercrime. Por exemplo, consulte Números de cartão de crédito hackeados ainda são compatíveis com o Google .