XSS y el navegador

El fallo de XSS se ve en el punto donde la aplicacion pinta en la pagina algo que vino del usuario. En buscar.php de Boletia la entrada $_GET['q'] se concatena dentro de un echo que arma HTML, sin pasar por ninguna funcion que la convierta en texto inofensivo. El navegador recibe lo que el usuario escribio como si fuera parte del documento. El auditor reconoce el fallo por eso: salida sin codificar, no por probar un payload.

Abre el archivo y fijate en que le pasa a $q entre que entra y que se imprime: nada.

Un auditor sostiene el hallazgo con evidencia, no con una corazonada. En la carpeta evidencia de Boletia hay una respuesta HTTP guardada donde se ve que lo que un revisor escribio en el buscador volvio dentro del HTML tal cual, sin convertirse en texto. Eso confirma que el navegador recibiria el marcado y lo ejecutaria. Leer la respuesta guardada es la forma estatica de confirmar el XSS sin lanzar nada contra un sistema vivo.

La evidencia no es el ataque: es la prueba de que la salida no se codifica, que es lo que el informe necesita.

Contra el XSS el arreglo tiene dos capas, y la primera es imprescindible: codificar la salida, convirtiendo los caracteres que el navegador trata como marcado en su forma de texto cuando se pintan —en PHP, htmlspecialchars—. Encima de eso, una Content-Security-Policy limita que scripts puede ejecutar la pagina y reduce el dano si algo se escapa. El auditor recomienda las dos, en ese orden: codificar siempre, CSP como refuerzo.

Validar solo la entrada no basta: la misma entrada puede ser legitima en un sitio y peligrosa al pintarla en otro. Se codifica donde se imprime.

La nota de triaje de Boletia recoge el fallo: el archivo, el parametro, la clasificacion CWE-79 y el arreglo. Abrela en el laboratorio y lee el codigo del hallazgo con el que cierra. Ese codigo acompana al XSS en el informe.