Parece que la inyección de byte nulo es posible en aplicaciones Java. consulte: ¿Es posible la inyección de nulo en bytes en los nombres de archivo de Java?
Entonces, ¿cómo se protege uno contra eso? Inspeccione todos los bytes del nombre de archivo para un byte 0 (cero)?
Correcto. Si permite que una entrada que no sea de confianza afecte a cualquier parte de un nombre de archivo, debe aplicar la validación de entrada adecuada para protegerse de los ataques. Deberá protegerse no solo contra la inyección de bytes nulos, sino también contra el paso de ruta y otros ataques.
Mi recomendación es aplicar los siguientes controles:
Asegúrese de que el nombre de archivo no sea "" (la cadena vacía), "." (el directorio actual) o ".." (el directorio principal).
Asegúrese de que la entrada no confiable no contenga barras inclinadas, ya que pueden usarse para separar directorios y, por lo tanto, podrían habilitar un ataque transversal de ruta. Para ser portátil y seguro, le sugiero que verifique que no contenga ninguna instancia de File.separatorChar (el separador de directorio) ni de '/' (como '/' también funciona como separador en Windows, aunque no sea el valor de File.separatorChar ).
Asegúrese de que la ruta no contenga ningún ' caracteres (bytes NUL), ya que pueden usarse para montar un ataque de inyección de nulo byte. File.isFile()'
Verifique que el nombre del archivo corresponda a un archivo normal, usando PRN . El propósito aquí es garantizar que el archivo no se corresponda con un archivo especial específico de la plataforma.
Por ejemplo, en Windows, el nombre de archivo PRN está reservado y se trata especialmente: se refiere a la impresora. Además, \Foo\Bar\PRN se interpreta globalmente: si accede al archivo PRN , Windows lo interpreta como una referencia a la impresora (y, en general, File.isFile() es especial en cada directorio). Hay un rango de archivos reservados de Windows Me gusta esto. Desea asegurarse de que el atacante no lo engañe para que abra uno de estos archivos reservados.
Tenga en cuenta que verificar con %code% antes de abrir el archivo no es atómico en presencia de actualizaciones concurrentes. Por lo tanto, si hay otros procesos en el sistema que podrían modificar el sistema de archivos al mismo tiempo y podrían verse influidos por entradas no confiables, esta verificación podría no ser suficiente: es posible que desee verificar explícitamente si el último componente de la ruta coincide con alguno de los sistemas reservados de Windows. nombres de archivos Aquí está la lista de nombres de archivos reservados de Windows I ' Estoy al tanto de: CON, AUX, COM1, COM2, COM3, COM4, LPT1, LPT2, LPT3, PRN, NULL. (Sospecho que esta lista probablemente esté incompleta).
Si desea ver algún código de un proyecto separado que contenga este tipo de controles, aunque para un propósito ligeramente diferente, he aquí un ejemplo .
Controla cada entrada de tu aplicación. Por lo general, es mejor hacer una lista blanca de entradas buenas y luego una lista negra de las malas (se puede olvidar fácilmente en algo en la lista negra o se descubre un nuevo ataque que no está en la lista negra). posibles entradas.
La inyección de bytes nulos en los nombres de archivo se corrigió en la actualización 40 de Java 7 (lanzada alrededor de septiembre de 2013). Entonces, se ha solucionado por un tiempo, pero fue un problema por más de una década y fue una vulnerabilidad NASTY en Java.
La solución se documenta aquí: JDK-8014846: el archivo y otras clases en java.io no se manejan incrustar nulos correctamente
Lea otras preguntas en las etiquetas file-system injection