Canonicalización y codificación de salida

Creo que la mejor manera de describir la canonicalización es recordar que proviene de canon , que significa una pieza auténtica de escritura. De lo que están hablando es de tomar datos que no son de confianza y de formatearlos como una representación inequívoca, de modo que nunca pueda ser tergiversado por ningún proceso de software.

El primer paso es tomar su entrada y almacenarla en algún lugar. Su entrada puede estar codificada como ASCII, UTF-8, UTF-16, o cualquier número de otros esquemas de codificación. El software debe detectar esto y convertir y almacenar adecuadamente los datos en un solo formato. Ahora está en un formato único e inequívoco, y por lo tanto se sabe que es correcto cuando se interpreta como tal, es decir, es canon . Esto permite una certeza absoluta cuando se envían más tarde los datos.

Por ejemplo, si inserto '; DROP TABLE users; -- en un formulario, podría causar una inyección de SQL si la aplicación está mal escrita. Sin embargo, con la canonicalización, los datos son solo datos y no pueden representarse como parte de una consulta SQL. En realidad, la forma de canonicalización de SQL son consultas parametrizadas. Además, se deben tomar medidas para convertir la codificación de texto en un solo tipo conocido, de modo que solo se almacenen los puntos de código válidos. Si esto no se hace, un punto de código puede malinterpretarse como un carácter diferente.

Se puede dar un ejemplo similar para salida en HTML. Si la base de datos contiene <script>alert('xss!');</script> , entonces una aplicación ingenua podría escribir eso directamente en la página e introducir un problema de seguridad. Sin embargo, con la canonización adecuada en forma de codificación de salida, obtendríamos <script>alert('xss!');</script> , que un navegador no puede malinterpretar.

La doble codificación es un truco utilizado para engañar a ciertos analizadores. El atacante identifica la codificación que está utilizando y luego precodifica sus datos en este formato. El analizador asume erróneamente que los datos son canon , y los maneja como tales. El resultado es que los datos están mal manejados, de manera que se produce un exploit. Es un ataque de ofuscación, porque el atacante está ofuscando datos de exploits, por lo que el codificador no ve caracteres malos.

• ¿Qué es la "codificación de salida", y alguien puede proporcionar un ejemplo concreto de cómo una rutina de validación podría utilizarlo?

La codificación de salida significa que los datos se codifican de manera adecuada para el contexto en el que se colocan. Ejemplo, supongamos que desea mostrar dinámicamente un nombre de una fuente no confiable: Your name is:<b>Foo bar</b> Si el nombre contiene caracteres html, desea codificarlos, por lo que el resultado es <b>Foo &lt;i&gt Bar</b> en lugar de <b>Foo <i> Bar</b> .

Entonces, la conversión de < a < es un ejemplo de codificación html. Sin embargo, si el contexto es un atributo html, es posible que también tenga que codificar caracteres de espacio, ya que un atributo puede no estar entre comillas y, por lo tanto, un espacio puede romper el atributo y la entrada puede crear un nuevo atributo: <input value=data> es atacado con: <input value=data onclick=javascript:alert(1)/>

• ¿Qué es la "codificación doble" y por qué es un "ataque de ofuscación"?

Cuando escribes ciertos caracteres en una URL, estos se codifican como URL (generalmente, aunque no siempre en IE):

1. Parámetro no codificado: test<script>alert(1)</script>
2. parámetro codificado en URL: test%3Cscript%3Ealert%281%29%3C%2fscript%3E
3. Parámetro de doble codificación: test%253Cscript%253Ealert%25281%2529%253C%252fscript%253E

Dependiendo del manejo de los parámetros de entrada, la codificación doble puede pasar a través de algunos filtros / validadores y terminar rompiendo el contexto donde se hacen eco (lo que lleva a XSS).

• ¿Qué es la "canonicalización" y por qué impide la doble codificación?

La canonización es el acto de escribir algo en la forma más simple, por lo tanto, la forma canónica de algo es la forma "más simple" de escribirlo. Para canonizar en este contexto, significa descodificar los datos hasta que ya no cambie.

Un triple codificado < -sign, pasa por las siguientes transformaciones:

1. %25253C
2. %253C
3. %3C
4. <

Otro ejemplo puede ser si la entrada se escribe como, por ejemplo, escapes octales, secuencias UTF demasiado largas y codificaciones esotéricas, como UTF-7. La canonicalización los convierte en una base común, en aras de la desambiguación.