Subida de archivos y deserializacion

Una subida segura decide por lo que el archivo ES, no por como se llama, y lo guarda donde el servidor no ejecuta nada. En subir.php de Depostock pasa lo contrario: comprueba el final del nombre —y ademas con un || true que anula la comprobacion— y mueve el archivo a publico/subidas, una carpeta dentro de la raiz que ejecuta PHP. El auditor ve el fallo en esos dos detalles: se fia del nombre y guarda en zona ejecutable.

La extension del nombre la pone quien sube: fiarse de ella es fiarse del que podria estar abusando.

El arreglo de una subida insegura tiene varias piezas, y una es la que corta el peligro de raiz: guardar los archivos FUERA de la raiz publica, en un sitio desde el que el servidor no ejecuta nada, y servirlos de forma controlada. Encima, validar el tipo real con una lista blanca y renombrar el archivo. Asi, aunque alguien suba algo que no es una imagen, el servidor nunca lo ejecuta. El auditor lo clasifica como subida de fichero peligroso sin restriccion (CWE-434).

Comprobar mejor la extension ayuda, pero la pieza que de verdad cierra el fallo es que lo guardado no viva donde se ejecuta codigo.

El segundo fallo de Depostock esta en sesion.php: una cookie del usuario, $_COOKIE['pref'], se pasa a unserialize, que reconstruye un objeto a partir de ese texto. El problema es que el texto lo controla el usuario, y reconstruir un objeto desde datos no confiables permite forzar comportamientos que el programa no previo. El auditor lo clasifica como deserializacion insegura (CWE-502) y recomienda no deserializar datos del usuario: usar un formato de datos como JSON y, si hace falta integridad, firmarlo.

Es la misma leccion de toda la sala: lo que viene de fuera es dato, no instruccion ni objeto, hasta que se valida.

La nota de triaje de Depostock recoge el hallazgo principal de la subida, su clasificacion y el arreglo, y menciona el segundo. Abrela en el laboratorio y lee el codigo del hallazgo con el que cierra.