È abbastanza ben spiegato in questo post del blog come Funziona. In sostanza, se è possibile costruire una query URL per suddividere singole parti di una query SQL successiva in più parametri di query (quindi la parte frammentazione del nome), WAF (Web Application Firewall) potrebbe avere problemi nel determinare che si suppone che la richiesta venga interrotta, o qualsiasi altra cosa sia configurata da fare quando viene rilevato un tale tentativo.
Un modo per sfruttarlo è aggiungere un commento iniziale /*
alla fine di un parametro di input e commento finale */
all'inizio di il prossimo. WAF considererà accettabili i due parametri, se non guardano l'intera immagine (quale sintassi SQL viene prodotta come il prodotto di tutti i parametri di input).
Ciò potrebbe causare una parte del codice SQL tra i due parametri di input da ignorare dal motore SQL di RDBMS. Se la parte ignorata (commentata) capita di filtrare i risultati della query SQL (ad esempio, ... WHERE user=$param1 and start_date>=$param2...
può quindi risultare in ... WHERE user=$param1/* and start_date>=*/$param2...
, prevedendo che un vettore possa sfruttare i possibili valori di $ param1 che WAF considererà accettabile e ignorerà anche altri filtri fino al punto in cui viene utilizzato il valore $ param2), il prodotto finale di tale exploit può rivelare informazioni che gli sviluppatori non intendevano mai divulgare.
attacchi HPP , d'altra parte, stanno cercando di sfruttare le differenze tra l'interpretazione dei parametri di input da parte di WAF e dell'applicazione web di gestione richieste, quando un singolo nome di parametro viene ripetuto molte volte. Ad esempio, consideriamo questa query URL analizzata e analizzata da entrambi: ?q=acceptable+request&q=not+acceptable+request
. WAF potrebbe prendere il primo parametro di input come quello da analizzare e ignorare quello successivo, mentre l'applicazione web potrebbe fare esattamente il contrario.
Si noti che sto solo utilizzando gli URL come esempio e che i parametri di input possono essere richiesti in qualsiasi altra parte di intestazioni di richieste HTTP (cookie, campi di richiesta POST o GET, ...) , a seconda di dove vengono analizzati in seguito dall'applicazione Web.