Leia sobre dicas e funcionalidades da GoCache CDN para melhorar a seguranca do seu site, loja virtual ou app mobile.

O OWASP Top 10 é um documento padrão de conscientização para desenvolvedores e segurança de aplicativos da web. Ele representa um amplo consenso sobre os riscos de segurança mais críticos para aplicativos da web.

10 riscos de segurança de aplicativos da Web

A1: 2017-Injeção: Falhas de injeção, como SQL, NoSQL, OS e injeção de LDAP, ocorrem quando dados não confiáveis ​​são enviados a um intérprete como parte de um comando ou consulta. Os dados hostis do invasor podem induzir o intérprete a executar comandos indesejados ou acessar dados sem a autorização adequada.

A2: 2017-Quebra de Autenticação: As funções do aplicativo relacionadas à autenticação e gerenciamento de sessão são frequentemente implementadas incorretamente, permitindo que invasores comprometam senhas, chaves ou tokens de sessão ou explorem outras falhas de implementação para assumir as identidades de outros usuários temporária ou permanentemente.

A3: 2017-Exposição de dados confidenciais: Muitos aplicativos da web e APIs não protegem adequadamente os dados confidenciais, como finanças, saúde e PII. Os invasores podem roubar ou modificar esses dados fracamente protegidos para conduzir fraude de cartão de crédito, roubo de identidade ou outros crimes. Os dados confidenciais podem ser comprometidos sem proteção extra, como criptografia em repouso ou em trânsito, e requerem precauções especiais quando trocados com o navegador.

A4: 2017-XML Entidades externas (XXE): Muitos processadores XML mais antigos ou mal configurados avaliam referências de entidades externas em documentos XML. Entidades externas podem ser usadas para divulgar arquivos internos usando o manipulador de URI de arquivo, compartilhamentos de arquivos internos, varredura de porta interna, execução remota de código e ataques de negação de serviço.

A5: 2017-Quebra de Controle de Acesso: as restrições sobre o que os usuários autenticados têm permissão para fazer, muitas vezes não são aplicadas de forma adequada. Os invasores podem explorar essas falhas para acessar funcionalidades e/ou dados não autorizados, como acessar contas de outros usuários, visualizar arquivos confidenciais, modificar dados de outros usuários, alterar direitos de acesso, etc.

A6: 2017-Configuração incorreta de segurança: a configuração incorreta de segurança é o problema mais comum. Isso geralmente é o resultado de configurações padrão inseguras, configurações incompletas ou ad hoc, armazenamento em nuvem aberta, cabeçalhos HTTP configurados incorretamente e mensagens de erro detalhadas contendo informações confidenciais. Não apenas todos os sistemas operacionais, estruturas, bibliotecas e aplicativos devem ser configurados com segurança, mas também devem ser corrigidos/atualizados em tempo hábil.

A7: 2017-Cross-Site Scripting XSS: As falhas de XSS ocorrem sempre que um aplicativo inclui dados não confiáveis ​​em uma nova página da web sem validação ou escape adequado, ou atualiza uma página da web existente com dados fornecidos pelo usuário usando uma API do navegador que pode criar HTML ou JavaScript. O XSS permite que os invasores executem scripts no navegador da vítima, que podem sequestrar as sessões do usuário, desfigurar sites ou redirecionar o usuário para sites maliciosos.

A8: 2017-Desserialização Insegura: a desserialização insegura geralmente leva à execução remota de código. Mesmo que as falhas de desserialização não resultem na execução remota de código, elas podem ser usadas para realizar ataques, incluindo ataques de repetição, ataques de injeção e ataques de escalonamento de privilégios.

A9: 2017 – Usando Componentes Com Vulnerabilidades Conhecidas: componentes, como bibliotecas, frameworks e outros módulos de software, são executados com os mesmos privilégios do aplicativo. Se um componente vulnerável for explorado, tal ataque pode facilitar a perda de dados sérios ou o controle do servidor. Aplicativos e APIs que usam componentes com vulnerabilidades conhecidas podem minar as defesas do aplicativo e permitir vários ataques e impactos.

A10: 2017-Registro e monitoramento insuficientes: registro e monitoramento insuficientes, juntamente com a integração ausente ou ineficaz com a resposta a incidentes, permite que os invasores ataquem ainda mais os sistemas, mantenham a persistência, pivotem para mais sistemas e adulterem, extraiam ou destruam dados. A maioria dos estudos de violação mostra que o tempo para detectar uma violação é de mais de 200 dias, sendo normalmente detectada por partes externas em vez de processos internos ou monitoramento.

> Leia mais sobre o que é OWASP. 

Referencia: https://owasp.org/www-project-top-ten/

SSL / TLS são protocolos usados ​​para criptografar informações entre dois pontos. Geralmente é entre o servidor e o cliente, mas há momentos em que a criptografia de servidor para servidor e cliente para cliente é necessária. Este artigo se concentrará apenas na negociação entre servidor e cliente.

Para que a negociação SSL / TLS ocorra, o administrador do sistema deve preparar no mínimo 2 arquivos: Chave Privada e Certificado. Ao solicitar de uma Autoridade de Certificação, como DigiCert Trust Services, um arquivo adicional deve ser criado. Este arquivo é chamado de Solicitação de Assinatura de Certificado, gerado a partir da Chave Privada. O processo de geração dos arquivos depende do software que usará os arquivos para criptografia.

Observe que, embora os certificados solicitados de autoridades de certificação sejam inerentemente confiáveis ​​para a maioria dos clientes, certificados adicionais chamados Certificados de autoridade de certificação intermediários e Certificados de raiz de autoridade de certificação, podem precisar ser instalados no servidor. Novamente, isso depende do software do servidor. Geralmente, não há necessidade de instalar os arquivos de CA intermediário e raiz nos aplicativos cliente ou navegadores.

Assim que os arquivos estiverem prontos e corretamente instalados, basta iniciar a negociação SSL / TLS usando o protocolo seguro. Em aplicativos de navegador, geralmente é https://www.domain.com. Lembre-se de usar o endereço do seu site seguro. Acima é apenas um exemplo de endereço.

O handshake SSL padrão

A seguir está um handshake SSL padrão quando o algoritmo de troca de chave RSA é usado:

1. Olá Cliente

Informações de que o servidor precisa para se comunicar com o cliente usando SSL. Isso inclui o número da versão SSL, configurações de criptografia e dados específicos da sessão.

2. Olá Servidor

Informações de que o servidor precisa para se comunicar com o cliente usando SSL. Isso inclui o número da versão SSL, configurações de criptografia e dados específicos da sessão.

3. Autenticação e segredo pré-mestre

O cliente autentica o certificado do servidor. (por exemplo, nome comum / data / emissor) O cliente (dependendo da cifra) cria o segredo pré-mestre para a sessão, criptografa com a chave pública do servidor e envia o segredo pré-mestre criptografado para o servidor.

4. Descriptografia e segredo mestre

O servidor usa sua chave privada para descriptografar o segredo pré-mestre. Tanto o servidor quanto o cliente executam etapas para gerar o segredo mestre com a cifra acordada.

5. Criptografia com chave de sessão

O cliente e o servidor trocam mensagens para informar que as mensagens futuras serão criptografadas.

Referência: https://www.websecurity.digicert.com/security-topics/how-does-ssl-handshake-work

Depois de alguns meses de dedicação da equipe, temos orgulho em anunciar o lançamento de nosso painel multiusuário com gerenciamento de acesso via RBAC (Role Based Access Control). Pode parecer algo pouco significativo, mas o contexto e as premissas usadas no desenvolvimento são um marco para a evolução do posicionamento da GoCache.

TL:DR

• O multiusuário e o RBAC são os primeiros passos de uma evolução do posicionamento da GoCache
• O foco de nosso trabalho são empresas de tecnologia em crescimento, em processo de amadurecimento de suas práticas em DevOps e SRE, apoiadas ou não por MSPs e consultorias
• Buscamos um modelo que pudesse ser flexível e versátil, mas sem complicar a vida de quem gerencia os controles de acesso

Novo posicionamento

Tem sido nítida a mudança no mercado de tecnologia nos últimos anos. Aplicações web e mobile têm cada vez mais protagonismo na estratégia de entrega de valor de empresas de diferentes verticais. Isso tem pressionado bastante os limites aceitáveis de performance, disponibilidade e, principalmente, segurança dessas aplicações. Por sua vez, novas práticas de desenvolvimento e operação vem emergindo para suportar este aumento de escala demandado, sem sair dos limites de qualidade aceitáveis mencionados anteriormente.

Porém, essas mudanças organizacionais não costumam vir sem um preço. Conceitos emergentes como microsserviços costumam não ser tão compatíveis com aplicações mais legadas, ou até mesmo com aplicações de empresas mais novas, mas que acabaram de encontrar seu fit com o mercado, uma vez que sua missão recente era provar valor e ainda era muito cedo para gastar recursos com preparação para escala.

É nessa hora que hora que a organização é posta em cheque. A implantação de mudanças de arquitetura, de processos e culturais, que elevariam a produtividade, concorrem com os mesmos recursos empregados nas antigas rotinas mais onerosas, em um ambiente com mais pressão por entregas e com uma expansão de equipe demorada e trabalhosa. Mesmo com a importante ajuda de MSPs e consultorias auxiliando na modernização da plataforma, o período de instabilidade demora meses, gerando mais riscos para a resiliência e principalmente, para a segurança das aplicações.

Por isso, a GoCache resolveu entrar também nessa batalha. Já estava no DNA usar nossa tecnologia para resolver problemas mais amplos de nossos clientes, como por exemplo, elaborar estratégias de cache dinâmico para reduzir o consumo do servidor de origem dos mesmos. Ampliaremos nossa capacidade de solução de problemas de resiliência e segurança para além do proporcionado por CDN/WAF, mas, especialmente dentro de um contexto: empresas digitais com pressões por escala, reestruturando suas equipes e processos. Nesse momento, o gerenciamento de infra e segurança da aplicação precisa ser compartilhado entre diferentes pessoas, times e até mesmo com outras organizações, como MSPs e consultorias. É aí que o multiusuário e o RBAC tornam-se um passo importante.

Por que RBAC

Tendo em vista segurança em primeiro lugar, é fundamental seguir o princípio do menor privilégio em uma ferramenta de infraestrutura e segurança gerida por pessoas em diferentes papéis. Dessa forma, o modelo de controle de acesso baseado em papéis (Role-based Access Control ou RBAC) veio de forma natural.

Alguém pode estar se perguntando por que não usar um modelo mais simples, como por exemplo, definir as permissões individualmente para cada usuário (conhecido tecnicamente como DAC ou Discretionary Access Control). O que parece mais simples quando você tem poucos usuários pode se tornar um inferno à medida que sua equipe cresce, e ainda pode piorar ambientes dinâmicos e/ou com rotatividade, como costuma ser o caso de empresas ganhando escala. A cada nova pessoa, você teria que definir cada permissão que ela pode ter. A cada mudança de posição dela, você precisaria rever cada um desses itens. A cada revisão de políticas de acesso da empresa, você teria que mapear cada usuário afetado e fazer a correção um por um.

Por outro lado, existem modelos mais flexíveis e modernos, como o ABAC (Attribute-based Access Control), em que as políticas de acesso são implementadas de acordo com atributos do usuário, dos recursos e do contexto. O problema desta abordagem, é que traria uma complexidade desnecessária em toda a experiência de uso da GoCache, uma vez que o administrador seria obrigado a definir atributos para cada usuário, como cargo e squad, e também dos recursos, como por exemplo, qual squad é dono do recurso. E também teria que desenvolver um processo para garantir que essas informações estivessem sempre corretamente atualizadas. Desenvolvemos o controle de acesso no formato RBAC, mas buscando trazer o melhor compromisso entre simplicidade e flexibilidade em seu design, como mostraremos a seguir.

Como o RBAC da GoCache se diferencia de outras CDNs?

Poderíamos adotar uma abordagem mais minimalista como a da Cloudflare, em que os papéis já são pré-definidos em agrupamentos genéricos de privilégios para todos os domínios da conta, como “Somente Leitura”, “Analytics” e “Cache Purge”. Mas logo na fase de pesquisa, percebemos que as políticas de acesso para cada papel podem variar muito de empresa para empresa. Ex.: em algumas empresas o suporte pode fazer limpeza de cache, em outras não. Em outras, um analista jr de segurança pode apenas gerenciar os IPs bloqueados pelo Firewall, mas não pode desativar o WAF. Daí podem derivar dois problemas: o privilégio de um papel pode ser permissivo demais e a cada novo usuário, ou mudança na organização, o administrador precisaria fazer match entre as políticas de sua empresa e quais papéis predefinidos ele deveria escolher para um usuário.

Outro problema, é o acesso a todos os domínios da conta. Temos clientes, como MSPs e consultorias de ecommerce, que fazem o gerenciamento da GoCache para seus clientes. E uma das demandas que aparecem com certa frequência, é a necessidade de compartilhar alguns recursos para seus clientes, como limpeza de cache, mas sem o mesmo ter acesso a todos os domínios dos outros clientes. Uma outra necessidade que pode surgir está relacionada a empresas que se compõe de múltiplos squads. O uso da GoCache como um gateway de entrada da aplicação, a partir das smart rules, em que são criadas regras de roteamento para diferentes serviços de acordo com o padrão de URL, vem se tornando mais comum. E uma tendência atual, é que a gestão de cada serviço seja delegada ao seu respectivo squad, portanto, a configuração de um squad não pode conflitar com o squad vizinho.

A Fastly tem uma abordagem para contornar esse problema, mas ainda tem suas limitações. Nela, cada usuário deve ter um papel e apenas um. Todos dão acesso a todas as propriedades da conta, com exceção de apenas um, o “Engineer”. Quando você configura este papel, você define em quais serviços o usuário pode limpar cache e/ou visualizar as configurações, ou fazer tudo. Além de faltar granularidade, essa configuração trabalhosa tem que ser feita em cada usuário com papel de engineer, mesmo que exista mais de um com o mesmo tipo de papel na empresa. Buscamos uma abordagem mais granular, mas procurando combater a complexidade por meio de duas características, como você verá a seguir: reuso e contexto de negócio.

Como funciona o RBAC da GoCache?

O painel multiusuário e controle de acesso RBAC da GoCache é dividido em 4 elementos: Usuários, Grupos de Usuários, Listas de Domínios e Modelos de Permissões. O grupo de usuários basicamente tem a mesma função dos “Papéis” no modelo RBAC. O que diferencia o modelo da GoCache é que ao definir um papel, no caso, um grupo de usuários, você já define o escopo onde um conjunto de privilégios será aplicado, sendo o escopo uma lista dos domínios em que você quer dar algum privilégio, e o conjunto de privilégios em si, é definido no que chamamos modelo de permissões. Abaixo, você pode ver um diagrama para entender melhor como funciona.

Diagrama do funcionamento do RBAC da GoCache

Exemplo da implementação de um grupo de usuários

Como o próprio nome diz, a granularidade mínima do escopo é por domínio. Optamos por isso em um primeiro momento, para evitar problemas de usabilidade, principalmente por haver configurações que podem afetar um domínio inteiro e gerar conflitos de interpretação. Mas estamos pesquisando formas de permitir mais granularidade, portanto, se for algo que faça sentido para sua empresa, entre em contato conosco, pois seu feedback pode ser importante para criarmos uma experiência incrível na resolução deste problema.

No modelo de permissões, você pode definir as ações (criar, atualizar, excluir, ler e ordenar) pertinentes em cada recurso de nosso painel/API. Por exemplo: você pode criar um modelo em que o usuário pode apenas atualizar entradas de DNS existentes, mas não pode criar ou excluir. Em um primeiro momento, pode parecer complexo, mas a intenção é que você configure isso apenas uma vez e possa reusá-lo em diferentes grupos de usuários. Além disso, trazer modelos já prontos de casos de uso comuns, como Todas as Permissões, Apenas Leitura, Apenas Limpeza de Cache e Permissões para Financeiro.

Exemplo de um modelo de Permissões.

Exemplo de Uso

Suponha que sua empresa seja uma plataforma de e-commerce com milhares de clientes. Ela acabou de se fundir com outra plataforma, e, por causa disso, metade dos domínios apontam para uma aplicação, metade para outra, sendo cada uma gerida por times diferentes. Os domínios de sua própria empresa também estão presentes na mesma conta, sendo alguns usados para o site institucional e landing pages, geridos pela equipe de marketing, e outros para abrigar seus painéis de controle, geridos por outros times específicos. Uma empresa desse perfil provavelmente ainda teria outros papéis, mas vamos parar por aqui para não ficar extenso. Como ficaria a configuração?

Podemos primeiro, criar os grupos de usuários “Time Aplicação A” e “Time Aplicação B”. De acordo com as políticas de sua empresa, esses times têm permissão somente para configurar Smart Rules, Cache e ver Analytics, apenas dos domínios das aplicações que eles gerem. O primeiro passo é criar um modelo de permissões com o nome “Times de aplicações” e ativar os privilégios que condizem com essa política, dentro desse modelo. Depois, você agrupa os domínios de cada aplicação nas listas “Aplicação A” e “Aplicação B”. São milhares de domínios? Não tem problema! Você pode gerir essas listas de domínios, assim como todos os recursos do multiusuário e RBAC, via API, podendo integrar com seus pipelines de automação, assim, sempre que um domínio de seus novos clientes entrar na GoCache, você já atualiza ele em sua devida lista de domínios. Por fim, é só vincular a lista de domínios “Aplicação A” e o modelo de permissões “Times de aplicações” no grupo de domínios “Time Aplicação A”, e fazer o mesmo de forma análoga com o time B.

Para dar privilégio ao time de marketing, o processo é o mesmo. Vamos supor que o marketing pode fazer exatamente o mesmo que os times de aplicação, mas apenas nos domínios da empresa. Você reaproveita o modelo de permissões já criado “Times de aplicações”, cria a lista de domínios “Marketing”, contendo apenas os domínios da empresa voltados a marketing, e vincula ambos ao grupo de usuários “Marketing”. Agora sobraram apenas os times responsáveis pelos dashboards. Se sua política for a mesma que a dos times de desenvolvimento, mas com a adição de gestão de DNS, você pode copiar o modelo de permissões times de desenvolvimento, adicionar as opções de DNS e renomeá-lo como “Times de dashboards”. Em seguida, você cria as listas de domínios de cada dashboard, e as vincula junto com o modelo de permissões aos seus respectivos grupos de usuários. Por último, você adiciona cada usuário ao seu respectivo grupo de usuários.

Visão final do exemplo de uso do RBAC

Esse é apenas o começo

Nossos clientes evoluíram, e estamos evoluindo junto para apoiá-los ainda mais neste momento difícil, mas recompensador. O multiusuário e RBAC são passos importantes para suportar essa evolução organizacional, mas apenas a base do que está por vir. O que estiver ao nosso alcance em termos de tratamento de tráfego web para trazer muito mais resiliência e segurança para aplicações, faremos, mas sempre de olho abordagem mais descomplicada que conseguirmos.

Um firewall de aplicativo da web (web application firewall – WAF) ajuda a proteger os aplicativos da web de uma empresa, inspecionando e filtrando o tráfego entre cada aplicativo da web e a Internet. Um WAF pode ajudar a defender aplicativos da web de ataques como falsificação de solicitação entre sites (cross-site request forgery – CSRF), scripts entre sites (cross-site-scripting – XSS), inclusão de arquivos e injeção de SQL.

Um WAF pode ser especialmente benéfico para uma empresa que fornece um site de comércio eletrônico, serviços financeiros online ou qualquer outro tipo de produto ou serviço baseado na web que envolva interações com clientes ou parceiros de negócios. Nesses casos, os WAFs podem ser especialmente úteis na prevenção de fraudes e roubo de dados. No entanto, como um WAF não foi projetado para evitar todos os tipos de ataques, ele funciona melhor como parte de um conjunto de ferramentas que oferece suporte a um programa de segurança de aplicativo abrangente.

Principais benefícios de um WAF

Um WAF pode fornecer proteção crítica para qualquer empresa on-line que lide com dados privados de clientes com segurança. As empresas normalmente implantam um WAF para proteger os seus aplicativos da web de ataques sofisticados e direcionados, como cross-site scripting (XSS) e injeção de SQL, que podem resultar em fraude ou roubo de dados. Quando bem-sucedidos, esses tipos de incursões podem comprometer seriamente a confiança do cliente e até mesmo resultar em penalidades regulatórias. A proteção adicional que um WAF oferece pode ajudar a proteger a reputação e a posição de uma empresa no mercado.

Um WAF também alivia a carga administrativa de garantir testes de segurança de aplicativos da web adequados de maneira contínua. Ao ajudar a definir diretrizes e regras de forma proativa, as equipes de segurança de aplicativos podem monitorar o que deve e o que não deve ser permitido por meio de um WAF. A partir daí, as equipes podem receber notificações oportunas sobre um ataque em andamento para que possam responder com muito mais rapidez a possíveis incidentes de segurança.

Como um WAF fornece aos administradores de segurança a visibilidade do aplicativo necessária para demonstrar conformidade com padrões regulatórios como PCI, HIPAA e GDPR, ele também pode ser valioso do ponto de vista de conformidade. Combinadas, todas essas vantagens podem ajudar uma empresa a fortalecer a segurança de seus aplicativos da web e proteger melhor os dados do cliente contra ameaças em evolução.

WAFs sem estado vs. WAFs com estado

Um WAF fica entre os aplicativos da web de uma empresa e as solicitações vindas da Internet. Por meio do proxy reverso, ele monitora, filtra ou bloqueia pacotes de dados conforme eles viajam de e para um aplicativo da web. Ao fazer isso, ele tenta filtrar o tráfego potencialmente prejudicial que possa permitir explorações da web. Um WAF pode vir na forma de uma solução baseada em nuvem, um dispositivo, um plug-in de servidor ou um filtro.

Os primeiros WAFs, conhecidos como WAFs sem estado, usavam regras estáticas para analisar ameaças potenciais que chegavam por meio de solicitações de entrada aos servidores de aplicativos da web de uma empresa. Usando o reconhecimento de padrões, eles geraram efetivamente suposições educadas sobre como um aplicativo da web pode reagir a uma forma específica de ataque, usando modelos predeterminados de comportamento do aplicativo e comportamento de ataque. Por exemplo, WAFs sem estado podem verificar a rapidez com que as solicitações chegam, se são originadas da mesma fonte e outras métricas de comportamento que podem indicar que a atividade mal-intencionada está em andamento.

WAFs sem estado podiam executar essas tarefas muito mais rapidamente do que seus equivalentes humanos, mas não eram adaptáveis ​​ou ágeis o suficiente para evitar ataques em evolução. Seguiu-se um jogo contínuo de gato e rato no qual os invasores, ao descobrirem que sua forma inicial de ataque a um aplicativo da web não foi bem-sucedida, simplesmente criavam uma nova forma de comportamento de ataque que o WAF não tinha visto antes e não poderia evitar. Então, quando o WAF eventualmente recebesse novas regras que poderiam repelir essa nova variante de ataque, os invasores criariam outro método para evitar a detecção.

A segunda geração de WAFs, conhecida como WAFs com estado, oferece defesas mais ágeis do que o seu antecessor. WAFs com estado podem enriquecer os dados coletados com contexto relevante e analisar o cenário de ameaças atual de um aplicativo da web. Como eles levam em consideração uma visão mais ampla e contextual, os WAFs com monitoração de estado são melhores na detecção de problemas críticos, como ataques DDoS e ataques “baixos e lentos” que tentam minar a segurança voando sob o radar.

WAF vs. RASP

Outra tecnologia usada para monitoramento e proteção é a Autoproteção de Aplicativo de Tempo de Execução (Runtime Application Self-Protection – RASP). O RASP bloqueia o tráfego malicioso sem a necessidade de regras estáticas usando o próprio aplicativo. Em vez de depender de previsões sobre como um aplicativo pode se comportar em um determinado cenário, o RASP avalia o comportamento real do aplicativo para detectar atividades potencialmente maliciosas (por exemplo, uma chamada para um banco de dados, uma solicitação para abrir um arquivo ou uma solicitação para iniciar um shell para fins de execução de um comando) à medida que elas ocorrem.

Isso pode reduzir os falsos positivos frequentemente vistos ao usar um WAF, dando a uma equipe de segurança uma visão mais precisa dos ataques em potencial, em tempo real. E, como usa o próprio aplicativo, o RASP ainda pode avaliar a segurança de um aplicativo, mesmo que ele seja continuamente atualizado e desenvolvido. O RASP se encaixa mais facilmente em um processo contínuo, porque você pode observar como o aplicativo se comporta à medida que você envia alterações de código continuamente em vez de ter que manipular as regras estáticas para WAF. WAF e RASP podem se complementar, combinando forças para fornecer a uma empresa uma segurança de aplicativo abrangente e robusta.

3 dicas para o sucesso com um WAF

Aqui estão três dicas para garantir que a sua empresa maximize os benefícios de um WAF:

1. Certifique-se de que o seu WAF suporta os seus objetivos de segurança de aplicativo

Existem muitas soluções WAF disponíveis, cada uma com vários recursos e técnicas de segurança para identificar e prevenir ataques. Certifique-se de que qualquer WAF que você escolher seja compatível com os seus objetivos de segurança de aplicativo específicos.

2. Avalie e teste cuidadosamente a sua solução WAF

Para entender verdadeiramente como um WAF pode servir como parte integrante do seu programa de segurança de aplicativo, pode ser benéfico testar qualquer solução WAF que você está avaliando antes de tomar uma decisão final sobre implementá-la. Dessa forma, você pode avaliar e entender como ela funcionará em coordenação com outras ferramentas de segurança de aplicativos que você pode estar usando, como RASP, uma vez que essas tecnologias não são mutuamente exclusivas e podem ser usadas em conjunto para uma cobertura mais abrangente.

3. Considere quais recursos internos você precisará

Enquanto você avalia uma solução WAF, pense em quais recursos internos você precisará para aproveitá-la ao máximo. Você pode determinar que precisará desenvolver habilidades e capacidades adicionais dentro da equipe de segurança, por exemplo, ou pode querer considerar como a implementação de um WAF mudará os processos de segurança existentes que a sua equipe implementou.

As empresas enfrentam ataques cada vez mais sofisticados em seus aplicativos da web, à medida que agentes mal-intencionados buscam uma recompensa por fraude e roubo de dados. Garantir a segurança adequada de aplicativos da web nunca foi tão crítico, mas as empresas podem fazer avanços significativos para proteger os seus aplicativos da web e dados de clientes, adotando um firewall de aplicativo da web. É uma parte essencial de um kit de ferramentas de segurança de aplicativo robusto, bem como de um programa de segurança de aplicativo moderno.

Eu preciso de um firewall de aplicativo da web (WAF)?

Com os ataques cibernéticos se tornando cada vez mais complexos, as empresas e organizações devem se colocar na melhor posição para defenderem a si mesmas e a seus clientes de intenções maliciosas. As empresas envolvidas em e-commerce, serviços financeiros online e vários outros produtos baseados na web enfrentam uma ameaça constante de fraude e roubo de dados, o que as deixa sujeitas a comprometer a confiança do cliente e a possíveis disciplinas regulatórias.

Junto com um conjunto de ferramentas, os WAFs podem adicionar uma camada de defesa extra e essencial a um programa de segurança de aplicativo já robusto. Os profissionais de segurança podem aproveitar um firewall de aplicativo da web para monitorar um possível ataque em andamento, recebendo alertas para atividades que violam diretrizes e regras predeterminadas. Essa visibilidade garante que as equipes de segurança tenham a capacidade necessária para cumprir os padrões regulatórios, ao mesmo tempo em que mantém a máxima proteção para os dados do cliente.

Referencia: https://www.rapid7.com/fundamentals/web-application-firewalls/

new RDStationForms(‘newsletter-artigos-blog-842f5cbb60b7ed599409’, ‘UA-47041721-1’).createForm();

Se você já precisou comprar furadeira e ferramentas elétricas pela internet, provavelmente deve ter se deparado com a Dutra Máquinas, um dos principais e-commerces de máquinas e ferramentas do Brasil.

Fundada em 1982, a Dutra Máquinas comercializa equipamentos, máquinas e ferramentas para os mais diversos segmentos, distribuindo seus produtos por todas as regiões do Brasil.

Em sintonia com o mercado, a equipe da Dutra Máquinas investe em excelência e tecnologia para ganhar mais espaço dentro de um mercado tão competitivo quanto o de vendas online.

Desde 2019, o time da Dutra Máquinas escolheu a GoCache como parceiro tecnológico, buscando reforçar a segurança de seu site e otimizar a distribuição de sua loja em todas as regiões do Brasil.

Dutra Máquinas & GoCache em 2019:

O time da Dutra Máquinas escolheu a GoCache durante o período da Black Friday de 2019, em um momento delicado onde era necessário tomar ações rápidas.

Na quinta-feira as 23:00 o site esteve sob ataque de DDoS, causando lentidão e intermitência de acesso, e a solução encontrada foi integrar o serviço da Dutra Máquinas dentro da GoCache, que por sua vez, mitigou os ataques rapidamente à nível de rede e garantiu que a aplicação seguisse funcional e com velocidade para aproveitar o melhor período de vendas do varejo brasileiro.

Preparativos para Black Friday 2020:

Considerando o histórico de ataques durante o período de Black Friday de 2019, o time da Dutra Máquinas se concentrou em aprimorar a proteção de sua aplicação para 2020.

Neste período foram implementados os recursos:

Firewall: 

Soluções de Firewall são amplamente utilizadas dentro de servidores web, permitindo estabelecer condições de white list (permitir acesso) e black list (bloquear acesso) para otimizar a segurança de aplicações.

Dentro da GoCache, é possível utilizar os recursos de Firewall na borda, realizando bloqueios antes que as requisições cheguem de fato ao servidor web. Além disso, o Firewall da GoCache possibilita criar regras de desafios (recaptcha), com granularidade de configuração de URL, país de origem, versão HTTP, entre outros.

Analytics Firewall Smartrules

Conforme vemos acima, durante uma fração de tempo na Black Friday as regras de firewall interceptaram mais de 40 mil requisições. Dentre todos os eventos de firewall, 100% das vezes houve ações de desafio (recaptcha).

Caso tenha interesse em conhecer um pouco mais sobre o Firewall da GoCache, recomendamos a leitura de nossa documentação – Documentação de Segurança / Firewall

WAF: 

While proxies generally only protect clients, WAF protects servers. A WAF is implemented to protect a specific web application or set of web applications and can be considered a reverse proxy.

Basicamente, o WAF analisa diversos parâmetros de cada requisição com o objetivo de encontrar ações maliciosas, tais como Cross-Site Scripting (XSS) e SQL Injection, entre outros, antes que alcancem os servidores de hospedagem.

Analytics – Ações do WAF

Como vemos acima, durante uma fração de tempo dentro da Black Friday, a aplicação da Dutra Máquinas teve 488 ameaças detectadas. Dentre todos os eventos de WAF, 100% foram “desafiados” pela ferramenta da GoCache, onde é exibido um recaptcha para que o visitante prove ser um humano.

Caso tenha interesse em conhecer um pouco mais sobre o WAF da GoCache, recomendamos a leitura de nossa documentação – Documentação de Segurança / WAF

Rate Limit: 

O Rate Limit é uma ferramenta da GoCache utilizada para limitar a quantidade de requisições recebidas de um mesmo IP para a hospedagem.

Como recurso para segurança da hospedagem, o Rate Limit pode ser utilizado para suprimir alguns ataques da Web como DoS (também conhecido como “Denial Of Service”) e também tentativas de login por meio de força bruta.

Antes de implementar os recursos de Rate Limit, o time da Dutra Máquinas avaliou o histórico de requisições do site, buscando entender as taxas compatíveis com usuários legítimos, aplicando regras de Rate Limit somente para volumes de requisição fora do padrão usual.

Conformes vemos acima, durante uma fração de tempo da Black Friday 2020 foram interceptadas mais de 3.300 requisições. Dentre todas as requisições interceptadas, 100% foram desafiadas com recaptcha.

Caso tenha interesse em conhecer mais sobre os recursos de Rate Limit, recomendamos a leitura do nossa documentação – Documentação de Segurança / Rate Limit

E agora? Preparativos para a Black Friday 2021?

É claro!

Sustentar operações complexas na internet tem exigido cada vez mais tempo dos times de desenvolvimento e infraestrutura, tornando essa frente um pilar de grande importância dentro de empresas com alto grau de maturidade digital.

Manter-se protegido exige que você esteja avaliando constantemente sua aplicação, buscando encontrar vulnerabilidades para corrigi-las antes que usuários mal intencionados o façam.

E é claro que o time da Dutra Máquinas vai estar ainda mais preparado para o Black Friday de 2021 :)

Outros cases da GoCache: 

• UltraFarma – Reduz uso de CPU e ganha escala com GoCache
• Guia Invest – Otimizando métricas de Web Vitals
• Onfly – Como melhoramos a experiência de seus usuários
• Buser – Aprimorando segurança com Rate Limit