Introducción

Este artículo se centra en proporcionar una guía clara, simple y práctica para
proporcionar la funcionalidad de seguridad de Validación de entrada en sus
aplicaciones.

Objetivos de validación de entrada

La validación de entrada se realiza para garantizar que solo los datos formados
correctamente ingresen al flujo de trabajo en un sistema de información,
evitando que los datos con formato incorrecto persistan en la base de datos y
desencadenen el mal funcionamiento de varios componentes posteriores. La
validación de entrada debe realizarse lo antes posible en el flujo de datos,
preferiblemente tan pronto como se reciban los datos de la parte externa.

Los datos de todas las fuentes potencialmente no confiables deben estar

sujetos a validación de entrada, incluidos no solo clientes web con conexión a
Internet, sino también alimentaciones de back-end a través de extranets,
de proveedores, socios, vendedores o reguladores , cada uno de los cuales
puede verse comprometido por sí mismo y comenzar a enviar malformados
datos.
La validación de entrada no debe usarse como el método principal para
prevenir XSS , inyección de SQL y otros ataques que pueden contribuir
significativamente a reducir su impacto si se implementan correctamente.

Estrategias de validación de entrada

La validación de entrada debe aplicarse tanto a
nivel sintáctico como semántico .

La validación sintáctica debe aplicar la sintaxis correcta de los campos

estructurados (por ejemplo, SSN, fecha, símbolo de moneda).
La validación semántica debe exigir la corrección de sus valores en el
contexto comercial específico (por ejemplo, la fecha de inicio es anterior a la
fecha de finalización, el precio está dentro del rango esperado).

Siempre se recomienda evitar ataques lo antes posible en el procesamiento

de la solicitud del usuario (atacante). La validación de entrada se puede usar
para detectar entradas no autorizadas antes de que la aplicación las procese.

Implementación de validación de
entrada
La validación de entrada se puede implementar utilizando cualquier técnica de
programación que permita la aplicación efectiva de la corrección sintáctica y
semántica, por ejemplo:

 Validadores de tipo de datos disponibles de forma nativa en marcos de

aplicaciones web (como Django Validators , Apache Commons Validators, etc.).
 Validación contra el esquema JSON y el esquema XML (XSD) para la entrada en
estos formatos.
 Conversión de tipos (por ejemplo, Integer.parseInt()en Java, int()en Python)
con manejo estricto de excepciones
 Verificación de rango de valor mínimo y máximo para parámetros numéricos y
fechas, verificación de longitud mínima y máxima para cadenas.
 Matriz de valores permitidos para pequeños conjuntos de parámetros de cadena
(por ejemplo, días de la semana).
 Expresiones regulares para cualquier otro dato estructurado que cubra toda la
cadena de entrada (^...$)y no use el comodín "cualquier carácter" (como .o \S)

Lista blanca vs lista negra

Es un error común usar la validación de la lista negra para intentar detectar
caracteres y patrones posiblemente peligrosos como el 'carácter
de apóstrofe , la cadena 1=1o la <script>etiqueta, pero este es un enfoque
enormemente defectuoso ya que es trivial que un atacante evite tales filtros
Además, dichos filtros con frecuencia impiden la entrada autorizada,
como O'Brian, donde el 'personaje es totalmente legítimo. Para obtener más
información sobre la evasión del filtro XSS, consulte esta página wiki .
La validación de la lista blanca es apropiada para todos los campos de entrada
proporcionados por el usuario. La validación de la lista blanca implica definir
exactamente lo que está autorizado y, por definición, todo lo demás no está
autorizado.

Si se trata de datos bien estructurados, como fechas, números de seguridad

social, códigos postales, direcciones de correo electrónico, etc., el
desarrollador debería poder definir un patrón de validación muy fuerte,
generalmente basado en expresiones regulares, para validar dicha entrada.

Si el campo de entrada proviene de un conjunto fijo de opciones, como una

lista desplegable o botones de radio, entonces la entrada debe coincidir
exactamente con uno de los valores ofrecidos al usuario en primer lugar.

Validación de texto Unicode de forma libre

El texto de forma libre, especialmente con caracteres Unicode, se percibe
como difícil de validar debido a un espacio relativamente grande de caracteres
que deben incluirse en la lista blanca.

También es una entrada de texto de forma libre que resalta la importancia de

una codificación de salida adecuada con contexto y demuestra claramente que
la validación de entrada no es la principal protección contra las secuencias de
comandos entre sitios. Si sus usuarios desean escribir un apóstrofe 'o menos
que firmar <en su campo de comentarios, pueden tener una razón
perfectamente legítima para eso y el trabajo de la aplicación es manejarlo
adecuadamente durante todo el ciclo de vida de los datos.
Los medios principales de validación de entrada para la entrada de texto de
forma libre deben ser:

 Normalización: asegúrese de utilizar la codificación canónica en todo el texto y

de que no haya caracteres no válidos.
 Lista blanca de categorías de caracteres: Unicode permite categorías de listas
blancas como "dígitos decimales" o "letras", que no solo cubren el alfabeto latino
sino también otros scripts que se usan globalmente (por ejemplo, ideogramas
árabes, cirílicos, CJK, etc.).
 Lista blanca de caracteres individuales: si permite letras e ideógrafos en los
nombres y también desea permitir el apóstrofe 'para los nombres irlandeses,
pero no desea permitir toda la categoría de puntuación.

Referencias

 Validación de entrada de texto Unicode de forma libre en Python

Expresiones regulares
El desarrollo de expresiones regulares puede ser complicado y está mucho
más allá del alcance de esta hoja de trucos.

Hay muchos recursos en Internet sobre cómo escribir expresiones regulares,

incluido este sitio y el repositorio de expresiones regulares de validación
OWASP .

En resumen, la validación de entrada debe:

 Se aplicará a todos los datos de entrada, como mínimo.

 Defina el conjunto permitido de caracteres que se aceptarán.
 Defina una longitud mínima y máxima para los datos (p {1,25}. Ej .).

Lista blanca Ejemplos de

expresiones regulares
Validación de un código postal de EE. UU. (5 dígitos más -4 opcional)
^\d{5}(-\d{4})?$
Validación de la selección del estado de EE. UU. Desde un menú desplegable
^(AA|AE|AP|AL|AK|AS|AZ|AR|CA|CO|CT|DE|DC|FM|FL|GA|GU|
HI|ID|IL|IN|IA|KS|KY|LA|ME|MH|MD|MA|MI|MN|MS|MO|MT|NE|
NV|NH|NJ|NM|NY|NC|ND|MP|OH|OK|OR|PW|PA|PR|RI|SC|SD|TN|
TX|UT|VT|VI|VA|WA|WV|WI|WY)$
Ejemplo de uso de Java Regex

Ejemplo validando el parámetro "zip" usando una expresión regular.

private static final Pattern zipPattern = Pattern.compile("^\d{5}(-
\d{4})?$");

public void doPost( HttpServletRequest request, HttpServletResponse

response) {
try {
String zipCode = request.getParameter( "zip" );
if ( !zipPattern.matcher( zipCode ).matches() {
throw new YourValidationException( "Improper zipcode format." );
}
// do what you want here, after its been validated ..
} catch(YourValidationException e ) {
response.sendError( response.SC_BAD_REQUEST, e.getMessage() );
}
}
Algunos validadores de la lista blanca también se han predefinido en varios
paquetes de código abierto que puede aprovechar. Por ejemplo:

 Validador de Apache Commons

Validación del lado del cliente frente

al lado del servidor
Tenga en cuenta que cualquier validación de entrada de JavaScript realizada
en el cliente puede ser ignorada por un atacante que deshabilita JavaScript o
usa un Proxy Web. Asegúrese de que cualquier validación de entrada
realizada en el cliente también se realice en el servidor.

Validar contenido de usuario

enriquecido
Es muy difícil validar contenido enriquecido enviado por un usuario. Para
obtener más información, consulte la hoja de referencia XSS
sobre Desinfección del marcado HTML con una biblioteca diseñada para el
trabajo .

Prevención de XSS y política de

seguridad de contenido
Todos los datos de usuario controlados deben codificarse cuando se
devuelven en la página html para evitar la ejecución de datos maliciosos (por
ejemplo, XSS). Por ejemplo <script>, se devolvería como&lt;script&gt;
El tipo de codificación es específico para el contexto de la página donde se
insertan los datos controlados por el usuario. Por ejemplo, la codificación de
entidad HTML es apropiada para los datos ubicados en el cuerpo HTML. Sin
embargo, los datos del usuario ubicados en un script necesitarían una
codificación de salida específica de JavaScript.
Validación de carga de archivos
Muchos sitios web permiten a los usuarios cargar archivos, como una foto de
perfil o más. Esta sección ayuda a proporcionar esa característica de forma
segura.

Verificación de carga
 Use la validación de entrada para asegurarse de que el nombre del archivo
cargado use un tipo de extensión esperado.
 Asegúrese de que el archivo cargado no sea más grande que un tamaño máximo
de archivo definido.
 Si el sitio web admite la carga de archivos ZIP, verifique la validación antes de
descomprimir el archivo. La verificación incluye la ruta de destino, el nivel de
compresión, el tamaño estimado de descompresión.

Subir almacenamiento
 Use un nuevo nombre de archivo para almacenar el archivo en el sistema
operativo. No utilice ningún texto controlado por el usuario para este nombre de
archivo o para el nombre de archivo temporal.
 Cuando el archivo se carga en la web, se sugiere cambiar el nombre del archivo
en el almacenamiento. Por ejemplo, el nombre del archivo cargado
es test.JPG , cámbiele el nombre a JAI1287uaisdjhf.JPG con un nombre de
archivo aleatorio. El propósito de hacerlo para evitar los riesgos de acceso directo
a archivos y nombres de archivo ambiguos para evaluar el filtro,
como test.jpg;.asp or /../../../../../test.jpg.
 Los archivos cargados deben analizarse en busca de contenido malicioso
(antimalware, análisis estático, etc.).
 La ruta del archivo no debe poder especificarse por parte del cliente. Se decide
por el lado del servidor.

Publicación pública de contenido cargado

 Asegúrese de que las imágenes cargadas se sirvan con el tipo de contenido
correcto (por ejemplo, image / jpeg, application / x-xpinstall)

Cuidado con los archivos "especiales"

La función de carga debe usar un enfoque de lista blanca para permitir solo
tipos de archivos y extensiones específicos. Sin embargo, es importante tener
en cuenta los siguientes tipos de archivos que, si se permiten, podrían generar
vulnerabilidades de seguridad:

 crossdomain.xml / clientaccesspolicy.xml: permite la carga de datos entre

dominios en Flash, Java y Silverlight. Si se permite en sitios con autenticación,
esto puede permitir el robo de datos entre dominios y ataques CSRF. Tenga en
cuenta que esto puede ser bastante complicado dependiendo de la versión
 específica del complemento en cuestión, por lo que es mejor prohibir los archivos
llamados "crossdomain.xml" o "clientaccesspolicy.xml".
 .htaccess y .htpasswd: proporciona opciones de configuración del servidor por
directorio y no debe permitirse. Consulte la documentación de HTACCESS .
 Se sugiere que los archivos de script ejecutables web no estén permitidos
como aspx, asp, css, swf, xhtml, rhtml, shtml, jsp, js, pl, php, cgi.

Verificación de carga
 Utilice las bibliotecas de reescritura de imágenes para verificar que la imagen sea
válida y eliminar el contenido extraño.
 Configure la extensión de la imagen almacenada para que sea una extensión de
imagen válida basada en el tipo de contenido detectado de la imagen del
procesamiento de imágenes (por ejemplo, no confíe solo en el encabezado de la
carga).
 Asegúrese de que el tipo de contenido detectado de la imagen esté dentro de una
lista de tipos de imagen definidos (jpg, png, etc.)

Validación de dirección de correo

electrónico
Validación Sintáctica
El formato de las direcciones de correo electrónico está definido por RFC
5321 , y es mucho más complicado de lo que la mayoría de la gente
piensa. Como ejemplo, todos los siguientes se consideran direcciones de
correo electrónico válidas:

 "><script>alert(1);</script>"@example.org
 user+subaddress@example.org
 user@[IPv6:2001:db8::1]
 " "@example.org

Analizar adecuadamente las direcciones de correo electrónico para la validez

con expresiones regulares es muy complicado, aunque hay una serie
de documentos disponibles públicamente sobre expresiones regulares .

La mayor advertencia sobre esto es que, aunque el RFC define un formato

muy flexible para las direcciones de correo electrónico, la mayoría de las
implementaciones del mundo real (como los servidores de correo) utilizan un
formato de dirección mucho más restringido, lo que significa que rechazarán
las direcciones que son técnicamente válidas. Aunque pueden ser
técnicamente correctos, estas direcciones son de poca utilidad si su aplicación
no podrá enviarles correos electrónicos.

Como tal, la mejor manera de validar las direcciones de correo electrónico es

realizar una validación inicial básica, y luego pasar la dirección al servidor de
correo y detectar la excepción si la rechaza. Esto significa que cualquiera de
las aplicaciones puede estar segura de que su servidor de correo puede enviar
correos electrónicos a cualquier dirección que acepte. La validación inicial
podría ser tan simple como:

 La dirección de correo electrónico contiene dos partes, separadas con

un @símbolo.
 La dirección de correo electrónico no contiene caracteres peligrosos (como
comillas inversas, comillas simples o dobles o bytes nulos).
o Exactamente qué caracteres son peligrosos dependerá de cómo se usará la
dirección (reflejada en la página, insertada en la base de datos, etc.).
 La parte del dominio contiene solo letras, números, guiones ( -) y puntos ( .).
 La dirección de correo electrónico tiene una longitud razonable:
o La parte local (antes de @) no debe tener más de 63 caracteres.
o La longitud total no debe tener más de 254 caracteres.

Validación Semántica
La validación semántica se trata de determinar si la dirección de correo
electrónico es correcta y legítima. La forma más común de hacer esto es enviar
un correo electrónico al usuario y exigirle que haga clic en un enlace del correo
electrónico o que ingrese un código que se le haya enviado. Esto proporciona
un nivel básico de seguridad de que:

 La dirección de correo electrónico es correcta.

 La aplicación puede enviarle correos electrónicos con éxito.
 El usuario tiene acceso al buzón.

Los enlaces que se envían a los usuarios para demostrar la propiedad deben
contener un token que sea:

 Al menos 32 caracteres de largo.

 Generado usando una fuente segura de aleatoriedad .
 De un solo uso.
 Tiempo limitado (por ejemplo, que expira después de ocho horas).

Después de validar la propiedad de la dirección de correo electrónico, se debe

solicitar al usuario que se autentique en la aplicación a través del mecanismo
habitual.

Direcciones de correo electrónico desechables

En algunos casos, los usuarios pueden no desear dar su dirección de correo
electrónico real al registrarse en la aplicación, y en su lugar proporcionarán
una dirección de correo electrónico desechable. Estas son direcciones
disponibles públicamente que no requieren que el usuario se autentique y, por
lo general, se usan para reducir la cantidad de spam recibido por las
direcciones de correo electrónico principales de los usuarios.

El bloqueo de direcciones de correo electrónico desechables es casi imposible,

ya que hay una gran cantidad de sitios web que ofrecen estos servicios, y cada
día se crean nuevos dominios. Hay varias listas disponibles públicamente y
listas comerciales de dominios desechables conocidos, pero estas siempre
estarán incompletas.

Si estas listas se usan para bloquear el uso de direcciones de correo

electrónico desechables, se le debe presentar al usuario un mensaje que
explica por qué están bloqueadas (aunque es probable que simplemente
busquen otro proveedor desechable en lugar de dar su dirección legítima).

Si es esencial que las direcciones de correo electrónico desechables estén

bloqueadas, entonces los registros solo deben permitirse desde proveedores
de correo electrónico específicamente incluidos en la lista blanca. Sin
embargo, si esto incluye proveedores públicos como Google o Yahoo, los
usuarios simplemente pueden registrar su propia dirección desechable con
ellos.

Subdireccionamiento
El subdireccionamiento permite al usuario especificar una etiqueta en la parte
local de la dirección de correo electrónico (antes del @signo), que el servidor
de correo ignorará. Por ejemplo, si ese example.orgdominio admite
subdireccionamiento, las siguientes direcciones de correo electrónico son
equivalentes:

 user@example.org
 user+site1@example.org
 user+site2@example.org

Muchos proveedores de correo (como Microsoft Exchange / Office 365) no

admiten subdireccionamiento. El proveedor más notable que lo hace es Gmail,
aunque hay muchos otros que también lo hacen.
Algunos usuarios usarán una etiqueta diferente para cada sitio web en el que
se registren, de modo que si comienzan a recibir correo no deseado en una de
las subdirecciones puedan identificar qué sitio web se filtró o vendió su
dirección de correo electrónico.

Debido a que podría permitir a los usuarios registrar varias cuentas con una
sola dirección de correo electrónico, algunos sitios pueden desear bloquear el
subdireccionamiento eliminando todo entre los signos +y @. Esto generalmente
no se recomienda, ya que sugiere que el propietario del sitio web desconoce
el subdireccionamiento o desea evitar que los usuarios los identifiquen cuando
pierden o venden direcciones de correo electrónico. Además, puede evitarse
trivialmente mediante el uso de direcciones de correo electrónico
desechables o simplemente registrando varias cuentas de correo electrónico
con un proveedor de confianza.