modsecurity whitelisting certian tipos de cookies

Question

Estou vendo cookies sendo gerados em nosso servidor que parecem ser de objetos de terceiros no site e não aparecem quando alguém faz login ou navega pelo site.

Os cookies são aleatórios, mas todos começam com Wm. Então alguns deles podem ser wm_cm_12345-12345-12345-12345 e alguns deles podem ser wm-wtchd-22. Eu estou pensando que talvez eu pudesse fazer com que eles não alertassem se são Wm *.

Como posso colocar cookies na lista de permissões começando por Wm?

e outras ideias que você gostaria de incluir e como posso colocar na lista de permissões?

Obrigado

um exemplo de cookie

TX:981243-Detects classic SQL injection probings 2/2-OWASP_CRS/WEB_ATTACK/SQLI-REQUEST_COOKIES:wm_rx_123456eabcdef7890_0edb4989-1523-ff12-ccab-beddddaaffccc. [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_49_inbound_blocking.conf"] [line "26"] [id "981176"] [msg "Inbound Anomaly Score Exceeded (Total Score: 41, SQLi=9, XSS=): Last Matched Message: 981243-Detects classic SQL injection probings 2/2"] [data "Last Matched Data: \x22:61"] [hostname "Somefoowebsite.com"] [uri "/images/nyancat.jpg"] 

Outro exemplo do que estou vendo:

[30/Nov/2015:13:54:27 --0700] [bumblebeetune.com/sid#7fee134ee758][rid#7fee13b510d8][/nyancat.foo][2] Warning. Pattern match "(.*)" at TX:981243-Detects classic SQL injection probings 2/2-OWASP_CRS/WEB_ATTACK/SQLI-REQUEST_COOKIES:[30/Nov/2015:13:54:27 --0700] [bumblebeetuna.com/sid#7fee134ee758][rid#7fee13b510d8][/nyancat.foo][2] Warning. Pattern match "(.*)" at TX:981243-Detects classic SQL injection probings 2/2-OWASP_CRS/WEB_ATTACK/SQLI-REQUEST_COOKIES:wm_ct_877bb6e0e4744fd6a270f70f3e0c8a67_d464ab47-3cf0-fe3f-89d5-bd785f7bdcfa. [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_49_inbound_blocking.conf"] [line "26"] [id "981176"] [msg "Inbound Anomaly Score Exceeded (Total Score: 18, SQLi=4, XSS=): Last Matched Message: 981243-Detects classic SQL injection probings 2/2"] [data "Last Matched Data: \x22:61"]. [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_49_inbound_blocking.conf"] [line "26"] [id "981176"] [msg "Inbound Anomaly Score Exceeded (Total Score: 18, SQLi=4, XSS=): Last Matched Message: 981243-Detects classic SQL injection probings 2/2"] [data "Last Matched Data: \x22:61"]

    

Answer 1

Você pode fazer o que quiser. Você pode adicionar configurações como esta (conforme detalhado aqui ) :

SecRuleUpdateTargetById 981243 !REQUEST_COOKIES:'/^wm.*/'

Na verdade, isso já é parte integrante de alguns cookies comuns que essa regra sinaliza incorretamente como falsos positivos (__utm usado pelo Google Analytics e _pk_ref usado por um software analítico semelhante) como você pode ver ao olhar para a definição de regra da regra original sinalizada:

SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|!REQUEST_COOKIES:/_pk_ref/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "(?i:(?:[\"'´’‘]\s*?\*.+(?:x?or|div|like|between|and|id)\W*?[\"'´’‘]\d)|(?:\^[\"'´’‘])|(?:^[\w\s\"'´’‘-]+(?<=and\s)(?<=or|xor|div|like|between|and\s)(?<=xor\s)(?<=nand\s)(?<=not\s)(?<=\|\|)(?<=\&\&)\w+()|(?:[\"'´’‘][\s\d]*?[^\w\s]+\W*?\d\W*?.*?[\"'´’‘\d])|(?:[\"'´’‘]\s*?[^\w\s?]+\s*?[^\w\s]+\s*?[\"'´’‘])|(?:[\"'´’‘]\s*?[^\w\s]+\s*?[\W\d].*?(?:#|--))|(?:[\"'´’‘].?*\s?\d)|(?:[\"'´’‘]\s*?(x?or|div|like|between|and)\s[^\d]+[\w-]+.*?\d)|(?:[()\*<>%+-][\w-]+[^\w\s]+[\"'´’‘][^,]))" "phase:2,capture,t:none,t:urlDecodeUni,block,msg:'Detects classic SQL injection probings 2/2',id:'981243',tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.id}-%{rule.msg}',setvar:tx.sql_injection_score=+1,setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:'tx.%{tx.msg}-OWASP_CRS/WEB_ATTACK/SQLI-%{matched_var_name}=%{tx.0}'"

Agora, se você puder descobrir qual é esse regexpr, você é um homem melhor do que eu, mas é possível ver a configuração para a qual os cookies se aplicam no começo.

Note que é melhor adicionar a configuração acima para modificar dinamicamente a regra, em vez de editar a própria regra, já que atualizar suas regras sobrescreverá quaisquer edições, enquanto que as substituições poderão ser mantidas (supondo que elas estejam em um arquivo de substituição separado que ainda esteja presente após atualização).