A cada 3 anos temos a expectativa de um novo relatório gerado pelo OWASP mostrando quais são as vulnerabilidades que estão mais presentes na Internet baseado em dados dos anos anteriores.
Duas coisas são quase certas.
A primeira é que para a identificação das 10 vulnerabilidades teremos alguns pontos bastante discutíveis, pois há sempre uma boa discussão sobre quais vulnerabilidades devem ser adicionadas ou retiradas.
A segunda é que, quase com certeza, o primeiro lugar da lista das 10 vulnerabilidades mais presentes será ocupado pela “Injection”, coisa que já vem acontecendo nos últimos 3 relatórios.
Alguns inclusive dizem que em caso de uma guerra nuclear, duas coisas são certas. A primeira que as baratas vão sobreviver e a segunda é que com certeza o sistema de lançamento das bombas tenha uma vulnerabilidade de “Injection” em seu código.
SQL Injection e o OWASP Top 10
Deixando as brincadeiras de lado, ainda fico impressionado como depois de 15 anos de relatório da OWASP, já que o primeiro relatório foi lançado em 2004, ainda temos esta vulnerabilidade figurando entre as mais importantes do cenário de web applications.
Se traçarmos uma cronologia veremos que a primeira vez que surgiu o relatório foi em 2004, com injection já na sexta posição. No relatório seguinte (2007) já estava em segundo lugar e assim seguiu evoluindo, chegando ao primeiro lugar já no relatório de 2010, de onde não saiu mais dessa posição até hoje.
Aplicações Web são o foco
São vários os relatórios que ao longo do ano, e principalmente nos meses finais do ano, tentam nos mostrar um cenário do que aconteceu durante este período.
A Verizon, anualmente realiza uma avaliação sobre as melhores práticas e as vulnerabilidades que mais foram reportadas, semelhante ao que acontece na OWASP.
Neste ano nos foi colocado que mesmo com todos as melhorias em processos de desenvolvimento e outras práticas ainda temos um grande volume dos ataques sendo feitos contra aplicações web.
Somente esse fato isolado não deve nos trazer muitas informações, visto que hoje a grande maioria das aplicações são web e a grande maioria das empresas tem seu core focado neste tipo de aplicação.
Mas o que chama a atenção é que mesmo com todos estes dados e informações, ainda temos muitos problemas nas aplicações, sendo o maior deles as vulnerabilidades de Injection, e dentro desta categoria a SQL Injection.
SQLi e LFI
Outro relatório importante é liberado anualmente pela Akamai. Em seu relatório que trata exclusivamente sobre Web Attacks and Gaming Abuses podemos ver que por mais que o cenário de vulnerabilidades seja grande, a maioria dos ataques está focada em apenas duas categorias SQLi e LFI (Local File Inclusion), estas duas representando 89% dos ataques.
Isso em uma análise bem fria dos números nos mostra que se tivéssemos atenção e cuidado com nossos códigos, olhando apenas para estas duas categorias, teríamos uma grande parte das vulnerabilidades mitigadas.
Outro dado preocupante é mostrado no relatório da Veracode, que em seu volume 10 do relatório nos mostra que além do crescimento dos números das vulnerabilidades, também temos um aumento no tempo entre a descoberta e a correção.
“When Veracode published Volume 1 of the State of Software Security Report, the average number of days organizations took to fix flaws was 59 days. In Volume 10, that average is nearly three times higher at 171 days.”
Quando o primeiro relatório foi lançado, o tempo médio entre a descoberta e a correção eram de 59 dias, o que mudou para este último relatório, mostrando que este número chega hoje a 171 dias entre a descoberta e a correção.
O que os números nos dizem
Bom, o que eles nos mostram é que estamos perdendo a corrida, cada vez mais as ferramentas automatizadas e a criatividade humana estão ganhando espaço no campo dos ataques.
Em contrapartida, ainda temos a antiga disputa de poder entre duas das áreas mais importantes nas empresas hoje. Como colocamos em nosso artigo falando sobre o assunto.
A quantidade de vulnerabilidades SQLi reportadas nos mostra uma coisa bem mais fundamental.
Acreditamos que acima de tudo esta quantidade e a presença por tanto tempo destas vulnerabilidades nos mostra que estamos falhando em passar o conhecimento para nossos desenvolvedores.
Precisamos estruturar processos de aquisição de conhecimento por meio de treinamentos e a própria retenção do conhecimento gerado no processo de gestão de vulnerabilidades.
Além de melhorarmos o processo de aquisição de conhecimento, precisamos atuar fortemente na comunicação das equipes de desenvolvimento e de segurança.
Esse é um dos principais problemas que encontramos, a comunicação deficiente afeta na resolução de vulnerabilidades em nossas aplicações.
SQLi são “inofensivos”
Mesmo com todos estes dados e todos estes números ainda encontramos profissionais de desenvolvimento e segurança que não entendem como são críticas as vulnerabilidades trazidas pelo OWASP TOP 10.
Eles não entendem a relação destas vulnerabilidades com outras bem mais críticas, deixam de perceber que muitas vezes estas vulnerabilidades mais “simples” são usadas como ponto inicial para explorações mais complexas e perigosas.
Os profissionais de AppSec estão cientes disso e trabalham cada vez mais para melhorar o cenário. Afinal, essa é uma de suas principais habilidades que os torna um recurso de equipe tão valioso. No entanto, eles são freqüentemente impedidos por vários fatores.
Também devemos perceber que, para todo problema, existe um processo de precisar encontrar uma solução, implementá-la e testá-la.
Ao contrário do que muitos gestores imaginam, a correção de uma vulnerabilidade, mesmo que mínima pode levar muito tempo e recursos.
A quantidade de vulnerabilidades hoje é imensa, e é simplesmente impossível que qualquer empresa possa se defender contra todas elas.
Porque enquanto isso, os desenvolvedores continuam criando recursos e, por sua vez, continuam introduzindo vulnerabilidades no código que escrevem.
Criação de Processos Estruturados
Depois de entendermos que há sim um Gap no conhecimento dos nossos desenvolvedores, precisamos criar um cenário favorável para que eles possam diminuir esse gap.
As vulnerabilidades de SQLi são apenas um reflexo do que estamos deixando de enfrentar, precisamos entender esta falha e suas consequências.
Precisamos buscar criar processos melhores e mais estruturados, com processos de validação de código integrados e equipes mais preparadas.
Esperamos que as empresas entendam que investir em treinamento não deve ser encarado como um requisito necessário apenas para cumprir em uma auditoria.
Queremos mostrar para o mercado que preparar sua equipe é fundamental e que o resultado que isso trará é muito maior que o investimento feito.
Poucos ouviram falar da OWASP Top 10
Como podemos ver, é evidente que estamos deixando passar alguma coisa quando o assunto é AppSec.
Uma pressão enorme por prazos curtos, falta de planejamento adequado, um processo de desenvolvimento inexistente e pouco controle sobre o processo de gestão de vulnerabilidades. Esses são alguns pontos.
Mas, não vamos deixar o desenvolvedor de lado, sabemos por experiência que pouco, poucos mesmo, conhecem ou pelo menos já ouviram falar do TOP 10 da OWASP, conhecimento que no nosso entendimento deveria ser básico para quem trabalha com desenvolvimento web.
Quando olhamos para o lado acadêmico, o cenário é ainda um pouco pior, pois quase nenhuma instituição tem em sua grade uma matéria voltada para mostrar as melhores práticas de desenvolvimento.
A grande maioria dos alunos saem sem ao menos saber os conceitos básicos de um desenvolvimento mais focado em segurança, e isso precisa ser mudado.
Conhecimento adquirido
Pelo lado das empresas, elas têm que entender que investir em treinamento não é de forma alguma colocar recursos em um profissional que pode deixar a empresa, mas tem que entender que este investimento vai ser revertido em melhor qualidade de desenvolvimento.
A preocupação não é o gasto de recursos com profissionais que podem sair e sim em perder o conhecimento adquirido, mas há outras formas de se manter isso, e uma delas é garantindo que as vulnerabilidades identificadas e o processo de correção receberam a atenção adequada e tiveram todas as etapas registradas em uma plataforma central e que pode ser consultada muito facilmente.
E então, depois de tudo isso, o que você quer fazer?
