Si tratta di un attacco web di cui dovrei preoccuparmi: provare a inserire il codice per i moduli vars

Sembra che ci sia una buona risposta qui e qui .

1 declare @q varchar(8000) select @q = 0x57414954464F522044454C4159202730303A30303A313527 exec(@q) --

Se semplicemente osserviamo quanto sopra possiamo avere un'idea di cosa sta succedendo:

declare @q varchar(8000)
select @q = 0x57414954464F522044454C4159202730303A30303A313527
exec(@q)
--

• Riga 1: dichiara la variabile q come varchar con 8000 caratteri.
• Riga 2: assegna la stringa codificata alla variabile q .
• Riga 3: esegue la variabile q .
• Riga 4: commenti sul resto della query inserita.

Secondo 2 la stringa 0x57414954464F522044454C4159202730303A30303A313527 è WAITFOR DELAY '00:00:15' hex-encoded. Una tecnica di attacco di iniezione SQL temporanea cieca che dice al server di attendere 15 secondi prima di rispondere. Una volta iniettato il carico utile, se il server impiega 15 secondi per rispondere, è probabile che sia vulnerabile a SQL Injection. Questo può essere ulteriormente verificato aumentando il DELAY di tempo.

Non sono affatto un esperto, ma sembra essere un tentativo di SQL Injection. Sperano che ciò che entrano in qualche modo venga eseguito dal tuo server, determinando il fatto che il contenuto delle variabili @q venga eseguito se ci sono riusciti. Direi che è un comando sql in qualche modo codificato, quella stringa "0x5741 ....". Ma penserei, qualcuno qui potrebbe gettare molta più luce su questo di quanto io possa.

Leggi le Iniezioni SQL e controlla se il tuo codice è sufficiente per essere immune. Immagino che potresti anche implementare un meccanismo di blocco (per l'IP sorgente per qualche tempo) se il tuo codice rileva una certa quantità di tali tentativi.

Benvenuti in Internet. L'esecuzione di un server Web pubblico su Internet significa che sarai attaccato. Non c'è davvero niente che puoi fare per impedirlo. Quello che puoi fare è cercare di impedire che gli attacchi abbiano successo. Ciò implica pratiche di codifica sicure, mantenimento del software aggiornato e forse introduzione di alcuni controlli di sicurezza.

Questo particolare attacco, come altri hanno menzionato, è un cieco tentativo di iniezione SQL. Prova tu stesso; se il tuo server attende 15 secondi prima di rispondere, allora lo script CGI è vulnerabile. Ci sono molte risorse disponibili su che prevengono l'iniezione SQL , quindi non voglio annoiarvi con i dettagli qui.

Consiglio vivamente di utilizzare alcuni controlli di sicurezza per il tuo sito. Potresti provare controlli preventivi come mod_security o controlli detective come un programma di controllo del registro web. Gestisco solo un sito di hobby con una pagina statica, quindi ho la soluzione di un hobbista: un filtro personalizzato fail2ban per il mio log web che rileva un pochi attacchi comuni e quindi riduce la connessione a quell'IP. Non è davvero nulla che consiglierei a un sito che aveva risorse reali da proteggere, ma illustra il punto in cui puoi eseguire semplici controlli di sicurezza per aumentare le soluzioni collaudate che tutti gli altri utilizzano.