¿Puede una codificación de servidor no coincidente en HTTP POST o GET resultar en un problema de seguridad?

Solicitud del cliente al servidor

Suponiendo que no hay vulnerabilidades en el decodificador UTF-8 en el servidor (por ejemplo, codificación UTF-8 prolongada o bytes de continuación UTF-8 ilegales ) que podrían pasar por alto un filtro u otra rutina de codificación que pueda ' No imagines ninguna secuencia que pueda ser descodificada a cualquier cosa peligrosa en sí misma. No es como UTF-7 donde una secuencia como +ADw- puede omitir un filtro o codificador porque no entienden la codificación.

Por supuesto, esto supone que el UTF-8 se decodifica y luego se vuelve a codificar para otros componentes del backend que pueden ser vulnerables (por ejemplo, un proceso de backend que decodifica en el UTF-7 podría ser vulnerable si los bytes en bruto se envían desde el frente final).

Respuesta del servidor al cliente

Nuevamente, si el decodificador UTF-8 del cliente está libre de vulnerabilidades, esto debería ser seguro. Suponiendo que el cliente está interpretando la respuesta del servidor como codificación UTF-8, no estaba seguro de su pregunta de si el cliente que envía UTF-7 también esperaba UTF-7 en la respuesta. Si este fuera el caso, sí, podría ser vulnerable a XSS a través de etiquetas no codificadas pasadas desde el servidor. Si no es así, otra cosa que podría lanzar una llave inglesa en las obras son los complementos del navegador (por ejemplo, Flash / Silverlight), pero estos normalmente obtendrían su entrada desde el navegador una vez que el texto haya sido decodificado, o directamente desde el servidor (en cuyo caso su condición previa de solo lectura en UTF-8 a través de la red aún se aplicaría).

(La respuesta de SilverlightFox es excelente. Considere mi respuesta debajo de una nota relacionada en lugar de una respuesta por derecho propio.)

MSDN advierte contra la ejecución de entradas no confiables a través de la clase de codificación UTF7. Las versiones recientes de ASP.NET realmente han eliminado el soporte para UTF-7 ya que ningún cliente legítimo enviará datos a un servidor web utilizando esta codificación. En estos escenarios, la solicitud se trata como si fuera UTF-8.

Para las comunicaciones de servidor a cliente, una buena manera de mitigar esto es usar UTF-8 y verificar que el encabezado Content-Type de la respuesta siempre contiene charset = utf-8 . La mayoría de los marcos web deberían hacer esto automáticamente en su nombre.

Output

Cuando una salida de Unicode se traduce a un conjunto de caracteres de 8 bits, a veces se realiza con una conversión de "mejores esfuerzos". Los caracteres que no tienen una coincidencia exacta se convierten en algo similar, por lo que tal vez "a con circunflejo" se convierta en "a". Esto puede ser extremadamente peligroso para la seguridad. Hay un carácter de Unicode "medio ancho menos que signo". Los navegadores no reconocen esto como el inicio de una etiqueta, por lo que generalmente no se escapa. Sin embargo, en una conversión de los mejores esfuerzos, se puede traducir a un formato regular < y esto puede causar un defecto XSS. Esto no es solo una preocupación teórica; He visto esto en la naturaleza. Alguna información aquí .

En la mayoría de los casos, la mejor solución es utilizar utf-8 en todas partes. Si esto no es posible, debe hacer una conversión estricta, en lugar de realizar los mejores esfuerzos. Y si eso no es posible, entonces debes hacer el mejor esfuerzo de conversión ANTES de escapar.

Input

Hay una regla muy simple para evitar problemas: descodificar antes de validar . Independientemente del conjunto de caracteres que obtenga (o la codificación de la URL, etc.), descodifíquelo completamente antes de validar o realizar cualquier operación en los datos. Si sigues esta regla, deberías ser bueno, incluso si hay fallas en tu decodificación (por ejemplo, aceptar secuencias de utf-8 demasiado largas).