Codificaciones que confunden (URL, HTML, Unicode)

En una URL solo pueden ir ciertos caracteres; el resto se escribe con un % seguido de dos cifras hexadecimales que representan un byte. Un espacio se escribe %20, una barra %2F, y un carácter que no es ASCII ocupa varios bytes en UTF-8, cada uno con su %. En formularios y cadenas de consulta, el + también significa espacio. El registro de acceso suele guardar la forma codificada, tal como llegó.

La consecuencia para el auditor: un control que busca un carácter en el texto crudo no lo encuentra si ese carácter llegó codificado, y luego la aplicación lo decodifica y lo usa. Antes de decir «aquí no hay nada» o «aquí hay un ataque», se decodifica.

Abre busquedas.log y tabla-codigos.txt. La primera búsqueda lleva un carácter con tilde, que en UTF-8 son dos bytes y aparece como dos códigos seguidos; los espacios van como %20.

Si un texto se codifica y el resultado se vuelve a codificar, cada % se convierte en %25. Así, %3C pasa a ser %253C. Una doble codificación en un registro es una señal que el auditor anota: o hay un componente que codifica de más (un error inofensivo), o alguien la usa para que un filtro que decodifica una sola vez deje pasar lo que otra capa decodificará después. En los dos casos interesa saber cuántas veces decodifica cada capa de la aplicación.

Unicode tiene caracteres distintos que se ven casi iguales: letras cirílicas idénticas a latinas, o signos de ancho completo pensados para textos asiáticos, como ＜ y ＞, que no son < y >. La normalización Unicode (por ejemplo, la forma NFKC) convierte muchas de estas variantes en su carácter básico. Si una aplicación filtra primero y normaliza después, un ＜ atraviesa el filtro y sale convertido en <. El orden correcto es decodificar, normalizar y solo entonces validar, sobre el mismo texto que la aplicación va a usar.

La tabla de códigos trae los bytes UTF-8 de los dos signos de ancho completo.

Al pintar en una página algo que vino del usuario, la aplicación debe convertir los caracteres con significado en HTML en referencias de carácter: < en <, & en &, y así con los demás. Si en el código fuente de la respuesta se ve <b>, el navegador mostrará el texto <b> como letras; si se ve <b> tal cual, el navegador lo interpreta como una etiqueta. Esta lectura no prueba nada contra nadie: solo dice dónde la salida no se está codificando, y eso se lleva al análisis de XSS de la ruta.

Abre respuestas-guardadas.txt y compara cómo aparece el mismo término en cada fragmento.