Un usuario malintencionado puede usar Base-64 u otro esquema de codificación para omitir la validación de entrada de la aplicación web o para saltarse algún firewall externo de la aplicación web. Dado que estos esquemas de codificación son infinitos, podemos hacer que estas entradas sean finitas para validar todas y cada una de las cadenas de entrada.
El atacante no puede elegir qué codificaciones podrían ser efectivas. Si no hay un decodificador base64 en el extremo de la aplicación, la codificación base64 no logrará nada.
Si hay un paso de decodificación en base64 al final de la aplicación, la aplicación debe realizar la validación de entrada después de que se haya realizado la decodificación.
En el caso de los WAF, que están en el medio y no saben qué descodificación podría estar haciendo la aplicación, tienes razón: no son confiables.
Algunas herramientas solo aplican la decodificación estándar de protocolo (por ejemplo, decodificación de URL para parámetros de URL) y serían falsos negativos en ataques codificados utilizando un esquema ad hoc; algunas herramientas prueban una selección de codificaciones y, opcionalmente, combinaciones n de profundas codificaciones para tratar de detectar firmas de ataques, lo que puede llevar a falsos positivos como texto inocuo que nunca será descifrado con base64 se interpreta erróneamente como la base64- Codificación de algo que podría ser un ataque.
Así que sí, las correcciones como WAF que operan por encima de la capa de aplicación no son confiables, pero eso no es nada nuevo. Nadie debe confiar únicamente en un WAF para la seguridad; son buenos para detectar ataques genéricos y para soluciones temporales temporales para vulnerabilidades conocidas hasta que haya una solución disponible, pero nunca pueden ser un filtro de entrada hermético.
No validas las cadenas de entrada in abstracto . Valida las cadenas para un propósito específico .
Cuando un usuario malintencionado trabaja alrededor de un sistema de validación usando Base64, esto significa que el sistema de validación y el sistema que usa el valor, no están de acuerdo. El sistema de validación no sabe sobre Base64, pero el sistema subyacente aplicará con gusto la decodificación Base64 en la entrada. Esto es una validación mal hecha.
Podríamos argumentar que la "validación de entrada" está más o menos condenada a fallar cuando se realiza en un sistema separado (por ejemplo, en un front-end), porque dos piezas de software mantenidas independientemente no se pueden mantener completamente sincronizadas en todo momento. Ese es el problema genérico con mysql_real_escape_string() en el contexto de PHP + MySQL: esa función PHP debe ser plenamente consciente de todos los detalles de cómo la implementación de MySQL subyacente interpretará las cadenas de entrada, y dichos detalles varían con las versiones del producto.
Estoy de acuerdo con la publicación de @ Thomas-pornin con respecto a la validación de entrada, pero vale la pena señalar (RE: OP) que no hay un número infinito de esquemas de codificación. Hay muchas, pero no es un sistema interminable. Al proteger sus aplicaciones, es importante investigar qué esquemas de codificación son compatibles con sus sistemas y adaptar su seguridad a las necesidades de su sistema, en lugar de tratar de mapear cada conjunto de códigos conocidos para cada posible problema de seguridad. Lamentablemente, no existe un "martillo de oro" para resolver el problema de la adquisición o gestión inseguras de los datos, por lo que el cuidado y la diligencia debidos son críticos.
La mejor de las suertes con tu trabajo.
Un usuario malintencionado que generalmente intenta inyectar código malintencionado utilizando vulnerabilidades de XSS o inyección de SQL, consideremos que implementó una declaración preparada que impide la inyección de SQL, luego, la posibilidad restante es un ataque de XSS.
El código malicioso para XSS contiene JavaScript o cualquier tipo de incrustación de origen cruzado:
JavaScript with <script src="..."></script> CSS with <link rel="stylesheet" href="..."> Images with <img> Media files with <video> and <audio>. Plug-ins with <object>, <embed> and <applet>. Fonts with @font-face. Some browsers allow cross-origin fonts, others require same-origin fonts. Anything with <frame> and <iframe>De ( Política del mismo origen )
Ahora, considere que el usuario usa uno de estos métodos, se sabe que permitir el HTML es peligroso para el usuario, considerando que el usuario malicioso usa la codificación base65 para ofuscar el código, pero ¿cómo se puede ejecutar este código? ¿Y por qué tu sistema decodifica base64?
Otro escenario es cuando su aplicación utiliza la entrada de usuario que se usará en una aplicación de terceros, en este caso, puede decirle al usuario que siga el patrón permitido, de lo contrario podría rechazar la entrada.
Lea otras preguntas en las etiquetas web-application validation