Cos'è questo per una richiesta?

1

Vedo la seguente stringa di richiesta (vedi l'esempio completo di seguito) con gli stessi request_parameters, ma valori diversi, che colpiscono tutti i nostri siti / wafs. lo schema è sempre lo stesso:

&sa=...&ei=..&ved=..&usg=...

Gli UA variano da quelli di Libwww-perl a quelli (probabilmente falsificati).

a volte si trova un tentativo di exploit basato su url dopo questa stringa, che punta a timthump e joomla-vulns (nessuna di queste app è presente sui nostri sistemi)

queste stringhe vengono aggiunte a:

  • urls come / contact /
  • statiche-files
  • parametri di richiesta esistenti

campione:

&sa=U&ei=w0QtUoiKC4jukQWZjYGQDg&ved=0CMcBEBYwOTiQAw&usg=AFQjCNFRKoHdBKgBMHRgJFfxPXluxhkSRg/
    
posta that guy from over there 12.09.2013 - 23:22
fonte

3 risposte

5

È difficile giudicare la fonte o lo scopo di queste richieste in base alle informazioni fornite, ma una cosa è piuttosto chiara: qualcuno stava traducendo gli URL delle richieste con la funzione sbagliata, usando codifica HTML al posto di ciò che avrebbe dovuto essere codifica URL di la parte della query degli URL richiesti.

Ad esempio, l'esempio che fornisci dovrebbe essere:

&sa=U&ei=w0QtUoiKC4jukQWZjYGQDg&ved=0CMcBEBYwOTiQAw&usg=AFQjCNFRKoHdBKgBMHRgJFfxPXluxhkSRg/

Se questo doveva essere passato a un altro URL come una singola variabile, avrebbe dovuto essere tradotto usando la codifica URL, e sarebbe simile a questo:

%26sa%3DU%26ei%3Dw0QtUoiKC4jukQWZjYGQDg%26ved%3D0CMcBEBYwOTiQAw%26usg%3DAFQjCNFRKoHdBKgBMHRgJFfxPXluxhkSRg%2F

Come invece è stato tradotto con la codifica HTML, il & simbolo e commerciale (ad esempio, ci sono altri problemi con esso) che denota il nuovo valore del parametro URL si ripeterà nella stringa codificata HTML in posti sbagliati, il tuo server web non ha modo per sapere quali parti sono il nome della query URL e le parti valore nel formato: &field=value una volta che l'URL decodifica la posizione della risorsa richiesta.

Questo, immagino, si traduce in tutti i tipi di richieste illegali elencate nei log di accesso del tuo server web. Consiglierei semplicemente di bloccare tutte le richieste di questo tipo nella configurazione del tuo server web, in quanto non c'è modo in cui possano essere comunque fornite risposte adeguate. Come lo farai, dipende interamente da te e dai tuoi bisogni. Personalmente, rifiuto l'accesso a qualsiasi stringa User Agent (UA) che ritengo non abbia alcuna attività commerciale che acceda al mio server, inclusi gli UA predefiniti di molte librerie di framework Web, tra cui quella che si menziona: Libwww-perl .

Sono su Apache e utilizzo PeristablePress '2010 Blacklist per agente utente per queste attività (tra gli altri blocchi personalizzati nella configurazione del server web e altri mezzi per controllare l'accesso, ovviamente). È a mio parere una raccolta abbastanza comoda di UA in blacklist, e mentre ce ne sono di più nuovi pubblicati anche su questo stesso blog, trovo quello del 2010 che funziona meglio per le mie esigenze. Ad ogni modo, ho pensato che potresti trovarlo utile anche. ;)

    
risposta data 13.09.2013 - 14:54
fonte
1

Ho le stesse richieste nel mio log. Tutte quelle richieste provenivano dal Kazakistan. E tutte le richieste non hanno referrer o fanno riferimento alla stessa pagina della richiesta. Inoltre, non ci sono richieste per altre risorse statiche, come immagini, risorse JS o CSS. Come davvero paranoico, penso che questo lavoro di qualche tipo di scanner di vulnerabilità. Possibile, prova a rilevare la versione di CMS o la ricerca di iniezioni SQL / PHP.

    
risposta data 29.04.2015 - 08:11
fonte
0

ho trovato qualcosa e qualcosa di più

per me sembra che questa linea dovrebbe essere presente solo nel referer, mai all'interno dell'URL stesso. la mia conclusione:

  • ovvio malevolo
  • i creatori di script non riescono a includere questo campo nel referer?
  • non può essere un crawler sbagliato
  • forse aggiunto per far sembrare che "ufficialmente" provenga da google
risposta data 13.09.2013 - 09:45
fonte

Leggi altre domande sui tag