No artigo anterior, falamos o quanto o estado atual de ferramentas para Web Application Security e Application Security não estão adaptados para trazer segurança para APIs. Hoje vamos falar porque uma boa estratégia de segurança para aplicações web deve passar por uma boa estratégia de segurança para APIs.
Podemos dizer que as APIs servem a 3 propósitos principais: compartilhamento de regras de negócio entre organizações, desacoplar o front-end do back-end e comunicação entre máquinas. O primeiro propósito pode ser visto desde o que se diz ser os primórdios das APIs no ano 2000, quando Salesforce e eBay disponibilizaram serviços para desenvolvedores incorporarem em suas aplicações por meio desta interface.
A partir de então, o uso da internet veio se intensificando, demandando aplicações mais complexas e interativas. O que não era bem atendido pelo padrão da época, em que as páginas eram geradas estaticamente pelo servidor e qualquer alteração de dados vinda do lado do servidor demandava a geração de uma nova página para ser visualizada. A introdução do AJAX deu início a uma arquitetura que veio para ficar, na qual o cliente que processa atualizações de conteúdo, a partir de requisições a endpoint que fornecem dados atualizados. Desde então vimos o surgimento de Single-Page Applications, frameworks reativos, aplicativos mobile e esses endpoints que alimentam o front-end também passaram a ser chamados de APIs.
Já o terceiro propósito é mais recente, com a ascensão da Internet das Coisas e desenvolvimento da automação de infraestrutura. Os dois primeiros propósitos das APIs tocam diretamente o campo de aplicações web modernas. Hoje, é extremamente difícil você usar uma aplicação que não tenha pelo menos uma integração com uma empresa de meio de pagamentos ou de cartão de crédito. Como gerar e enviar uma nota fiscal ao governo sem pelo menos uma integração? E se você estivesse comprando em um e-commerce e a página fosse recarregada enquanto você estivesse validando um cupom? Sua visão sobre a experiência não seria nem um pouco afetada?
As APIs são fundamentais para a experiência com aplicações web, e não há um caminho alternativo emergente. O problema é que essa atenção para elas ainda não chegou ao campo de segurança. É comum ver times de desenvolvimento considerando como o suficiente apenas autenticação, SSL e cuidado com ataques comuns como injection. Ou então, equipes de segurança que recebem os pacotes antes do lançamento e fazem avaliações sobre o risco daquele código específico. Ou equipes de operações que consideram WAF e API Gateway e monitoramento das redes o suficiente. Por que essas abordagens não são o suficiente?
O desenvolvimento das APIs trouxe consigo novas práticas. Entre elas, a arquitetura de microsserviços. Como consequência, o risco de uma falha de segurança na interação entre serviços cresce exponencialmente à medida que novos serviços são adicionados. Um provável reflexo disso é o comportamento da Quebra de Controle de Acesso nas listas da OWASP. Na primeira divulgação, em 2004, essa vulnerabilidade ocupava a segunda posição. Após a evolução do conhecimento sobre o assunto e a incorporação disso em frameworks de aplicação, esse problema ocupava a quinta posição na lista de 2017. Agora, se olharmos para a primeira OWASP Top 10 para API, de 2019, a principal ameaça é um tipo de Quebra de Controle de Acesso. E na última publicação da principal lista da OWASP, em 2021, essa vulnerabilidade está no topo, enquanto Injection, que historicamente tem sido um dos principais temores de quem se preocupa com segurança de aplicações, caiu para a terceira posição.
Usando como exemplo o BOLA (Broken Object Level Authorization), que ocupa o topo da OWASP para APIs e é uma quebra de controle de acesso, sua exploração gera uma requisição com características iguais à de um usuário normal, dificultando sua detecção por um WAF (para mais detalhes, veja o artigo anterior). Uma estratégia de mitigação eficiente demanda informações contextuais da lógica da aplicação. Informações que precisam ser adquiridas com agilidade, uma vez que toda essa evolução na arquitetura das aplicações web contribuiu para um salto na velocidade de lançamentos de novas features.
Essa maior velocidade na implementação de código em produção é um fator que piora o cenário de vulnerabilidade em APIs/Aplicações Web. Uma pesquisa da ESG (Enterprise Strategy Group) apontou que 48% dos respondentes lançam código com vulnerabilidade com frequência. Entre os principais motivos, 54% responderam que foi para cumprir um deadline e 45%, porque as vulnerabilidades foram descobertas muito tarde para serem corrigidas a tempo. Imagine a potencial superfície de ataque em um ambiente com inúmeras APIs (algumas não catalogadas e “esquecidas” pelo time, inclusive), múltiplos microsserviços se comunicando, sendo que frequentemente alguns deles contêm vulnerabilidades.
Portanto, é fundamental que uma abordagem que resolva problemas específicos de segurança para APIs esteja incluída em uma abordagem de segurança para aplicações web.
Diante disso, é dever da GoCache se alinhar às novas necessidades, assim, anunciamos que estamos desenvolvendo uma nova suite para proteção de APIs.
Uma série de novidades serão anunciadas, e se você quiser saber em primeira mão e participar do beta, entre em contato com produto@gocache.com.br.
Vamos construir o futuro da Segurança de Aplicações Web juntos?
Por Victor Queiroz Vilas Boas, Product Manager GoCache.
https://gocache.com.br/wp-content/uploads/2022/02/waf-diferencas-difere.jpg6831024Go Cachehttps://gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.pngGo Cache2022-02-23 13:56:292022-07-13 10:41:49Por que API Security também é Web Application Security?
Quem não está preocupado com a segurança da sua aplicação online? Quer saber como proteger seu site ou loja virtual com WAF? Vamos demonstrar neste artigo.
A configuração da segurança na camada de aplicação é crucial. Falhas podem levar a enormes prejuízos, financeiros e de reputação da sua marca.
Se você pensa que este é um problema exclusivamente das grandes empresas, ledo engano. Mais de 60% dos ataques têm como alvo as empresas de pequeno e médio porte. E a má notícia é que, caso um ataque destes seja bem sucedido, mais de 60% destas empresas irá fechar por não ter recursos suficientes para se recuperar.
Para um blog, perda ou deformação de conteúdo. Uma loja virtual pode sofrer roubo de dados, ou até mesmo fraudes em suas transações comerciais. Um aplicativo móvel pode ter suas chamadas de API clonadas e sofrer todos estes sintomas. A área administrativa de qualquer destas aplicações pode ser indevidamente acessada e o estrago pode ser irreparável.
Quem quer correr estes riscos?
Mas a pergunta que importa mesmo é, como saber se o seu site/loja/app está vulnerável? Ou se está na “mira” de algum usuário mal-intencionado?
Resolvemos abrir um case para vocês, o do nosso próprio site – www.gocache.com.br
Em nosso site utilizamos o WordPress em sua última versão, com todos plugins atualizados e hospedado em servidor virtual.
Pouco antes de lançarmos nossa solução de WAF, partimos para o teste final, nada mais justo que testar a ferramenta em nosso site de produção.
A situação inicial
Ativamos o Web Application Firewall com alto critério de filtragem e em modo simulação, para que apenas fossem gerados logs, já que não queríamos arriscar um falso positivo.
Eis o resultado:
Tivemos apenas uma tentativa de acesso suspeita. Eis os detalhes do incidente:
Pelas características do incidente deduzimos tratar-se de um robô, provavelmente sondando vulnerabilidades.
No segundo dia com a ferramenta ativa, percebemos que este tipo de acesso não era raro:
Foram 25 acessos que a ferramenta identificou como suspeitos.
Ao checar os detalhes destes eventos, identificamos o seguinte:
Além do acesso de um robô semelhante ao do primeiro dia, também houve tentativas de quebra de senha (brute-force) na área administrativa.
O tamanho do problema
Com o tempo o volume de acessos suspeitos foi aumentando consideravelmente. Ainda estávamos utilizando o modo de simulação da ferramenta para termos certeza de que não ocorreriam falsos positivos, ou que caso ocorressem poderíamos identificar e criar uma regra de filtragem que evitasse o falso positivo quando habilitássemos o modo de bloqueio.
Seguimos com o plano inicial, de gerar logs durante uma semana antes de ativar o bloqueio. Veja a que ponto chegamos:
Sim, 14 páginas de log para o dia 13, apenas uma semana após o início do uso da ferramenta. Mais de 400 tentativas de ataque ao nosso site em apenas um dia.
A Solução
A esta altura já tinhamos dados suficientes para configurar uma regra de filtragem específica e então modificar o modo de funcionamento do WAF para “bloquear” ao invés de “simular”:
Note que para esta regra específica colocamos o WAF em modo “desafiar” ao invés de “bloquear”. Isso porque para o tipo de ataque que identificamos, feito via robô, o desafio é uma medida um pouco menos drástica e quase tão eficiente quanto o bloqueio. O resultado desta regra é a exibição desta tela antes de apresentar os campos para autenticação na área administrativa do WordPress:
Com isso ficamos tranquilos para ativar o bloqueio completo dos acessos suspeitos.
Os Benefícios
O resultado, além da segurança da aplicação, é a economia de recursos computacionais e de rede, uma vez que os acessos bloqueados no WAF ficam na borda e não consomem a banda na infraestrutura de hospedagem.
Ou seja, além de proteção você também economiza.
Acreditamos que o uso de WAF não é mais uma opção, mas sim uma necessidade, e quem deixar para depois pode não ter tempo para se arrepender. É melhor prevenir do que remediar!
https://gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.png00Go Cachehttps://gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.pngGo Cache2017-05-14 01:44:432017-07-24 03:27:59Como proteger seu site, loja virtual ou APP contra SQL Injection, XSS e Brute-Force usando WAF
Se você está lendo este artigo, provavelmente está bem ciente da importância da segurança em aplicações web. É possível que você já tenha colocado em prática algumas medidas mencionadas aqui. Mas, como muitos proprietários de websites, apps e lojas virtuais, provavelmente não fez o suficiente para cobrir todas as áreas necessárias.
Se o seu site já foi afetado por algum tipo de ataque DDoS, ou se você leu a respeito do grande ataque que a empresa Dyn sofreu no final de 2016 derrubando milhares de sites relevantes, então você sabe que esta é uma grande preocupação. Como mostrado no gráfico abaixo, o número de ataques DDoS têm crescido consistentemente ao longo dos últimos anos e a tendência é que isso continue piorando.
Ataques DDoS ocorrem na camada de rede, são por natureza volumétricos (em sua maioria) e dependem do seu provedor de hospedagem, datacenter ou CDN para serem apropriadamente mitigados. Normalmente, quando ocorrem, os provedores de infraestrutura tomam as providências necessárias para restabelecer o serviço.
Subindo alguns níveis no modelo OSI, voltemos à camada de aplicação. Embora não haja maneira de garantir 100% de segurança, pois é impossível prever tudo, existem medidas que podem ser utilizadas para reduzir as chances de ocorrência de problemas de segurança em aplicativos web. Quanto mais destas medidas forem tomadas simultâneamente, mais protegida estará sua aplicação.
Criar um plano de segurança para aplicações web
O primeiro passo para assegurar-se que você está utilizando as melhores práticas de segurança para aplicações web é ter um plano traçado. Com frequência as empresas adotam uma abordagem desorganizada para esta situação e acabam realizando muito pouco. Sente-se com sua equipe de segurança de TI para desenvolver um plano de segurança detalhado e acionável. É importante que este plano esteja alinhado com os objetivos da sua organização.
Por exemplo, talvez você queira melhorar seu compliance, ou talvez você precise proteger sua marca. É necessário priorizar quais aplicativos devem ser protegidos primeiro e como eles serão testados. Você pode optar por fazê-lo manualmente, através de uma solução em nuvem, através de software específico, de um provedor de serviços gerenciados ou por outros meios.
Embora o plano de segurança e a lista de verificação de cada empresa sejam diferentes e dependam da arquitetura de sua infraestrutura, é importante que você defina especificamente quais os requisitos de segurança a serem atendidos e os critérios para avaliação. A OWASP (Open Web Application Security Project), grupo especializado em segurança online, criou um checklist bem detalhado que você pode utilizar como base para a sua avaliação – link.
Além disso, se sua organização é grande o suficiente, seu plano deve relacionar os indivíduos dentro da organização que serão responsáveis pela manutenção contínua dessas melhores práticas. Finalmente, não se esqueça de levar em conta os custos em que sua organização incorrererá ao engajar essas atividades, pois este pode ser um fator decisivo na hora de priorizar.
Realizar um inventário das suas aplicações web
É provável que você não tenha uma ideia muito clara sobre quais aplicativos web sua empresa utiliza. Na verdade, a maioria das organizações tem muitos aplicativos “rogue” rodando sem saber, até que algo dê errado. Você não pode esperar manter uma boa política de segurança em aplicações web sem mapear detalhadamente quais aplicativos sua empresa utiliza.
Quantos são? Onde estão localizados? Executar esse inventário pode ser uma tarefa trabalhosa e é provável que leve algum tempo até sua conclusão. Ao fazê-lo, anote a finalidade de cada aplicação. Quanto maior a organização, maiores as chances de encontrar aplicações redundantes ou até mesmo inúteis. O inventário virá a calhar para as próximas sugestões, por isso invista o tempo necessário e certifique-se de obter os detalhes de cada aplicação utilizada.
Priorize suas aplicações web
Depois de concluir o inventário de seus aplicativos web, classificá-los em ordem de prioridade é o próximo passo lógico. Sem priorizar quais aplicativos focar primeiro, você terá dificuldade em fazer qualquer progresso significativo.
Classifique as aplicações em três categorias:
Crítico
Importante
Normal
As aplicações críticas são principalmente aquelas que podem ser acessadas externamente e contém informações de clientes. Estas são as aplicações que devem ser geridas em primeiro lugar, pois são as mais suscetíveis como alvos a serem exploradas por hackers. As aplicações importantes podem ser de uso interno ou externo e podem conter algumas informações confidenciais. Aplicações normais têm muito menos exposição, mas devem ser incluídas em testes por precaução, mesmo que em um segundo momento.
Categorizando suas aplicações assim você pode focar testes extensivos nas aplicações críticas e usar testes menos complexos (e caros) nas demais. Isso permite que você faça o uso mais eficaz dos recursos da empresa ao mesmo tempo em que pode alcançar resultados significativos com maior velocidade.
Priorizar Vulnerabilidades
Conforme você avalia sua lista de aplicativos web antes de testá-los, é necessário decidir quais vulnerabilidades valem a pena eliminar e quais não são tão preocupantes. A maioria das aplicações web tem muitas vulnerabilidades. Por exemplo, dê uma olhada no relatório abaixo, que avaliou e categorizou 9000 sites infectados:
Eliminar todas as vulnerabilidades de todas as aplicações web não só não é possível como nem mesmo vale o seu tempo.
Mesmo depois de categorizar suas aplicações de acordo com a importância, será necessário um investimento considerável de recursos para analisá-las. Limitando os testes apenas às vulnerabilidades mais ameaçadoras, você economizará muito tempo e fará o trabalho muito mais rápido. Quanto à determinação das vulnerabilidades a serem focadas, isso realmente depende das aplicações que você está usando. Existem algumas medidas de segurança padrão que devem ser implementadas (discutidas mais adiante), porém vulnerabilidades específicas de aplicativos precisam ser pesquisadas e analisadas.
Mantenha em mente também que, à medida que o teste evolui, você pode perceber que ignorou certas questões importantes. Não tenha medo de interromper os testes para redefinir prioridades ou focar em vulnerabilidades adicionais. Lembre-se que no futuro este trabalho será muito mais fácil, pois será iterativo, o esforço inicial é o mais trabalhoso.
Executar aplicativos usando o mínimo de privilégios
Mesmo depois que todas as suas aplicações web forem avaliadas, testadas e sanitizadas contra as vulnerabilidades mais problemáticas, você não está a salvo. Cada aplicativo web possui privilégios específicos em computadores locais e remotos. Esses privilégios podem, e devem, ser ajustados para aumentar a segurança. Sempre use as configurações menos permissivas para todas as aplicações web. Isso significa que as aplicações devem ser “amarradas”. Somente pessoas com autorizações de alto nível devem poder fazer alterações no nível de sistema.
Este é um fator a ser considerado em suas avaliações iniciais, caso contrário você terá que repassar toda a lista ajustando as permissões de acordo. Para a vasta maioria das aplicações apenas os administradores de sistemas necessitam de acesso completo. A maioria dos outros usuários pode realizar o necessário com configurações minimamente permissivas. No caso improvável em que privilégios são ajustados incorretamente para um aplicativo e certos usuários não podem acessar os recursos de que precisam, o problema pode ser tratado pontualmente. É muito melhor ser demasiado restritivo nesta situação do que ser demasiado permissivo.
Proteja-se mesmo durante o processo de avaliação
Mesmo uma empresa pequena e simples pode levar semanas – ou até meses – para listar seus aplicativos web e fazer as alterações necessárias. Durante esse período o negócio pode estar vulnerável a ataques, portanto é crucial utilizar as ferramentas adequadas para evitar maiores problemas. Para isso existem algumas opções:
Remover funcionalidades de determinados aplicativos: se a funcionalidade torna o aplicativo mais vulnerável a ataques pode valer a pena restringir o seu uso.
Use um WAF (Web Application Firewall) para proteção contra as vulnerabilidades mais preocupantes.
O firewall de aplicação web filtra e obstrui tráfego HTTP indesejável e ajuda a blindar contra XSS, SQL injection e muito mais.
Durante todo o processo as aplicações web existentes devem ser monitoradas continuamente, para assegurar que não estão sendo violadas por terceiros. Se sua empresa, ou site, sofre um ataque durante este período, identifique o ponto fraco e faça a correção antes de continuar com o processo de checagem e sanitização. Você deve adquirir o hábito de documentar cuidadosamente as vulnerabilidades e como elas devem ser tratadas, para que as ocorrências futuras possam ser solucionadas de forma mais rápida e eficaz.
Use cookies de forma segura
Outra área que muitas organizações não aborda cuidadosamente é o uso de cookies. Os cookies são incrivelmente convenientes, tanto para empresas quanto para usuários. Eles permitem que os usuários sejam lembrados pelos sites que visitam, para que visitas futuras sejam mais rápidas e, em muitos casos, mais personalizadas. No entanto, cookies também podem ser manipulados por hackers para obter acesso a áreas protegidas. Apesar de não ser necessário interromper completamente o uso de cookies – o que seria um grande retrocesso em muitos aspectos – é necessário fazer ajustes a fim de minimizar o risco de ataques.
Nunca use cookies para armazenar informações altamente sensíveis ou críticas, por exemplo não use cookies para lembrar as senhas dos usuários, pois isso facilita muito aos hackers a obtenção de acesso não autorizado.
Você também deve ser conservador ao definir o prazo de expiração para os cookies. Claro, é bom saber que um cookie permanecerá válido para um usuário por meses, mas a realidade é que cada cookie representa um risco de segurança e quanto mais tempo durar, maior o tempo de exposição ao risco.
Finalmente, considere criptografar as informações armazenadas nos cookies que você usa, isto já vai dificultar muito o uso de forma maliciosa.
Implementar as seguintes sugestões de segurança web
Além do que já mencionamos, existem algumas outras sugestões de segurança de aplicações mais “imediatas” que você pode implementar:
Utilize HTTPS e redirecione todo o tráfego HTTP para HTTPS;
Evite ataques de cross-site-script (XSS) usando o cabeçalho de segurança x-xss-security;
Implemente uma política de segurança de conteúdo;
Nunca é demais lembrar, use senhas fortes que empregam uma combinação de letras minúsculas e maiúsculas, números e símbolos especiais, etc.
Conduzir Treinamentos para Conscientização de Segurança em Aplicações Web
Em uma empresa, são grandes as chances de que apenas um punhado de pessoas compreenda a importância da segurança em aplicações web. A maioria dos usuários tem apenas a compreensão mais básica do problema e isso pode torná-los descuidados. Usuários sem instrução não conseguem identificar apropriadamente os possíveis riscos de segurança. Em essência, educar a todos sobre segurança em aplicações web é uma ótima maneira de envolver a organização no ato de encontrar e eliminar vulnerabilidades. Com isso em mente, considere a possibilidade de trazer um especialista em segurança de aplicativos web para conduzir treinamentos de conscientização aos seus funcionários. Isso é muito importante para ajudar na implementação e manutenção das melhores práticas.
Manter as melhores práticas de segurança em aplicativos web é um esforço de equipe. Sua segurança como um todo é limitada ao elo mais fraco, seja sistema ou membro da equipe. Mantenha isso em mente e busque identificar constantemente o elo mais fraco a fim de fortalecê-lo.
https://gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.png00Go Cachehttps://gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.pngGo Cache2017-04-18 22:35:492017-11-23 03:22:04Melhores práticas de segurança em aplicações web
Este site utiliza cookies para aprimorar sua navegação. Na GoCache o uso de cookies é feito apenas para reconhecer um visitante constante e melhorar a experiência no uso dos Serviços. Os cookies são pequenos arquivos de dados transferidos de um site da web para o disco do seu computador, e não armazenam dados pessoais. OkNoPolítica de privacidade