Validación de entradas y codificación de salidas

Cualquier dato que una aplicación recibe del exterior —entradas de formularios de usuario, parámetros de URL, cabeceras HTTP, cuerpos de solicitudes de API, cargas de archivos— está potencialmente bajo el control de un atacante. Sin validación, los atacantes inyectan comandos SQL, scripts HTML, comandos de shell y directivas XML/LDAP en los flujos de datos de la aplicación. La validación de entradas y la codificación de salidas son los dos controles principales que neutralizan las vulnerabilidades de inyección antes de que puedan causar daños.

La validación de entradas comprueba que los datos recibidos cumplen el tipo, formato, longitud y rango de valores esperados antes de que la aplicación los procese. La validación debe realizarse en el servidor; la validación del lado del cliente en JavaScript se puede eludir fácilmente interceptando las solicitudes con herramientas como Burp Suite. Un nombre de usuario solo debe aceptar caracteres alfanuméricos; un campo de fecha solo debe aceptar formatos de fecha válidos; y un campo de correo electrónico debe cumplir la sintaxis RFC 5322.

La validación mediante lista de permitidos (allowlist) especifica exactamente qué elementos ESTÁN permitidos y rechaza todo lo demás. La validación mediante lista de bloqueados (denylist) especifica qué elementos NO ESTÁN permitidos y permite todo lo demás. Siempre se prefiere la validación mediante lista de permitidos, porque los atacantes descubren continuamente nuevas técnicas para eludir las listas de bloqueados. Por ejemplo, las listas de bloqueados contra la inyección SQL intentan bloquear SELECT, UNION y los caracteres --, pero las codificaciones ingeniosas suelen eludir estos filtros. Una lista de permitidos que solo acepta dígitos en un campo numérico no se puede eludir.

Para las interacciones con bases de datos, las consultas parametrizadas (prepared statements) son la defensa definitiva contra la inyección SQL. La estructura de la consulta se define por separado de los datos proporcionados por el usuario, por lo que el motor de la base de datos nunca interpreta la entrada como sintaxis SQL. Aunque un usuario introduzca ' OR '1'='1, se trata como un parámetro de cadena literal, no como SQL ejecutable. Las consultas parametrizadas están disponibles en los principales lenguajes y controladores de bases de datos.

La codificación de salidas convierte los caracteres especiales de los datos antes de insertarlos en un contexto de salida (HTML, JavaScript, SQL, URL o comandos de shell). Esto garantiza que los datos de un contexto no se interpreten como código ejecutable en otro. El principio clave es la codificación según el contexto: la codificación aplicada debe coincidir con el contexto de salida. La codificación HTML, la codificación de URL, la codificación de JavaScript y el entrecomillado de argumentos de shell neutralizan la inyección en sus respectivos contextos.

Cuando los datos proporcionados por el usuario se representan en HTML, los caracteres especiales deben estar codificados en HTML para prevenir Cross-Site Scripting (XSS). El carácter < se convierte en <, > se convierte en > y & se convierte en &. Si un atacante introduce <script>alert('XSS')</script>, la codificación HTML lo muestra como texto visible en lugar de ejecutar el script. Todos los frameworks web proporcionan funciones de codificación HTML; utilícelas de forma coherente.

Cada contexto de salida requiere estrategias de codificación diferentes. Cuerpo HTML: codifique < > & ' ". Atributos HTML: codifique los mismos caracteres y, además, fuerce el uso de atributos entrecomillados. Contexto JavaScript: utilice codificación JSON o escape de cadenas de JavaScript. Parámetros de URL: aplique codificación porcentual a los caracteres especiales. Comandos de shell: evite por completo construir comandos de shell a partir de entradas del usuario; utilice las API del lenguaje con arrays de argumentos en lugar de concatenar cadenas con intérpretes de shell.

La validación de entradas debe realizarse en varias capas, no solo en el endpoint de la API. La validación del lado del cliente mejora la experiencia del usuario (proporciona información inmediata), pero nunca debe considerarse fiable para la seguridad. La validación en la API o el controlador es la capa de seguridad principal. La validación en los servicios y la lógica de negocio aplica las reglas del dominio. Las restricciones de la base de datos (NOT NULL, CHECK, FOREIGN KEY) proporcionan una capa de defensa final. La defensa en profundidad significa que eludir una capa no da lugar inmediatamente a una explotación.

Las entradas de carga de archivos son especialmente peligrosas. Los atacantes pueden cargar web shells (disfrazados de imágenes), documentos maliciosos (con macros) o archivos de gran tamaño (DoS). La validación debe incluir: verificar el tipo de archivo por su contenido (magic bytes), no solo por su extensión; aplicar un tamaño máximo de archivo; almacenar las cargas fuera de la raíz web; cambiar el nombre de los archivos en el servidor para evitar rutas predecibles; analizarlas con un antivirus o sandbox; y no ejecutar nunca directamente los archivos cargados.

Las aplicaciones modernas utilizan ampliamente REST API y GraphQL, por lo que es necesario validar los cuerpos de las solicitudes JSON/XML. Los frameworks de validación de API, como JSON Schema, definen los campos obligatorios, los tipos de datos, los patrones de cadenas y los rangos de valores. La limitación de profundidad de GraphQL evita que las consultas profundamente anidadas provoquen un DoS. La limitación de velocidad de las solicitudes evita el abuso automatizado incluso cuando cada entrada individual es válida. La validación del esquema debe realizarse antes de que la lógica de negocio procese la solicitud.

Los mensajes de error devueltos a los usuarios pueden revelar inadvertidamente información confidencial que ayude a los atacantes. Los mensajes de error de la base de datos pueden revelar nombres de tablas, tipos de columnas o sintaxis SQL. Los stack traces exponen las versiones del framework de la aplicación y las rutas de los archivos. Los errores detallados de validación de entradas pueden confirmar a un atacante qué caracteres se rechazan, lo que le ayuda a elaborar intentos para eludir los controles. Práctica recomendada: devuelva a los clientes mensajes de error genéricos y fáciles de entender (por ejemplo, «Entrada no válida») y registre la información detallada del error en el servidor para la depuración de los desarrolladores. No exponga nunca mensajes de excepción sin procesar a los usuarios finales.

Compruebe sus conocimientos sobre los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido que: la validación de entradas en el servidor mediante listas de permitidos garantiza que solo se procesen los datos esperados; las consultas parametrizadas previenen la inyección SQL al separar los datos de la estructura de la consulta; y la codificación de salidas según el contexto previene XSS y otros ataques de inyección al neutralizar los caracteres especiales antes de que entren en contextos HTML, JavaScript, URL o shell. A continuación, analizaremos la gestión segura de secretos y la inyección de variables de entorno.