2011-08-29 4 views
21

Ho avuto problemi con XSS. Nello specifico ho ricevuto un avviso JS per l'iniezione individuale che mostrava che il mio input aveva vulnerabilità. Ho fatto ricerche su XSS e ho trovato degli esempi, ma per qualche motivo non riesco a farli funzionare.Esempi di XSS che posso utilizzare per testare l'input della mia pagina?

Posso ottenere degli esempi di XSS che posso inserire nel mio input e quando restituisco all'utente l'avviso di una sorta di modifica come un avviso per sapere che è vulnerabile?

Sto usando PHP e ho intenzione di implementare htmlspecialchars() ma prima sto cercando di riprodurre queste vulnerabilità.

Grazie!

+4

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

+0

Qual è il punto di test per le vulnerabilità XSS ** prima ** implementate 'htmlspecialchars()' (o 'htmlentities()')? – Mike

+0

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

risposta

14

È possibile utilizzare questo addon per Firefox:

XSS-Me è lo strumento Exploit-Me utilizzato per verificare riflessa Cross-Site Scripting (XSS). Attualmente NON prova per XSS memorizzato.

Lo strumento funziona inviando i moduli HTML e sostituendo il modulo con stringhe rappresentative di un attacco XSS. Se la pagina HTML risultante imposta un valore JavaScript specifico (document.vulnerable = true), lo strumento contrassegna la pagina come vulnerabile alla stringa XSS fornita. Lo strumento non tenta di compromettere la sicurezza del sistema specificato. Cerca possibili punti di ingresso per un attacco contro il sistema. Non sono disponibili funzioni di scansione delle porte, pacchetti sniffing, hacking delle password o attacchi firewall eseguiti dallo strumento .

Si può pensare al lavoro svolto dallo strumento come lo stesso dei tester QA per il sito che inserisce manualmente tutte queste stringhe nei campi del modulo .

+1

Questo strumento è fantastico, lo consiglio vivamente! Vite che reinventa la ruota –

+0

Non è supportato con la versione 5.0. Qualcuno l'ha usato su 5.0 con successo? – KRB

4

Ad esempio:

<script>alert("XSS")</script> 
"><b>Bold</b> 
'><u>Underlined</u> 
1

Ad-hoc test è OK, ma vi consiglio anche cercando uno strumento di scansione delle vulnerabilità di applicazioni web per assicurarsi di non aver perso nulla.

Acunetix è piuttosto buona e ha una prova gratuita della loro applicazione:

http://www.acunetix.com/websitesecurity/xss.htm

(Nota non ho alcuna affiliazione con questa società, però ho utilizzato il prodotto per testare le mie applicazioni).

+0

Sfortunatamente, lo scripting cross-site è una cosa che gli scanner automatici sono veramente terribili nel trovare. Loro perdono la maggior parte delle configurazioni vulnerabili in natura e sparano solo sul più semplice codice aperto. – Cheekysoft

3

È 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>

Problemi correlati