Spiegazione della codifica multi-byte illegale che porta a XSS

0

Sto leggendo questo rapporto sulla sicurezza unicode e ho trovato confusi i seguenti paragrafi:

When converting from a multi-byte encoding, a byte value may not be a valid trailing byte, in a context where it follows a particular leading byte. For example, when converting UTF-8 input, the byte sequence E3 80 22 is malformed because 0x22 is not a valid second trailing byte following the leading byte 0xE3. Some conversion code may report the three-byte sequence E3 80 22 as one illegal sequence and continue converting the rest, while other conversion code may report only the two-byte sequence E3 80 as an illegal sequence and continue converting with the 0x22 byte which is a syntax character in HTML and XML (U+0022 double quote). Implementations that report the 0x22 byte as part of the illegal sequence can be exploited for cross-site-scripting (XSS) attacks.

Therefore, an illegal byte sequence must not include bytes that encode valid characters or are leading bytes for valid characters.

In base all'esempio descritto (E3 80 22) come sequenza di byte, è chiaro che non è valido:

>>> b'\xe3\x80\x22'.decode('utf-8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf-8' codec can't decode bytes in position 0-1: invalid continuation byte

e la domanda è come un buon parser / convertitore dovrebbe gestire questo tipo di errore.

Probabilmente sto fraintendendo qualcosa, ma si dice che alcuni potrebbero riportare un errore con l'intera sequenza ( E3 80 22 ), ma altri potrebbero riportare un errore con E3 80 e continuare a convertire il 22 byte come un doppio citazione. Tuttavia, si dice che quando il report include il 22 byte, questo può essere sfruttato in un attacco XSS. Questa è la parte che confonde; Avrei pensato che fosse la seconda istanza quella che portava alle vulnerabilità XSS. Qual è la logica per ritenere che dovrebbe essere la prima istanza vulnerabile all'XSS?

Un'ulteriore domanda: in che modo questo tipo di problema è sfruttabile nella pratica (supponendo che siamo interessati alle applicazioni web)? Dovrei semplicemente usare la codifica dell'URL o la codifica HTML ( %E3%80%22 e &#xE3&#x80&#x22 , rispettivamente) e sperare per il meglio?

    
posta Robert Smith 10.11.2017 - 07:17
fonte

1 risposta

1

Se la tua pagina web considera "E3 80 22" come una sequenza, il "22" non sarà scappato ... se consegni questa pagina a un browser che considera "E3 80 22" come "E3 80" + " 22 ', spogliando la sequenza illegale risulta in' 22 ', allora hai un' 22 'che non vuoi e questo permette attacchi XSS.

    
risposta data 10.11.2017 - 18:49
fonte

Leggi altre domande sui tag