Sembra che Null Byte Injection sia possibile nelle app Java. vedere: È possibile l'iniezione null-byte nei nomi file Java?
Quindi come si può proteggerlo? Ispeziona tutti i byte del nome file per un byte 0 (zero)?
Sembra che Null Byte Injection sia possibile nelle app Java. vedere: È possibile l'iniezione null-byte nei nomi file Java?
Quindi come si può proteggerlo? Ispeziona tutti i byte del nome file per un byte 0 (zero)?
Una corretta. Se si consente agli input non attendibili di influire su qualsiasi parte di un nome file, è necessario applicare una convalida dell'input corretta per proteggersi dagli attacchi. Dovrai proteggerti non solo dall'iniezione di byte null, ma anche dall'attraversamento del percorso e da altri attacchi.
La mia raccomandazione è di applicare i seguenti controlli:
Verifica che il nome file non sia "" (la stringa vuota), "." (la directory corrente) o ".." (la directory principale).
Assicurati che l'input non attendibile non contenga barre, in quanto possono essere utilizzate per separare le directory e quindi attivare un attacco di attraversamento del percorso. Per essere portatile e sicuro, ti suggerisco di controllare che non contenga alcuna istanza di File.separatorChar (il separatore di directory) né di '/' (come '/' funziona anche come separatore su Windows, anche se non è il valore di File.separatorChar ).
Assicurati che il percorso non contenga alcun ' caratteri (NUL byte), in quanto possono essere utilizzati per montare un attacco di iniezione byte nul. File.isFile()'
Verifica che il nome file corrisponda a un file normale, utilizzando PRN . Lo scopo è garantire che il file non corrisponda a un file speciale specifico della piattaforma.
Ad esempio, su Windows, il nome file PRN è riservato e trattato in modo speciale: si riferisce alla stampante. Inoltre, \Foo\Bar\PRN viene interpretato globalmente: se si accede al file PRN , Windows interpreta questo come riferito alla stampante (e in generale, File.isFile() è speciale in ogni directory). Esiste una gamma di file riservati di Windows come questo. Vuoi assicurarti che l'autore dell'attacco non ti stia ingannando nell'aprire uno di questi file riservati.
Si noti che il controllo con %code% prima di aprire il file non è atomico in presenza di aggiornamenti simultanei. Pertanto, se sul sistema sono presenti altri processi che potrebbero modificare il filesystem contemporaneamente e potrebbero essere influenzati da input non attendibili, questo controllo potrebbe non essere sufficiente: potresti voler controllare esplicitamente se l'ultimo componente del percorso corrisponde a uno dei Windows riservati i nomi dei file. Ecco la lista dei nomi di file riservati di Windows I ' Conoscenza di: CON, AUX, COM1, COM2, COM3, COM4, LPT1, LPT2, LPT3, PRN, NULL. (Sospetto che questa lista sia probabilmente incompleta.)
Se vuoi vedere del codice da un progetto separato che contiene questo tipo di controlli, anche se per uno scopo leggermente diverso, questo è un esempio .
Controlla ogni input della tua applicazione. In genere è meglio fare una whitelist di input positivi, quindi inserire nella lista nera quelli sbagliati. (Si può facilmente dimenticare qualcosa nella blacklist o viene scoperto un nuovo attacco che non è nella lista nera.) Quindi consiglio di controllarlo con un'espressione regolare che dovrebbe coprire tutti possibili input.
L'iniezione di byte nulli nei nomi dei file è stata risolta con l'aggiornamento 40 di Java 7 (rilasciato intorno a settembre 2013). Quindi, è stato risolto per un po 'di tempo, ma è stato un problema per oltre un decennio ed era una vulnerabilità NASTY in Java.
La correzione è documentata qui: JDK-8014846: File e altre classi in java.io non gestiscono nuli incorporati correttamente
Leggi altre domande sui tag file-system injection