Sto testando un'applicazione che salta solo < e > simboli. L'input dell'utente che viene convalidato viene sempre inserito tra tag html come <b> , <span> , <div> , ecc. E non viene mai passato alla pagina come attributo. C'è abbastanza protezione o c'è un modo per aggirare questo tipo di filtro?
Esempio:
<a href="http://www.site.com" style="color:white">
UserInput
</a>
Saluti.
Questa non è una protezione sufficiente
Ci sono molti modi in cui un utente malintenzionato potrebbe intrufolarsi in una sequenza di byte che verrà interpretata dal browser di qualcuno come markup.
Nel tuo caso, potrebbe anche essere possibile utilizzare solo codifica e commerciale per passare < e > caratteri.
In caso contrario, è possibile utilizzare doppia codifica per ignorare i filtri o persino overlong sequenze utf-8 (tuttavia quest'ultimo è un po 'obsoleto e la maggior parte degli stack di software non cade per questo).
Questi sono solo alcuni esempi, ma ci sono molti altri modi per aggirare i filtri di markup semplici come i tuoi. Questo bit in particolare è pertinente.
Oh, da dove cominciare ...
Se c'è un principio di sicurezza che si rivela ancora e ancora e ancora è che le blacklist falliscono.
Gioca al lungo gioco: certo che la tua applicazione web possa resistere al numero limitato di attacchi che hai lanciato oggi, ma internet sarà in grado di provare migliaia di altre cose con migliaia di altre variabili (nuovo codice, diverso browser, set di lingue diverse, ecc. ecc. ecc.).
"L'input dell'utente che viene convalidato è sempre" - ti dice oggi. Cosa succede quando si passa e un altro sviluppatore eredita quel codice? Capiranno e onoreranno gli impegni che hai preso per te nella tua testa? Se inserisci la convalida e la codifica in uscita, dai al ragazzo successivo una possibilità di combattere.
Vai avanti e spoglia "" < script > ", cosa succede quando qualcuno invia" "< scr < script > ipt >" "?
Chi fornisce l'HREF nell'URL che hai fornito qui:
<a href="http://www.site.com" style="color:white">
UserInput
</a>
Se href viene estratto da un tag di input. Quindi questo è solo l'ennesimo caso di filtraggio o escaping insufficiente dell'input dell'utente. Tutti gli input dell'utente devono essere considerati malvagi.
Ad esempio, se è l'utente che fornisce l'URL per quel tag di ancoraggio nel tuo caso di esempio, è del tutto possibile che questo sXSS funzioni e venga caricato su ogni mouse sopra:
URL: http://www.site.com" onmouseover="javascript:alert(1)"
In alternativa, puoi modificare onmousover to onload e ora hai il tuo javascript in esecuzione su ogni caricamento della pagina. Disabilitare gli eventi DOM dai tag HTML è un altro metodo per prevenire questo tipo di attacco sXSS.
Leggi altre domande sui tag web-application xss