non è necessario un form per fare una injection.... i parametri possono essere passati anche via GET e quindi l'iniezione può essere portata a termine anche via GET... anzi di solito è anche più semplice.

Database che permettono le stacked queries (queries che possono essere accodate l'una all'altra separandole con un ; Tra questi MS SQL server e Postgre SQL), in cui i diritti dell'utente che accede al DB non sono settati correttamente, potrebbero permettere l'iniezione in scrittura attraverso pagine web che di per sè eseguono solo letture! Teoricamente è possibile l'azzeramento completo del DB.

Le regole sono sempre quelle... validare, validare, validare.. tutto quello che arriva dal browser remoto: POST, GET e COOKIES. Un parametro passato dal browser deve essere un numero? Verifichiamo che sia un numero prima di costruire la stringa per la query SQL. Deve essere una stringa? limitiamo il tipo di caratteri di cui la stringa può essere composta (eliminiamo caratteri critici come ' " % # -- etc...). Invece di definire i caratteri illegali sarebbe meglio definire quelli ammessi e verificare che quelli della stringa appartengano solo all'insieme "buono". Limitiamo la lunghezza massima della stringa per limitare la lunghezza di una possibile injection etc...
Le regole guida per evitare questi inconvenienti si trovano molto facilmente in rete.


Il javascript iniettato cerca un cookie di nome banner82, se lo trova ne estende la validità di 24 ore e inietta nella tua pagina un iframe che richiama l'url incriminato.

Eliminare lo script è importante... molto più importante è eliminare la vulnerabilità.