Una codifica del server non corrispondente su HTTP POST o GET causa un problema di sicurezza?

Richiesta dal client al server

Supponendo che non ci siano vulnerabilità nel decoder UTF-8 sul server (es. codifica UTF-8 eccessiva o byte di continuazione UTF-8 illegali ) che potrebbero bypassare un filtro o un'altra routine di codifica che posso ' Immagina qualsiasi sequenza che possa essere decodificata a qualcosa di pericoloso in sé. Non è come UTF-7 in cui una sequenza come +ADw- può bypassare un filtro o un encoder poiché non comprendono la codifica.

Questo naturalmente presuppone che l'UTF-8 sia decodificato e quindi ri-codificato per altri componenti di back-end che potrebbero essere vulnerabili (ad esempio un processo di back-end che decodifica in UTF-7 potrebbe essere vulnerabile se i byte grezzi vengono inviati dal front-end fine).

Risposta dal server al client

Anche in questo caso, se il decodificatore UTF-8 client è libero da vulnerabilità, questo dovrebbe essere sicuro. Ciò presuppone che il client stia interpretando la risposta del server come codifica UTF-8 - Non ero sicuro dalla tua domanda se il client che inviava UTF-7 si aspettava anche UTF-7 nella risposta. Se fosse così, allora si potrebbe essere vulnerabili a XSS tramite tag codificati sono passati dal server. Altrimenti, un'altra cosa che potrebbe lanciare una chiave inglese nei lavori sono i plug-in del browser (es. Flash / Silverlight), ma normalmente questi ricevono il loro input dal browser una volta che il testo è stato decodificato o direttamente dal server (nel qual caso il tuo la pre-condizione di sola lettura in UTF-8 attraverso la rete sarebbe comunque valida).

(La risposta di SilverlightFox è ottima. Considera la mia risposta al di sotto di una nota correlata piuttosto che una risposta a sé stante.)

MSDN mette in guardia contro l'esecuzione di input non fidati attraverso la classe UTF7Encoding. Le versioni recenti di ASP.NET hanno effettivamente abbandonato il supporto per UTF-7 poiché nessun client legittimo invierà dati a un server Web utilizzando questa codifica. In questi scenari, la richiesta viene trattata come se fosse UTF-8.

Per le comunicazioni da server a client, un buon modo per mitigare questo è usare UTF-8 e verificare che l'intestazione Content-Type della risposta contenga sempre charset = utf-8 . La maggior parte dei framework web dovrebbe farlo automaticamente a tuo nome.

Output

Quando un output unicode viene convertito in un set di caratteri a 8 bit, a volte viene eseguito con una conversione "best effort". I personaggi che non hanno una corrispondenza esatta vengono convertiti in qualcosa di simile, quindi forse "a con circonflesso" diventa "a". Questo può essere estremamente pericoloso per la sicurezza. C'è un carattere unicode "mezza larghezza inferiore al segno". I browser non riconoscono questo come l'inizio di un tag, quindi di solito non viene salvato. Tuttavia, su una conversione best effort può essere tradotto in un normale < e questo può causare un difetto XSS. Questa non è solo una preoccupazione teorica; Ho visto questo in natura. Alcune informazioni qui .

Nella maggior parte dei casi, la soluzione migliore è usare utf-8 ovunque. Se questo non è possibile, dovresti fare una conversione rigorosa, piuttosto che i migliori sforzi. E se ciò non è possibile, allora devi fare la conversione dei migliori sforzi PRIMA di fare qualsiasi fuga.

ingresso

C'è una regola molto semplice per evitare problemi: decodifica prima di convalidare . Qualunque set di caratteri tu riceva (o codifica URL, ecc.) - decodificalo completamente prima di convalidare o eseguire qualsiasi operazione sui dati. Se segui questa regola, dovresti essere bravo, anche se ci sono difetti nella tua decodifica (ad esempio accettando lunghe sequenze utf-8).