Forem: Gabriel Galdino

O que vem depois do Pentesting?

Gabriel Galdino — Wed, 31 Jan 2024 11:49:30 +0000

Se você trabalha com Segurança de Aplicações (AppSec), provavelmente já se deparou com essa situação: o que fazer depois de receber o relatório de pentesting?

Para explorar esse tema, convidei o @sushicomabacate para compartilhar sua visão e contribuir para essa discussão. O conteúdo deste artigo é baseado em várias pesquisas e também experiências e aprendizados, que podem não obrigatoriamente se aplicar ao seu caso, mas com certeza vão te inspirar a pensar em novas ideias e possibilidades.

Obs: não vamos abordar neste texto as diferenças de metodologia e escopo do pentesting; nem tampouco a efetividade desse tipo teste em um Programa de Segurança de Aplicações.

Um agradecimento especial aos profissionais de infosec que também de certa forma indiretamente colaboraram com essa pesquisa @Heitor Gouvêa, @Eduardo Santos e @Bruno Oliveira.

Ponto zero

Antes de tudo, vamos dar uma olhada em quando e por que realizamos o pentesting.

Quando o assunto é a segurança das nossas aplicações, o teste de penetração (penetration testing), ou pentest, geralmente acontece na fase de testes, quando a aplicação já está e produção no ciclo de desenvolvimento. Basicamente, é uma técnica que consiste em simular ataques reais contra um sistema, com o objetivo de identificar e explorar vulnerabilidades que possam comprometer a sua integridade, confidencialidade ou disponibilidade - os pilares de segurança da informação..

Dito isso, o penetration testing não pode ser tratado como uma peça isolada na sua estratégia de segurança.

Isso se torna ineficaz, uma vez que novos códigos estão constantemente sendo incorporados à aplicação, trazendo consigo potenciais vulnerabilidades.

Seguindo a máxima conhecida: o pentesting é como uma fotografia instantânea da sua aplicação, mas com data de vencimento.

(Imagem criada por IA)

Agora, dando esse passo para trás, podemos encarar o pentesting de uma maneira mais estratégica, especialmente para a gestão de AppSec.

Ao submeter suas aplicações a uma bateria de testes e simulações de ataques, você acaba se aproximando - pelo menos na essência - de uma possível realidade. Ao investir em nesses testes, algumas perguntas fundamentais devem surgir para justificar e acompanhar essa empreitada:

As funcionalidades da minha aplicação estão sendo desenvolvidas com consideração aos requisitos de segurança?
Os desenvolvedores estão recebendo treinamento adequado em Segurança de Aplicações (AppSec)? Existe um processo de revisão de código voltado para a segurança?
Como estão sendo implementados os testes básicos de segurança no pipeline de desenvolvimento?
Está claro para todos os envolvidos no desenvolvimento quem são os responsáveis, quais são os processos e objetivos em relação à Segurança de Aplicações?
Qual é o nível de maturidade em Segurança de Aplicações que estamos atingindo?

Manter essas questões em mente vai fazer uma enorme diferença para a próxima etapa do processo.

1 Recebendo o Relatório de Pentesting

A empresa que fez o Pentest vai convidá-lo para uma call, na qual apresentará os achados. Em seguida, você definirá a forma de receber o relatório final de pentest em PDF, com senha, por ser uma informação muito sensível. O meio mais comum é o email, mas pode-se usar métodos mais seguros.

(Imagem fictícia de um relatório sendo compartilhado via e-mail)

Este documento é um exemplo acurado do que contém um desses reports. Fora a enrolação parte pré-textual, ele contém os seguintes itens:

Um sumário executivo (já que eles não estão interessados no técniquês);
Objetivo, premissas, etc;
Metodologia de teste e escopo;
Resumo das vulnerabilidades (quantidade, criticidade e classes de vulnerabilidades);
Descrição das vulnerabilidades por ordem de criticidade (que é a melhor parte). Pra cada vulnerabilidade são apresentados:
Detalhamento;
Criticidade (contendo impacto e viabilidade técnica);
Provas de conceito (geralmente não mais que 2);
Sugestão de solução;
Referências.

Bom, você abriu o relatório. A tensão e a frustração já percorreram todo o corpo: meus ativos estão vulneráveis. E agora?

Para muitos, esse momento pode ser como receber uma bomba nas mãos, e a vontade imediata é passar esse artefato explosivo para outra pessoa. Mas aqui, surpreendentemente, é necessário uma mente analítica e crítica para pensar em algo que muitas vezes é esquecido: a estratégia.

É hora da equipe de segurança se reunir e discutir sobre o relatório e seus resultados.

Com o documento em mãos, é possível repensar toda sua estratégia de desenvolvimento seguro através dessas evidências. Você pode olhar para aquelas perguntas do tópico zero e obter algumas hipóteses interessantes sobre seus processos e ferramentas de AppSec.

Não duvido da capacidade das empresas ou profissionais que realizam esses testes, mas erros podem acontecer. Ter sangue frio para analisar esses resultados também é fundamental para identificar possíveis problemas e abrir espaço para contestações que não foram feitas nas reuniões anteriores com a empresa que forneceu o serviço. “Será que essa vulnerabilidade de fato é crítica tendo em vista o impacto do negócio?”. Lembre-se do seguinte: quanto maior detalhe nas evidências e prova de conceito, mais fácil ficará para construir seu plano de remediação.

Os resultados obtidos trazem não apenas uma fotografia das suas aplicações, mas também revelam como está sua estratégia geral. Afinal, se um SQL injection simples na tela de login de um ativo crítico foi identificado, alguma coisa no início do seu processo necessita de atenção - muita atenção.

Em resumo: examine com carinho os principais tipos de vulnerabilidades identificados, pois eles dizem muito sobre o estado de segurança do seu desenvolvimento de software.

Alguns exemplos:
Se muitos pacotes desatualizados foram identificados, é hora de questionar a eficiência do seu Software Composition Analysis (SCA). Será que a gestão de dependências precisa ser aprimorada?

Questões básicas de segurança no código foram identificadas. Será que há algo a ser ajustado nos treinamentos realizados? Precisa investir mais tempo em code review com enfoque em segurança?

Essas questões precisam ser desdobradas, discutidas e analisadas, e se possível, documentadas.

Executivos, diretores, e outros gestores vão querer saber sobre o relatório do pentesting: prepara-se para uma reunião.

Se possível, prepare um material para uma apresentação, acompanhado de um resumo com uma linguagem específica para gestores, enfatizando a parte de impacto de negócio e técnico - campos que precisam estar descritos nos relatórios.

Com esse material, é possível angariar novos investimentos para seu time, principalmente se na construção de seu argumento deixar claro as evidências dos possíveis impactos de negócio.

Portanto, antes de iniciar as correções em si, pense em como esses resultados podem aprimorar sua estratégia como um todo. Este pode ser o maior valor gerado a partir desse processo.

2 Gestão de vulnerabilidades e orientação à riscos

Entramos em um momento interessante, as vulnerabilidades estão identificadas no relatório, e após uma análise cuidadosa foi possível documentar algumas hipóteses para a estratégia do time de segurança. Então, como vamos corrigi-las?

A realidade é que nenhuma vulnerabilidade pode ser corrigida de forma isolada. É necessário incorporá-la ao seu fluxo natural de vida, algo que chamamos aqui de gerenciamento de vulnerabilidades:

(Desenho do fluxo de tratamento de uma vulnerabilidade by @sushicomabacate)

Esse fluxo considera que a vulnerabilidade pode assumir alguns estados. Quando recebemos a vulnerabilidade, ela possui o estado Nova. Onde basicamente não sabemos nada sobre ela. Dependendo do resultado das primeiras validações, ela pode ir pro estado Duplicada ou Falso Positivo. Por exemplo, a vulnerabilidade pode ser reproduzida com sucesso pelo time que está analisando o resultado, mas se ela já foi achada anteriormente (por um scanner, outro pentest anterior ou qualquer outra coisa) aí ela vai para duplicada.
Após conseguirmos reproduzir a vulnerabilidade com sucesso, ela tem o estado Triada.

Nesse caso, vamos pensar que temos a vulnerabilidade já testada e comprovada sua veracidade, confirmando-se como um verdadeiro positivo - foi triada como segue a imagem:

(Desenho do fluxo de Estados de uma vulnerabilidade by @sushicomabacate)

Esse fluxo foi largamente inspirado nas recomendações da OWASP, porém, é apenas uma simplificação da tríade: Detection, Reporting e Remediation. Existem vários detalhes omitidos que são bem explorados em OWASP Vulnerability Management Guide. Dentre eles: definição do risco da vulnerabilidade, criação de reports para compartilhar na empresa- (incluindo o time owner do código vulnerável - e priorização da remediação das vulnerabilidades.

Compreender a existência desse fluxo é crucial para evitar redundância de dados. Chamamos isso de desduplicação: será que esse SQL Injection não é o mesmo identificado no mês passado por um DAST (Dynamic Application Security Testing) e já em processo de correção? Ou será esse XSS aquela vulnerabilidade que havíamos aceitado como um risco tolerável? Se todas essas informações estão sendo organizadas de maneira centralizada e padronizada, você terá essas respostas de maneira muito fácil e rápida.

Se você ainda não possui um sistema de gerenciamento de vulnerabilidades, este é o momento ideal para começar. Crie um fluxo, desenhe-o e documente o processo, alinhando as partes e padronizando as atividades.

Vale destacar que o gerenciamento de vulnerabilidades envolve mais do que identificar e corrigir falhas de segurança.

Para isso, é necessário adotar uma abordagem baseada em riscos, que considere o contexto, o impacto e a probabilidade de cada vulnerabilidade. Assim, você poderá proteger os ativos mais críticos para o seu negócio e alocar os recursos de forma mais eficiente. Para isso, é essencial ter uma gestão de ativos que permita identificar quais são os sistemas e aplicativos mais importantes e priorizar as ações de correção de acordo com o nível de severidade das vulnerabilidades.

3 Tratando a remediação

Vamos voltar para o relatório, a vulnerabilidade está descrita em detalhes juntamente com orientações sobre como deve ser remediada. É primordial examinar essas recomendações com a máxima atenção possível.

Eu costumo acreditar que a palavra final da orientação de como deve ser corrigido vem da OWASP, aliada à análise do contexto real da vulnerabilidade. Portanto, uma sugestão valiosa é consultar os materiais da OWASP, seja no cheat sheet ou nos projetos do próprio OWASP TOP 10. Além disso, você pode buscar outras referências para auxiliar, como o CAPEC para ataques e o CWE para vulnerabilidades. Discuta com o seu time sobre suas considerações, por fim, compare as informações de sua pesquisa interna com as do relatório.

Um aspecto fundamental é criar um plano de ação para a remediação individual de cada vulnerabilidade. Profissionalmente, costumo documentar todos os processos e atividades possíveis. Talvez você queira um documento específico para orientar a correção de cada vulnerabilidade, com exemplos de código, refinamento nos detalhes, referências importantes da OWASP para consulta, proporcionando objetividade e praticidade.

Ademais, acrescenta-se a esta documentação a realização de um acordo de nível de serviço (SLA), delineando prazos, os serviços a serem prestados, as metas de nível de serviço e as responsabilidades de cada parte no que tange à remediação. Lembre-se: vulnerabilidades classificadas como críticas devem ter prazos urgentes para remediação!

Relembrando: se você deseja ter controle total sobre seu processo de segurança de aplicações, quanto mais detalhes, contexto e refinamento, melhor será para o desenvolvedor.

4 O plano de ação para remediação

Se você se interessou por trabalhar com mais afinco na orientação da remediação, acredito que o método de divisão das correções em tasks possa te atrair.

Com o report em mãos, a pessoa do time de segurança pode criar cards na sua plataforma de gerenciamento (Jira, Kanban, etc) para cada uma dessas vulnerabilidades e seguir um fluxo de tratamento de vulnerabilidades.

Podendo conter nesse card o seguinte fluxo abaixo que ilustra o caminho de correção de uma vulnerabilidade:

Dado um report de vulnerabilidade, verificar se é uma duplicata de outro report já recebido;
Verificar se é possível reproduzir a vulnerabilidade;
Atribuir um risco, seguindo a política da empresa;
Atualizar a task/documentação com as informações obtidas durante a reprodução da vulnerabilidade;
Discutir com pares do time de segurança as melhores práticas pra fix, verificar a base de procedimentos da empresa se já existe alguma recomendação;
Apresentar todas as evidências + sugestão de fix para o time dono do código vulnerável e acompanhar o desenvolvimento, deploy e prazos;
Após desenvolvimento e deploy do fix, retestar/solicitar reteste da vulnerabilidade para garantir que foi resolvida;
Caso o reteste confirme que a vulnerabilidade foi erradicada, atualiza-se a documentação/task com os aprendizados.

Se a sua empresa adota uma abordagem ágil e de Produto no processo de desenvolvimento de software, é provável que os desenvolvedores estejam acostumados a receber esses tipos de cards com user stories, tasks, etc., detalhando o que precisam alcançar.

Ao seguir essa mesma estratégia, é possível tornar seu plano de ação mais acessível para desenvolvedores que preferem receber as atividades com a mesma padronização a que estão habituados no desenvolvimento de novas funcionalidades.

Exemplo de user story focada em segurança e tarefas de segurança associadas (SAFECode):

(Exemplo de User Story para correção de vulnerabilidades)

Esses itens são posteriormente inseridos no backlog, devidamente priorizados. Quando um novo sprint de desenvolvimento é iniciado, a equipe de desenvolvimento seleciona (ou recebe) as tarefas alocadas para o sprint, abrangendo tanto tarefas funcionais quanto aquelas focadas em segurança, e dá início ao trabalho de desenvolvimento.

Dentro desse contexto, algumas tarefas de segurança demandam ações combinadas de recursos arquitetos/desenvolvedores e controle de qualidade. Essas tarefas são prefixadas como A/D/T (Arquiteto/Desenvolvedor/Teste). Outras são marcadas como A/D (Arquiteto/Desenvolvedor) ou T (Teste).

5 Tornando a segurança uma responsabilidade compartilhada

Com toda a papelada pronta para botar todo mundo pra trabalhar, você deve imaginar, é só deliberar?

A real é que ninguém gosta de receber um trabalho a mais ou uma nova demanda assim inesperadamente. Quando se trata de AppSec, dimensionamos a cultura e a colaboração como fatores fundamentais. Todo mundo precisa estar conectado com este propósito. Se você busca apoio para resolver seus problemas, é crucial conscientizar e atualizar as pessoas sobre o que está acontecendo.

Para isso, é vital que sua equipe realize treinamentos, reuniões, seja com os líderes ou responsáveis pelo time de desenvolvimento ou até mesmo com os próprios desenvolvedores. Nesse momento, a comunicação, didática e clara é essencial. É importante também discutir sobre as estratégias de correção, pois os desenvolvedores são aqueles que mais conhecem o código. Vale lembrar que mesmo que você esteja familiarizado com os termos de segurança, outras pessoas podem não ter ideia do que significa.

Se deseja que essas vulnerabilidades sejam corrigidas, é preciso garantir que elas sejam compreendidas.

Apresentações, discussões e reflexões sobre o resultado do relatório são, portanto, peças chaves nesse processo, pois nesse momento você pode descobrir que no documento houve confusão entre autenticação de tokens JWT e autenticação de cookies, por exemplo. Quem conhece melhor as aplicações do que os desenvolvedores? Portanto, não subestime a autoridade que eles têm sobre o que constroem.

Se você transmitir a mensagem corretamente, todos, de alguma forma, abraçarão sua causa e se sentirão à vontade para incorporar as correções em suas sprints.

6 escrever, testar, corrigir, testar

Entregou os documentos, dividiu as tarefas e agora é só esperar o reteste do código corrigido? Assim como você precisa dos desenvolvedores, eles também vão precisar de você, e dessa vez de forma mais constante.

"Não entendi como funciona a correção dessa vulnerabilidade." Nesse momento, é fundamental prestar atenção às lacunas da equipe. Marcar treinamentos mais frequentes sobre as vulnerabilidades do relatório pode auxiliar em um alinhamento geral.

"Escrevi o código, mas não sei se corrigi de fato." Essa insegurança pode surgir nos desenvolvedores, pois, apesar de estarem acostumados com testes unitários, verificar um código para garantir sua efetividade contra um ataque pode ser uma novidade.

Profissionais de segurança são essenciais nessa fase de correções, seja para oferecer orientações sobre como lidar com esse tipo de vulnerabilidade recomendando documentações da OWASP ou do próprio framework, seja para analisar a execução de testes automatizados na esteira, como um SAST (Static application security testing).

Além disso, ter em mente o passo a passo de como funciona o ataque é um conhecimento que faz a diferença na hora de realizar um teste manual antes de ir para produção.

Se você entende que mensagens de erro não podem conter informações sensíveis, então teste todas as possibilidades para garantir que o que foi alterado no código seja efetivo. Esse tipo de teste, além de auxiliar no aprendizado sobre o funcionamento do ataque, fortalece o que pregamos em AppSec de "hacker mindset".

Em algumas situações, uma vulnerabilidade pode ter seu risco aceito pela organização, significando que ela opta por não corrigir ou mitigar o problema. Essa decisão pode ser baseada na percepção de que o impacto ou a probabilidade de exploração são baixos, ou que o custo e a complexidade da correção ou mitigação são consideráveis. Nesse cenário, a organização assume conscientemente o risco de possíveis ciberataques, monitorando a vulnerabilidade e revisando a decisão periodicamente.

Outros cenários

Quando uma vulnerabilidade não pode ser completamente remediada, ou seja, resolvida de forma a não ser mais explorada, a alternativa é a mitigação. Isso envolve tornar a exploração da vulnerabilidade mais difícil por meio de medidas de controle ou compensação. Por exemplo, se um software possui uma vulnerabilidade irremediável pelo fabricante, a organização pode optar por mitigá-la implementando um firewall, um antivírus ou uma política de acesso restrito.

Em times de segurança menos maduros, vulgo recém criados, é normal pedirem para o próprio time de segurança consertar as vulnerabilidades. O fluxo é basicamente o mesmo que foi comentado aqui, porém o item “owners do código vulnerável” é substituído pelo próprio time de segurança.

Geralmente, esse último cenário não se mantém por muito tempo, pois rapidamente se torna um gargalo. Mas é bom saber que existe.

Pentesting deve ser desafiador para quem faz

Se você contratou um serviço de pentesting ou possui uma equipe dedicada a isso, pense que esses profissionais adoram desafios, então dê trabalho a eles, dificultando ao máximo a possibilidade de encontrar uma brecha na aplicação. Para isso, invista em iniciativas de Segurança de Aplicações que estejam integradas desde o início do ciclo de desenvolvimento. Dessa forma, você potencializa a eficácia e o valor do pentesting.

Portanto, o fluxo apresentado neste artigo pode ser usado independentemente da origem das vulnerabilidades. Pode ser um report de pentest, um email relatando uma vulnerabilidade, ou mesmo um report de #bugbounty. O importante é que o fluxo de tratamento de vulnerabilidade seja uniforme e que se garanta que os passos sejam seguidos. Afinal, você não vai querer que uma vulnerabilidade seja marcada como Mitigada sem retestar, certo?

Lembre-se, pentesting deve ser apenas uma etapa dentro do seu abrangente Programa de Segurança de Aplicações. Não deixe de lado os outros processos.

Pensando sobre Cultura de AppSec

Gabriel Galdino — Thu, 21 Dec 2023 14:21:25 +0000

No Digital AppSec Summit compartilhei algumas ideias sobre como criar uma cultura de Segurança de Aplicações em uma organização.

Transcrevi algumas ideias e opiniões nesse texto, mas para ver a palestra completa, acesse o link, começa no tempo de 1h30m: https://www.youtube.com/watch?v=VanVyPnmIAU&t=6156s

Muitas vezes, quando falamos de cultura, não temos uma definição clara do que isso significa. Quando vejo artigos ou textos tratando sobre o tema, sinto que falta um certo embasamento teórico sobre o que é "cultura", o que passa a impressão de uma subestimação.

Nesse sentido, sempre pontuo duas dimensões muito importante que aprendi durante minha formação nas ciências sociais (Relações Internacionais) sobre o que é cultura: o conhecimento e o poder.

A cultura para Iuri Lotman é o conjunto de significados que são produzidos, transmitidos e transformados pelos seres humanos em suas interações sociais. Assim, acaba sendo um sistema que organiza a realidade e orienta o comportamento dos indivíduos e dos grupos. Ela acaba servindo como uma espécie de memória de longo prazo de uma “comunidade”, que guarda as informações e os valores que são compartilhados por seus membros.

Nesse entendimento, a cultura pode ser vista como uma forma de poder que pode influenciar outras pessoas a realizarem determinadas ações. Essa capacidade da cultura de atrair e persuadir outros indivíduos sem recorrer à força ou à coerção é chamado pelo Joseph Nye como o "soft power".

Compreender esses conceitos ajuda a entender, por exemplo, como a força do cinema norte americano (Hollywood) durante o século XX influenciou a cultura de diversos países, divulgando os valores, os vocabulários sociais, as marcas e os comportamentos que são típicos dos estadunidenses pensando nos valores que os EUA propagavam na época como uma democracia liberal.

Um exemplo dessa força cultural estadunidense propagada pelo cinema hollywoodiano é a calça jeans, um produto que se tornou popular em todo o mundo, atravessando as fronteiras ideológicas da Guerra Fria ao encontrar popularidade até mesmo na União Soviética.

Assim como os países, as empresas também podem ter um “soft power” corporativo, que é o efeito que elas têm na cultura organizacional e nos valores dos seus profissionais. E isso pode afetar a forma como eles lidam com a segurança da informação.

A cultura de segurança das aplicações é uma forma de criar uma mentalidade proativa de segurança nos profissionais ligados ao desenvolvimento de aplicações. Acaba sendo um modo de pensar e de agir que considera a segurança como um requisito fundamental e integrado ao processo de desenvolvimento das aplicações.

A segurança das aplicações é um valor que deve ser compartilhado por todos os profissionais envolvidos no desenvolvimento de software. Para criar uma cultura de AppSec na sua empresa, você pode usar o “soft power”, fazendo por exemplo que a segurança seja parte da identidade e da memória dos seus funcionários, desde o momento em que eles entram na empresa.

É preciso também que as lideranças da organização estejam comprometidas e engajadas com a segurança. Elas devem ser as responsáveis por financiar, apoiar e adotar as iniciativas de cultura organizacional, sendo exemplo de comportamento que elas querem ver nos seus liderados. Investindo assim não só no treinamento, mas também no aprendizado contínuo dos seus profissionais.

Somente assim, com o apoio de todos, a cultura de AppSec pode se tornar uma realidade na sua empresa, e contribuir para a proteção das suas aplicações e dos seus clientes.

Como identificar vulnerabilidades no código fonte?

Gabriel Galdino — Tue, 21 Nov 2023 15:34:52 +0000

Se você é um profissional ou estudante de Segurança de Aplicações, é provável que já tenha se deparado com esta pergunta: “Como posso identificar vulnerabilidades no código fonte?”. Embora pareça uma questão simples, a resposta pode variar bastante, e às vezes uma solução pode parecer mais completa que outra.

Com base na minha experiência na área e em referências importantes, elaborei este artigo para ajudá-lo a responder a essa pergunta com confiança.

Mas, antes de mergulharmos nesse assunto, vamos entender alguns conceitos básicos.

O que é vulnerabilidade?

Segundo o artigo “Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy” do NIST (National Institute of Standards and Technology), vulnerabilidades são pontos fracos que podem permitir que uma fonte de ameaça cause danos a um sistema de informação ou aos dados nele armazenados.

Esses pontos fracos, ou brechas, podem ser causados por falhas no design da aplicação, problemas no código, na configuração, nos procedimentos ou nas medidas de segurança do sistema.

Para isso, a identificação de vulnerabilidades é o primeiro passo no processo conhecido como gestão de vulnerabilidades.

É crucial entender a gestão de vulnerabilidades antes de qualquer coisa

Segundo o NIST, o gerenciamento de vulnerabilidades é definido como a atividade de identificar, avaliar, tratar e reduzir as vulnerabilidades que poderiam ser exploradas ou acionadas por uma fonte de ameaça.

Além desse conceito, a própria Microsoft traz também em seus documentos uma outra abordagem para essa proposta, traduzido na seguinte definição:

“O gerenciamento de vulnerabilidades é uma abordagem baseada em risco para descobrir, priorizar e remediar vulnerabilidades e configurações incorretas.”

Um aspecto frequentemente negligenciado na identificação de vulnerabilidades é o risco associado. Afinal, o objetivo do gerenciamento de vulnerabilidades é minimizar o risco para a organização, mitigando o máximo de vulnerabilidades possível.

Então, antes de iniciar o processo de identificação de vulnerabilidades, é crucial avaliar o risco de cada aplicação do negócio. Essa avaliação pode ajudar a priorizar quais vulnerabilidades precisam de atenção imediata.

Isso destaca a importância de uma organização utilizar práticas de gestão de riscos para orientar seu programa de vulnerabilidades. Mas como fazer isso? Cada organização acaba personalizando seus critérios com base em regras de negócio ou questões técnicas específicas.

Um framework interessante para conduzir a gestão de riscos dos ativos é o ISO 31000, que oferece um conjunto de princípios, diretrizes e processos.

Antes de iniciar o processo de identificação de vulnerabilidades, é importante avaliar o risco de todos os ativos digitais do negócio. Além disso, existem mandatos de Compliance que obrigam a organização a agir em relação a alguns sistemas em específico. Ter esse conhecimento pode ajudar a priorizar as aplicações que precisam de atenção especial.

Deixando tudo pronto para a identificação de vulnerabilidades

Com a gestão de riscos de ativos bem definida, é crucial que algumas questões sejam esclarecidas e estabelecidas antes de iniciar a identificação de vulnerabilidades. Isso garantirá que as vulnerabilidades sejam identificadas e tratadas de maneira consistente.

Aqui estão algumas perguntas que você precisa ter em mente:

Quem é responsável por identificar e corrigir as vulnerabilidades? É importante definir claramente as responsabilidades e os papéis.
Quais ferramentas e técnicas serão utilizadas para identificar as vulnerabilidades? A escolha das ferramentas e técnicas adequadas é crucial.
Quando as vulnerabilidades serão identificadas e corrigidas? É necessário estabelecer um cronograma.
Quais serão os canais de comunicação entre os responsáveis? Como os resultados serão comunicados aos responsáveis? É importante definir um fluxo de comunicação eficaz.
Como o processo será medido e aprimorado?

Com o escopo, a estratégia, as condições e o ambiente bem definidos, estamos prontos para a execução.

Identificando vulnerabilidades: quanto mais cedo, melhor

A melhor estratégia para identificar vulnerabilidades no código fonte é integrá-las ao processo de desenvolvimento. Isso permite que as falhas sejam detectadas mais cedo, quando são mais fáceis de corrigir.

Análises automatizadas

Como estamos focando na etapa de construção de código, logo, vamos entender que no instante de realizar a codificação já é possível começar com uma identificação direta no ambiente do desenvolvedor a partir de ferramentas do tipo SAST (Static Application Security Testing).

Implementar revisões automáticas de teste de segurança no ambiente de desenvolvimento integrado (IDE) pode ajudar os desenvolvedores a identificar vulnerabilidades mais cedo. Isso pode economizar tempo se os desenvolvedores também realizarem treinamentos em codificação segura.

O SAST também pode ser implementado na pipeline de desenvolvimento, juntamente com o SCA (Software Composition Analysis), para avaliar bibliotecas e pacotes de terceiros. Isso ajuda a garantir que todas as vulnerabilidades sejam identificadas antes que o código seja integrado à branch principal.

Existem outras ferramentas de segurança que também podem ser integradas à pipeline de desenvolvimento. No entanto, é importante entender as limitações das ferramentas de análise estática, pois elas não detectam todas as vulnerabilidades, especialmente as mais complexas.

Análises manuais

Temos, por outro lado, a análise manual do código, o famoso Code Review tão comum ao universo de quem desenvolve aplicações. Nesse caso, é importante que os revisores estejam familiarizados com os tipos de vulnerabilidades mais comuns - como o OWASP TOP 10 - e com as técnicas para identificá-las.

Normalmente, essa tarefa é realizada por profissionais de AppSec ou desenvolvedores com conhecimento em segurança.

É importante destacar que, conforme o Guia de Code Review da OWASP, o Code Review é um um processo crucial no ciclo de desenvolvimento seguro, sendo uma das melhores maneiras de identificar vulnerabilidades.

Para realizar a análise manual do código, abordei um pouco do assunto neste artigo. Ele pode ajudar a construir a mentalidade necessária para a revisão de código manual, já que este é um tema complexo que exige um conhecimento profundo em arquitetura e lógica de programação.

Identificando vulnerabilidades em execução

Com a aplicação em execução, podemos realizar uma análise mais ampla e prática da superfície de ataque. A superfície de ataque, segundo a OWASP, descreve todos os pontos onde um invasor pode entrar em um sistema e obter dados.

Com isso em mente, podemos realizar testes de forma experimental, ou seja, de maneira dinâmica.

Análises dinâmicas

As análises dinâmicas testam a segurança de uma aplicação em execução. Elas podem ser realizadas por ferramentas automatizadas, conhecidas como DAST (Dynamic Application Security Testing), que simulam ataques reais contra o software.

A vantagem desse tipo de análise é que ela cobre uma grande parte da superfície de ataque da aplicação, detectando problemas que só aparecem em cenários específicos e fornecendo evidências concretas dos riscos de segurança. No entanto, como qualquer ferramenta de segurança, o DAST tem suas limitações e pode não detectar todas as vulnerabilidades existentes.

De tal maneira, é recomendado utilizar uma abordagem integrada de teste de segurança, que combine as diferentes técnicas e ferramentas disponíveis.

Se você quiser saber mais sobre as ferramentas de segurança para automatizar em seu fluxo DevOps, recomendo este guia da OWASP.

Penetration testing (testes de penetração)

Outra atividade fundamental para a identificação de vulnerabilidades é a realização dos testes manuais do tipo pentesting, também denominados como teste de intrusão ou teste de invasão.

O pentesting é conduzido por profissionais especializados em segurança, usando ferramentas e técnicas específicas. Além disso, existem diferentes abordagens para o pentesting, conhecidas como gray, white e black box:

Gray Box: Neste tipo de teste, os pentesters têm algum conhecimento e acesso ao sistema. Isso permite uma abordagem mais focada, pois os testadores têm uma ideia de onde as vulnerabilidades podem estar.
White Box: Aqui, os pentesters têm acesso total ao código fonte e ao sistema. Isso permite uma análise mais profunda e detalhada, mas também é mais demorado.
Black Box: Neste cenário, os pentesters não têm nenhum conhecimento prévio do sistema. Isso simula um ataque realista de um invasor externo.

Em suma, o processo envolve uma análise ativa da aplicação, simulando ataques reais, em busca de quaisquer vulnerabilidades, falhas técnicas ou fraquezas, tanto conhecidas quanto desconhecidas.

Vale destacar que, diferentemente dos outros métodos, o pentesting pode revelar as vulnerabilidades mais críticas e prioritárias de um sistema, permitindo que sejam corrigidas antes que sejam exploradas por agentes maliciosos. Por outro lado, o pentesting pode criar uma falsa sensação de segurança, se não for feito de forma regular, abrangente e consistente com as demais práticas de identificação de vulnerabilidades.

Existem vários frameworks disponíveis para ajudar a conduzir testes de penetração de maneira eficaz. Um exemplo é o Penetration Testing Execution Standard (PTES), que fornece um conjunto de diretrizes para realizar testes de penetração.

Identificar vulnerabilidades requer uma mentalidade proativa e criativa

A criação de uma política de gestão de vulnerabilidades bem documentada é um passo inicial importante. Esta política deve consolidar as políticas e o escopo do processo, definir papéis e responsabilidades, objetivos do processo, postura de gestão de riscos, tecnologias e ambientes envolvidos, além de quaisquer requisitos adicionais de regulamentação ou conformidade. Isso fornece uma estrutura para o gerenciamento eficaz das vulnerabilidades, incluindo considerações de conformidade.

Automatizar o processo de identificação de vulnerabilidades é outro passo crucial para garantir uma avaliação consistente e periódica de todas as aplicações do negócio. Mas isso é apenas o começo. Treinar os desenvolvedores em codificação segura também é essencial para minimizar a introdução de vulnerabilidades no código desde o início e introduzir uma cultura de segurança no processo.

Portanto, à medida que novas vulnerabilidades são descobertas, é essencial manter nossas ferramentas e técnicas atualizadas. Isso requer uma mentalidade proativa e criativa, sempre buscando aprender e inovar.

Nesse sentido, o monitoramento de logs pode ser um método para identificar vulnerabilidades, fornecendo insights valiosos sobre atividades suspeitas que podem indicar a presença de uma vulnerabilidade. Além disso, a modelagem de ameaças, quando aplicada a uma aplicação já desenvolvida, pode ser uma estratégia interessante para identificar potenciais vulnerabilidades e entender melhor o panorama de ameaças.
Diferentes práticas, quando combinadas, podem fortalecer significativamente a postura de segurança de uma organização.

*Me diz agora: você acha que faltou alguma atividade ou algo importante no texto? Estou ansioso para ler seu comentário. *

Dicas de codificação segura em C#

Gabriel Galdino — Tue, 07 Nov 2023 14:26:43 +0000

Você sabia que C# está entre as 4 linguagens de programação mais populares no mundo, segundo dados do Programming Language Index? Se você é uma pessoa desenvolvedora em C#, é bem provável que tenha interesse em aperfeiçoar suas práticas nessa linguagem, inclusive no que tange à segurança de aplicações, tema que está cada vez mais em alta à medida que aumenta os casos de crimes cibernéticos.

C# é uma das linguagens de programação que fazem parte do .NET, que é uma plataforma para desenvolvimento de software da Microsoft. O .NET fornece um ambiente de execução, uma biblioteca de classes e vários serviços que facilitam o trabalho dos desenvolvedores. Esses recursos são fáceis de usar, versáteis e poderosos. Você pode usar C# e .NET para criar vários tipos de aplicações: desktop, web e jogos.

Mas essas tecnologias também têm seus riscos. A maioria das aplicações dessa linguagem pode simplesmente usar a infraestrutura implementada pelo .NET. Em alguns casos, é necessária segurança adicional e específica da aplicação. Por isso, desenvolvimento seguro em C# significa seguir algumas práticas recomendadas que evitam introduzir vulnerabilidades de segurança mais comuns no software.

Neste artigo, iremos apresentar algumas das práticas e princípios que a OWASP (Open Worldwide Application Security Project) e a Microsoft recomendam para desenvolvedores. Seguindo essas dicas, você vai proteger sua aplicação contra algumas ameaças de segurança e agregar valor e qualidade ao seu código.

Estude os padrões, estruturas e frameworks da linguagem

A segurança no mundo do C# geralmente está relacionada ao .NET Framework. De tal forma, uma das vantagens de trabalhar com um framework sólido é que ele oferece padrões eficazes que ajudam a manter as aplicações seguros.

Com o ASP.NET Core 7.0, o framework tornou-se ainda mais robusto. Como desenvolvedor, é importante que você compreenda esses padrões e saiba como garantir que eles não sejam comprometidos.

Dessa forma, a segurança de suas aplicações web com ASP.NET Core depende de vários fatores e práticas a serem considerados e implementados. Algumas recomendações importantes de segurança destacadas pela documentação que você precisa conhecer são:

Usar autenticação e autorização baseadas em tokens: o processo de verificar a identidade de um usuário, enquanto autorização é o processo de verificar as permissões de um usuário. ASP.NET Core oferece vários mecanismos para implementar autenticação e autorização nas suas aplicações web, como o Identity, que é um sistema integrado para gerenciar usuários, senhas, perfis e funções.
Usar limitação de taxa: uma técnica para controlar o número de requisições que um cliente pode fazer aos seus serviços em um determinado período de tempo.
Utilizar mecanismo CORS (Cross-Origin Resource Sharing): um mecanismo que permite ou bloqueia requisições de origens diferentes do seu domínio.
Usar técnicas de registro e monitoramento: são técnicas para acompanhar as atividades e os eventos dos seus serviços e detectar possíveis problemas ou ameaças à segurança.

Em resumo, é fundamental realizar uma pesquisa aprofundada sobre o framework, seus principais recursos e as ferramentas que você está utilizando na aplicação. Vale lembrar que essas práticas não são as únicas e nem as definitivas, mas são um bom ponto de partida para você começar a entender sobre a profundidade da segurança de suas aplicações.

Mantenha seu framework, bibliotecas e pacotes de terceiros atualizados

O framework e as bibliotecas que você utiliza no seu código são essenciais para o funcionamento e a qualidade do seu software. Mas eles também podem ser alvos de ataques cibernéticos, principalmente se não forem verificados e atualizados com frequência.

Para evitar isso, você deve manter suas bibliotecas sempre atualizadas com as versões mais recentes. Isso vai garantir que você tenha os recursos, as correções e as melhorias de segurança atualizadas. Ademais, isso evitará problemas de compatibilidade ou desempenho que podem ocorrer com versões desatualizadas.

Uma forma fácil e prática de atualizar o seu framework e as suas bibliotecas é usar o NuGet, um gerenciador de pacotes para .NET. O NuGet permite que você instale, remova e atualize os pacotes utilizados em sua aplicação.

Além disso, você pode usar uma ferramenta SCA (Software Composition Analysis) para complementar o NuGet na atualização do seu framework e das suas bibliotecas. Uma ferramenta SCA pode verificar se os pacotes que você usa estão atualizados, se eles têm alguma vulnerabilidade conhecida, se eles são compatíveis com as licenças do seu projeto e se eles têm alguma dependência transitiva que você não conhece

Siga as boas práticas e os cuidados necessários ao usar a criptografia

A criptografia, em termos simples, é uma forma de transformar os seus dados em um código secreto que só pode ser lido por quem tem a chave certa. Ela é essencial para garantir a segurança, a privacidade e a integridade dos dados confidenciais de sua aplicação.

A primeira e mais importante regra da criptografia é: não tente inventar a sua criptografia. Criar um algoritmo criptográfico seguro é uma tarefa muito difícil e complexa, que requer muito conhecimento e experiência.

Por isso, você deve usar os algoritmos criptográficos que já foram testados e aprovados por especialistas em criptografia. Esses algoritmos são baseados em princípios matemáticos sólidos e foram submetidos a um rigoroso processo de análise e revisão.

Não se esqueça que o .NET framework é o seu facilitador. Ele oferece várias implementações de algoritmos criptográficos padrão, que você pode usar em suas aplicações em C#. Você pode encontrar esses algoritmos na biblioteca System.Security.Cryptography.

Vale destacar que é necessário utilizar os algoritmos mais fortes e modernos que estão disponíveis no .NET framework, pois eles oferecem uma maior proteção contra ataques e uma melhor eficiência na execução.

Não confie nas entradas dos usuários

De maneira geral, as entradas dos usuários representam as informações recebidas do lado do client, e, em segurança, a regra de ouro é não confiar cegamente no que os usuários possam inserir nas aplicações. Por exemplo, imagine que você tem um método que recebe um número e calcula a sua raiz quadrada. Se você usar os dados do usuário como parâmetro para esse método, um agente mal intencionado pode enviar um valor negativo ou muito grande, e fazer o seu método dar um erro ou travar.

Para evitar esses problemas, é crucial verificar e validar os dados de entrada do usuário. Isso envolve pensar em todos os possíveis valores que esses dados podem ter e rejeitar aqueles que não são válidos ou esperados.

Além disso, é importante seguir algumas dicas de segurança fornecidas nesta documentação oficial, tais como:

Evite usar funções como Eval ou inserir tags <script> nas aplicações web.
Não confiar na URL solicitada pelo lado do client. Um atacante pode modificar a URL para acessar recursos não autorizados ou enviar dados falsos.
Não aceitar caminhos de arquivos estranhos ou inválidos. Evite o uso de caracteres especiais (*), expansão de tokens (%token%), nomes alternativos de fluxo ou versões curtas de nomes de arquivos (.filename::$DATA).

Fique por dentro das defesas contra ataques do tipo Injection

Injection está na terceira posição do OWASP Top 10, lista das dez categorias de ameaças mais comuns de segurança em aplicações web. O Injection pode afetar vários tipos de interpretadores, como SQL, NoSQL, OS command, LDAP e outros.

O SQL Injection, por exemplo, ocorre quando um atacante insere dados maliciosos em uma consulta SQL que é executada pelo seu banco de dados. Isso pode permitir que o atacante acesse, modifique ou apague dados sensíveis, ou execute comandos arbitrários no seu servidor.

Se você concatenar os dados fornecidos pelo usuário em uma consulta SQL sem validar ou escapar, você pode criar uma vulnerabilidade de SQL Injection.

Para evitar esse tipo de ataque, é essencial seguir as diretrizes de segurança recomendadas pela OWASP:

Utilize, sempre que possível, um Mapeador Relacional de Objetos (Object-Relational Mapper; ORM) ou procedimentos armazenados (stored procedures) sempre que possível, pois são umas das formas mais eficazes de combater essas vulnerabilidades. Além disso, faça o uso também de consultas parametrizadas sempre que precisar empregar uma consulta SQL direta.

Por exemplo, usando o Entity Framework:

var sql = @"Update [User] SET FirstName = @FirstName WHERE Id = @Id"; context.Database.ExecuteSqlCommand( sql, new SqlParameter("@FirstName", firstname), new SqlParameter("@Id", id));

Evite a concatenação de strings em seu código para criar consultas que serão executadas em seu banco de dados. Isso pode ser feito acidentalmente, mesmo com ORM ou procedimentos armazenados, portanto, verifique sempre. Por exemplo:

string sql = "SELECT * FROM Users WHERE UserName='" + txtUser.Text + "' AND Password='" + txtPassword.Text + "'"; context.Database.ExecuteSqlCommand(sql); // SQL Injection!

Para se prevenir aos demais tipos de Injection siga as demais recomendações informadas nesta documentação da OWASP.

Proteja os seus segredos com segurança

Segredos ou secrets são informações confidenciais que você usa no seu código, como chaves de API, senhas de banco de dados, tokens de acesso e outros dados sensíveis. Esses segredos são essenciais para o funcionamento da sua aplicação, mas também são um alvo tentador para os atacantes. Se os seus segredos forem expostos, você pode comprometer a segurança e a privacidade dos seus sistemas e dados.

Uma das formas mais comuns de expor os segredos de codificação é codificá-los diretamente no seu código-fonte. Para evitar isso, você deve guardar os seus segredos em um lugar seguro, longe do seu código.

Uma prática segura comum é a de utilizar variáveis de ambiente para armazenar segredos. As variáveis de ambiente são armazenadas fora do nosso código e podem ser acessadas pela aplicação em tempo de execução. Para definir uma variável de ambiente, podemos usar o seguinte comando em um terminal ou prompt de comando:

set VARIABLE_NAME = "secret-value"

Para recuperar o valor de uma variável de ambiente em nosso código C#, podemos usar o seguinte trecho de código:

var secretValue = Environment.GetEnvironmentVariable("VARIABLE_NAME");

Mas atenção, você também deve evitar que os seus segredos sejam vazados por outros meios, como repositórios do Github e Gitlab ou em logs. Para isso, você pode usar ferramentas como o Git Secrets ou o Azure Key Vault para gerenciar os seus segredos.

Desenvolvimento seguro em C# deve ser uma jornada contínua

Em um cenário de crescente ameaça cibernética, a segurança se tornou um dos maiores desafios para desenvolvedores atualmente. Não podemos mais negligenciar a proteção do nosso código e de nossas aplicações.

Para isso, é fundamental adotar as melhores práticas de codificação segura, que têm o poder de prevenir ou minimizar os tipos mais comuns de ataques. Essas práticas não devem ser consideradas como um obstáculo, mas como um alicerce sólido para construir aplicações robustas e confiáveis aos usuários.

No geral, a codificação segura em C# requer uma abordagem proativa e atenção aos detalhes. Ao seguir as práticas recomendadas discutidas neste artigo, você estará reduzindo de maneira significativa o risco de vulnerabilidades de segurança em seu código.

Para você seguir sua jornada de codificação segura C#, recomendo as seguintes referências técnicas de segurança de aplicações em C#:

Codificação segura, por que todos devs precisam conhecer?

Gabriel Galdino — Thu, 24 Aug 2023 23:07:06 +0000

Olá! Se você chegou até este artigo, então imagino que tenha um pouco de curiosidade e interesse em saber mais sobre Segurança de Aplicações. Você precisa conhecer um dos seus princípios básicos: a segurança deve ser integrada desde o começo do processo de desenvolvimento. Mas o que isso quer dizer?

Quer dizer que, ao criar um software, você não pode deixar a segurança de lado ou como sendo exclusiva apenas de um time... Você tem que considerar todos os aspectos do seu projeto, como os fluxos de informações, requisitos, funcionalidades, arquitetura, stacks e tecnologias etc. A segurança deve fazer parte de todas essas esferas, e não ser apenas um complemento.

Dessa forma, ao construir uma aplicação, logo na etapa de desenvolvimento, uma das primeiras preocupações que temos como desenvolvedores é em criar o código, compilar e executar a funcionalidade que estamos desejando construir. Muitas vezes, nós desenvolvedores temos a tentação de “fazer gambiarra” e escrever milhares de linhas de código sem seguir nenhuma boa prática de “code clean”. E isso é um problema?

Bom, a Segurança de Aplicações não quer limitar a sua criatividade ou impor regras rígidas no seu processo. Pelo contrário, AppSec quer te orientar e te ajudar a usar a sua criatividade para construir código mais seguro. Como?

Por meio das capacitações em “codificação segura”, que são treinamentos que podem ser realizados por vídeo chamadas ou por plataformas com exercícios prontos em ambientes virtualizados que usam a gamificação para motivar os participantes com pontos. Uma espécie de Duolingo para a resolução de problemas de segurança em um código fictício, mas parecido com casos reais.

A codificação segura é essencial para os desenvolvedores porque atua como um facilitador em vários aspectos, como:

Shift-left: inserindo segurança no início do ciclo de desenvolvimento
Conscientização em AppSec
Resolução de problemas em tempo real
Agilidade na hora de inserir segurança na esteira
Colaboração entre times de segurança e de desenvolvimento

Na Conviso, a codificação segura funciona como parte do processo de gestão de vulnerabilidades. Ou seja, na plataforma, quando você identifica uma vulnerabilidade, você recebe uma trilha de exercícios para treinar e aprender como corrigi-la.

Caso tenha ficado curioso, recomendo olhar esta documentação.

Existem outras plataformas que oferecem esse tipo de treinamento, como o Secure Flag, Security Journey, AppSec Engineer e muitas outras!

Ficou curioso em resolver problemas de código inseguro? Acompanhe a hashtag #CodeFighters da conta do Twitter da Conviso, onde publicamos código com vulnerabilidade para desafiar o público geral.

Espero que esse texto tenha te inspirado a iniciar os estudos em AppSec! Até a próxima.

Explicando o TOP 4 da OWASP "Design Inseguro" para desenvolvedores

Gabriel Galdino — Thu, 23 Feb 2023 18:23:08 +0000

Olá, mais uma vez!

Vamos agora falar de uma categoria nova e que chamou bastante a atenção quando foi lançada pelo OWASP TOP 10 em 2021, o "Design Inseguro".

Vou esclarecer brevemente sobre ela neste texto, uma vez que algumas pessoas podem ter dificuldade em compreendê-la.

Aqui você pode aprender mais sobre a importância do design seguro.

O que é "Design Inseguro"

A categoria de risco "Design Inseguro", na 4ª posição do OWASP TOP 10, se concentra nos riscos relacionados a falhas de design e arquitetura, com um apelo para o uso de modelagem de ameaças e padrões de design seguros.

Assim como uma casa, que precisa de um bom projeto arquitetônico para garantir que seja segura e funcional, um software também precisa de um bom design para garantir que seja seguro e confiável.

Mas não é só corrigir as vulnerabilidades na hora da implementação?

Não é bem assim...

O design inseguro e a implementação insegura são conceitos diferentes visto que possuem causas e remediações distintas!

Enquanto um design seguro ainda pode ter problemas de implementação, um design inseguro não pode ser corrigido apenas com uma implementação perfeita, já que os controles de segurança necessários nunca foram criados para se defender contra ataques específicos.

Ou seja, mesmo que a implementação seja feita de forma perfeita, o design inseguro permanece, e é necessário investir um tempo pensando no design seguro para garantir a segurança do sistema.

Então tudo começa no início

Uma das causas para o design inseguro é a falta de compreensão dos riscos de negócios inerentes ao software que está sendo desenvolvido.

Portanto, é essencial que desenvolvedores considerem os riscos de segurança desde o início do projeto, para garantir que o software tenha um design seguro e implementação correta, garantindo a segurança da aplicação.

Quais são as vulnerabilidades dessa categoria?

Até aqui muito abstrato, certo? Falhas de design inseguro ocorrem quando equipes de desenvolvimento, qualidade e segurança não consideram ou avaliam adequadamente as ameaças durante a fase de design do código.

Com o cenário de ameaças em constante evolução, a mitigação das vulnerabilidades de design requer uma modelagem de ameaças consistente para evitar métodos de ataque conhecidos. Sem um design seguro, é difícil identificar e corrigir falhas arquitetônicas, como:

Armazenamento desprotegido de credenciais;
Falhas de projeto no gerenciamento de identidade e acesso;
Violações de limite de confiança que podem levar a Injection;
Geração de mensagens de erro contendo informações confidenciais;

Na documentação da OWASP você pode encontrar mais detalhes sobre essas vulnerabilidades.

Como desenvolvedores podem se prevenir?

Para prevenir vulnerabilidades de design inseguro, é fundamental aplicar uma mentalidade "shift left", trazendo a segurança desde o início do ciclo de desenvolvimento de software. Para tanto, é importante ter conhecimento do framework OWASP SAMM a fim de entender melhor sobre todos esses processos.

Temos essa série que sintetiza o OWASP SAMM para profissionais da área.

Faça uma modelagem de ameaças

Uma das maneiras mais eficazes de garantir que a segurança seja considerada desde o início é através da modelagem de ameaças. Ela é uma técnica usada para identificar potenciais ameaças e vulnerabilidades em um sistema e gerar requisitos de segurança.

Ao fazer a modelagem de ameaças no início do ciclo de desenvolvimento, as equipes podem antecipar e mitigar as vulnerabilidades de segurança, economizando tempo e dinheiro em correções tardias e, possivelmente, em violações de segurança.

Construa seguro desde cedo

Espero que tenha ficado claro sobre o risco de "Design Inseguro" que, embora muitos ainda acreditem que a segurança deva ser implementada apenas na fase final, é essencial considerar os riscos de segurança desde o início do projeto.

Sendo assim, a modelagem de ameaças é uma das maneiras mais eficazes de garantir que a segurança seja considerada logo na etapa de planejamento.

Você pode aprender mais sobre modelagem de ameaças aqui.

Consulte aqui a documentação inteira da OWASP.

Roteiro com Cursos Gratuitos em Ciência da Computação

Gabriel Galdino — Thu, 16 Feb 2023 14:22:16 +0000

A Ciência da Computação é um campo em constante evolução e pode ser difícil saber por onde começar.

Pensando nisso, preparei um roteiro com uma formação básica em Ciência da Computação, usando materiais on-line e de qualidade. Este roteiro tem como base os Referenciais de Formação para Cursos de Graduação em Computação, da Sociedade Brasileira de Computação e cursos recomendados pela comunidade de tecnologia.

O roteiro é dividido em três partes, para que você possa começar do zero e progredir para tópicos mais avançados:

Introdução à Computação - essa parte contém cursos de introdução à programação e ciência da computação.
Aprofundamento de Conceitos Introdutórios - aqui você começará a aprofundar seus conhecimentos em ciência da computação.
Tópicos Finais - nessa etapa, você aplicará todo o conhecimento adquirido nos tópicos anteriores para técnicas avançadas de computação.

Todos os cursos recomendados neste roteiro podem ser realizados gratuitamente, embora alguns cursos tenham diplomas, certificados ou atividades opcionais pagas, como a Coursera.

Introdução à Computação

Programação para iniciantes | Série "Começando aos 40"
por Fabio Akita via Youtube. Para acessar, clique aqui.
Introdução à Ciência da Computação I
pela USP via Coursera. Para acessar, clique aqui.

Aprofundamento de Conceitos Introdutórios

Introdução à Ciência da Computação II
pela USP via Coursera. Para acessar, clique aqui.
Laboratório de Programação Orientada a Objetos
pela USP via Coursera. Para acessar, clique aqui.

Para seguir uma área específica em Programação, sugerimos que você confira o roadmap.sh, que é um esforço da comunidade para criar roteiros, guias e outros conteúdos educacionais para ajudar a orientar os desenvolvedores a escolher o caminho e orientar seus aprendizados.

A Trilha Info tem o objetivo de agregar e organizar conteúdos gratuitos em português para pessoas que querem ingressar na área de Tecnologia. As linguagens exigidas nas vagas da Conviso são Python, Javascript, Go e Ruby.

Tópicos Finais

DevOps & Agile Culture
pela FIAP. Para acessar, clique aqui.
Princípios de Desenvolvimento Ágil de Software
pelo ITA, via Coursera. Para acessar, clique aqui.
Essentials
via Linux. Para acessar, clique aqui.
Introdução à Cibersegurança
pela University of Washington, via EDX. Para acessar, clique aqui.

Dicas

Além disso, tenho algumas dicas bônus para você. O curso Aprendendo a aprender: ferramentas mentais poderosas para ajudá-lo a dominar assuntos difíceis, via Coursera, ajudará você a aprender melhor e mais rápido. E, por fim, o curso Como estudar do jeito certo, via Youtube, ajudará você a ser mais eficiente em seus estudos.

Com este roteiro, espero que você possa começar sua jornada na área de tecnologia. Lembre-se de que a prática é fundamental, então pratique sempre que puder.

Boa sorte em seus estudos!

Explicando o TOP 3 da OWASP "Injection" para desenvolvedores

Gabriel Galdino — Thu, 09 Feb 2023 20:49:54 +0000

Dando seguimento a nossa série das principais categorias de riscos do OWASP TOP 10, em terceira posição temos o "Injection".

Neste artigo, apresentarei sobre o que é essa categoria de risco, os tipos de ataques que existem, bem como os cenários em que ela pode ser explorada. Dessa forma, compartilharei informações importantes para ajudar desenvolvedores a protegerem suas aplicações contra essa ameaça.

O que é "Injection"?

Injection é um risco referente à situação quando dados fornecidos pelo usuário não são validados, filtrados ou sanitizados pela aplicação, permitindo que um invasor insira (Injete, por isso a palavração "injeção") comandos maliciosos nas entradas de dados.

Isso pode levar a roubo de informações confidenciais ou a comprometimento do sistema. Invasores aproveitam falhas de validação de entrada, como o formato de dados, caracteres permitidos e quantidade de dados esperados, para desenvolver códigos maliciosos

Anteriormente, era comum associar o ataque "Injection" ao SQL Injection (SQLi), entretanto, o OWASP TOP 10 mas recente (2021) inclui outros diversos tipos de ataques, incluindo o SQLi, nessa categoria.

Saiba por que SQL Injection é tratada como "baratas digitas".

Vamos ampliar um pouco mais sobre os tipos de Injection

SQL INJECTION

Como foi dito anteriormente, é um dos mais conhecidos da categoria e se refere a quando um atacante consegue inserir comandos maliciosos em uma consulta SQL, a fim de manipular ou acessar informações não autorizadas do banco de dados.

CROSS-SITE SCRIPTING

É quando o atacante consegue injetar scripts maliciosos no conteúdo do site alvo, que é então incluído com o conteúdo dinâmico entregue ao navegador da vítima. O navegador da vítima não tem como saber que os scripts maliciosos não são confiáveis e, portanto, os executa.

OS COMMAND INJECTION

Quando uma aplicação permite que um atacante induza uma aplicação a executar comandos do sistema operacional (SO). Também conhecido como injeção de shell.

ORM INJECTION

Se refere a quando um atacante consegue inserir comandos maliciosos em uma consulta ORM.

LDAP INJECTION

Ataque usado para explorar aplicações que constroem declarações LDAP com base na entrada do usuário. Quando uma aplicação falha em sanitizar adequadamente a entrada do usuário, é possível modificar as declarações LDAP usando um proxy local.

EXPRESSION LANGUAGE INJECTION

Ocorre quando uma aplicação incorpora dados controláveis pelo usuário em uma string que é avaliada dinamicamente por um interpretador EL. Se os dados não forem validados, um invasor pode usar a entrada para modificar o código e injetar código malicioso que será executado pelo servidor.

Cenários de ataque

Cenário #1: Uma aplicação usa dados não confiáveis na construção da seguinte chamada SQL vulnerável:

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

Cenário #2: Da mesma forma, a confiança cega de uma aplicação em frameworks pode resultar em consultas ainda vulneráveis (por exemplo, Hibernate Query Language (HQL)):

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

Em ambos os casos, o invasor modifica o valor do parâmetro 'id' no seu navegador para enviar: ' or '1'='1. Por exemplo:

http://example.com/app/accountView?id=' or '1'='1

Isso altera o significado das duas consultas para retornar todos os registros da tabela accounts. Ataques mais perigosos poderiam modificar ou excluir dados ou até invocar procedimentos armazenados.

Como desenvolvedores podem se prevenir a esse tipo de ataque?

A opção preferencial é usar uma API segura, que evita totalmente o uso do interpretador, fornecendo uma interface parametrizada ou migrando para uso Object Relational Mapping Tools (ORMs).

Utilizar LIMIT e outros controles SQL dentro das consultas para prevenir a divulgação em massa de dados em caso de Injection.

Realizar a validação de entrada do lado do servidor.

Vale lembrar que a OWASP tem uma série de outras medidas importantes que se precisa ter em mente contra esse risco, veja aqui!

Uma das formas mais antigas de ataque e também uma das mais comuns

Ter conhecimento do OWASP Top 10 Injection é importante para nós, desenvolvedores, pois mesmo com vários recursos disponíveis para lidar com esse tipo de ataque, ele ainda é um dos mais comuns.

Ao não validar ou codificar corretamente a entrada de dados do usuário, uma aplicação corre o risco de permitir a execução de código malicioso que pode afetar a segurança de toda a aplicação. Por isso, é crucial que desenvolvedores estejam cientes dos riscos desse tipo de vulnerabilidade e saibam como ser defensivos na hora do desenvolvimento!

Fique por dentro sobre SQL Injection.

Explicando o TOP 2 da OWASP "Falhas Criptográficas" para desenvolvedores

Gabriel Galdino — Thu, 02 Feb 2023 14:12:17 +0000

Seguindo a nossa série sobre OWASP TOP 10 de 2021, temos como segunda categoria de risco mais comum a "Cryptographic Failures" ou "Falhas Criptográficas" em português.

Se você estiver construindo um software sem se preocupar com os aspectos de segurança, será como construir uma casa sem trancas nas portas e janelas. Portanto, todo engenheiro de software precisa ter conhecimento geral sobre as maneiras pelas quais é necessário proteger as aplicações e a criptografia é uma delas.

Quer saber mais sobre a OWASP, confira este artigo.

Mas o que são as criptografias?

Criptografia é a arte/ciência da escrita secreta. Quando falamos de criptografia, estamos nos referindo a um processo para codificar informações, fazendo com que ela se torne inelegível para terceiros não autorizados. Para isso, diferentes técnicas são utilizadas, incluindo a cifra, a chave e algoritmos.

Em resumo, a cifra é a técnica específica usada para codificar a informação; a chave é o elemento secreto utilizado para decodificar a informação codificada; enquanto os algoritmos de criptografia são os métodos matemáticos que fazem a cifra funcionar de forma eficiente.

Juntos, esses elementos formam a criptografia, mas o tema pode ficar ainda mais complexo! Além disso, temos alguns tipos de criptografia.

Criptografia de chave simétrica: Este é um tipo de criptografia em que apenas uma chave (uma chave secreta) é usada para criptografar e descriptografar texto simples e texto cifrado. Existem vários tipos de criptografia de chave simétrica:

Data Encryption Standard (DES);
Electronic Code Book (ECB);
Cipher block Chain(CBC);
Advanced Encryption Standard (AES).

A principal vantagem da criptografia simétrica é que é mais rápida em performance por usar uma só chave, e uma das principais é o uso da mesma chave tanto para criptografar como para descriptografar os dados, gerando problemas de segurança.

Criptografia de chave assimétrica: Este é um tipo de criptografia que usa duas chaves separadas, mas matematicamente relacionadas, para criptografar e descriptografar dados. A chave pública criptografa os dados enquanto sua chave privada correspondente os descriptografa.

Algumas das criptografias de chave assimétrica são:

Algoritmo RSA;
Algoritmo Diffie Hellman;
Algoritmo de curva elíptica Diffie Hellman;
Algoritmo de Assinatura Digital.

A principal vantagem da criptografia assimétrica é que ela elimina o problema de distribuição de chaves, pois usa dois pares. A desvantagem é que será lento devido à geração e uso de dois pares de chaves.

Preciso criar minha própria criptografia?

Criar uma criptografia segura e confiável é extremamente difícil e requer muito conhecimento e experiência na área. Portanto, não, desenvolvedores não precisam se preocupar com isso!

Algoritmos criptográficos reconhecidos são submetidos a vários testes rigorosos de segurança antes de serem considerados seguros o suficiente para uso.

Além disso, essas criptografias são frequentemente incluídas em bibliotecas, sendo fáceis de usar e integrar a aplicações.

Pensando no cotidiano de quem desenvolve, temos o caso comum de uso da “criptografia de senhas”.

Quando os usuários criam contas em uma aplicação web, por exemplo, é importante que as senhas sejam armazenadas de forma segura para evitar vazamentos.

Em vez de armazenar as senhas como texto simples, podemos usar uma biblioteca de criptografia para codificar as senhas, como a biblioteca "bcrypt" em Python.

Mas e se o mecanismo criptográfico dessa biblioteca falhar? É o que veremos no próximo ponto.

Falhas criptográficas

Em 2021, o OWASP TOP 10 de 2021 chama a atenção para essa categoria de risco de segurança para aplicações web.

Nela, a OWASP lista erros comuns na implementação da criptografia que colocam em risco a segurança de dados do nosso sistema, como:

o uso de algoritmos antigos ou fracos;
chaves inseguras;
gerenciamento inadequado de chaves,
falta de validação de certificados de servidor;
uso inadequado de senhas como chaves, funções obsoletas, entre outros problemas.

Impacto

Quando uma falha de criptografia ocorre, é possível que invasores tenham acesso a dados sensíveis, como informações financeiras, senhas e dados pessoais, o que pode resultar em perdas financeiras, riscos de vazamento de informações e outros danos irreparáveis.

Além da perda financeira, falhas desse tipo também podem afetar a confiança dos usuários e a imagem da marca.

Por esses motivos, é importante que as aplicações sejam desenvolvidas com segurança criptográfica adequada.

Recomendações importantes da OWASP

O OWASP Top 10 traz algumas práticas importantes para evitar as falhas criptográficas:

Classificar os dados processados, armazenados ou transmitidos pela aplicação e identificar quais são sensíveis de acordo com leis de privacidade, regulamentos ou necessidades comerciais;
Não armazenar dados sensíveis desnecessariamente;
Criptografar todos os dados sensíveis que estão em repouso;
Garantir que algoritmos, protocolos e chaves atualizados e fortes estejam em uso e utilizar gerenciamento de chaves adequado.
Criptografar todos os dados em trânsito com protocolos seguros como TLS com cifras de segredo para frente e priorização de cifra pelo servidor. Forçar a criptografia usando diretivas como HTTP Strict Transport Security (HSTS);
Desativar cache para respostas que contêm dados sensíveis;
Aplicar controles de segurança necessários de acordo com a classificação de dados;
Não usar protocolos legados como FTP e SMTP para transportar dados sensíveis;
Armazenar senhas usando funções de hash adaptativas e salgadas com fator de trabalho, como Argon2, scrypt, bcrypt ou PBKDF2;
Escolher vetores de inicialização apropriados para o modo de operação. Para muitos modos, isso significa usar um gerador de números pseudo-aleatórios seguro (CSPRNG). Para modos que exigem um não-repetido, o vetor de inicialização (IV) não precisa ser gerado por um CSPRNG. Em todos os casos, o IV nunca deve ser usado duas vezes com a mesma chave;
Usar sempre criptografia autenticada ao invés de apenas criptografia;
Gerar chaves de forma aleatória e armazená-las na memória como matrizes de bytes. Se uma senha for usada, ela deve ser convertida em uma chave através de uma função adequada de derivação de chave baseada em senha;

E muitas outras medidas importantes!

Criptografia não precisa ser um bicho de sete cabeças!

Desenvolvedores são a primeira linha de defesa da segurança de uma aplicação e para isso é necessário conhecer como funciona a essência da criptografia, sem se apegar às detalhes estatísticas ou altamente complexas que envolvem algoritmos, por exemplo.

Além disso, é necessário fazer parte da nossa rotina de desenvolvimento verificar se estamos usando algoritmos e protocolos criptográficos atualizados e fortes, com gestão de chaves adequada e com validação correta do certificado do servidor.

Em resumo, a falta de conhecimento pode levar a vulnerabilidades que podem ser exploradas por atacantes, colocando dados e informações confidenciais em risco.

Para mais conteúdos sobre a OWASP TOP 10, acesse este artigo.

Para mais dicas da OWASP!

Explicando o TOP 1 da OWASP "Broken Access Control" para desenvolvedores

Gabriel Galdino — Wed, 25 Jan 2023 18:38:05 +0000

A OWASP (Open Web Application Security Project) é uma organização sem fins lucrativos que tem como objetivo fornecer recursos e ferramentas para ajudar os desenvolvedores a criar aplicações mais seguras. Um desses recursos é o OWASP TOP 10, que representa uma lista com as principais categorias de riscos de segurança para aplicações web.

A primeira categoria é o Broken Access Control, ou em português “Quebra de Controle de Acessos”. Vou explicar neste texto como ela funciona e porquê nós devemos estar cientes desse tipo de risco na hora de construir uma aplicação.

Antes de começar, é importante que devs tenham contato com o OWASP TOP 10 porque são eles os principais responsáveis pela construção e manutenção das aplicações. Conhecer esses riscos, suas vulnerabilidades e tipos de ataques, podem ajudá-los a identificar e corrigir problemas de segurança antes de serem explorados por atacantes.

Quer saber mais sobre a OWASP, confira este artigo.

Mas antes de pensar na quebra, o que seria o “Controle de Acessos”?

O controle de acesso em aplicações web é o processo de garantir que somente usuários autorizados tenham acesso a recursos e funcionalidades específicas do aplicativo. Ele é composto de duas partes principais: autenticação e autorização.

A autenticação é o processo de verificação da identidade do usuário. Ele garante que somente usuários legítimos possam acessar o aplicativo. Isso pode ser feito por meio de login e senha, tokens de acesso, certificados digitais, entre outros. Por outro lado, a autorização é o processo de garantir que um usuário autenticado tenha acesso somente aos recursos e funcionalidades para os quais ele foi autorizado. Isso é feito através de permissões e papéis de usuários

O controle de acesso em aplicações web é importante para garantir a segurança dos dados e sistemas, impedindo acesso não autorizado e protegendo contra ameaças como ataques de força bruta, roubo de identidade e vazamentos de informações confidenciais.

Exemplos de Controles de Acesso em Software:

Gestão de contas;
Mapeamento dos direitos dos usuários para requisitos de negócios e processos;
Mecanismos que impõem políticas sobre o fluxo de informações;
Limites no número de sessões simultâneas;
Bloqueio de sessão após um período de inatividade;
Encerramento da sessão após um período de inatividade, tempo total de uso ou hora do dia;
Limitações no número de logs retornados de uma consulta (mineração de dados);
Apresenta políticas de aplicação de segregação de funções;
Segregação e gerenciamento de contas de usuários privilegiados;
Implementação do princípio do menor privilégio para a concessão de acesso;
Exigir VPN (rede privada virtual) para acesso;
Reconfiguração dinâmica de interfaces de usuário com base em autorização;
Restrição de acesso após uma determinada hora do dia.

A01 "Broken Access Control" - a Quebra de Controle de Acessos

Broken Access Control é o risco de segurança de aplicações web mais comum, segundo a OWASP, e foi classificado como o #1 em 2021. Isso representa um salto significativo em relação ao seu lugar anterior de #5 em 2017.

Em resumo, o "Broken Access Control" é uma categoria de risco porque é uma falha no mecanismo de controle de acesso, permitindo que usuários acessem recursos ou realizem ações fora de suas permissões. Ou seja, ocorre quando as verificações de autorização e autenticação são mal implementadas, permitindo que usuários não autorizados acessem recursos e dados confidenciais.

Isso pode incluir violação do princípio de menor privilégio ou negação por padrão, onde o acesso deve ser concedido somente para capacidades, papéis ou usuários específicos, mas está disponível para qualquer um que tenha acesso. Outras vulnerabilidades comuns incluem: burlar as verificações de controle de acesso, permitir visualização ou edição de contas de outros usuários, acessando API sem controles de acesso, manipulação de metadados e falhas na configuração do CORS.

Mas por que esse risco está em primeiro lugar? Com o Broken Access Control representando uma ameaça mais ampla,a falta de experiência em segurança de aplicações pelos devs, protocolos de segurança complexos e a diversidade de soluções de gerenciamento de acesso são alguns dos motivos pelos quais este risco é tão comum.

Quer aprender sobre esta categoria em vídeo, clique aqui e acesse o curso sobre OWASP TOP 10.

Impacto

E o que acontece quando as pessoas têm acesso a informações que não deveriam ter?
Em um ataque bem-sucedido, um agente mal-intencionado pode ser capaz de acessar conteúdo não autorizado, alterar ou excluir conteúdo, executar funções e até mesmo assumir o controle total da administração do site.

Uma vez que esse nível de comprometimento tenha sido alcançado, o dano do ataque é limitado apenas pelos privilégios concedidos ao perfil de usuário da aplicação que sofre o ataque.

Exemplo de cenário no tipo de ataque mostrado pela OWASP:

Imagina uma aplicação que tem uma funcionalidade de gerenciamento de usuários, onde os administradores podem visualizar, editar e excluir usuários. A aplicação usa o parâmetro "userId" para identificar qual usuário está sendo gerenciado. No entanto, a aplicação não verifica se o usuário atualmente conectado tem a permissão de gerenciar usuários.

Um atacante pode aproveitar isso, modificando o valor do parâmetro "userId" em uma requisição para acessar informações ou realizar ações em contas de usuários que eles não deveriam ter acesso.

Exemplo:

https://example.com/app/manageUsers?userId=999

Se a aplicação não verificar se o usuário atual tem permissão para gerenciar usuários, o atacante pode acessar informações ou realizar ações em uma conta de usuário específica, mesmo se eles não tiverem permissão para fazê-lo. Muito simples e fácil!

Para solucionar o problema descrito, desenvolvedores devem adotar as seguintes medidas:

Adicionar verificações de permissão para garantir que somente usuários com a permissão adequada possam acessar a funcionalidade de gerenciamento de usuários. Isso pode ser feito usando o mecanismo de autenticação e autorização existente na aplicação.
Validar o valor do parâmetro "userId" antes de processar a requisição. Isso pode ser feito verificando se o valor do parâmetro está presente na lista de usuários permitidos para serem gerenciados pelo usuário atual.
Adicionar um mecanismo de log para registrar todas as tentativas de acesso não autorizado à funcionalidade de gerenciamento de usuários. Isso pode ser usado para identificar e rastrear os atacantes.
Realizar testes unitários e de integração para garantir que as novas verificações de permissão e validação de parâmetros estejam funcionando corretamente.

Prevenção

Para evitar esse tipo de ataque, desenvolvedores devem implementar as seguintes medidas de segurança:

Implementar controles de acesso no código do lado do servidor, onde o atacante não pode modificar as verificações de acesso ou metadados. Isso garante que somente usuários autorizados possam acessar recursos específicos.
Utilizar a regra "negar por padrão", onde somente usuários com permissões específicas podem acessar os recursos necessários.
Reutilizar os mecanismos de controle de acesso em toda a aplicação e minimizar o uso de Cross-Origin Resource Sharing.
Modelar os controles de acesso para garantir a propriedade dos registros, em vez de permitir que todo usuário crie, leia, atualize ou exclua qualquer registro. Isso garante que somente os proprietários dos registros possam acessá-los.
Definir regras de negócio únicas aplicadas ao domínio. Isso garante que os usuários não possam realizar ações que eles não deveriam ser capazes de fazer.
Desabilitar a listagem de diretórios do servidor web e garantir que os metadados de arquivos e arquivos de backup não estejam presentes nos diretórios raízes da web. Isso impede que os atacantes acessem arquivos sensíveis.
Fazer log das falhas de controle de acesso e alertar os administradores quando apropriado (por exemplo, falhas repetidas). Isso ajuda a identificar e corrigir problemas rapidamente.
Limitar a taxa de acesso à API e controladores para minimizar danos causados por ferramentas de ataque automatizadas. Isso impede que os atacantes sobrecarreguem a aplicação com requisições.
Invalidar identificadores de sessão stateful no servidor depois do logout e tornar os tokens JWT stateless de curta duração. Isso minimiza a janela de oportunidade para um atacante.
Incluir testes de unidade e de integração de controle de acesso funcional para desenvolvedores e equipe de QA. Isso garante que os controles de acesso sejam testados e verificados antes do lançamento.

Tudo isso você pode encontrar aqui, na própria página da OWASP sobre esta categoria.

Não deixe o Controle de Acessos da sua aplicação quebrar!

Portanto, o Broken Access Control é uma dos riscos mais comuns no campo de Segurança de Aplicações web. E, com este artigo, você obteve uma compreensão mais clara sobre esse risco, como ele funciona, quais são os impactos potenciais e como proteger suas aplicações.

Não deixe de levar essas informações e aplicá-las na prática para garantir que suas aplicações estejam protegidas contra este risco comum. Lembre-se de implementar medidas de segurança, como o princípio de privilégios mínimos, mecanismos de controle de acesso consistentes, além de testar regularmente e manter-se atualizado sobre as tendências e ameaças. Com essas medidas, você pode ter a certeza de que suas aplicações estão protegidas e seus usuários estão seguros.

Para mais conteúdos sobre a OWASP TOP 10, acesse este artigo.

Existem algumas dicas sobre como implementar medidas de “Autorização” fornecidas pela OWASP
Veja algumas vulnerabilidades associadas a esta categoria de risco fornecida pela OWASP.

10 Cursos Gratuitos no freeCodeCamp

Gabriel Galdino — Wed, 25 Jan 2023 16:48:03 +0000

Olá, sou voluntário do freeCodeCamp e faz um tempo que venho conhecendo vários recursos da organização.

Hoje venho compartilhar cursos gratuitos, com certificações, que a plataforma oferece para desenvolvedores de todos os níveis:

Responsive Web Design
https://lnkd.in/drV2vGsV
Você aprenderá as linguagens usadas para criar páginas Web: HTML para conteúdo e CSS para design.
Algoritmos e Estruturas de Dados em JavaScript
https://lnkd.in/dUFitUJb
Você aprenderá os fundamentos do JavaScript, como variáveis, arrays, objetos, loops e funções.
Aprendendo a usar bibliotecas no Front-end
https://lnkd.in/dzyaWgGz
Você aprenderá como adicionar lógica aos seus estilos CSS, além de aprender como usar Bootstrap.
Visualização de Dados
https://lnkd.in/dcaQJDUC
Construirá gráficos, gráficos e mapas para apresentar diferentes tipos de dados com a biblioteca D3.js. Além de aprender sobre JSON e como trabalhar com dados online usando APIs.
Banco de Dados Relacional
https://lnkd.in/dakCTfqH
Aprendendo a trabalhar com PostgreSQL e SQL. Tem um pouco de Git, o sistema de controle de versão, uma ferramenta essencial para todo mundo que desenvolve!
Aprendendo sobre o funcionamento do Back-end e APIs
https://lnkd.in/dNwPHSUW
Neste curso aprenderá a escrever aplicativos back-end com Node.js e npm. Tem algumas atividades para mexer com o framework Express e construirá um microserviço com MongoDB.
Quality Assurance (QA)
https://lnkd.in/dGhSF8QJ
Você aprenderá a escrever testes e conceitos avançados de Node e Express.
Computação Científica com Python
https://lnkd.in/dASAvhpq
Você aprenderá os fundamentos de Python, como variáveis, loops, condicionais e funções. Recomendo muito para quem quer aprender esta linguagem!
Análise de Dados com Python
https://lnkd.in/dTxNN8bg
Você aprenderá análise de dados com Python, usando bibliotecas como Numpy, Pandas, Matplotlib e Seaborn para processamento e visualização de dados.
Segurança de Informação
https://lnkd.in/dMf9k6up
Curso interessante que aborda como construir uma aplicação web com HelmetJS tendo em vista conceitos de segurança.

Se foi útil para você, compartilhe!

Não perca essa oportunidade de ampliar seus conhecimentos e se destacar no mercado.

Por que autenticação e autorização são importantes para desenvolvedores?

Gabriel Galdino — Mon, 09 Jan 2023 17:50:26 +0000

A implementação de medidas de autenticação e autorização é crucial para assegurar a segurança da aplicação e criar uma primeira linha de defesa contra ataques.

Pode-se dizer, ainda, que essas medidas ajudam a aumentar a confiança dos usuários no software, pois garantem que apenas usuários autorizados tenham acesso a funcionalidades e informações confidenciais.

Preparei esse resumo que ajuda a entender melhor sobre esses conceitos trazendo algumas dicas da OWASP.

Confira este artigo da Conviso que detalha outros conceitos importantes.

Autenticação x Autorização

Em resumo, a autenticação é necessária para confirmar que a pessoa que está tentando acessar uma aplicação é realmente quem diz ser.

Já a autorização é o processo de garantir que o usuário tenha permissão para realizar a ação que está tentando realizar. Por exemplo, um usuário pode ter a autenticação confirmada, mas ainda não ter a autorização para acessar uma área restrita do sistema.

É importante notar que a autenticação e a autorização são duas etapas diferentes e independentes.

Tipos de Autenticação

Por usuário e senha: neste caso, o usuário fornece um nome de usuário e uma senha para acessar uma conta.

Autenticação de três fatores: é uma técnica que combina três tipos diferentes de informações para verificar a identidade do usuário. Esses três tipos são:

Algo que você conhece: geralmente uma senha ou frase de segurança.
Algo que você tem: geralmente um dispositivo físico, como um token de segurança ou um aplicativo de autenticação em seu celular.
Algo que você usa: geralmente algo que está relacionado ao seu corpo, como uma impressão digital ou reconhecimento facial.

Autenticação baseada em tokens: neste caso, o usuário recebe um token de acesso que é enviado junto com cada solicitação de API.

Autenticação através de certificados: o usuário possui um certificado digital que é usado para autenticar sua identidade.

Exemplos para entender Autorização

Permissões de usuário: usada para garantir que o usuário só tenha acesso às ações que estão dentro de suas permissões.

Baseada em papéis: um usuário pode ter um determinado papel em uma aplicação, como administrador ou usuário comum. A autorização é usada para garantir que o usuário só tenha acesso às ações permitidas para o seu papel.

Baseada em condições externas: a autorização pode ser concedida ou negada com base em condições externas, como localização geográfica, horário ou padrões de uso.

Por que são necessárias?

A autenticação é crucial para garantir que apenas os usuários autorizados tenham acesso à aplicação, enquanto a autorização é fundamental para assegurar que os usuários só possam realizar as ações permitidas.

Essas medidas são importantes para proteger a integridade e a segurança da aplicação e dos dados. Além disso, a autenticação e a autorização são essenciais para manter a privacidade e a confidencialidade das informações e garantir que apenas os usuários autorizados tenham acesso a elas.

Implementando autenticação e autorização

Implementar autenticação e autorização em uma aplicação envolve diversas etapas e pode ser realizado de diferentes maneiras, dependendo do contexto e das necessidades da aplicação.

Algumas dicas gerais para a implementação de autenticação e autorização segundo a documentação da OWASP ASVS:

1º Utilizar autenticação de multifatores:

A autenticação de vários fatores exige que o usuário forneça outra informação além da senha para acessar a aplicação.

Essa técnica inclui ainda mais fatores de autenticação, como reconhecimento de voz ou biometria.

2º Armazenar senhas de maneira segura:

É fundamental garantir que as senhas dos usuários sejam armazenadas de maneira segura, para evitar que elas sejam comprometidas em caso de ataques.

Para isso, é recomendável usar criptografia de senhas ou outras técnicas de segurança, como hash de senhas com sal ou PBKDF2 (Password-Based Key Derivation Function 2).

3º Utilizar tokens de acesso seguros

Se a aplicação utiliza tokens de acesso (como JWTs ou cookies) para autenticar os usuários, é importante garantir que esses tokens sejam seguros e protegidos contra ataques.

Isso pode incluir usar assinaturas criptográficas para validar os tokens e renová-los com frequência.

É isso!

Consulte a documentação completa da OWASP para saber mais. Acesse os canais da Conviso e fique atualizado com os principais tópicos sobre Segurança de Aplicações.

Referência: https://bit.ly/3vP1IJX