2015-11-23 8 views
12

Durante l'ultimo fine settimana alcuni dei miei siti registrati tutti gli errori che implica l'uso errato dei nostri URL:URL strano contenente 'A = 0 o' 0 = A nei log dei server web

...news.php?lang=EN&id=23'A=0 

o

...news.php?lang=EN&id=23'0=A 

invece di

...news.php?lang=EN&id=23 

ho trovato solo una pagina in origine che ha menzionato questo (https://forums.adobe.com/thread/1973913) dove hanno speculato t La stringa di query aggiuntiva proviene da GoogleBot o un errore di codifica.

Ho recentemente modificato i miei siti per utilizzare PDO anziché mysql_*. Forse questo cambiamento ha causato gli errori? Qualche suggerimento sarebbe utile.


Inoltre, tutte le richieste provengono dallo stesso agente utente mostrato di seguito.

Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729) 

Questo mi ha portato a trovare i seguenti discussioni: pt-BR e Strange parameter in URL - what are they trying?

+0

tale collegamento non può essere generato da HREF nel sito stesso. ed è strano che 5 siti diversi generino link simili in diverse ore del weekend – Atara

+0

Ok, allora perché hai generato i link sbagliati? – zerkms

+0

Questa è la mia domanda. Non ho generato URL con A = 0 o 0 + A. Mi chiedo cosa abbia generato questi URL – Atara

risposta

-6

poiché si tratta di una versione molto vecchia di Firefox, ho bloccato nel mio file .htaccess -

RewriteCond %{HTTP_USER_AGENT} Firefox/3\.5\.2 [NC] 
RewriteRule .* err404.php [R,L] 
22

È un test di bot per le vulnerabilità di SQL injection chiudendo una query con apostrofo, quindi impostando una variabile. Esistono anche inject simili che trattano i comandi shell e/o gli attraversamenti di file path. Non è noto se si tratti di un "buon bot" o di un bot scadente, ma se l'inject funziona, hai problemi più grandi da affrontare. C'è una probabilità del 99% che il tuo sito non stia generando questi link di stile e non c'è nulla che puoi fare per impedirgli di creare quegli URL a meno che tu non blocchi la richiesta con una semplice stringa regolare o un WAF più complesso come ModSecurity.

Il blocco in base all'utente agente non è un angolo efficace. È necessario cercare l'euristica della richiesta e bloccare in base a quello invece. Alcuni esempi di cose da cercare nella url/richiesta/POST/referrer, sia come UTF-8 e hex caratteri:

  • doppie apostrofi
  • doppi periodi, soprattutto seguiti da una barra in varie codifiche
  • parole come "script", "etc" o "passwd"
  • percorsi come dev/null usati con piping/echeggiano uscita guscio
  • % 00 nulli caratteri di stile di byte usati per init un nuovo comando
  • http nell'url di più di onc e (a meno che il sito lo utilizza)
  • nulla per quanto riguarda cgi (a meno che il sito lo utilizza)
  • casuali "impresa" percorsi per cose come ColdFusion, Tomcat, ecc

Se non si utilizza un WAF, ecco un concat regex che dovrebbe catturare molti di quelli all'interno di un URL. Lo usiamo in app PHP, quindi potresti/avrai bisogno di modificare alcuni escape/look a seconda di dove stai usando questo.Si noti che questo ha .cgi, wordpress e wp-admin insieme a un sacco di altre cose nella regex, rimuoverli se necessario.

$invalid = "(\(\))"; // lets not look for quotes. [good]bots use them constantly. looking for() since technically parenthesis arent valid 
$period = "(\\002e|%2e|%252e|%c0%2e|\.)"; 
$slash = "(\\2215|%2f|%252f|%5c|%255c|%c0%2f|%c0%af|\/|\\\)"; // http://security.stackexchange.com/questions/48879/why-does-directory-traversal-attack-c0af-work 
$routes = "(etc|dev|irj)" . $slash . "(passwds?|group|null|portal)|allow_url_include|auto_prepend_file|route_*=http"; 
$filetypes = $period . "+(sql|db|sqlite|log|ini|cgi|bak|rc|apk|pkg|deb|rpm|exe|msi|bak|old|cache|lock|autoload|gitignore|ht(access|passwds?)|cpanel_config|history|zip|bz2|tar|(t)?gz)"; 
$cgis = "cgi(-|_){0,1}(bin(-sdb)?|mod|sys)?"; 
$phps = "(changelog|version|license|command|xmlrpc|admin-ajax|wsdl|tmp|shell|stats|echo|(my)?sql|sample|modx|load-config|cron|wp-(up|tmp|sitemaps|sitemap(s)?|signup|settings|" . $period . "?config(uration|-sample|bak)?))" . $period . "php"; 
$doors = "(" . $cgis . $slash . "(common" . $period . "(cgi|php))|manager" . $slash . "html|stssys" . $period . "htm|((mysql|phpmy|db|my)admin|pma|sqlitemanager|sqlite|websql)" . $slash . "|(jmx|web)-console|bitrix|invoker|muieblackcat|w00tw00t|websql|xampp|cfide|wordpress|wp-admin|hnap1|tmunblock|soapcaller|zabbix|elfinder)"; 
$sqls = "((un)?hex\(|name_const\(|char\(|a=0)"; 
$nulls = "(%00|%2500)"; 
$truth = "(.{1,4})=\1"; // catch OR always-true (1=1) clauses via sql inject - not used atm, its too broad and may capture search=chowder (ch=ch) for example 
$regex = "/$invalid|$period{1,2}$slash|$routes|$filetypes|$phps|$doors|$sqls|$nulls/i"; 

Con esso, almeno con PHP, è abbastanza semplice con i preg_match_all(). Ecco un esempio di come si può utilizzare: https://gist.github.com/dhaupin/605b35ca64ca0d061f05c4cf423521ab

ATTENZIONE: Fare attenzione se si imposta questa opzione per Autoban (filtro cioè fail2ban). MS/Bing DumbBots (e altri) spesso muck up urls inserendo cose come strani tripli punti da seguire url troncati, o cercando di colpire un collegamento tel: come un URi. Non so perché. Ecco cosa intendo: un collegamento con il testo www.example.com/link-too-long...truncated.html potrebbe puntare a un URL corretto, ma Bing potrebbe tentare di accedervi "come sembra" invece di seguire lo href, provocando un hit WAF dovuto a doppi punti.

+0

Come nota, se si finisce per utilizzare ModSecurity, impostarlo prima in modalità verbose + no-process. Ci sono più di poche regole che cercheranno di negare Googlebot - stranamente una di queste è una regola della reputazione ip. In modalità no-process è possibile visualizzare i log inondazioni, ma non prendere provvedimenti, quindi è possibile disabilitare le regole severe. – dhaupin

+1

Ho visto anche questi 'A = 0 alla fine dei miei URL. Ho passato un sacco di codice chiedendomi cosa avessi fatto per causare questo, trovando ovviamente nulla. Poi ho controllato gli indirizzi IP, nessuno di loro proviene da alcun indirizzo IP del cliente che riconosco. È davvero qualcuno che sta provando a fare un'iniezione. –

Problemi correlati