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?
No dia 9 de dezembro, a internet veio abaixo com a descoberta de uma vulnerabilidade (CVE-2021-44228) de alta criticidade encontrada na biblioteca do Java log4j 2, vastamente utilizada por milhares de serviços e empresas, como Steam, Twitter e até mesmo o famoso jogo eletrônico Minecraft.
A vulnerabilidade em questão, permite Remote Code Execution (RCE) no servidor afetado, isto é, uma vez explorada, a vulnerabilidade permite controle total sobre a máquina atacada
O que é o log4j 2?
Para entender como esta vulnerabilidade é explorada, primeiro precisamos entender o que é o pacote log4j2.
Uma das bibliotecas de logging mais populares, o log4j2 é um framework open source de logging incorporado em muitas aplicações baseadas em Java. Ela oferece aos desenvolvedores uma maneira de criar logs para gravar sua atividade em diversos casos de uso, como monitoração, rastreamento de dados, troubleshooting, entre outras coisas. Em suma, o log4j2 é um pacote open source, gratuito, que é utilizado pelas maiores empresas do mundo.
O impacto de CVE-2021-44228
O impacto desta vulnerabilidade é enorme devido à ampla adoção desta biblioteca Log4j . Se você tiver alguns aplicativos java em seu ambiente, é provável que eles estejam usando Log4j para registrar eventos internos.
A exploração também é bastante flexível, permitindo que você recupere e execute código arbitrário de servidores LDAP locais para remotos e outros protocolos.
Todos esses fatores e o alto impacto em tantos sistemas dão a essa vulnerabilidade uma classificação de gravidade CRÍTICA de CVSS3 10.0. O fato de a vulnerabilidade estar sendo explorada ativamente aumenta ainda mais o risco para as organizações afetadas.
Por dentro da falha
A vulnerabilidade se aproveita do Java Naming and Directory Interface (JNDI), que é uma API para acesso a serviços de diretórios. Ela permite que aplicações cliente descubram e obtenham dados ou objetos através de um nome. É fornecido um nome diferente de resolução e serviço de diretórios, como DNS e LDAP.
A vulnerabilidade existe por que no pacote Log4j, o componente afetado valida de forma não ideal os dados fornecidos pelo usuário, potencialmente permitindo um atacante fornecer uma linha que é interpretada como uma variável de código, que resulta no carregamento de um arquivo de classe Java.
Segue um exemplo resumido de como essa vulnerabilidade pode ser explorada, este método se baseia em uma política de logs especialmente construída para passar dados maliciosos como uma mensagem de erro.
Para concretizar a exploração, a URL JNDI/LDAP fornece um objeto de uma classe do Java que será carregada no host vítima, onde há a presença do Log4j, e isto só é possível por que o JDNI não reforça nenhum controle de segurança nas requisições do protocolo LDAP. E além disso, o protocolo LDAP suporta o carregamento de classe por usuários remotos.
Mitigação com a GoCache
Um dos serviços GoCache é o seu WAF (Web Application Firewall), que protege aplicações contra ataques e atividades maliciosas. Foram disponibilizadas novas regras para bloquear tentativas de exploração do Log4Shell, que fazem o bloqueio de qualquer requisição que tenha em seu corpo ou parâmetro, a carga maliciosa que explora a vulnerabilidade recém-descoberta, mitigando inclusive tentativas de formatação de textos, prática comum na tentativa de contornar o sistema de segurança do WAF.
Por Marcos Medeiros, Support Analyst GoCache
https://gocache.com.br/wp-content/uploads/2021/12/log4shell.jpg6831024Go Cachehttps://gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.pngGo Cache2021-12-27 13:00:322022-07-13 10:35:51Log4shell: A vulnerabilidade zero day encontrada na biblioteca Log4j2 do Java
No post de hoje, vamos explorar como manter a segurança de um site ou loja virtual e como gerenciar melhor os logins. Vamos ir um pouco além das dicas como “escolha uma senha complicada” para aprofundar um pouco mais sobre as questões essenciais.
Na hora de criar sua loja virtual é importante que você tenha em mente que a segurança é um fator decisivo para o sucesso – e longevidade – do seu negócio online.
Está pronto?
Limite de logins
Uma das primeiras coisas que você pode fazer para gerenciar a segurança do WordPress é limitar o número de vezes que as pessoas podem tentar fazer o login. Muitos hackers usam ataques de força bruta para tentar decifrar seu nome de usuário e/ou senha. Mesmo que essas investidas não sejam bem-sucedidos, a natureza repetitiva pode colocar uma carga significativa em seu servidor.
Ao limitar logins, você evita que um hacker tente um ataque de força bruta. Ele tentaria duas a três vezes e então seu IP seria banido. Você pode facilmente configurar isso usando o plugin Loginizer.
Uma outra opção muito interessante é o plugin Login Lockdown. Como essas duas opções limitam o número de tentativas de login que um usuário pode fazer antes que seu IP seja banido por quantas horas você determinar, ataques de força bruta seriam muito mais difíceis de serem executados. O plugin continuaria proibindo esse endereço IP após um determinado número de tentativas de login com falha. Além disso, você pode personalizar para criar a configuração de segurança ideal para o seu site.
Banir usuários que tentam usar “admin” como nome de usuário
Evite usar o nome de usuário como “admin”, visto que boa parte dos ataques de força bruta nos dias de hoje são de hackers que utilizam esse nome de usuário padrão para tentar invadir o site. No entanto, você pode interromper suas tentativas, proibindo qualquer pessoa que tente usar o “admin”.
O plugin Wordfence é muito bom para configurar esse recurso de proibição automática. É claro que este plugin inclui muitos outros recursos, como autenticação de dois fatores, bloqueio de invasores conhecidos e muito mais.
Estabelecer as permissões corretas dos arquivos
Outra coisa que você quer fazer é estabelecer as permissões de arquivo corretas no seu site. De acordo com o WordPress.org, a configuração de um diretório com permissões 777 pode permitir que um hacker ou outra entidade mal-intencionada edite seus arquivos ou até mesmo faça o upload de novos, como malwares. Seu arquivo wp-config.php deve ser configurado para 600; seus arquivos regulares devem ser configurados para 640 ou 644; e seus diretórios devem ser configurados para 750 ou 755. Embora não seja necessário fazer essa alteração em todos os hosts, você ainda deve consultá-lo através do guia do WordPress para alterar permissões de arquivos.
Ocultar a página de login
O arquivo .htaccess é um arquivo de texto oculto usado pelo servidor da web Apache para configurar seu site sem a necessidade de criar ou modificar arquivos globais de configuração do servidor. Geralmente, ele está localizado na pasta raiz do site, mas também pode estar em outros locais, dependendo de quais arquivos e pastas você deseja que sejam afetados pela configuração especificada.
Essa é outra modificação do .htaccess, mas é um pouco diferente das outras. Você pode negar o acesso à página de login do seu site WordPress completamente. Claro, só funciona se o site tiver um único autor e se o endereço praticamente nunca tenha sido alterado. Outras poucas linhas de código no arquivo .htaccess negarão o acesso à página de login para todos, exceto os endereços IP que você especificar.
Se você deseja manter suas opções abertas em termos de adicionar autores ao seu site mais tarde, você sempre pode usar um plugin para simplesmente ocultar a página de login de usuários não autorizados. Secure Hidden Login é uma dessas opções. Embora você possa configurá-lo para que a tela de login apareça quando o logotipo do WordPress for clicado, uma opção mais segura seria definir a ativação dos campos de nome de usuário e senha pressionando uma combinação de teclas.
Remover informações da tag do gerador
Hackers podem fazer todo tipo de ação para tentar entrar em sites do WordPress, como por exemplo executar scripts para encontrar instalações da plataforma na Internet com base em footprints.
Footprints são linhas de texto ou códigos identificáveis ou ainda recorrentes que identificam que um site usa um conjunto particular de código.
No caso do WordPress, por exemplo, é um exemplo de “linhas recorrentes de texto ou código”. Além disso, por padrão, a plataforma identifica que o site que você está vendo foi construído no WP.
O código fonte de um site WordPress vai dizer algo assim:
Você pode remover essa tag do código-fonte, o que dá aos hackers algo a menos para encontrar (e segmentar) seu site. Os webmasters podem adicionar a seguinte linha de código ao seu arquivo functions.php:
remove_action(‘wp_head’, ‘wp_generator’);
Remover a tag generator significa que seu site não se identifica mais como WordPress.
Ativar autenticação em duas etapas
Outra ação bastante indicada para proteger seu site é configurar a autenticação em duas etapas. Ao exigir que os usuários do site executem duas etapas para o login, potencialmente desestimulará os ataques de força bruta da maioria dos hackers. Tudo isso irá fazer com que seu site se torne considerado difícil de quebrar, o que definitivamente é algo muito bom!
Existem vários plugins que ativam esse recurso em seu site. Alguns favoritos em particular incluem:
Clef : uma vez configurado, tudo o que você precisa fazer é abrir o aplicativo Clef no seu celular e focar sua câmera em uma imagem em movimento na tela do seu computador. Ele vai “travar” no lugar e você estará logado.
Duo Two-Factor Authentication : depois de inserir sua senha através do formulário de login normal, você terá que concluir uma etapa secundária para efetuar login, como confirmá-la em um aplicativo de telefone, em uma mensagem de texto SMS ou em uma chamada telefônica.
WAF (Web Application Firewall)
Uma das maneiras mais rápidas de proteger um site em WordPress é usar o WAF (Web Application Firewall). O WAF adiciona vários elementos de segurança de imediato e protege contra as maiores ameaças online.
Basicamente um WAF (Web Application Firewall) é um filtro que fica na frente de seu aplicativo, inspecionando o tráfego de entrada em busca das ameaças mais comuns como Cross-Site Scripting (XSS) e SQL Injection e DDoS. É um dos meios mais comuns de proteção contra ataques na camada de aplicativo.
Você pode utilizar um WAF hospedado ou um WAF baseado em nuvem. Quando baseado em nuvem, você pode contrata-lo individualmente, ou como em muitos casos, contratá-lo em um pacote disponibilizado por um fornecedor CDN (Content Delivery Network, veja o que é uma CDN).
A GoCache oferece WAF em todos os planos de CDN que disponibiliza, sem custo adicional. Além de proteger seu site, você pode acelerá-lo sem muito esforço, pois já existem configurações específicas para WordPress e um plugin para integração com o Back-End.
Conclusão
Gerenciar a segurança em seu site WordPress e configurar logins seguros levará algum tempo. Mas uma vez que todas essas medidas estiverem em vigor, seu site será muito mais confiável para seus usuários. E você terá a tranquilidade de saber que uma queda maliciosa é improvável.
Você usa algum dos métodos de segurança mencionados anteriormente? Você faz mais alguma coisa que não citamos aqui? Comente abaixo!
“Este é um post escrito por nosso convidado Caio Nogueira, co-fundador e da UpSites Digital, empresa especializada em criação de sites responsivos WordPress. Apaixonado por novas tecnologias e pelo desafio de criar soluções na internet que ajudem empresas e pessoas a aumentar as vendas, gerar leads e contar histórias”.
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 Cache2018-12-18 16:11:342019-01-10 14:53:41Guia de Segurança para WordPress: Gerenciamento e Logins
Quando alguém precisa descobrir o IP de um computador é quase certo que utilizará o famoso site MeuIP.com.br. O site tem mais de 20 anos de existência e é, de longe, o mais usado para essa simples, porém importante, funcionalidade.
Nos últimos meses este site estava tendo um problema muito grande de gastos com banda, desproporcional ao número de visitantes que recebia. Após alguns dias analisando o problema, os administradores chegaram a conclusão de que havia um número excessivo de acessos de robôs, crawlers e outros tipos de user agents maliciosos, e estes estavam consumindo muita banda e processamento do servidor (user agent é o identificador dos navegadores que acessam seu site).
Foi então que o MeuIP decidiu utilizar um WAF (Web Application Firewall) para bloquear esses acessos indesejados. Eles utilizaram o sistema da GoCache para isso e o sucesso foi tamanho que resolveram dividir conosco, através deste artigo, os resultados que conseguiram.
Acesso de User Agents indesejados ao site:
Após analisar profundamente os acessos ao site, os administradores notaram que haviam milhares de acessos onde o user agent continha strings como: Indy, Sinapse, curl, Python, Delphi, Java, Ruby e mesmo vazia.
Aparentemente isso ocorria porque inúmeros aplicativos estavam usando o servidor, indevidamente, para resolver o endereço IP dos computadores onde estavam rodando. O problema é que o site não estava preparado para isso, o que acabou por sobrecarregar os servidores e consumir muita banda.
A solução foi utilizar o WAF da GoCache para bloquear esses acessos indesejados, veja como:
Configurando o Web Application Firewall:
1. Nível de Segurança:
O primeiro ponto a ser configurado foi em regras “Geral” do Firewall. Conforme pode ver abaixo, foi escolhido o nível de segurança Alto, e modo de Simulação.
O modo de simulação costuma ser inicialmente utilizado para ter certeza de que não estará bloqueando acessos que gostaria que fossem permitidos. Após simularmos e termos certeza de que está tudo certo, muda-se o Modo de Segurança de “Simular” para “Bloquear”.
Em apenas alguns segundos após habilitar essa regra no firewall, dezenas de eventos de bloqueio aparecem na aba “Eventos”:
Clicando no ícone azul, do lado direito, pudemos analisar os bloqueios que seriam feitos. Veja, por exemplo, que o WAF bloqueará acesso do User Agent Indy, que é considerado um Rogue Crawler, ou seja, um Navegador malicioso, muito usado para Spam, por exemplo.
Além deste User Agent, o WAF também mostrou outros eventos de bloqueio, como User Agent Vazio ou outros acessos suspeitos.
No entanto, ainda havia vários outros User Agent que gostaríamos de bloquear. Poderíamos adicionar outras regras ao Firewall, uma para cada User Agent que desejássemos bloquear. No entanto, optamos por utilizar as SmartRules do Firewall, como verá abaixo.
2. Regras SmartRules do Firewall:
Ao invés de colocarmos uma regra para cada User Agent que desejávamos bloquear, utilizamos apenas uma SmartRule para WAF, bloqueando todos os agentes. (Para usar, clique em SmartRules e depois Firewall).
Isso ocorre porque nas SmartRules podemos usar expressões regulares, como os símbolos: * = significando tudo, & = significando ‘e’, | = significando ‘ou’.
Inicialmente parece um pouco assustadora, mas ela é bem simples e foi capaz de bloquear praticamente todos os User Agents indesejados.
É importante lembrar que, para que todas as configurações façam efeito, você precisa trocar o Modo de Segurança do Firewall, do modo “Simular” para o modo “Bloquear”.
Economia de Banda após o uso do WAF:
Imediatamente após proteger o site com o Web Application Firewall e bloquear os User Agents com a SmartRule, ocorreu uma queda surpreendente no consumo de banda. Veja os gráficos do servidor que estava hospedado na AWS (Amazon).
O site estava consumindo por volta de 27MBytes a cada 5 minutos e passou a consumir pouco mais de 10MBytes. Isso representou uma economia de quase 70% de banda, muito mais do que os administradores do site esperavam.
Veja que o Gráfico de Consumo encontrado no Painel da GoCache também confirma a redução de 3 vezes na transferência de dados. (A escala é diferente do anterior e um deles está no horário de SP e outro GMT).
Também note que o tráfego na CDN se manteve igual (verde escuro) e os tráfegos no servidor (verde claro) e total (marrom) foram reduzidos. Ou seja, a CDN bloqueou o tráfego indesejado ao servidor, economizando banda e processamento.
Considerando que a banda era um dos principais gastos do site, o uso do WAF representou uma excepcional economia com da transferência de dados. Especialmente se considerar que o tráfego de dados na Amazon é bastante caro.
Por fim, além da economia de banda, o WAF também, certamente, deixou o sistema mais seguro contra outros tipos de ataques, como DDoS e Força Bruta.
Uma outra dica interessante sobre WAF é que você pode também bloquear o acesso de ataques vindos de outros países, deixando seu site ainda mais seguro. Veja como fazer isto neste artigo: Bloquear IPs de outros países.
E, para entender melhor como uma CDN pode acelerar e proteger seu site, não deixe de ver o vídeo abaixo.
https://gocache.com.br/wp-content/uploads/2017/10/Waf.png269297Go Cachehttps://gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.pngGo Cache2017-12-08 13:05:592018-07-03 15:12:40Protegendo seu Site e Economizando Banda com WAF
É muito comum ver os proprietários de sites WordPress irritados com questões de segurança.
A opinião mais comum é que um software de código aberto (open source) é vulnerável a todos os tipos de ataques. Mas isso não é verdade – normalmente é o contrário. Ou, ok, digamos que é parcialmente verdade, mas mesmo assim você não deve culpar o WordPress.
Por quê? Porque costuma ser sua culpa que seu site tenha sido hackeado. Existem algumas responsabilidades que você precisa ter como proprietário de um site. Então, a questão-chave é sempre: o que você está fazendo para garantir a segurança do seu site?
Vamos ver abaixo alguns truques simples que podem ajudá-lo a proteger seu site WordPress:
Parte (a): Proteja a página de login e evite ataques de força bruta
Todos conhecem a URL padrão da página de login do WordPress. O backend do site é acessado a partir daí, e essa é a razão pela qual as pessoas tentam entrar na força bruta. Basta adicionar /wp-login.php ou /wp-admin/ no final do seu nome de domínio e pronto, o hacker já sabe a URL que deve atacar.
O que recomendamos é personalizar o URL da página de login. Essa é a primeira coisa a ser feita para começar a proteger seu site.
Abaixo estão mais algumas sugestões para proteger sua página de login:
1. Configurar bloqueio do site e proibir os usuários
Um recurso de bloqueio limitando o número de tentativas de login pode resolver um enorme problema, pois não dará mais pra ficar usando força-bruta, testando milhares de senhas. Sempre que alguém tentar hackear com senhas erradas e de forma repetitiva, o site ficará bloqueado e você será notificado dessa atividade não autorizada.
O plugin iThemes Security é um dos melhores plugins desse tipo, e já o uso há muito tempo. Esse plugin tem muito a oferecer a esse respeito. Você pode especificar um certo número de tentativas de login, após as quais o plugin proíbe acessos do endereço IP do invasor.
(Alternativamente, você também pode usar o plugin Login LockDown que foi criado para ajudá-lo especificamente com esse problema.)
2. Use a autenticação de dois fatores
Apresentar a autenticação de 2 fatores (2FA) na página de login é outra boa medida de segurança. Nesse caso, o usuário fornece detalhes de login para dois componentes diferentes. O proprietário do site decide o que esses são esses dois fatores. Pode ser uma senha regular seguida de uma pergunta secreta, um código secreto, um conjunto de caracteres, etc.
Há pessoas que preferem usar um código secreto ao implantar o 2FA em seus sites. O plugin do Google Authenticator pode ajudar com isso em apenas alguns cliques.
3. Use o email como login
Por padrão, você deve inserir seu nome de usuário para fazer login. Usar uma ID de email em vez de um nome de usuário é uma abordagem mais segura. Os motivos são bastante óbvios. Os nomes de usuário são fáceis de prever, enquanto as IDs de e-mail não são. Além disso, qualquer conta de usuário do WordPress sempre é criada com um endereço de e-mail exclusivo, tornando-se um identificador válido para iniciar sessão.
O plug-in de Login por Email do WP funciona muito bem para isso. Ele começa a funcionar logo após a ativação e não requer nenhuma configuração.
Para testá-lo, basta sair do seu site e, em seguida, fazer login novamente, mas desta vez use o endereço de e-mail com o qual você criou a conta.
4. Renomeie seu URL de login
Alterar a URL de login é algo muito fácil de ser feito. Por padrão, a página de login do WordPress pode ser acessada facilmente em wp-login.php ou wp-admin, adicionado à URL principal do site. Exemplo: http://seublog.com/wp-admin
Quando os hackers conhecem a URL da sua página de login, eles podem tentar entrar na força bruta. Tentam fazer login com o GWDb (Guess Work Database, ou seja, um banco de dados de nomes de usuário e senhas, por exemplo, nome de usuário: admin e senha: p@ssword … com milhões de tais combinações).
Então, até este momento – se você acompanhou – já restringimos as tentativas de login do usuário e trocamos os nomes de usuário por IDs de e-mail. Agora podemos substituir o URL de login e eliminar 99% dos ataques diretos de força bruta.
Este pequeno truque restringe a entrada de alguém mal intencionado na página de login. Somente alguém com a URL exato pode fazer isso. Mais uma vez, o plugin iThemes Security pode ajudá-lo a alterar seus URLs de login. Algo como:
Altere wp-login.php para algo único; por exemplo my_new_login
Alterar /wp-admin/ para algo único; por exemplo my_new_admin
Mude /wp-login.php?action=register para algo único, ex: my_new_registration
5. Ajuste suas senhas
Trabalhe com as senhas do site e mude-as regularmente. Melhore sua força adicionando letras maiúsculas e minúsculas, números e caracteres especiais. Esse Gerador de Senha, por exemplo, pode te ajudar nessa tarefa.
Parte (b): proteja seu painel de administração
Para um hacker, a parte mais desejada de um site é o Painel do Administrador, que é de fato a seção mais protegida de todos. Então, atacar a parte mais forte é o verdadeiro desafio e, se cumprido, dá ao hacker uma vitória moral e o acesso para causar um dano enorme.
Veja o que você pode fazer para se proteger:
6. Proteja o diretório wp-admin
O diretório wp-admin é o coração de qualquer site do WordPress. Portanto, se esta parte do seu site for violada, todo o site pode ficar danificado.
Uma maneira de evitar isso é proteger com senha o diretório wp-admin . Com essa medida de segurança, o proprietário do site pode acessar o painel exibindo duas senhas. Um protege a página de login e a outra a área de administração do WordPress. Se os usuários do site forem obrigados a acessar algumas partes específicas do wp-admin , você pode desbloquear essas partes enquanto bloqueia o resto.
Você pode usar o plugin AskApache Password Protect para proteger a área de administração. Ele gera automaticamente um arquivo .htpasswd , criptografa a senha e configura as permissões de segurança do arquivo.
7. Use SSL para criptografar dados
A implementação de um certificado SSL (Secure Socket Layer) é uma jogada inteligente para proteger o painel de administração. O SSL garante a transferência segura de dados entre os navegadores dos usuários e o servidor, dificultando a invasão de hackers ou a falsificação de suas informações.
Obter um certificado SSL para o seu site WordPress não é um problema. Você pode comprar um de algumas empresas dedicadas, ou mesmo utilizar um Certificado SSL Gratuito .
O certificado SSL também afeta o ranking do seu site no Google. O Google classifica sites com SSL superiores aos que não possuem. Isso significa mais tráfego. Quem não quer isso?
8. Adicione contas de usuários com cuidado
Se você tiver um blog do WordPress com vários autores, então você precisa lidar com várias pessoas que acessam seu painel de administração. Isso pode tornar seu site mais vulnerável a ameaças de segurança.
Você pode usar um plugin que force seus usuários a usarem senhas fortes, assim você garante que as senhas que utilizam sejam seguras. Esta é apenas uma medida de precaução.
9. Altere o nome de usuário do administrador
Durante a instalação do WordPress, você nunca deve escolher “admin” como o nome de usuário da sua conta de administrador principal. Esse nome de usuário é fácil de adivinhar e acessível para hackers. Metade do trabalho dos hackers já estará feita, só vão precisar descobrir a senha, pois já sabem o ID do administrador.
Novamente, o plugin de iThemes Security pode interromper tentativas de Login do usuário Admin, de forma inteligente, proibindo imediatamente qualquer endereço IP que tente fazer login com esse nome de usuário.
10. Monitore seus arquivos
Se você quiser alguma segurança extra adicionada, você pode monitorar as alterações nos arquivos do site através de plugins como Wordfence ou, novamente, iThemes Security.
Parte (c): Proteja o banco de dados
Todos os dados e informações do seu site são armazenados no banco de dados. Cuidar disso é crucial. Aqui estão algumas coisas que você pode fazer para torná-lo mais seguro:
11. Altere o prefixo da tabela de banco de dados do WordPress
Se você já instalou o WordPress, você está familiarizado com o prefixo wp- table que é usado pelo banco de dados. É recomendado que você mude isso para algo único.
O uso do prefixo padrão torna o banco de dados do site propenso a ataques de injeção SQL. Esse ataque pode ser evitado mudando wp- para algum outro termo, por exemplo, você pode usar mywp- , wpnew- , etc.
Se você já instalou seu site do WordPress com o prefixo padrão, então você pode usar alguns plugins para alterá-lo. Plugins como WP-DBManager ou iThemes Security podem ajudá-lo a fazer o trabalho com apenas um clique de um botão. (Certifique-se de fazer uma cópia de segurança do seu site antes de fazer qualquer coisa no banco de dados).
12. Faça backup de seu site regularmente
Não importa o quão seguro o seu site é, sempre há margem para melhorias. E no final das contas, manter um backup, longe de seu servidor original, talvez seja o melhor antídoto, não importa o que aconteça.
Se você tem um backup, você sempre pode restaurar seu site WordPress para um estado de trabalho sempre que desejar. Existem alguns plugins que podem ajudá-lo a esse respeito. Por exemplo, existem todos estes.
Se você está procurando uma solução premium, então eu recomendo o VaultPress pela Automattic, o que é excelente. Eu tenho configurado para criar backups a cada 30 minutos. E se alguma coisa ruim acontecer, eu posso facilmente restaurar o site com apenas um clique. Além disso, ele também verifica meu site em busca de malware, e me avisa se alguma coisa está acontecendo.
Outra opção é utilizar o site DropMySte. Ele faz backups diário dos seus arquivos e do seu banco de dados, e é super fácil restaurar caso tenha problemas.
13. Defina senhas fortes para o seu banco de dados
Uma senha forte para o usuário principal do banco de dados é uma obrigação!.
Como sempre, use letras maiúsculas, minúsculas, números e caracteres especiais para a senha. Recomendamos mais uma vez usar um gerador de senhas para isso
Parte (d): Proteja sua configuração de hospedagem
Quase todas as empresas de hospedagem afirmam fornecer um ambiente otimizado para o WordPress, mas ainda podemos dar um passo adiante:
Ao falarmos em proteção de Hospedagem, não há nada mais eficiente e completo que o novo conceito de Firewall para Web, mais conhecido como WAF – Web Application Firewall para WordPress.
O WAF para WordPress é um filtro de acesso ao ser servidor de hospedagem, que aplica um conjunto de regras, com o objetivo de proteger seu site de ataques comuns, tais como Cross-Site Scripting (XSS) e SQL Injection e DDoS. Isso tudo, antes mesmo do atacante sequer chegar ao seu servidor de hospedagem.
Esse tipo de serviço é muito recomendável e pode ser contratado individualmente, ou como parte integrante dos serviços disponibilizados por uma boa CDN (Veja o que é CDN).
15. Proteja o arquivo wp-config.php
O arquivo wp-config.php contém informações cruciais sobre sua instalação do WordPress e, de fato, é o arquivo mais importante no diretório raiz do seu site. Protegê-lo significa proteger o núcleo do seu blog WordPress.
É difícil para hackers violar a segurança do seu site se o arquivo wp-config.php se tornar inacessível para eles.
A boa notícia é que fazer isso é realmente fácil. Basta pegar o seu arquivo wp-config.php e movê-lo para um nível superior ao seu diretório raiz.
Agora a questão é, se você armazená-lo em outro lugar, como o servidor irá acessá-lo? Na arquitetura atual do WordPress, mesmo que o arquivo de configuração seja armazenado um nível acima do diretório raiz, o WordPress ainda poderá vê-lo.
16. Proibir a edição de arquivos
Se um usuário tiver acesso de administrador ao seu painel do WordPress, ele pode editar quaisquer arquivos que façam parte da instalação. Isso inclui todos os plugins e temas.
No entanto, se você não permitir a edição de arquivos, mesmo que um hacker obtenha acesso de administrador ao seu painel do WordPress, eles ainda não poderão modificar nenhum arquivo.
Adicione o seguinte ao arquivo wp-config.php (no final):
define('DISALLOW_FILE_EDIT', true);
17. Conecte o servidor corretamente
Ao configurar seu site, conecte o servidor somente através de SFTP ou SSH. O SFTP é sempre preferido ao invés do FTP tradicional por causa de seus recursos de segurança que, claro, não são atribuídos ao FTP.
A conexão do servidor dessa maneira garante transferências seguras de todos os arquivos. Muitos provedores de hospedagem oferecem este serviço como parte de seu pacote. Caso contrário – você pode fazê-lo manualmente (procure no google por tutoriais, vai achar muita coisa).
18. Defina as permissões do diretório com cuidado
As permissões de diretório incorretas podem ser fatais, especialmente se você estiver trabalhando em um ambiente de hospedagem compartilhado.
Nesse caso, alterar arquivos e permissões de diretório é uma boa jogada para proteger o site no nível de hospedagem. Definir as permissões de diretório para “755” e os arquivos para “644” protegem todo o sistema de arquivos – diretórios, subdiretórios e arquivos individuais.
Isso pode ser feito manualmente através do Gerenciador de arquivos, dentro do seu painel de controle de hospedagem, ou através do terminal (conectado via SSH) – use o comando “chmod”.
Para mais informações, você pode ler sobre o esquema de permissão correto do WordPress ou instalar o plugin iThemes Security para verificar suas configurações de permissão atuais.
19. Desativar listagem de diretórios com .htaccess
Se você criar um novo diretório no seu site e não colocar um arquivo index.html dentro dele, você ficará surpreso ao descobrir que seus visitantes podem obter uma listagem completa do diretório e de tudo o que está lá dentro.
Por exemplo, se você criar um diretório chamado “dados”, você pode ver tudo nesse diretório simplesmente digitando http://www.seublog.com/dados/ no seu navegador. Nenhuma senha ou qualquer coisa é necessária.
Você pode evitar isso adicionando a seguinte linha de código no seu arquivo .htaccess :
Options All -Indexes
Parte (e): proteja seus temas e plugins do WordPress
Temas e plugins são ingredientes essenciais de qualquer website do WordPress. Infelizmente, eles também podem representar sérias ameaças à segurança. Vamos descobrir como podemos proteger os temas e plugins do WordPress da maneira correta:
20. Atualize regularmente
Todo bom produto de software é suportado por seus desenvolvedores e é atualizado frequentemente, o WordPress não foge à regra é atualizado com muita frequência. Essas atualizações destinam-se a corrigir erros e às vezes possuem patches de segurança muito importantes.
Não atualizar seus temas e plugins pode significar sérios problemas. Muitos hackers contam com o fato das pessoas não se preocuparem em atualizar seus plugins e temas. Na maioria das vezes, esses hackers exploram erros e falhas de segurança que já foram corrigidas nas versões atuais.
Então, se você estiver usando os produtos do WordPress, atualize-os regularmente plugins, temas, tudo.
21. Remova o número da versão do WordPress
Seu número de versão atual do WordPress pode ser encontrado com muita facilidade.
Isso é algo básico, se os hackers sabem qual versão do WordPress você usa, é mais fácil para elas criarem o ataque perfeito.
Quase todos os plugins de segurança que mencionamos acima podem ajudar você, ocultando o número de versão do seu WordPress.
Uma opção também é utilizar a ferramenta de rate limit para WordPress da GoCache. Caso queira conhecer mais sobre o recurso, acesse a página – Rate Limit para WordPress
https://gocache.com.br/wp-content/uploads/2017/10/seguranca_wordpress.jpg348571Go Cachehttps://gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.pngGo Cache2017-10-20 14:19:172020-10-21 19:22:2921 Dicas de Segurança pra Proteger seu site WordPress
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
WAF, SmartRules e Firewall – 3 camadas de proteção para o seu site
Na GoCache um é pouco, dois é bom e três é demais!
Além dos benefícios que o Firewall e o WAF proporcionam, você ainda conta com o auxilio das nossas exclusivas e extraordinárias SmartRules, as regras que permitem customização inigualável.
Defina áreas específicas de sua aplicação e em questão de segundos as SmartRules serão aplicadas. Nosso painel dá acesso em tempo real aos eventos de segurança de qualquer camada. É um conjunto de tecnologias que proporciona flexibilidade e robustez inéditos no mercado!
As camadas (por ordem de processamento/prioridade):
Conhecendo um pouco mais sobre cada uma das camadas:
# 1 camada: SmartRules
Com as SmartRules, é possível criar regras customizadas para determinadas áreas da sua aplicação, essa é a camada com a maior prioridade. As regras criadas nessa camada se sobrepõe às das outras camadas. Ative e desative as regras de Firewall, crie novas regras, ou altere todas as políticas de segurança do WAF para determinadas áreas de sua aplicação através das SmartRules.
# 2 Camada: Firewall
Crie um conjunto de regras para bloquear acessos indesejados, ou permitir acessos bem-vindos em toda a sua aplicação utilizando os seguintes critérios:
– Endereço IP/Range
– Pais
– Continente
– User Agent
– Referer Host
– URI
# 3 Camada: WAF
O WAF – Web Application Firewall – é uma funcionalidade que ajuda a proteger toda a sua aplicação das vulnerabilidades mais comuns na Internet: padrões comuns de ataques, SQL Injections e Cross-site scripting (XSS). Configure o nível de segurança e o modo de bloqueio desejado e pronto, toda a sua aplicação estará protegida.
– Níveis: Alto, Médio e Baixo
– Modos:
Simular: Entenda melhor o seu tráfego sem que os bloqueios sejam aplicados, qualquer acesso considerado “suspeito” será exibido no log de eventos em tempo real.
Bloquear: Bloqueia efetivamente qualquer atividade incomum em toda a aplicação.
Desafiar: Aplica um desafio(reCAPTCHA do Google) assim que identifica algo incomum no seu tráfego. Você define o tempo válido para esse desafio e, caso queira expirar os desafios temporários, pode fazê-lo imediatamente com um simples clique em seu painel de controle.
Segurança para sua aplicação web como você nunca viu antes!
Go Faster. GoCache!
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-03-13 21:11:522017-03-16 10:42:55As 3 camadas de segurança na GoCache CDN
O Carnaval está chegando, mas a GoCache não pára! Anunciamos o lançamento das SmartRules para WAF! Esta nova funcionalidade permite tornar seu WAF flexível, para que você configure o acesso às áreas sensíveis do seu site como preferir.
As possibilidades são infinitas, você especifica o critério(ou critérios) para o qual uma regra será aplicada:
As opções de critério são:
URL
Método HTTP
Cookies
User Agent
HTTP Referer
Endereço ou Range de IP
País de Origem
Continente de Origem
Em seguida seleciona qual o tipo de ação a ser tomada quando o critério for satisfeito:
As ações possíveis são:
Whitelist – libera o acesso para os acessos que correspondem ao critério.
Blacklist – bloqueia o acesso para os acessos que correspondem ao critério.
Challenge – exibe um captcha para que o usuário prove ser humano.
As regras podem ser facilmente Ativadas/Desativadas, ou Editadas, através de um simples botão:
Com a adição das SmartRules o WAF da GoCache se torna a mais flexível solução deste tipo disponível no mercado nacional, resultado do nosso compromisso em entregar o melhor produto que a tecnologia atual permite construir.
Mãos à obra, pode criar suas regras e se tiver alguma dúvida nossa equipe de atendimento está pronta para te ajudar.
Quer testar nosso WAF sem compromisso durante 7 dias?Cadastre-se aqui, não é necessário cartão de crédito!
Go faster. GoCache!
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-02-24 15:23:542017-07-24 03:28:42SmartRules para WAF – Controle total da segurança nas suas mãos
Se você se já pesquisou seriamente sobre segurança, deve estar familiarizado com o termo “Intrusion Prevention System”, ou IPS. Porém ultimamente tem ganhado destaque e atenção outro tipo de proteção, o “Web Application Firewall”, ou WAF. Mas qual a diferença entre os dois? Neste artigo faremos uma breve análise de ambos, suas limitações e a forma como se complementam.
O Sistema de Prevenção a Intrusão (IPS)
O IPS observa o fluxo de pacotes através da rede. Age de forma semelhante a um Sistema de Detecção de Intrusão (IDS), tentando identificar dados suspeitos nos pacotes de rede com base em um banco de dados de assinaturas, ou detectar anomalias em comparação ao que é pré-definido como tráfego “normal”. Além de sua funcionalidade IDS, um IPS pode fazer mais do que apenas gerar logs e alertas. É possível programa-lo para reagir ao que detecta. A capacidade de reagir às detecções é o que torna o IPS mais desejáveldo que o IDS.
Há algumas desvantagens para um IPS. Ele é projetado para bloquear certos tipos de tráfego, identificados como potencialmente perigosos. O IPS não tem a capacidade de compreender a lógica do protocolo da aplicação web. Assim, o IPS não distingue completamente se uma solicitação é normal ou malformada na camada de aplicação (camada OSI 7). Esta limitação poderia potencialmente permitir a passagem de alguns tipos de ataques sem que sejam detectados ou prevenidos, especialmente novos tipos de ataques mais sofisticados e sem assinaturas.
Havendo um grande número de aplicações web, tanto comerciais quanto caseiras, a tendência é que existam os mais diversos tipos de vulnerabilidades a serem exploradas por hackers. O IPS não consegue efetivamente cobrir todas essas vulnerabilidades potenciais e, provavelmente, acabará produzindo muitos falsos positivos. Falso positivos são péssimos pois fazem com que os analistas de segurança, normalmente já ocupados, fiquem ainda mais ocupados. Uma sobrecarga de falsos positivos pode atrasar a resposta a ataques reais, ou fazer com que sejam aceitos porque um analista tentou reduzir o “ruído”.
O IPS de Host (HIPS) é um pouco mais granular do que o IPS de rede (NIPS). O HIPS monitora a camada de aplicação (OSI Layer 7) um pouco mais próximo da lógica fornecida à aplicação web. Mas o HIPS ainda carece de alguma compreensão das linguagens de aplicações web e sua lógica. Em resposta a essas deficiências, surgiu o Firewall de Aplicação Web – WAF.
O WAF é projetado para proteger aplicações web/servidores de ataques baseados na web que um IPS não pode impedir. Assim como um IPS, o WAF pode ser baseado em rede ou host. Ele monitora o tráfego de e para os aplicativos/servidores web. Basicamente, a diferença está no nível de capacidade de análise da lógica de aplicação web na camada 7.
Enquanto o IPS avalia o tráfego comparando assinaturas e comportamentos anômalos, o Web Application Firewall avalia o comportamento e a lógica do que é solicitado e devolvido. O WAF protege contra ameaças de aplicações web tais como injeção de SQL, cross-site scripting, sequestro de sessão, alteração de URL ou de parâmetro e estouro de buffer. Ele faz isso da mesma maneira que um IPS faz, analisando o conteúdo de cada pacote de entrada e de saída.
WAFs normalmente são implantados em um proxy na frente das aplicações web, para que não vejam todo tráfego da rede. Ao monitorar o tráfego antes que ele atinja a aplicação Web, o WAF pode analisar as requisições antes de transmiti-las. Isto é o que lhe dá vantagem sobre o IPS, que é projetado para interrogar todo o tráfego de rede, sem analisar a camada de aplicação com o rigor necessário.
O WAF não apena detecta ataques que são conhecidos por ocorrerem em ambientes de aplicações Web, mas também detecta (e pode prevenir) novos tipos desconhecidos de ataques. Ao observar padrões inusitados ou inesperados no tráfego, ele pode alertar e/ou defender contra ataques até então desconhecidos. Por exemplo, se o WAF detecta um aplicativo retornando mais dados que o esperado, pode bloqueá-lo e alertar alguém.
Conclusão
Os Firewalls de Aplicação Web são um tipo especial de produto, utilizados para detectar ataques contra aplicações web com mais profundidade e critério do que os Sistemas de Prevenção a Intrusão. O WAF pode ser usado no ambiente para fornecer proteção aprimorada a aplicações/servidores Web. Usar um WAF é uma boa maneira de complementar o IPS e fornecer uma camada adicional de proteção para uma arquitetura de defesa em profundidade mais completa.
*Publicado originalmente no portal iMasters: http://imasters.com.br/infra/seguranca/web-application-firewall-x-intrusion-prevention-system-qual-diferenca/
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-02-08 12:10:522020-12-03 13:07:27Qual a diferença entre um WAF e um IPS?
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
PT_BR 
EN 