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.
SSL (Secure Sockets Layer) e seu sucessor, TLS (Transport Layer Security), são protocolos para estabelecer links autenticados e criptografados entre computadores em rede. Embora o protocolo SSL tenha sido descontinuado com o lançamento do TLS 1.0 em 1999, ainda é comum se referir a essas tecnologias relacionadas como “SSL” ou “SSL / TLS”. A versão mais atual é o TLS 1.3, definido no RFC 8446 (agosto de 2018).
Chaves, certificados e Handshakes
SSL / TLS funciona vinculando as identidades de entidades, como sites e empresas, a pares de chaves criptográficas por meio de documentos digitais conhecidos como certificados X.509. Cada par de chaves consiste em uma chave privada e uma chave pública. A chave privada é mantida segura e a chave pública pode ser amplamente distribuída por meio de um certificado.
A relação matemática especial entre as chaves privadas e públicas em um par significa que é possível usar a chave pública para criptografar uma mensagem que só pode ser descriptografada com a chave privada. Além disso, o detentor da chave privada pode usá-la para assinar outros documentos digitais (como páginas da web) e qualquer pessoa com a chave pública pode verificar essa assinatura.
Se o próprio certificado SSL / TLS for assinado por uma autoridade de certificação (CA – certificate authority) publicamente confiável, como SSL.com, o certificado será implicitamente confiável para o software cliente, como navegadores da web e sistemas operacionais. CAs publicamente confiáveis foram aprovadas pelos principais fornecedores de software para validar identidades que serão confiáveis em suas plataformas. Os procedimentos de validação e emissão de certificados de uma CA pública estão sujeitos a auditorias regulares e rigorosas para manter esse status confiável.
Por meio do handshake SSL / TLS, as chaves privadas e públicas podem ser usadas com um certificado de confiança pública para negociar uma sessão de comunicação criptografada e autenticada pela Internet, mesmo entre duas partes que nunca se encontraram. Esse simples fato é a base da navegação segura na web e do comércio eletrônico como é conhecido hoje.
SSL / TLS e navegação segura na Web
O uso mais comum e conhecido de SSL / TLS é a navegação segura na web por meio do protocolo HTTPS. Um site HTTPS público configurado corretamente inclui um certificado SSL / TLS que é assinado por uma CA publicamente confiável. Os usuários que visitam um site HTTPS podem ter a certeza de:
Autenticidade: O servidor que apresenta o certificado possui a chave privada que corresponde à chave pública no certificado.
Integridade: Os documentos assinados pelo certificado (por exemplo, páginas da web) não foram alterados durante o trânsito por um intermediário.
Criptografia: As comunicações entre o cliente e o servidor são criptografadas.
Por causa dessas propriedades, SSL / TLS e HTTPS permitem que os usuários transmitam com segurança informações confidenciais, como números de cartão de crédito, números de previdência social e credenciais de login pela Internet, e garantam que o site para o qual eles estão enviando é autêntico. Com um site HTTP inseguro, esses dados são enviados como texto simples, prontamente disponível para qualquer bisbilhoteiro com acesso ao fluxo de dados. Além disso, os usuários desses sites desprotegidos não têm garantia confiável de terceiros de que o site que estão visitando é o que ele afirma ser.
Procure os seguintes indicadores na barra de endereço do seu navegador para ter certeza de que um site que você está visitando está protegido com um certificado SSL / TLS confiável:
Um ícone de cadeado fechado à esquerda do URL. Dependendo do seu navegador e do tipo de certificado instalado no site, o cadeado pode ser verde e / ou acompanhado de informações de identificação da empresa que o administra.
Se mostrado, o protocolo no início do URL deve ser https: //, não http: //. Observe que nem todos os navegadores exibem o protocolo.
Os navegadores de desktop modernos também alertam os visitantes sobre sites inseguros que não possuem um certificado SSL / TLS.
O que é SSL?
SSL (Secure Sockets Layer) e seu sucessor, TLS (Transport Layer Security), são protocolos para estabelecer links autenticados e criptografados entre computadores em rede. Embora o protocolo SSL tenha sido descontinuado com o lançamento do TLS 1.0 em 1999, ainda é comum se referir a essas tecnologias relacionadas como “SSL” ou “SSL / TLS”.
O que é um certificado SSL?
Um certificado SSL (também conhecido como certificado TLS ou SSL / TLS) é um documento digital que vincula a identidade de um site a um par de chaves criptográficas que consiste em uma chave pública e uma chave privada. A chave pública, incluída no certificado, permite que um navegador da web inicie uma sessão de comunicação criptografada com um servidor da web por meio dos protocolos TLS e HTTPS. A chave privada é mantida em segurança no servidor e é usada para assinar digitalmente páginas da web e outros documentos (como imagens e arquivos JavaScript).
Um certificado SSL também inclui informações de identificação sobre um site, incluindo seu nome de domínio e, opcionalmente, informações de identificação sobre o proprietário do site. Se o certificado SSL do servidor da web for assinado por uma autoridade de certificação (CA) publicamente confiável, como SSL.com, o conteúdo assinado digitalmente do servidor será considerado autêntico pelos navegadores da web e sistemas operacionais dos usuários finais.
O que é TLS?
TLS (Transport Layer Security), lançado em 1999, é o sucessor do protocolo SSL (Secure Sockets Layer) para autenticação e criptografia. O TLS 1.3 é definido na RFC 8446 (agosto de 2018).
Preciso de um endereço IP dedicado para usar SSL / TLS?
Antes, era um requisito obrigatório ter um IP dedicado para cada certificado SSL em um servidor web. Este não é mais o caso devido a uma tecnologia chamada Server Name Indication (SNI). Especificamente, sua plataforma de hospedagem terá que oferecer suporte a SNI.
Qual porta é recomendada para usar SSL / TLS?
Para compatibilidade máxima, a porta 443 é a porta padrão, portanto recomendada, usada para comunicações SSL / TLS seguras. No entanto, qualquer porta pode ser usada.
Qual é a versão atual do SSL / TLS?
TLS 1.3, definido em agosto de 2018 pela RFC 8446, é a versão mais recente de SSL / TLS. O TLS 1.2 (RFC 5246) foi definido em agosto de 2018 e também continua em amplo uso. As versões do SSL / TLS anteriores ao TLS 1.2 são consideradas inseguras e não devem mais ser usadas.
Quais são os problemas de segurança com as versões mais antigas do TLS?
As versões 1.0 e 1.1 do TLS são afetadas por um grande número de vulnerabilidades de protocolo e implementação que foram publicadas por pesquisadores de segurança nas últimas duas décadas. Ataques como ROBOT afetaram o algoritmo de troca de chave RSA, enquanto LogJam e WeakDH mostraram que muitos servidores TLS podem ser enganados em usar parâmetros incorretos para outros métodos de troca de chave. O comprometimento de uma troca de chaves permite que os invasores comprometam completamente a segurança da rede e descriptografem as conversas.
Ataques a cifras simétricas, como BEAST ou Lucky13, demonstraram que várias cifras suportadas em TLS 1.2 e anteriores, com exemplos incluindo cifras RC4 ou modo CBC, não são seguras.
Até as assinaturas foram afetadas, com o ataque de falsificação de assinatura RSA de Bleichenbacher e outros ataques de preenchimento semelhantes.
A maioria desses ataques foi mitigada no TLS 1.2 (desde que as instâncias do TLS estejam configuradas corretamente), embora o TLS 1.2 ainda seja vulnerável a ataques de downgrade, como POODLE, FREAK ou CurveSwap. Isso se deve ao fato de que todas as versões do protocolo TLS anteriores a 1.3 não protegem a negociação de handshake (que decide a versão do protocolo que será usada durante a troca).
https://www.gocache.com.br/wp-content/uploads/2021/06/o-que-e-ssl.png6281200Go Cachehttps://www.gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.pngGo Cache2021-07-01 06:00:502021-06-30 10:29:02O que é SSL e como ele protege um site
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.
https://www.gocache.com.br/wp-content/uploads/2021/05/RBAC-GoCache.png276643Go Cachehttps://www.gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.pngGo Cache2021-05-11 12:34:552021-05-11 12:39:49RBAC: o começo de uma nova era para a GoCache
Um ano com foco na pandemia tornou os eventos de 2020 sem precedentes de várias maneiras, e os ataques cibernéticos não foram diferentes.
À medida que o mundo fazia a transição para o virtual – trabalho, escola, reuniões e encontros familiares – os invasores perceberam. Os invasores adotaram novas técnicas e uma mudança apressada para o acesso remoto aumentou as ameaças cibernéticas em toda as linhas. Por exemplo, escolas de ensino fundamental e médio sofreram o maior impacto, e novos pontos baixos foram alcançados, como a extração de dados de alunos. A lista dos principais ataques cibernéticos de 2020 inclui ransomware, phishing, vazamento de dados, violações e um ataque devastador à cadeia de suprimentos com um escopo como nenhum outro.
O ano dominado virtualmente levantou novas preocupações em torno das posturas e práticas de segurança, que continuarão em 2021.
Embora houvesse muitos incidentes para escolher, aqui está uma lista dos 10 maiores ataques cibernéticos de 2020, em ordem cronológica.
Toll Group
O Toll Group está no topo da lista dos piores ataques cibernéticos do ano, porque foi atingido por um ransomware duas vezes em três meses. No entanto, um porta-voz do Toll Group disse ao SearchSecurity que os dois incidentes não estavam conectados e eram “baseados em diferentes formas de ransomware”. Em 3 de fevereiro, a empresa de logística com sede na Austrália anunciou no Twitter que havia sofrido um ataque cibernético. “Como medida de precaução, o Toll tomou a decisão de desligar vários sistemas em resposta a um incidente de segurança cibernética. Vários aplicativos do Toll voltados para o cliente foram afetados como resultado. Nossa prioridade imediata é retomar os serviços aos clientes assim que possível”, escreveu o Toll Group no Twitter. O ataque mais recente ocorreu em maio e envolveu uma variante de ransomware relativamente nova: o Nefilim.
Marriott International
Pela segunda vez em dois anos, a popular rede de hotéis sofreu uma violação de dados. Em 31 de março, a Marriott divulgou um comunicado divulgando que as informações de 5,2 milhões de hóspedes foram acessadas usando as credenciais de login de dois funcionários em uma propriedade franqueada. De acordo com o aviso, a violação afetou um aplicativo usado pela Marriott para fornecer serviços aos hóspedes. “Acreditamos que essa atividade tenha começado em meados de janeiro de 2020”, disse o comunicado. “Após a descoberta, confirmamos que as credenciais de login foram desativadas, iniciamos imediatamente uma investigação, implementamos monitoramento intensificado e organizamos recursos para informar e auxiliar os hóspedes.” Enquanto a investigação estiver em andamento, a Marriott disse não ter nenhuma razão para acreditar que as informações incluíram as senhas ou PINs da conta Marriott Bonvoy, informações de cartão de pagamento, informações de passaporte, IDs nacionais ou números de carteira de motorista. No entanto, as informações comprometidas podem ter envolvido detalhes de contato e informações relacionadas às contas de fidelidade do cliente, mas não as senhas.
Magellan
Em 12 de maio, o gigante dos seguros de saúde emitiu uma carta às vítimas afirmando que havia sofrido um ataque de ransomware. Os atores da ameaça exfiltraram logins, informações pessoais e informações fiscais com sucesso. O escopo do ataque incluiu oito entidades do Magellan Health e aproximadamente 365.000 pacientes podem ter sido afetados. “Em 11 de abril de 2020, Magellan descobriu que era alvo de um ataque de ransomware. O ator não autorizado obteve acesso aos sistemas da Magellan depois de enviar um e-mail de phishing em 6 de abril que se fazia passar por um cliente Magellan”, disse a carta. A empresa, que tem mais de 10.000 funcionários, disse no momento da carta que não tinha conhecimento de qualquer fraude ou uso indevido de qualquer uma das informações pessoais. Phishing, um vetor de ataque comum, intensificou-se ao longo do ano à medida que os agentes de ameaças refinavam as suas habilidades de representação.
Twitter
A popular empresa de mídia social foi violada em julho por três indivíduos em um incidente embaraçoso que viu várias contas importantes do Twitter serem sequestradas. Por meio de um ataque de engenharia social, posteriormente confirmado pelo Twitter como phishing de telefone, os invasores roubaram as credenciais dos funcionários e obtiveram acesso aos sistemas de gerenciamento interno da empresa. Dezenas de contas de alto perfil, incluindo as do ex-presidente Barack Obama, CEO da Amazon, Jeff Bezos, e Tesla e CEO da SpaceX, Elon Musk, foram hackeadas. Os atores da ameaça então usaram as contas para twittar fraudes de bitcoin que lhes renderam mais de $100.000. Duas semanas após a violação, o Departamento de Justiça (DoJ) indiciou os três suspeitos e indiciou Graham Ivan Clark, de 17 anos, como adulto, pelo ataque que ele supostamente “planejou”, segundo as autoridades.
Garmin
O fornecedor de tecnologia de navegação sofreu um ataque cibernético que criptografou alguns dos seus sistemas e forçou os serviços a ficarem offline. Embora a Garmin tenha relatado pela primeira vez como uma interrupção, a empresa revelou em 27 de julho que foi vítima de um ataque cibernético que resultou na interrupção de “funções do site, suporte ao cliente, aplicativos voltados para o cliente e comunicações da empresa”. O comunicado de imprensa também afirmou que não havia nenhuma indicação de que os dados do cliente foram acessados, perdidos ou roubados. Aumentaram as especulações de que o incidente foi um ataque de ransomware, embora a Garmin nunca tenha confirmado. Além disso, vários meios de comunicação relataram que cederam às exigências dos agressores e que um resgate foi pago. Alguns meios de comunicação informaram que chega a $10 milhões.
Distrito Escolar De Clark County
O ataque ao distrito escolar de Clark County (CCSD) em Nevada revelou um novo risco de segurança: a exposição de dados de alunos. O CCSD revelou que foi atingido por um ataque de ransomware em 27 de agosto, que pode ter resultado no roubo de dados de alunos. Depois que o distrito se recusou a pagar o resgate, uma atualização foi postada dizendo que estava ciente de reportagens da mídia alegando que os dados dos alunos haviam sido expostos na internet como retribuição. Embora não esteja claro quais são as informações, a ameaça de expor dados roubados de alunos foi um novo ponto baixo para os agentes de ameaças e representou uma mudança para o roubo de identidade em ataques a escolas.
Software AG
A gigante alemã de software foi vítima de um duplo ataque de extorsão que começou em 3 de outubro, que resultou no desligamento forçado dos sistemas internos e, por fim, em um grande vazamento de dados. Os arquivos foram criptografados e roubados pelos operadores por trás do ransomware Clop. De acordo com várias agências de notícias, um resgate de $20 milhões foi exigido, e a Software AG se recusou a pagar. Como resultado, a gangue de ransomware cumpriu a sua promessa e publicou dados confidenciais em um site de vazamento de dados, incluindo detalhes do passaporte dos funcionários, e-mails internos e informações financeiras. Os operadores por trás do ransomware Clop não foram o único grupo a utilizar um duplo ataque de extorsão. A tática do nome e da vergonha se tornou cada vez mais comum ao longo de 2020 e agora é a prática padrão para várias gangues de ransomware.
Centro de Psicoterapia Vastaamo
O maior provedor privado de psicoterapia da Finlândia confirmou que foi vítima de uma violação de dados em 21 de outubro, quando os atores da ameaça roubaram registros confidenciais de pacientes. O ataque abriu um novo precedente; em vez de fazer exigências à organização, os pacientes eram chantageados diretamente. No mês passado, 25.000 relatórios criminais foram enviados à polícia da Finlândia. Além disso, a resposta geral do governo ao incidente foi significativa, tanto em urgência quanto em sensibilidade. O ministro do interior da Finlândia convocou uma reunião de emergência com os principais membros do gabinete e forneceu serviços de aconselhamento de emergência para vítimas potenciais do esquema de extorsão.
Vítimas de ataque à cadeia de suprimentos da FireEye e SolarWinds
A FireEye deu início a uma cadeia de eventos em 8 de dezembro, quando revelou que suspeitos de hackers do estado-nação haviam violado o fornecedor de segurança e obtido as ferramentas da equipe vermelha da FireEye. Em 13 de dezembro, a empresa divulgou que o ataque do Estado-nação foi o resultado de um ataque massivo à cadeia de suprimentos da SolarWinds. A FireEye apelidou a campanha de backdoor de “UNC2452” e disse que ela permitiu que os agentes da ameaça obtivessem acesso a várias redes governamentais e empresariais em todo o mundo. De acordo com uma declaração conjunta em 17 de dezembro do Federal Bureau of Investigation, da Cybersecurity and Infrastructure Security Agency e do Gabinete do Diretor de Inteligência Nacional, os ataques estão em andamento. Além disso, o comunicado revelou que o ataque à cadeia de suprimentos afetou mais do que apenas a plataforma Orion. A CISA disse ter “evidências de que o comprometimento da cadeia de suprimentos da Orion não é o único vetor de infecção inicial alavancado pelo ator APT”. Desde a declaração, grandes empresas de tecnologia como Intel, Nvidia e Cisco divulgaram que receberam as atualizações maliciosas do SolarWinds, embora as empresas tenham afirmado não ter encontrado evidências de que os agentes da ameaça exploraram backdoors e violaram suas redes.
No entanto, a Microsoft revelou em 31 de dezembro que os agentes da ameaça se infiltraram na sua rede e viram – mas não alteraram ou obtiveram – o código-fonte da empresa. A Microsoft também disse que não há evidências de que a violação afetou os dados dos clientes ou os produtos e serviços da empresa.
SolarWinds
O escopo do ataque, a sofisticação dos atores da ameaça e das vítimas afetadas fazem deste não apenas o maior ataque de 2020, mas possivelmente da década. O incidente também destaca os perigos de ataques à cadeia de suprimentos e questiona a postura de segurança de uma empresa tão grande. Os atores da ameaça, que realizavam o reconhecimento desde março, plantaram uma backdoor na plataforma Orion da SolarWinds, que foi ativada quando os clientes atualizaram o software. A SolarWinds emitiu um comunicado de segurança sobre a backdoor que, segundo o fornecedor, afetou as versões 2019.4 HF5 até 2020.2.1 da plataforma Orion, lançadas entre março de 2020 e junho de 2020. “Fomos informados de que este ataque foi provavelmente conduzido por um estado-nação externo e pretendia ser um ataque estreito, extremamente direcionado e executado manualmente, em oposição a um ataque amplo em todo o sistema”, disse a empresa. Na investigação de três semanas desde então, toda a extensão do ataque cresceu imensamente, mas ainda não foi totalmente compreendida.
https://www.gocache.com.br/wp-content/uploads/2021/05/MAIORES-ATAQUES-WEB-2020.jpg6281200Go Cachehttps://www.gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.pngGo Cache2021-05-06 06:00:092021-04-16 17:56:5910 maiores ataques web de 2020
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.
new RDStationForms(‘newsletter-artigos-blog-842f5cbb60b7ed599409’, ‘UA-47041721-1’).createForm();
https://www.gocache.com.br/wp-content/uploads/2021/03/WAF-OQUE-E-SEUS-BENEFICIOS.png6281200Go Cachehttps://www.gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.pngGo Cache2021-04-06 06:00:412022-01-17 18:35:40WAF: O que é, e quais seus benefícios
Os firewalls do WordPress são considerados firewalls de aplicativos da web (web application firewalls – WAFs) projetados especificamente para proteger sites do WordPress.
WAFs são relativamente novos no setor de segurança da web. Portanto, compartilhamos este guia para explicar o que são firewalls e como eles evoluíram para WAFs. Ele também destaca os diferentes tipos de firewalls WordPress disponíveis no mercado e como eles funcionam.
O conceito de firewalls
Um firewall é um software ou serviço de segurança instalado entre duas ou mais redes para controlar o tráfego de entrada e saída de cada rede. Ele atua como uma barreira entre uma rede confiável e não confiável.
Em uma configuração típica, um firewall é instalado entre uma conexão de Internet e uma rede interna. Ele é usado para proteger a rede contra ataques vindos da Internet. Também é usado para controlar quem pode acessar a Internet. Se você estiver usando um roteador WiFi na sua casa, o roteador será o firewall da sua casa. Por exemplo, hoje em dia, quase todos os roteadores Wi-Fi domésticos têm um firewall embutido.
Firewalls de Primeira Geração – Filtragem de Pacotes
Originalmente, os firewalls foram projetados para controlar e bloquear o tráfego da rede. Eles só faziam filtragem de pacotes e não entendiam a carga de tráfego. Portanto, se você hospedasse um site na sua rede, você precisava abrir a porta 80 para o público por meio do firewall.
Depois de abrir uma porta, o firewall permitiria qualquer tipo de tráfego de entrada através dela, incluindo tráfego malicioso.
Firewalls de Segunda Geração – Filtragem De Estado
A segunda geração de firewalls operava na camada 4 do modelo OSI. Isso significa que eles podiam determinar o tipo de conexão que estavam lidando. Por exemplo, se um pacote estava abrindo uma nova conexão ou se uma conexão já tinha sido estabelecida, etc.
Ainda assim, os firewalls de segunda geração apresentavam muitas limitações no controle do tráfego. Porém, os administradores pelo menos podiam criar regras de firewall com base nos status de conexão.
Firewalls de Terceira Geração – Filtragem De Camada De Aplicativo
Os firewalls de hoje foram introduzidos em meados dos anos noventa. A tecnologia de firewall moderna entende aplicativos e protocolos. Assim, os firewalls de terceira geração podem entender se a carga útil de um pacote é para um servidor FTP e qual é a solicitação, ou se é uma solicitação de conexão HTTP e qual é a solicitação.
Essa tecnologia levou ao desenvolvimento de firewalls de escopo único, como o Web Application Firewalls (Firewalls de Aplicativos da Web).
Firewalls de Aplicativos da Web / Firewalls do WordPress
Os firewalls de aplicativos da Web são firewalls de escopo único. Sua função em uma rede é proteger um site contra ataques de hackers maliciosos.
Um firewall do WordPress é um firewall de aplicativo da web projetado especificamente para proteger o WordPress. Quando um firewall WordPress é instalado no seu site WordPress, ele é executado entre o seu site e a Internet, para analisar todas as solicitações HTTP recebidas.
Quando uma solicitação HTTP contém uma carga maliciosa, o firewall do WordPress interrompe a conexão.
Como Funcionam os Firewalls do WordPress?
A maneira como um firewall do WordPress detecta solicitações maliciosas é semelhante à forma como o software de malware detecta infecções por malware. Eles usam uma lista de ataques conhecidos chamados assinaturas e, quando a carga de uma solicitação HTTP corresponde a uma assinatura, isso significa que a solicitação é mal-intencionada.
A maioria dos firewalls do WordPress não permite que você modifique as assinaturas de ataque. Mas os firewalls de aplicativos da web não centrados no WordPress são altamente configuráveis. Você pode personalizá-los especificamente para o seu site, seja WordPress ou uma solução personalizada. Você pode criar o seu próprio conjunto de regras de segurança, exceções, etc. No entanto, deve-se ter muito cuidado ao configurar um firewall de aplicativo da web para não bloquear o tráfego legítimo.
Alguns firewalls de aplicativos da web também possuem tecnologia de aprendizagem automática. Essa tecnologia heurística analisa o tráfego do seu site para saber o que é tráfego legítimo e o que não é.
Plug-ins de Firewalls do WordPress
A maioria dos firewalls auto hospedados do WordPress são plug-ins do WordPress. Quando você instala um firewall de plug-in, cada solicitação HTTP enviada ao seu site é processada da seguinte maneira:
Primeiro, o serviço do servidor web (Apache ou Nginx) o recebe.
Em seguida, ele aciona o bootstrap / load do WordPress que inicializa o WordPress (wp-config.php, inicializa a conexão do banco de dados, as configurações do WordPress etc). Antes que a solicitação seja realmente processada pelo WordPress, ela é analisada pelo plug-in de firewall do WordPress.
Os plug-ins de firewall do WordPress são ideais para pequenas e médias empresas, porque são muito acessíveis e fáceis de usar. Além disso, a maioria deles tem scanners de malware incorporados. No entanto, esses firewalls estão sendo executados no seu site e inicializados pelo WordPress. Portanto, se houver uma vulnerabilidade no seu site antes que o firewall seja inicializado, é provável que os invasores possam obter acesso total ao seu site WordPress.
Firewalls de aplicativos da Web WordPress dedicados no local
Firewalls de aplicativos da web genéricos também podem ser usados como firewalls do WordPress. Eles podem ser um dispositivo de hardware dedicado ou um software.
Firewalls genéricos de aplicativos da web são instalados entre o seu site WordPress e a conexão com a Internet. Portanto, cada solicitação HTTP enviada ao seu site WordPress passa primeiro pelo WAF. Esses WAFs são certamente soluções mais seguras do que os plug-ins de firewall do WordPress. No entanto, eles são caros e são necessários conhecimentos técnicos específicos para gerenciá-los. Portanto, eles não são normalmente usados por pequenas empresas.
Firewalls de sites WordPress online
Ao contrário de um aplicativo ou plug-in de firewall WordPress auto hospedado, um firewall WordPress online não precisa ser instalado na mesma rede do seu servidor web. É um serviço online que atua como um servidor proxy – o tráfego do seu site passa por ele para filtragem e, em seguida, é encaminhado para o seu site.
Ao usar um firewall WordPress online, você configura os registros DNS do seu domínio para apontar para o WAF online. Isso significa que os visitantes do seu site se comunicam realmente com o firewall WordPress online e não diretamente com o seu site WordPress.
Normalmente, um firewall online tem mais de um escopo. Além de proteger o seu site WordPress de ataques de hack, ele também pode servir como servidor de cache e CDN. Os firewalls de aplicativos da web online também são muito acessíveis quando comparados aos firewalls de aplicativos da web genéricos auto hospedados.
Firewalls Online Podem Ser Contornados
Uma limitação conhecida dos firewalls WordPress online é que o seu servidor da web deve estar acessível pela Internet para que o WAF encaminhe o tráfego para o seu site WordPress. Isso significa que todos ainda podem se comunicar diretamente com o seu servidor web se souberem o seu endereço IP.
Portanto, em ataques WordPress não direcionados, durante os quais os invasores simplesmente examinam redes inteiras em busca de sites vulneráveis, o seu servidor web e site ainda podem ser acessados diretamente. No entanto, você sempre pode configurar o firewall do seu servidor para responder apenas ao tráfego proveniente do firewall online do WordPress para não ser vítima desse tipo de ataque.
Proteção limitada contra vulnerabilidade de zero dia
Uma das técnicas de proteção WAF mais comuns é verificar a carga útil de uma solicitação HTTP em um banco de dados de assinaturas. Portanto, quando alguém visita o seu site, o WAF verifica a carga útil em um banco de dados de ataques da Web conhecidos. Se corresponder, significa que é malicioso; se não, ele o deixa passar.
Portanto, no caso de uma vulnerabilidade de dia zero do WordPress, há chances de que o firewall do WordPress não bloqueie o ataque. É por isso que a capacidade de resposta do fornecedor é crucial e você deve sempre usar software de empresas responsivas e confiáveis. Quanto mais cedo o fornecedor puder atualizar as regras de firewall, melhor será.
Bypasses De Firewall De Aplicativo Da Web
Os firewalls de aplicativos da Web são como qualquer outro software. Eles têm os seus próprios problemas e podem ter vulnerabilidades. Na verdade, você pode encontrar um grande número de white papers e artigos falando sobre técnicas usadas para contornar a proteção de firewalls de aplicativos da web. Mas, novamente, contanto que o fornecedor seja responsivo e remedeie esses problemas em tempo hábil, tudo bem.
Você Deve Usar Um Firewall Do WordPress?
Com certeza! Qual firewall WordPress você deve usar? Cada firewall do WordPress tem os seus prós e contras, então escolha aquele que melhor se adapta às suas necessidades. No entanto, mesmo quando você tem um firewall do WordPress, não deixe a sua guarda abaixar.
Quer usar uma alternativa simples de WAF e Firewall em WordPress?
A GoCache oferece para todos seus clientes recursos de WAF e Firewall na borda para WordPress, facilmente integrados através de nosso backend e com integração nativa via plugin para WordPress. Conheça mais sobre nossa integração com WordPress através da página abaixo:
new RDStationForms(‘newsletter-artigos-blog-842f5cbb60b7ed599409’, ‘UA-47041721-1’).createForm();
https://www.gocache.com.br/wp-content/uploads/2021/03/wordpress-firewall-e-waf.png6281200Go Cachehttps://www.gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.pngGo Cache2021-03-15 18:09:262022-01-17 18:35:42WordPress: WAF e Firewall – Como funciona e quais as vantagens
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:
Enquanto os proxies geralmente protegem somente os clientes, o WAF protege os servidores. Um WAF é implementado para proteger um aplicativo da Web específico ou conjunto de aplicativos da Web, podendo ser considerado um proxy reverso.
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 :)
https://www.gocache.com.br/wp-content/uploads/2021/01/dutra-maquinas-wp.png250650Go Cachehttps://www.gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.pngGo Cache2021-02-22 06:00:372021-02-22 09:53:40Dutra Máquinas & GoCache – Segurança e escala na Black Friday
O Open Web Application Security Project (OWASP) é uma fundação sem fins lucrativos dedicada a melhorar a segurança do software. O OWASP opera sob um modelo de ‘comunidade aberta’, onde qualquer pessoa pode participar e contribuir com projetos, eventos, chats online e muito mais. Um princípio guia da OWASP é que todos os materiais e informações são gratuitos e de fácil acesso no site, para todos. OWASP oferece de tudo, desde ferramentas, vídeos, fóruns, projetos, até eventos. Resumindo, o OWASP é um repositório de todas as coisas relacionadas à segurança de aplicativos da web, apoiado pelo amplo conhecimento e experiência de seus colaboradores da comunidade aberta.
O que é TOP 10 OWASP?
O OWASP Top 10 é um documento online no site do OWASP que fornece classificação e orientação de remediação para os 10 principais riscos de segurança de rede de aplicativos. O relatório é baseado em um consenso entre especialistas em segurança de todo o mundo. Os riscos são classificados com base na frequência dos defeitos de segurança descobertos, na gravidade das vulnerabilidades e na magnitude de seus impactos potenciais. O objetivo do relatório é oferecer aos desenvolvedores e profissionais de segurança de aplicativos da web uma visão dos riscos de segurança mais prevalentes, para que possam incorporar as descobertas e recomendações do relatório em suas práticas de segurança, minimizando assim a presença desses riscos conhecidos em seus aplicativos.
Como funciona o OWASP Top 10 e por que é importante?
OWASP mantém a lista dos 10 melhores e tem feito isso desde 2003. A cada 2-3 anos a lista é atualizada de acordo com os avanços e mudanças no mercado de AppSec. A importância do OWASP está na informação acionável que fornece; ele serve como uma lista de verificação chave e padrão interno de desenvolvimento de aplicativos da Web para muitas das maiores organizações do mundo.
Os auditores muitas vezes veem a falha de uma organização em abordar o OWASP Top 10 como uma indicação de que ela pode estar falhando em relação aos padrões de conformidade. Integrar o Top 10 em seu ciclo de vida de desenvolvimento de software (SDLC) demonstra um compromisso geral com as melhores práticas da indústria para o desenvolvimento seguro.
A versão mais recente foi lançada em 2017 e incluiu mudanças significativas em relação à versão de 2013, conforme mostrado na figura abaixo. Os problemas de injeção continuam sendo um dos problemas de segurança mais vulneráveis no aplicativo, e a exposição de dados confidenciais aumentou em importância. Alguns novos problemas foram adicionados, como desserialização insegura, e alguns outros problemas foram mesclados.
Quais são as principais vulnerabilidades do TOP 10 OWASP?
1 – Injeção: A injeção de código ocorre quando dados inválidos são enviados por um invasor para um aplicativo da web. A intenção do invasor ao fazer isso é fazer com que o aplicativo faça algo para o qual não foi projetado.
Exemplo: A injeção de SQL é uma das falhas de injeção mais comuns encontradas em aplicativos. As falhas de injeção de SQL podem ser causadas pelo uso de dados não confiáveis por um aplicativo ao construir um SQL vulnerável.
Solução: Revisão da fonte de código é a melhor maneira de prevenir ataques de injeção. Incluir as ferramentas SASTe DAST no seu pipeline de CI/CD ajuda a identificar falhas de injeção que acabaram de ser introduzidas. Isso permite que você as identifique e mitigue antes do emprego de produção.
2 – Autenticação Quebrada: Certos aplicativos são frequentemente implementados de forma inadequada. Especificamente, funções relacionadas à autenticação e gerenciamento de sessão, quando implementadas incorretamente, permitem que os invasores comprometam senhas, palavras-chave e sessões. Isso pode levar ao roubo da identidade do usuário e muito mais.
Exemplo: Um aplicativo da web permite o uso de senhas fracas ou conhecidas (por exemplo, “senha1”).
Solução: A autenticação multifator pode ajudar a reduzir o risco de contas comprometidas. A análise estática automatizada é altamente útil para encontrar essas falhas, enquanto a análise estática manual pode aumentar a força na avaliação de esquemas de autenticação personalizados. A solução Coverity SAST da Synopsys inclui um verificador que identifica especificamente vulnerabilidades de autenticação quebradas.
3 – Exposição de dados confidenciais: A exposição de dados confidenciais ocorre quando dados importantes armazenados ou transmitidos (como números de previdência social) são comprometidos.
Exemplo: As instituições financeiras que não protegem adequadamente os seus dados confidenciais podem ser alvos fáceis para fraude de cartão de crédito e roubo de identidade.
Solução: Ferramentas SAST como Coverity e ferramentas SCA como Black Duck Binary Analysis incluem recursos e verificadores que identificam vulnerabilidades de segurança que podem resultar na exposição de dados confidenciais.
4 – Entidades externas XML (XXE): Os invasores podem tirar vantagem de aplicativos da web que usam XML de processamento de componentes vulneráveis. Os invasores podem fazer upload de XML ou incluir comandos ou conteúdo hostis em um documento XML.
Exemplo: Um aplicativo permite que fontes não confiáveis façam uploads de XML.
Solução: O teste de segurança de aplicativo estático (SAST) é muito útil para detectar XXE no código-fonte. O SAST ajuda a inspecionar a configuração e as dependências do aplicativo.
5 – Controle de acesso quebrado: O controle de acesso quebrado ocorre quando um invasor consegue acessar as contas do usuário. O invasor pode operar como usuário ou administrador do sistema.
Exemplo: Um aplicativo permite que uma chave primária seja alterada. Quando a chave é alterada para o registro de outro usuário, a conta desse usuário pode ser exibida ou modificada.
Solução: É fundamental usar um teste de penetração a fim de detectar controles de acesso não intencionais. Mudanças na arquitetura e design podem ser garantidas para criar limites de confiança para o acesso aos dados.
6 – Configuração incorreta de segurança: Configurações incorretas de segurança ocorrem quando as deficiências de design ou configuração resultam de um erro ou deficiência de configuração.
Exemplo: Uma conta padrão e sua senha original ainda estão ativadas, tornando o sistema vulnerável a explorações.
Solução: Soluções como o Coverity SAST da Synopsys incluem um verificador que identifica a exposição da informação disponível através de uma mensagem de erro.
7 – Cross-Site Scripting (XSS): Os ataques XSS ocorrem quando um aplicativo inclui dados não confiáveis em uma página da web. Os invasores injetam scripts do lado do cliente nesta página da web.
Exemplo: Dados não confiáveis em um aplicativo permitem que um invasor ‘roube uma sessão de usuário’ e obtenha acesso ao sistema.
Solução: As soluções SAST bem versadas em análise de fluxo de dados podem ser uma ótima ferramenta para ajudar a encontrar esses defeitos críticos e sugerir soluções. o site OWASP também fornece uma folha de dicas com as melhores práticas para eliminar tais defeitos do seu código. Para OWASP Top 10 categorias como XSS, que também têm um Enumerador de Fraqueza Comum (CWE), O Black Duck alertará as equipes de que essa é a fraqueza que leva à vulnerabilidade, permitindo que entendam melhor a vulnerabilidade e priorizem seus esforços de correção.
8 – Desserialização insegura: A desserialização insegura é uma vulnerabilidade em que as falhas de desserialização permitem que um invasor execute o código remotamente no sistema.
Exemplo: Um aplicativo é vulnerável porque desserializa objetos hostis que foram fornecidos por um invasor.
Solução: Ferramentas de segurança de aplicativos ajudam a detectar falhas de desserialização e o teste de penetração pode ser usado para validar o problema.
9 – Usando componentes com vulnerabilidades conhecidas: O título desta vulnerabilidade declara a sua natureza; ele descreve quando os aplicativos são construídos e executados usando componentes que contêm vulnerabilidades conhecidas.
Exemplo: Devido ao volume de componentes usados no desenvolvimento, uma equipe de desenvolvimento pode nem mesmo conhecer ou compreender os componentes usados em sua aplicação. Isso pode fazer com que fiquem desatualizados e, portanto, vulneráveis a ataques.
Solução: Ferramentas de análise de composição de software (SCA) como Black Duck podem ser usadas junto com a análise estática para identificar e detectar componentes desatualizados e inseguros no seu aplicativo.
10 – Registro e monitoramento insuficientes: O registro e o monitoramento são atividades que devem ser realizadas em um site com frequência, para garantir a sua segurança. A falha em registrar e monitorar adequadamente um site o deixa vulnerável a atividades comprometedoras mais graves.
Exemplo: Os eventos que podem ser auditados, como logins, logins com falha e outras atividades importantes, não são registrados, levando a um aplicativo vulnerável.
Solução: Depois de executar os Testes de penetração, os desenvolvedores podem estudar os logs de teste para identificar possíveis deficiências e vulnerabilidades. As soluções SAST também podem ajudar a identificar exceções de segurança não registradas.
Fonte: https://owasp.org/
https://www.gocache.com.br/wp-content/uploads/2021/02/o-que-owasp-top-10.png6281200Go Cachehttps://www.gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.pngGo Cache2021-02-18 06:00:182021-02-16 13:36:36O que é OWASP?
A injeção de SQL (ou SQL injection) é uma vulnerabilidade de segurança da web que permite que um invasor interfira nas consultas que um aplicativo faz ao seu banco de dados. Geralmente, permite que um invasor visualize dados que normalmente ele não é capaz de recuperar. Isso pode incluir dados pertencentes a outros usuários ou quaisquer outros dados que o próprio aplicativo é capaz de acessar. Em muitos casos, um invasor pode modificar ou excluir esses dados, causando alterações persistentes no conteúdo ou comportamento do aplicativo.
Em algumas situações, um invasor pode escalar um ataque de injection de SQL para comprometer o servidor subjacente ou outra infraestrutura de back-end, ou realizar um ataque de negação de serviço.
Qual é o impacto de um ataque de SQL Injection bem-sucedido?
Um ataque de SQL injection bem-sucedido pode resultar em acesso não autorizado a dados confidenciais, como senhas, detalhes de cartão de crédito ou informações pessoais do usuário. Muitas violações de dados de alto perfil nos últimos anos foram resultado de ataques de SQL injection, levando a danos à reputação e multas regulatórias. Em alguns casos, um invasor pode obter um backdoor persistente nos sistemas de uma organização, levando a um comprometimento de longo prazo que pode passar despercebido por um longo período.
Exemplos de SQL Injection
Há uma grande variedade de vulnerabilidades, ataques e técnicas de SQL Injection que surgem em diferentes situações. Alguns exemplos comuns de injeção de SQL incluem:
Recuperando dados ocultos, onde você pode modificar uma consulta SQL para retornar resultados adicionais.
Subvertendo a lógica do aplicativo, onde você pode alterar uma consulta para interferir com a lógica do aplicativo.
Ataques UNION, onde você pode recuperar dados de diferentes tabelas de banco de dados.
Examinando o banco de dados, onde você pode extrair informações sobre a versão e estrutura do banco de dados.
Injeção cega de SQL, onde os resultados de uma consulta que você controla não são retornados nas respostas do aplicativo.
Recuperando dados ocultos
Considere um aplicativo de compras que exibe produtos em diferentes categorias. Quando o usuário clica na categoria Presentes, o navegador solicita o URL: https://insecure-website.com/products?category=Gifts
Isso faz com que o aplicativo faça uma consulta SQL para recuperar detalhes dos produtos relevantes do banco de dados:
SELECIONE * DE produtos ONDE categoria = ‘Presentes’ E lançados = 1
Esta consulta SQL pede ao banco de dados para retornar:
todos os detalhes (*)
da tabela de produtos
onde a categoria é Presentes
e lançado é 1.
A restrição lançado = 1 está sendo usada para ocultar produtos que não foram lançados.
Para produtos não lançados, presumivelmente lançado = 0.
O aplicativo não implementa nenhuma defesa contra ataques de injeção de SQL, então um invasor pode construir um ataque como: https://insecure-website.com/products?category=Gifts’–
Isso resulta na consulta SQL:
SELECIONE * DE produtos ONDE categoria = ‘Presentes’ – ‘E lançado = 1
O principal aqui é que a sequência de dois traços - é um indicador de comentário em SQL e significa que o resto da consulta é interpretado como um comentário. Isso remove efetivamente o restante da consulta, de forma que não inclui mais E lançado = 1. Isso significa que todos os produtos são exibidos, incluindo os não lançados.
Indo além, um invasor pode fazer com que o aplicativo exiba todos os produtos em qualquer categoria, incluindo categorias que ele não conhece: https://insecure-website.com/products?category=Gifts’+OR+1=1– Isso resulta na consulta SQL:
SELECIONE * DE produtos ONDE categoria = ‘Presentes’ OU 1 = 1– ‘E lançado = 1
A consulta modificada retornará todos os itens em que a categoria seja Presentes ou 1 é igual a 1. Como 1 = 1 é sempre verdadeiro, a consulta retornará todos os itens.
Subvertendo a lógica do aplicativo
Considere um aplicativo que permite que os usuários façam login com um nome de usuário e senha. Se um usuário enviar o nome de usuário wiener e a senha bluecheese, o aplicativo verifica as credenciais executando a seguinte consulta SQL:
SELECIONE * DE usuários ONDE o usuário = ‘wiener’ E a senha = ‘bluecheese’
Se a consulta retornar os detalhes de um usuário, o login foi bem-sucedido. Caso contrário, é rejeitado.
Aqui, um invasor pode fazer login como qualquer usuário sem uma senha, simplesmente usando a sequência de comentário SQL -para remover a verificação de senha da cláusula de consulta ONDE. Por exemplo, enviar o nome de usuárioadministrador’–e uma senha em branco resulta na seguinte consulta:
SELECIONE * DE usuários ONDE o usuário = ‘administrador’ – ‘E senha =’ ‘
Esta consulta retorna o usuário cujo nome de usuário é administrador e loga com sucesso o invasor como esse usuário.
Recuperando dados de outras tabelas de banco de dados
Nos casos em que os resultados de uma consulta SQL são retornados nas respostas do aplicativo, um invasor pode aproveitar uma vulnerabilidade de injeção SQL para recuperar dados de outras tabelas no banco de dados. Isso é feito usando a palavra-chave UNION, que permite executar uma consulta SELECIONE adicional e acrescenta os resultados à consulta original.
Por exemplo, se um aplicativo executa a seguinte consulta contendo a entrada do usuário “Presentes”:
SELECIONE o nome, a descrição DOS produtos ONDE categoria = ‘Presentes’
então um invasor pode enviar a entrada:
‘UNION SELECIONE nome de usuário, senha DE usuários–
Isso fará com que o aplicativo retorne todos os nomes de usuário e senhas junto com os nomes e descrições dos produtos.
Examinando o banco de dados
Após a identificação inicial de uma vulnerabilidade de injeção de SQL, geralmente é útil obter algumas informações sobre o próprio banco de dados. Muitas vezes, essas informações podem abrir caminho para uma maior exploração.
Você pode consultar os detalhes da versão do banco de dados. A maneira como isso é feito depende do tipo de banco de dados, portanto, você pode inferir o tipo de banco de dados de qualquer técnica que funcione. Por exemplo, no Oracle você pode executar:
SELECT * FROM v$version
Você também pode determinar quais tabelas de banco de dados existem e quais colunas elas contêm. Por exemplo, na maioria dos bancos de dados, você pode executar a seguinte consulta para listar as tabelas:
SELECT * FROM information_schema.tables
Vulnerabilidades cegas de SQL Injection
Muitas instâncias de injeção de SQL são vulnerabilidades cegas. Isso significa que o aplicativo não retorna os resultados da consulta SQL ou os detalhes de quaisquer erros de banco de dados em suas respostas. Vulnerabilidades cegas ainda podem ser exploradas para acessar dados não autorizados, mas as técnicas envolvidas são geralmente mais complicadas e difíceis de executar.
Dependendo da natureza da vulnerabilidade e do banco de dados envolvido, as seguintes técnicas podem ser usadas para explorar vulnerabilidades cegas de injeção SQL:
Você pode alterar a lógica da consulta para acionar uma diferença detectável na resposta do aplicativo, dependendo da verdade de uma única condição. Isso pode envolver a injeção de uma nova condição em alguma lógica booleana ou o disparo condicional de um erro, como divisão por zero.
Você pode acionar condicionalmente um atraso de tempo no processamento da consulta, permitindo inferir a verdade da condição com base no tempo que o aplicativo leva para responder.
Você pode acionar uma interação de rede fora de banda, usando técnicas OAST. Esta técnica é extremamente poderosa e funciona em situações onde as outras técnicas não funcionam. Frequentemente, você pode exfiltrar dados diretamente por meio do canal fora de banda, por exemplo, colocando os dados em uma pesquisa DNS de um domínio que você controla.
Como detectar vulnerabilidades de SQL Injection
A maioria das vulnerabilidades de injeção de SQL podem ser encontradas de forma rápida e confiável usando o Burp Suite scanner de vulnerabilidade da web.
A injeção de SQL pode ser detectada manualmente usando um conjunto sistemático de testes em cada ponto de entrada no aplicativo. Isso normalmente envolve:
Enviar o caractere de aspas simples’e procurar por erros ou outras anomalias.
Enviar alguma sintaxe específica de SQL que avalia o valor base (original) do ponto de entrada e um valor diferente e procurar por diferenças sistemáticas nas respostas do aplicativo resultante.
Enviar condições booleanas, como OR 1=1 e OR 1=2, e procurar diferenças nas respostas do aplicativo.
Enviar cargas úteis projetadas para disparar atrasos quando executados em uma consulta SQL e procurar diferenças no tempo necessário para responder.
Enviar cargas OAST projetadas para acionar uma interação de rede fora de banda quando executado em uma consulta SQL e monitorar todas as interações resultantes.
SQL Injection em diferentes partes da consulta
A maioria das vulnerabilidades de injeção de SQL surgem dentro da cláusula ONDE de uma consulta SELECIONE.
Esse tipo de injeção de SQL é geralmente bem conhecido por testadores experientes.
Mas as vulnerabilidades de injeção de SQL podem, em princípio, ocorrer em qualquer local dentro da consulta e em diferentes tipos de consulta. Os outros locais mais comuns onde a injeção de SQL surge são:
Em declarações de ATUALIZAR, dentro dos valores atualizados ou na cláusula ONDE.
Em declarações de INSERIR, dentro dos valores inseridos.
Em declarações de SELECIONE, dentro da tabela ou nome da coluna.
Em declarações de SELECIONE, dentro da cláusula ORDENAR POR.
SQL Injection de segunda ordem
A injeção SQL de primeira ordem surge quando o aplicativo obtém a entrada do usuário de uma solicitação HTTP e, no decorrer do processamento dessa solicitação, incorpora a entrada em uma consulta SQL de uma maneira insegura.
Na injeção SQL de segunda ordem (também conhecida como injeção SQL armazenada), o aplicativo obtém a entrada do usuário de uma solicitação HTTP e a armazena para uso futuro. Isso geralmente é feito colocando a entrada em um banco de dados, mas nenhuma vulnerabilidade surge no ponto onde os dados são armazenados. Posteriormente, ao lidar com uma solicitação HTTP diferente, o aplicativo recupera os dados armazenados e os incorpora a uma consulta SQL de maneira insegura.
A injeção SQL de segunda ordem geralmente surge em situações em que os desenvolvedores estão cientes das vulnerabilidades da injeção SQL e, portanto, lidam com segurança com o posicionamento inicial da entrada no banco de dados. Quando os dados são posteriormente processados, são considerados seguros, uma vez que foram previamente colocados na base de dados de forma segura. Nesse ponto, os dados são tratados de maneira insegura, porque o desenvolvedor erroneamente considera que eles são confiáveis.
Fatores específicos do banco de dados
Alguns recursos básicos da linguagem SQL são implementados da mesma maneira em plataformas de banco de dados populares, e muitas maneiras de detectar e explorar vulnerabilidades de injeção de SQL funcionam de forma idêntica em diferentes tipos de banco de dados.
No entanto, também existem muitas diferenças entre os bancos de dados comuns. Isso significa que algumas técnicas para detectar e explorar injeção de SQL funcionam de maneira diferente em plataformas diferentes. Por exemplo:
Sintaxe para concatenação de strings.
Comentários.
Consultas em lote (ou empilhadas).
APIs específicas da plataforma.
Mensagens de erro.
Como evitar injeção de SQL
A maioria das instâncias de injeção de SQL pode ser evitada usando consultas parametrizadas (também conhecidas como instruções preparadas) em vez da concatenação de strings na consulta.
O código a seguir é vulnerável à injeção de SQL porque a entrada do usuário é concatenada diretamente na consulta:
Consulta string = “SELECIONE * DE produtos ONDE categoria = ‘” + input + “‘”;
Instrução de instrução = connection.createStatement ();
Este código pode ser facilmente reescrito de forma a evitar que a entrada do usuário interfira na estrutura da consulta:
Instrução PreparedStatement =
connection.prepareStatement (“SELECIONE * DOS produtos ONDE
categoria =? “);
instrução.setString (1, input);
ResultSet resultSet = instrução.executeQuery ();
As consultas parametrizadas podem ser usadas para qualquer situação em que a entrada não confiável apareça como dados dentro da consulta, incluindo a cláusula ONDE e valores em uma declaração INSERIR ou ATUALIZAR. Elas não podem ser usadas para lidar com entradas não confiáveis em outras partes da consulta, como nomes de tabela ou coluna, ou a cláusula ORDENAR POR.
A funcionalidade do aplicativo que coloca dados não confiáveis nessas partes da consulta precisará adotar uma abordagem diferente, como valores de entrada permitidos na lista branca ou usando uma lógica diferente para fornecer o comportamento necessário.
Para que uma consulta parametrizada seja eficaz na prevenção da injeção de SQL, a string usada na consulta deve ser sempre uma constante embutida no código e nunca deve conter dados variáveis de qualquer origem. Não fique tentado a decidir caso a caso se um item de dados é confiável e continue usando a concatenação de string dentro da consulta para casos considerados seguros.
É muito fácil cometer erros sobre a possível origem dos dados ou que as alterações em outro código violem suposições sobre quais dados estão corrompidos.
https://www.gocache.com.br/wp-content/uploads/2021/02/sql-injection-o-que-e.png6281200Go Cachehttps://www.gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.pngGo Cache2021-02-16 12:19:092021-02-16 13:14:07O que é SQL Injection? Para iniciantes
No mundo competitivo de hoje, todos buscam formas de inovar e fazer uso de novas tecnologias. Web scraping (também chamado de extração de dados da web ou coleta de dados) fornece uma solução para aqueles que desejam obter acesso a dados estruturados da web de maneira automatizada.
O web scraping é útil se o site público do qual você deseja obter dados não tiver uma API, ou tiver, mas fornecer apenas acesso limitado aos dados.
Neste artigo, vamos lançar alguma luz sobre web scraping, segue o que você aprenderá:
O que é web scraping?
O básico de web scraping
Qual é o processo de web scraping?
Para que ele é usado? – principais usos
Os melhores recursos para aprender mais sobre web scraping
O que é web scraping?
Web scraping é o processo de coleta de dados estruturados da web de maneira automatizada. Também é chamado de extração de dados da web. Alguns dos principais casos de uso do web scraping incluem monitoramento de preços, inteligência de preços, monitoramento de notícias, geração de leads e pesquisa de mercado, entre muitos outros.
Em geral, a extração de dados da web é usada por pessoas e empresas que desejam usar a vasta quantidade de dados da web disponíveis publicamente para tomar decisões mais inteligentes.
Se você já copiou e colou informações de um site, você executou a mesma função que qualquer “raspador” da web, apenas em uma escala microscópica e manual. Ao contrário do processo mundano e entorpecedor de extrair dados manualmente, o web scraping usa automação inteligente para recuperar centenas, milhões ou até bilhões de pontos de dados da fronteira aparentemente infinita da Internet.
E não deve ser surpresa, porque web scraping fornece uma coisa realmente valiosa, que nada além dele pode: ele fornece dados estruturados da web de qualquer site público.
Mais do que uma conveniência moderna, o verdadeiro poder do web scraping está na sua capacidade de criar e potencializar alguns dos aplicativos de negócios mais revolucionários do mundo. “Transformativo” nem mesmo começa a descrever a maneira como algumas empresas usam dados coletados da web para aprimorar as suas operações, desde informando decisões executivas até experiências individuais de atendimento ao cliente.
O básico do web scraping
É extremamente simples, na verdade, e funciona por meio de duas partes: um rastreador da web (web crawler) e um raspador da web (web scraper). O rastreador da web é o cavalo, e o raspador é a carruagem. O rastreador conduz o raspador, como que manualmente, pela internet, de onde ele extrai os dados solicitados.
O rastreador
Um rastreador da web, que geralmente chamamos de “aranha”, é uma inteligência artificial que navega na internet para indexar e procurar conteúdo seguindo links e explorando, como uma pessoa com muito tempo disponível. Em muitos projetos, você primeiro “rastreia” a web ou um site específico para descobrir URLs que depois você passa para o seu raspador.
O raspador
Um raspador da web é uma ferramenta especializada, projetada para extrair dados de uma página da web com precisão e rapidez. Os raspadores da web variam amplamente em design e complexidade, dependendo do projeto. Uma parte importante de cada raspador são os localizadores (ou seletores) de dados usados para encontrar os dados que você deseja extrair do arquivo HTML – geralmente, XPath, seletores CSS, regex ou uma combinação deles são aplicados.
O processo de web scraping
É assim que seria um processo geral de “faça você mesmo”:
Identifique o site de destino
Colete URLs das páginas de onde você deseja extrair dados
Faça uma solicitação a esses URLs para obter o HTML da página
Use localizadores para encontrar os dados no HTML
Salve os dados em um arquivo JSON ou CSV ou algum outro formato estruturado
Bastante simples, certo? É simples mesmo! Se você tiver apenas um pequeno projeto. Mas, infelizmente, existem alguns desafios que você precisa enfrentar se precisar de dados em escala. Por exemplo, manter o raspador se o layout do site mudar, gerenciar proxies, executar javascript ou contornar antibots. Todos esses são problemas profundamente técnicos que podem consumir muitos recursos. Essa é parte da razão pela qual muitas empresas optam por terceirizar os seus projetos de dados da web.
Para que é usado o web scraping?
O universo de aplicações de web scraping é bastante vasto, mas falaremos abaixo sobre algumas das aplicações mais comuns:
Inteligência de preço
Inteligência de preço é provavelmente o maior uso para web scraping. Extrair informações de produtos e preços de sites de comércio eletrônico e, em seguida, transformá-las em inteligência é uma parte importante das empresas de comércio eletrônico modernas que desejam tomar melhores decisões de preços / marketing com base em dados.
Como os dados de preços da web e inteligência de preços podem ser úteis:
Precificação dinâmica
Otimização de receita
Monitoramento do concorrente
Monitoramento de tendência de produto
Conformidade de marca e MAP
Pesquisa de mercado
A pesquisa de mercado é fundamental – e deve ser conduzida pelas informações mais precisas disponíveis. Dados extraídos da web de alta qualidade, alto volume e altamente perspicazes de todas as formas e tamanhos, estão alimentando análises de mercado e inteligência de negócios em todo o mundo.
Análise de tendência de mercado
Preços de mercado
Otimização do ponto de entrada
Pesquisa e desenvolvimento
Monitoramento do concorrente
Dados alternativos para finanças
Desvendar alfa e radicalmente criar valor com dados da web adaptados especificamente para investidores. O processo de tomada de decisão nunca foi tão informado, nem os dados tão perspicazes – e as empresas líderes mundiais estão cada vez mais consumindo dados extraídos da web, devido ao seu incrível valor estratégico.
Extraindo percepções de arquivos da SEC
Estimando os Fundamentos da Empresa
Integrações de Opinião Pública
Monitoramento de Notícias
Imobiliário
A transformação digital imobiliária nos últimos vinte anos ameaça desorganizar empresas tradicionais e criar novos participantes poderosos no setor. Ao incorporar dados de produtos obtidos da web aos negócios diários, os agentes e corretores podem se proteger contra a concorrência on-line e tomar decisões informadas no mercado.
Avaliação do Valor da Propriedade
Monitoramento de Taxas de Vacância
Estimação de Rendimentos de Aluguel
Compreensão da Direção do Mercado
Monitoramento de notícias e conteúdo
A mídia moderna pode criar valor excepcional ou uma ameaça existencial para o seu negócio – em um único ciclo de notícias. Se você é uma empresa que depende de análises de notícias oportunas ou uma empresa que aparece com frequência nas notícias, o web scraping dos dados de notícias é a solução definitiva para monitorar, agregar, e analisar as histórias mais críticas do seu setor.
Tomada de Decisão de Investimento
Análise de Sentimento Público Online
Monitoramento de Concorrentes
Campanhas Políticas
Análise de Sentimentos
Geração de leads
Geração de leads é uma atividade de marketing/vendas crucial para todos os negócios. Em 2020 o Hubspot reportou que 61% dos profissionais de marketing de atração disseram que gerar tráfego e leads era o seu desafio número 1. Felizmente, a extração de dados da web pode ser usada para obter acesso a listas de leads estruturadas da web.
Monitoramento de marca
No mercado altamente competitivo de hoje, uma das principais prioridades é proteger a sua reputação online. Quer você venda os seus produtos online e tenha uma política de preços rígida que precisa ser cumprida ou apenas queira saber como as pessoas veem os seus produtos online, o monitoramento de marca com web scraping pode lhe dar esse tipo de informação.
Automação comercial
Em algumas situações, pode ser complicado obter acesso aos seus dados. Talvez você tenha alguns dados que você precise de forma estruturada, no seu próprio site ou no site do seu parceiro, mas não há uma maneira interna que seja fácil de fazer isso e faz sentido criar um raspador e simplesmente pegar esses dados, em vez de tentar trabalhar em sistemas internos complicados.
Monitoramento de MAP
O monitoramento do preço mínimo anunciado (MAPA) é a prática padrão para garantir que os preços online de uma marca estejam alinhados com a política de preços. Com toneladas de revendedores e distribuidores, é impossível monitorar os preços manualmente. É por isso que o web scraping é útil, porque você pode ficar de olho nos preços dos seus produtos sem levantar um dedo.
https://www.gocache.com.br/wp-content/uploads/2021/02/modal-azul.png6281200Go Cachehttps://www.gocache.com.br/wp-content/uploads/2021/11/gocache-nova-preta.pngGo Cache2021-02-11 10:45:592021-02-16 11:39:38O que é Web Scraping? Para iniciantes