¿Se puede introducir XSS cambiando la codificación del idioma?

Question

Digamos que tengo una aplicación web que usa Latin1 o alguna codificación de idioma inglés predeterminada. Quiero cambiar la aplicación para usar UTF-8 o tal vez otra codificación de idioma. ¿Puede probar que este cambio introducirá XSS?

Esto no es una pregunta específica de PHP, pero en PHP puede mostrar un caso donde htmlspecialchars($var,ENT_QUOTES); es vulnerable a XSS y htmlspecialchars($var,ENT_QUOTES,'UTF-8'); no lo es.

Answer 1

De RFC 3629:

10. Consideraciones de Seguridad

implementadores de UTF-8 necesidad de considerar los aspectos de seguridad de la forma en que manejan UTF-8 secuencias ilegales. Es concebible que en algunas circunstancias un atacante podría explotar un intérprete UTF-8 incauto al enviar en una secuencia de octetos que no es permitida por la sintaxis UTF-8.

Una forma particularmente sutil de este ataque puede llevarse a cabo contra un analizador que realiza comprobaciones de validez seguridad críticos contra el UTF-8 forma codificada de su entrada , pero interpreta ciertas secuencias ilegales de octeto como caracteres . Para ejemplo, un analizador podría prohibir el carácter NUL cuando se codifica como la secuencia solo octeto 00, pero permitir erróneamente la secuencia dos octetos ilegal C0 80 e interpretar como un carácter NUL.Otro ejemplo podría ser un analizador que prohíbe la secuencia de octetos 2F 2E 2E 2F ("/../"), pero permite la secuencia de octetos ilegal 2F C0 AE 2E 2F. Este último exploit se ha utilizado en realidad en un virus ampliamente atacado Web servidores en 2001; por lo tanto, la amenaza de seguridad es muy real.

Por lo tanto, es de vital importancia para asegurarse de que sus datos es UTF-8 válidos.

Pero una vez que haya hecho esto, las preocupaciones de seguridad relacionadas con la codificación son mínimas. Todos los caracteres especiales HTML están en ASCII, y UTF-8 como ISO-8859-1 es totalmente compatible con ASCII. htmlspecialchars se comportará de la manera esperada.

Existe una mayor preocupación con las codificaciones no compatibles con ASCII. Por ejemplo, en GB18030, los bytes ASCII 0x30 y superiores pueden ocurrir dentro de la codificación de un carácter de múltiples bytes. El carácter de HYPHEN ‐ (U + 2010) está codificado como A9 5C, que incluye una barra diagonal inversa ASCII. Esto hace que sea más difícil manejar adecuadamente el escape de barra invertida, invitando al SQL injection.

Answer 2

Aquí hay un ejemplo tonto que hace trampas haciendo un uso indebido de htmlspecialchars de la forma que pretendía.

<?php 
$s = htmlspecialchars($_GET['x'], ENT_QUOTES); 
$s_utf8 = htmlspecialchars($_GET['x'], ENT_QUOTES, 'UTF-8'); 

if(!empty($s)) 
    print "default: " . $_GET['x'] . "<br>\n"; 

if(!empty($s_utf8)) 
    print "utf8: " . $_GET['x'] . "<br>\n" 
?> 

Envíe cualquier carga útil XSS y agregue un byte UTF-8 no válido, p.

http://site/silly.php?x=<script>alert(0)</script>%fe

htmlspecialchars fianzas en una secuencia de bytes UTF-8 no válida y devuelve una cadena vacía. Imprimir el valor $_GET es un agujero obvio, pero tengo algo que decir.

En resumen, obtendrá verificaciones byte a byte con Latin1 y UTF-8, por lo que no conozco un ejemplo dependiente del idioma donde htmlspecialchars perderá un byte peligroso en una codificación, pero no otro.

El punto de mi ejemplo es que su pregunta fue más general (y tal vez un poco demasiado vaga) a los peligros de XSS al cambiar los esquemas de codificación. Cuando el contenido comienza a tratar con diferentes codificaciones de múltiples bytes, los desarrolladores pueden ensuciar los filtros de validación basados ​​en strchr(), strlen(), o cheques similares que no son conscientes de múltiples bytes y pueden ser frustrados por un% 00 en la carga útil. (Oye, algunos desarrolladores aún mantienen el uso de expresiones regulares para analizar y desinfectar HTML.)

En principio, creo que las dos líneas de ejemplo en la pregunta tienen la misma seguridad en cuanto a cambiar la codificación. En la práctica, todavía hay muchas formas de cometer otros errores con codificación ambigua.