Qual é a lista de vulnerabilidades Top 10 OWASP?
publicado pela Primeira vez em 2004 pela Open Web Application Security Project, o agora famoso OWASP Top 10 Vulnerabilidades (lista, na parte inferior do artigo) é provavelmente o mais próximo que a comunidade de desenvolvimento jamais chegar a um conjunto de mandamentos sobre como manter seus produtos de seguro.,
esta lista representa as ameaças mais relevantes para a segurança do software hoje de acordo com OWASP, para o bater na testa de muitos que se perguntam como as injeções SQL ainda são uma preocupação após todos estes anos. Eles avaliam os tipos de vulnerabilidade com base em quatro pontos de critérios: facilidade de explorabilidade prevalências detectabilidade impacto empresarial bastante interessante, OWASP afirma que eles realmente não têm em conta na sua equação a probabilidade de os atacantes tentarem explorar uma determinada vulnerabilidade.,
Quando começou, os escritores decidiram que a melhor maneira de cobrir a maior parte do terreno era colocar vulnerabilidades semelhantes que eles acreditavam ser a mais concernente em agrupamentos. Eles reconheceram que, sem as estatísticas adequadas, sempre poderia haver uma questão sobre quais vulnerabilidades eram necessariamente as principais preocupações, especialmente porque isso pode ser uma questão subjetiva, de acordo com o modelo de ameaça de cada organização.no entanto, depois de muito debate, eles ofereceram a sua lista do que eles acreditavam abordar o mais amplo conjunto de organizações, embora não em qualquer ordem particular.,com o tempo, a lista de vulnerabilidades Top 10 da OWASP foi adotada como um padrão para as melhores práticas e requisitos por inúmeras organizações, estabelecendo um padrão em um sentido para o desenvolvimento. Um dos adoptantes bem conhecidos da lista são os padrões de processamento de pagamentos do PCI-DSS.
infelizmente, como a lista de vulnerabilidades Top 10 OWASP chegou a um público mais amplo, suas reais intenções como um guia foram mal interpretadas, prejudicando os desenvolvedores em vez de ajudar. Então, como devemos entender o propósito desta lista e realmente incentivar os desenvolvedores a codificar de forma mais segura?,
compreendendo atualizações para a lista de 2017
nos anos seguintes, eles refrescaram e reordenaram as entradas, adicionando alguns novos tipos de vulnerabilidade à medida que se tornam relevantes, mesmo que outros foram retirados da lista. Novas versões foram emitidas em 2010, 2013 e 2017. A nova lista foi montada após um longo e árduo estudo que analisou mais de 50 mil aplicações e analisou cerca de 2,3 milhões de vulnerabilidades.,
seguidores regulares da lista terão notado que, juntamente com algumas mudanças na ordem — apesar do fato de que os ataques de injeção permanecem no topo — existem alguns recém-chegados à versão atualizada de 2017 da família de vulnerabilidades Top 10 da OWASP.
bater para fora da competição para inchar seu caminho para o campo, chutando fora redirecionamentos não validados e para a frente é a questão das APIs não protegidas., Sua inclusão na lista no número A10 spot é provavelmente o resultado do fato de que os desenvolvedores são simplesmente muito mais dependentes de APIs do que costumavam, interagindo com muito mais Componentes e produtos externos do que antes. Entrar no A7 spot é proteção de ataque insuficiente, o que bate os desenvolvedores por não ser abrangente o suficiente na adição de proteções para detectar, registrar e, claro, responder às tentativas de prejudicar seus produtos.,
a outra grande mudança aqui na versão de 2017 é a combinação das referências de objetos diretos inseguros do A4 e o controle de acesso de nível de funções em falta do A7, criando uma vulnerabilidade de controle de acesso quebrado unificado e destacando a necessidade de estabelecer corretamente controles para quem pode e não pode acessar as contas e os dados.,
má interpretação da lista de vulnerabilidades do Top 10 OWASP
uma força para o bem, esta lista infelizmente se transformou em uma ferramenta para envergonhar desenvolvedores que não seguem seus ensinamentos, usado como um clube para repreendê-los por não serem perfeitos quando se trata de segurança. Esta abordagem é contraproducente e falha a missão da OWASP de incentivar e equipar os desenvolvedores para codificar de forma mais segura. Além disso, ele não reconhece as realizações dos escores de desenvolvedores que estão empurrando grandes quantidades de novo software a uma taxa nunca antes vista.,em uma entrevista recente, o presidente da OWASP, Martin Knobloch, expressou sua decepção com a lista sendo usada como uma espécie de Lista de verificação para uma execução final antes de um lançamento, servindo mais como um mecanismo de validação do que um guia.como alguém que acredita fortemente em uma abordagem de mudança para a segurança, não surpreende que eu esteja de acordo com a frustração de Knobloch de quantos tomaram o Top 10 da OWASP como um instrumento de FUD, e não o conjunto de princípios orientadores que ele pretendia ser.,estratégias de segurança organizacional que dependem da expectativa de falha dos elementos humanos em como eles protegem o software em favor de ferramentas brilhantes são obrigados a falhar.
nos últimos anos, as mensagens de muitos fornecedores, especialmente no lado da rede, tem sido que “o perímetro está morto” e que as empresas precisam buscar a segurança em profundidade para encontrar os bandidos que já estão dentro de sua rede., Demasiadas manchetes em conferências tentaram convencer CISOs de que equipas de hackers de elite estão a atacá-los com façanhas rarefeitas de 0 dias que os deixarão indefesos a menos que comprem o seu produto, o que de alguma forma os tornará impenetráveis a estes ataques imparáveis.
esta perspectiva sobre o estado de segurança é desnecessariamente fatalista, pingando com hipe de marketing, e perde alguns dos conceitos básicos de como os profissionais de segurança devem pensar sobre o risco.,
uma abordagem abrangente à segurança não deve pregar a remoção dos desenvolvedores humanos do processo, apenas para trazer as ferramentas de segurança de um fornecedor para corrigir depois que eles terminaram seu trabalho. Isto assume que os desenvolvedores não podem ser confiáveis, é insultuoso, e não faz nada para tornar sua equipe mais forte quando se trata de segurança e gestão de risco.
What the OWASP Top 10 Vulnerabilities List Is And Is Not
a few times a year there is the obligatory blog post asking how it is possible that in 2017 we are still talking about script kiddie level attacks., Devo ter escrito alguns deles, pelo que peço desculpa.
O OWASP Top 10 não é configurado para resolver todos os ataques no livro, mas para ajudar as equipes a evitar os erros comuns que são muito mais propensos a quebrar suas aplicações. Um atacante determinado pode encontrar muitas avenidas para quebrar o seu alvo. No entanto, os alertas inteligentes de gestão de risco não se concentram na minoria dos casos, mas sim procuram abordar as questões que enfrentam o público mais vasto.,para extrair dos conceitos de segurança física, o gerente de risco médio deve estar muito mais preocupado com o seu cliente entrar em um acidente na estrada do que ninjas treinados pela equipe SEAL 6 vindo através das janelas, guiado por AI (e blockchain).
segurança Real é sobre a formação de pessoas sobre como trabalhar de forma segura e dar-lhes as tecnologias, conhecimento e processos para facilitar a sua permanência em segurança., Embora seja sempre importante executar as verificações de segurança antes de um lançamento, a segurança precisa começar nos primeiros estágios de como sua equipe trabalha, correndo ao longo do processo de desenvolvimento do produto. Os erros vão acontecer, mas é muito mais rentável e mais inteligente tentar evitar o maior número possível de questões.
para muitos desenvolvedores, o objetivo de condução centra-se em conseguir que o produto funcione, focando-se menos em se é ou não seguro. A culpa não é deles.,
ao longo de sua educação, eles aprenderam que se eles produzirem um produto com uma quantidade mínima de bugs, então eles têm um A. Segurança seria tratada por outro departamento de qualquer maneira. Em vez disso, os gestores precisam aproveitar a oportunidade para mostrar-lhes uma maneira melhor de trabalhar, que inclui considerar como eles codificam, e os componentes com os quais eles estão trabalhando, impactam a segurança de seu produto.,
451 RESEARCH REPORT PROTEGER o SOFTWARE de FONTE ABERTA Download Grátis
Passos Práticos Para Permitir Melhores Práticas de Segurança
Uma armadilha comum que saiu dos dias da cachoeira de desenvolvimento era esperar até o final do ciclo de desenvolvimento para executar verificações de segurança, em que os desenvolvedores gostaria de receber uma lista de lavanderia de vulnerabilidades para corrigir, atrasando o lançamento e aumentar o atrito entre eles e a equipe de segurança.,
na esperança de lubrificar as engrenagens e manter o ritmo com a velocidade dos DevOps, as organizações estão à procura de novas formas de garantir o seu código desde o início e manter a harmonia entre os seus departamentos.
um método cada vez mais popular para trazer segurança para os estágios iniciais do desenvolvimento de produto é em equipes de polinização cruzada com uma mistura de desenvolvedores e pessoal de segurança, permitindo que cada lado dê entrada e aprender uns com os outros., Esta pode ser uma excelente oportunidade para os especialistas em segurança abordarem muitas das questões que o Top 10 da OWASP tenta abordar num ambiente menos conflituoso, numa fase que poderia realmente ter um impacto.quando se trata de ferramentas que podem ajudar a promover uma melhor implementação de segurança, precisamos pensar não só sobre como a tecnologia pode pegar nossos erros ou falhas após o fato, mas nos ajudar a trabalhar mais inteligente e mais seguro desde as fases iniciais., Esta perspectiva é parte integrante da mentalidade de mudança para a esquerda, procurando oportunidades para abordar as questões antes que elas se tornem problemas caros.
integrar tecnologias para aumentar as capacidades de desenvolvimento
um exemplo claro de como as tecnologias para mudar para a esquerda podem ajudar os desenvolvedores a utilizar o Top 10 OWASP vem com a entrada número 9 que adverte contra o uso de componentes com vulnerabilidades conhecidas. Um dos problemas mais comuns que surgem neste espaço é ganhar visibilidade sobre o que está nos componentes de código aberto que eles adicionaram ao seu produto.,
os desenvolvedores quase sempre se voltam para componentes de código aberto para ajudá-los a construir seu produto mais rápido e de forma mais eficiente, adicionando recursos poderosos sem a necessidade de escrever o novo Código eles mesmos.
na maioria dos casos, é improvável que eles verifiquem se o componente tem vulnerabilidades conhecidas antes de adicioná-lo ao seu produto. Mesmo que eles façam uma verificação superficial para ver se ele tem quaisquer problemas específicos, eles são improváveis de estar cientes de quaisquer problemas nas dependências do componente.,
no Entanto, se eles estão usando um Software de Análise de Composição de ferramenta, na verdade, eles podem receber informações úteis sobre se uma fonte aberta componente tem qualquer vulnerabilidades conhecidas associadas a ela ao longo de todo o ciclo de vida de desenvolvimento de software (SDLC), poupando-lhes o tempo que poderia ser gasto rasgo e substituindo o componente, depois de uma seleção da equipe de segurança posterior para baixo da linha antes do lançamento, depois que ele foi cometido ao seu código.,
Ser potenciadora da Segurança de Dentro de Sua Organização
com Base na minha leitura do OWASP Top 10 e Knobloch comentários, a lista deve ser tomado como uma ferramenta para capacitar equipes para incluir segurança no seu processo de pensamento de como elas código, configurar e transporte de seus produtos.as equipes de segurança que não se envolvem com seus desenvolvedores, fazendo o esforço para entender como eles podem capacitá-los para que a segurança seja um elemento inerente de seu fluxo de trabalho, vão rapidamente encontrar-se afastados.,
Se quiser manter-se relevante, torne-se um facilitador, e use a lista do Top 10 do OWASP como uma forma de iniciar conversas, não para ameaçar. No final, você pode descobrir que você apanha mais (o) vespas com mel do que vinagre.
a lista oficial das 10 vulnerabilidades oficiais do OWASP lista
A1. Falhas de injeção-injeção, tais como SQL, NoSQL, OS e LDAP injeção, ocorrem quando dados não confiáveis são enviados para um interpretador como parte de um comando ou consulta. Os dados hostis do atacante podem enganar o interpretador para executar comandos não intencionais ou acessar dados sem a devida autorização.
A2., As funções de autenticação – aplicação quebradas relacionadas com a autenticação e gestão de sessões são muitas vezes implementadas incorretamente, permitindo que os atacantes comprometam senhas, chaves ou tokens de sessão, ou para explorar outras falhas de implementação para assumir as identidades de outros usuários temporária ou permanentemente.
A3. Exposição de dados sensíveis-muitas aplicações web e APIs não protegem adequadamente dados sensíveis, tais como financeiros, cuidados de saúde e PII. Os atacantes podem roubar ou modificar esses dados de proteção fraca para conduzir a fraude de cartão de crédito, roubo de identidade, ou outros crimes., Os dados sensíveis podem ser comprometidos sem proteção extra, como criptografia em repouso ou em trânsito, e requer precauções especiais quando trocados com o navegador.A4. XML External Entities (XXE) – muitos processadores XML mais antigos ou mal configurados avaliam referências de entidades externas dentro dos documentos XML. Entidades externas podem ser usadas para divulgar arquivos internos usando o Gerenciador de arquivos URI, compartilhamento de arquivos internos, varredura de portas internas, execução de código remoto e ataques de negação de serviço.A5.,Controles de acesso quebrados-restrições sobre o que os usuários autenticados são autorizados a fazer muitas vezes não são devidamente aplicados. Os atacantes podem explorar essas falhas para acessar funcionalidades e/ou dados não autorizados, acessar contas de outros usuários, visualizar arquivos sensíveis, modificar dados de outros usuários, alterar direitos de acesso, etc.
A6. Erro de configuração da segurança-erro de configuração da segurança é o problema mais comumente visto., Isto é comumente um resultado de configurações inseguras por default, configurações incompletas ou ad hoc, armazenamento em nuvem aberto, cabeçalhos HTTP mal configurados, e mensagens de erro descritivas contendo informações sensíveis. Não só todos os sistemas operacionais, frameworks, bibliotecas e aplicações devem ser configurados de forma segura, mas eles devem ser remendados/atualizados em tempo hábil.
A7.,Cross Site Scripting (XXS)-XSS falhas ocorrem sempre que uma aplicação inclui dados não confiáveis em uma nova página web sem validação adequada ou escape, ou atualiza uma página web existente com dados fornecidos pelo usuário usando uma API de navegador que pode criar HTML ou JavaScript. O XSS permite que os atacantes executem scripts no navegador da vítima que podem sequestrar sessões de usuário, desfigurar sites ou redirecionar o Usuário para sites maliciosos.
A8. Deserialização insegura-deserialização insegura muitas vezes leva à execução de código remoto., Mesmo que falhas de deseralização não resultem em execução de código remoto, Eles podem ser usados para executar ataques, incluindo ataques de repetição, ataques de injeção e ataques de escalada de privilégios.
A9. Usando componentes com vulnerabilidades conhecidas-componentes, tais como bibliotecas, frameworks e outros módulos de software, executam com os mesmos privilégios que a aplicação. Se um componente vulnerável é explorado, tal ataque pode facilitar a perda de dados graves ou a tomada do servidor., Aplicações e APIs usando componentes com vulnerabilidades conhecidas podem minar as defesas das aplicações e permitir vários ataques e impactos.
A10. Registo insuficiente & monitorização – registo e monitorização insuficientes, juntamente com integração inexistente ou ineficaz com resposta a incidentes, permite aos atacantes continuar a atacar sistemas, manter a persistência, pivô para mais sistemas, e adulterar, extrair ou destruir dados., A maioria dos estudos de violação mostram que o tempo para detectar uma violação é de mais de 200 dias, normalmente detectados por partes externas em vez de processos internos ou monitoramento.