È molto utile utilizzare alcuni degli strumenti automatici, tuttavia non si otterrà alcuna conoscenza o esperienza da parte di questi.
Il punto di attacco XSS è l'esecuzione di javascript in una finestra del browser, che non è fornita dal sito. Quindi, per prima cosa è necessario dare un'occhiata al contesto in cui i dati forniti dall'utente sono stati stampati sul sito web; potrebbe essere compreso nel blocco di codice <script></script>
, potrebbe essere compreso nel blocco <style></style>
, potrebbe essere utilizzato come attributo di un elemento <input type="text" value="USER DATA" />
o, ad esempio, in un <textarea>
.A seconda di ciò vedrete quale sintassi userete per uscire dal contesto (o usarlo); ad esempio se si è all'interno dei tag <script>
, potrebbe essere sufficiente chiudere la paresi di una funzione e terminare la linea con punto e virgola, in modo che l'iniezione finale assomigli a ); alert(555);
. Se i dati forniti vengono utilizzati come attributo html, l'iniezione potrebbe apparire come " onclick="alert(1)"
che causerà l'esecuzione di js se si fa clic sull'elemento (quest'area è ricca da utilizzare specialmente con html5). Il punto è che il contesto di xss è tanto importante quanto qualsiasi funzione di filtraggio/sanificazione che potrebbe essere presente, e spesso potrebbero esserci piccole sfumature che lo strumento automatico non catturerà. Come puoi vedere sopra anche senza virgolette e tag html, in un numero limitato di circostanze potresti essere in grado di ignorare i filtri ed eseguire js.
Inoltre, è necessario considerare la codifica del browser, ad esempio si potrebbe essere in grado di ignorare i filtri se il browser di destinazione ha codifica utf7 (e si codifica l'iniezione in questo modo). L'evasione del filtro è tutta un'altra storia, tuttavia le attuali funzioni PHP sono piuttosto a prova di proiettile, se usate correttamente.
Anche qui è un elenco abbastanza lungo di XSS vectors
Come ultima cosa, ecco un esempio reale di una stringa XSS che è stato trovato su un sito, e vi garantisco che non un solo scanner avrebbe fatto hanno scoperto che (c'erano filtri e liste nere di parole diverse, la pagina ha permesso di inserire la formattazione di base HTML per personalizzare la pagina del profilo):
<a href="Boom"><font color=a"onmouseover=alert(document.cookie);"> XSS-Try ME</span></font>
fonte
2013-09-12 16:12:03
Codice vulnerabilità di iniezione, quali XSS o SQL injection sono sempre il risultato di un uso improprio o mancanza di dati in uscita. In PHP tu * devi * usare 'htmlspecialchars()' su * tutto * che mandi in uscita alla pagina che non è intesa come markup. Per salvare un po 'di digitazione potresti usare una funzione di 'wrapper' ($ s) {return htmlspecialchars (s); } 'e usa' h() 'ovunque. – Tomalak
Qual è il punto di test per le vulnerabilità XSS ** prima ** implementate 'htmlspecialchars()' (o 'htmlentities()')? – Mike
Inoltre, pensa sempre al "livello di codice" in cui ti trovi: Ad esempio: quando scrivi i dati generati dall'utente in un commento HTML, non devi davvero 'htmlspecialchars()', ma tu * devi * ricordarti di rimuovi qualsiasi occorrenza di '->' da quei dati o hai una possibile vulnerabilità XSS proprio lì. – Tomalak