Esiste un equivalente di SQL injection sui parametri url-passati a un servlet?

Se tutto ciò che fa è stampare i parametri, il vettore di attacco principale è XSS .

Sebbene questo non possa eseguire codice sul server, può eseguire codice nel browser.

Quindi, se un utente malintenzionato invia a un utente legittimo un link

http://www.example.com/foo.jsp?foo=<script>alert(123)</script>

e quando viene seguito il collegamento, il codice dello script viene eseguito dal browser dell'utente nella pagina, quindi la pagina è vulnerabile. In effetti, il lato client della sessione è ora sotto il controllo dell'attaccante se l'attaccante ha fatto qualcosa di più malvagio piuttosto che mostrare semplicemente una casella di avviso. Ad esempio, l'invio di cookie a se stessi o l'iniezione di un keylogger.

Ci sono molte varianti su questo attacco e non deve essere sotto forma di tag script .

L'esecuzione di codice arbitrario è dubbia, altre forme di iniezioni sono una possibilità.

Potrebbero verificarsi problemi come l'iniezione HTML o XSS se l'input non è correttamente controllato e / o la codifica dell'output non viene eseguita.

Prendi in considerazione anche la possibilità di phishing e defacement non persistente.

Un gestore di errori non dovrebbe mai dipendere dai parametri GET e dovrebbe visualizzare solo informazioni minime. Si consiglia di non utilizzare un parametro GET per generare un messaggio di errore.

Spero che questo aiuti!

Come accennato in precedenza, il vettore di attacco principale per la visualizzazione dei parametri della stringa di query sarebbe la vulnerabilità XSS. Se questi dati non vanno mai a un livello persistente, questo è noto come attacco XSS di tipo II (riflesso).

Dovresti sempre considerare il contesto in cui vengono presentati i dati non attendibili. Molti modelli di templating / web moderni come Jinja e Angular forniscono l'escape contestuale automatico. Anche così, dovresti comunque convalidare e disinfettare tutti i dati non fidati con cui entri in contatto.

Se un utente malintenzionato sa che i parametri della stringa di query non vengono disinfettati, potrebbe creare un parametro che invia un cookie di sessione a un server remoto, abbastanza facilmente. Questo è il motivo per cui devi sempre praticare la difesa in profondità nella sicurezza. HttpSolo (se si utilizzano i cookie) / Politica di sicurezza del contenuto / Sanitizzazione / Convalida / Crittografia, ecc.