Utilizza le funzioni htmlentities o htmlspecialchars per bloccare l'attacco XSS

Naviga le tue risposte
3

So che questa domanda è stata discussa in rete varie volte. e le persone danno qualche esempio su come bypassare queste funzioni passando il codice. Ma qui un problema, Tutti gli esempi di htmlentities / htmlspecialchars sono correlati quando incorporiamo come valore di attributo come 

<a href="" title="<?php echo htmlentities([XSS_CODE]) ?>"></a>

OR 

<img onerror="<?php echo htmlentities([XSS_CODE]) ?>" />

Ma se ho bisogno di mostrare i dati come contenuti come di seguito. 

<div><?php echo htmlentities([XSS_CODE]) ?></div>

Come potrebbe essere insicuro. Dato che il codice non ha trigger / eventi come nel caso di attributi, questo dovrebbe essere sicuro in tutti i casi.

Ho studiato link . Quasi tutti gli esempi di attacco XSS / filtro bypass non funzionano per un determinato caso. Ho provato il valore con codifica esadecimale di < & > come indicato nell'ultimo paragrafo dell'URL, ma che ancora una volta ha fallito e si è rivelato semplicemente come dati.

In realtà ho dei dubbi su link che hanno alcune combinazioni che non sono gestite da htmlentities come \ x3c, \ u003c,% 3C. Mentre io stesso non sono in grado di produrre e sfruttare il loro utilizzo.

Ho provato un esempio come 

$code = "\x3cstrong\x3eHello World\x3\cstrong\x3e";
// OR
$code = "\u003cstrongu003eHello Worldu003c\cstrongu003e";


<div><?php echo htmlentities($code); ?></div>

Nota: ho provato tutti gli attacchi su Firfox 40 in una macchina Ubuntu.

    
posta kuldeep.kamboj 21.09.2015 - 16:24
fonte

2 risposte

4

htmlentities è la funzione migliore da utilizzare in quanto codifica tutti i possibili caratteri.

L'unico modo in cui posso vedere XSS raggiunto nel tuo esempio è con Internet Explorer se il set di caratteri è impostato su UTF -7 .

Se il tuo set di caratteri è UTF-7 allora 

+ADw-script+AD4-alert(document.location)+ADw-/script+AD4-

diventa 

<script>alert(document.location)</script>

quando interpretato dal browser. Inoltre, htmlentities non causa alcuna codifica dei caratteri.

Ricorda che solo le vecchie versioni di Internet Explorer rileveranno automaticamente UTF-7 - dovrebbe essere esplicitamente impostato nelle versioni moderne (sia dall'autore del sito web che dall'attaccante usando un altro vettore) - vedi questa risposta .

    
risposta data 22.09.2015 - 13:36
fonte
1

Quando un browser analizza un attributo di evento come "onerror", prima HTML decodifica il valore dell'attributo e quindi lo invia al motore JS per l'esecuzione. Questo è il motivo per cui non è sufficiente solo la codifica HTML del contenuto dell'utente che stai inserendo in tali attributi.

Al contrario, quando un browser analizza un tag <script> , non decodifica HTML del suo contenuto. Si limita a inoltrare il suo contenuto al motore JS per l'esecuzione.

Allo stesso modo, quando inserisci il contenuto utente tra i tag <div> , non vedo un modo in cui XSS potrebbe essere possibile se i dati dell'utente sono codificati in HTML perché il browser non decodifica, tranne ovviamente solo per presentare i caratteri codificati sullo schermo .

E non ho idea di come l'attributo title del tag <a> possa portare a XSS se il suo contenuto è codificato in HTML ed è quotato due volte. Per favore fatemi sapere se sapete come:)

    
risposta data 21.09.2015 - 20:45
fonte

Leggi altre domande sui tag

Esiste un modo per garantire la rimozione dei dati dopo aver chiuso l'account Facebook / Gmail / Dropbox? [chiuso] È sicuro usare i file .netrc per memorizzare le credenziali per strumenti come curl o ftp?