|
|
Pubblicato su 31/07/2023 18:36:01
|
|
|
|
Una mattina di sole, ero seduto davanti al mio portatile a ristrutturare un po' di codice C#. Tutto sta andando bene e sarà una giornata produttiva. Poi ho aggiunto troppi segni uguali alla stringa costante letterale, e le cose sono esplose. La produttività è sparita. La calma ricostruzione di domenica è alle nostre spalle. Anche il sole decise di nascondersi dietro le nuvole.
Dopo aver passato 30-40 minuti a cercare di capire cosa stessi sbagliando, ho capito che non ero io. È Microsoft. A quanto pare, mi sono imbattuto in un vecchio bug nella funzione di decodifica di Base64.Convert.FromBase64StringQuesto bug è sicuramente presente fin dall'introduzione di .NET 1.1 nel 2003. Wow! È vecchio. E non è molto difficile da riprodurre. Ottimo lavoro:
Tecnicamente, questo è illegale, Base64. La versione legale è "abc=". Nota che solo un carattere riempitivo =. La codifica Base64 rappresenta ogni 6 bit di input binario in un carattere ASCII. Questo significa che ogni 4 caratteri in una stringa codificata in Base64 rappresenta 3 byte. Quando i dati codificati non sono un multiplo di 3 byte, l'encoder Base64 aggiunge un carattere di riempitivo per rendere Base64 un multiplo di 4 caratteri. Questo genererà una stringa Base64 che viene correttamente popolata con "abc=". Aggiungerne un altro = lo invaliderà.
Base64 "abc=" viene decodificato come due byte [105, 183]. Giusto. Aggiungere un altro carattere di riempimento alla fine non dovrebbe davvero cambiare il valore codificato. È come aggiungere uno spazio alla fine di una frase. Sì, c'è, ma non cambia il significato della frase. Ma .NET non la pensa così. "abc==" viene decodificato come un byte [109]. Non solo si è accorciato, il che era strano perché abbiamo reso l'input più lungo. È anche diventato diverso. Il primo byte passa da 105 a 109. E non ha fatto eccezioni. Aggiungi un altro = e ottieni un'eccezione. Sorprendente!
Codice:
Prodotto:
'abc=' -> [105, 183]
'abc==' -> [109]
All'inizio non ci potevo credere e ho iniziato a indagare. Ho cercato su Google per un po' e non ho trovato molto. Poi ho pubblicato su StackOverflow e non ho avuto molta fortuna nemmeno lei. Una volta capito cosa stava succedendo, ho dovuto rispondere anche alle mie domande. Dopo aver cercato un po' su GitHub, mi sono imbattuto in una correzione fatta in .NET Core nel luglio 2018. Quindi l'ultima versione di .NET Core gestisce correttamente questo problema e fa un'eccezione:
Eccezione non trattata: System.FormatException: L'input non è una stringa Base-64 valida poiché contiene un carattere non-base 64, più di due caratteri di riempimento, o un carattere illegale tra i personaggi imbottitori.
at System.Convert.FromBase64CharPtr(Char* inputPtr, Int32 inputLength)
presso System.Convert.FromBase64String(Strings s)
at Program.DecodeAndPrint(String base64) in ./base64/Program.cs:line 13
su Program.Main() in ./base64/Program.cs:riga 8
Convert.FromBase64() presenta un bug sottile in cui il secondo carattere irrigidamente riempito alla fine della stringa fa sì che la decodifica "abbia successo" rimuovendo il penultimo carattere.
Siamo a . Questo bug è stato corretto involontariamente quando l'API è stata ottimizzata in NetCore 2.1. Aggiungi test ai log degli errori e assicurati di non tornare indietro.
La soluzione alternativa in .NET 4.7.2 è ricaricare la stringa popolata in modo errato con qualcosa del genere:
Originale:Il login del link ipertestuale è visibile.
|
Precedente:Azure DevOps (viii) compila ASP.NET progetti MVC utilizzando Pipelines BuildProssimo:Viene utilizzato un nuovo timer in .NET 6, PeriodicTimer,
|
Padrone di casa|
Pubblicato su 31/07/2023 18:39:50
|
