Ataques de validación de entrada

La validación de entrada se realiza para reducir los datos malignos que pueden entrar en el sistema. Este método no es la principal prevención de XSS (Inyección de SQL). Estos datos se cubren en la codificación de salida y hojas de datos relacionados.

Validación de entrada de lista blanca

Siempre se recomienda evitar ataques lo antes posible en el proceso de la solicitud del usuario (atacante). La validación de entrada se puede utilizar para detectar intrusiones no autorizadas antes de que sea procesada por la aplicación. Los desarrolladores realizan con frecuencia la validación de listas negras para intentar detectar caracteres de ataque y patrones como el carácter, la cadena 1 = 1 o la etiqueta <script>, pero este es un enfoque masivo defectuoso, ya que es típicamente trivial para un atacante evitar ser atrapado por estos filtros. Además, estos filtros frecuentemente impiden la entrada autorizada cuando el carácter está siendo filtrado. Para obtener más información sobre la evasión de filtros XSS, consulte la hoja de trucos XSS Filter Evasion.

La validación de la lista blanca es apropiada para todos los campos de entrada proporcionados por el usuario. Esta implica definir exactamente qué es 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 ser capaz de definir un patrón de validación muy fuerte, normalmente 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, la entrada debe coincidir exactamente con uno de los valores ofrecidos al usuario en primer lugar. Los campos más difíciles de validar son los llamados campos de texto libre, como entradas de blog. Sin embargo, incluso esos tipos de campos pueden ser validados hasta cierto punto. Por ejemplo, puede excluir al menos todos los caracteres no imprimibles (excepto el espacio en blanco aceptable, por ejemplo, CR, LF, tabulación, espacio) y definir una longitud máxima para el campo de entrada.

En resumen, la validación de entrada:

  • Se aplicará a todos los datos de entrada, como mínimo.
  • Debe definir el conjunto de caracteres permitidos para ser aceptado.
  • Debe definir una longitud mínima y máxima para los datos. (por ejemplo, {1,25})

Ejemplos de expresiones regulares de lista blanca

Validando un archivo comprimido en ZIP (5 dígitos + 4 opcionales):

^\d{5}(-\d{4})?$

Validando una selección en 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 listas blancas también han sido predefinidos en varios paquetes de código abierto que se pueden aprovechar. Por ejemplo:

Lado de cliente vs validación de lado de servidor

Tenga en cuenta que cualquier validación de entrada de JavaScript realizada en el cliente puede ser anulada 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 realiza en el servidor.

Validación de contenido de usuario enriquecido

Es muy difícil validar contenido enriquecido enviado por un usuario. Para obtener más información, se puede consultar la hoja de Sanitizing HTML Markup with a Library Designed for the Job.

Prevención de XSS y política de seguridad de contenido
  • Todos los datos de usuario controlados deben codificarse cuando se devuelvan en la página html para evitar la ejecución de datos maliciosos (por ejemplo, XSS). Por ejemplo, & lt; script & gt; Sería devuelto como & amp; lt; script & amp; 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 colocados en el cuerpo HTML. Sin embargo, los datos de usuario colocados en un script necesitarían una codificación de salida específica para JavaScript.

Información detallada sobre la prevención XSS aquí: Hoja de trucos de prevención de XSS de OWASP

Validación de carga de archivos

Muchos sitios web permiten a los usuarios subir archivos, como una imagen de perfil o más. Esta sección ayuda a proporcionar esa característica de forma segura.

Verificación de la carga
  • Utilice la validación de entrada para asegurarse de que el nombre de archivo cargado utiliza un tipo de extensión esperada.
  • Asegúrese de que el archivo subido no sea mayor que un tamaño máximo de archivo definido.

Almacenamiento de subida
  • Utilice 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.
  • Los archivos cargados deben ser analizados por contenido malicioso (antimalware, análisis estático, etc).

Servicio público de contenido cargado
  • Asegúrese de que las imágenes subidas 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 utilizar 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 archivo que, si se permiten, podrían resultar en vulnerabilidades de seguridad.
  • "Crossdomain.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 simplemente los archivos denominados "crossdomain.xml" o "clientaccesspolicy.xml".
  • ".htaccess" y ".htpasswd" proporcionan opciones de configuración del servidor en una base por directorio, y no deben permitirse. Ver http://en.wikipedia.org/wiki/Htaccess.

Verificación de la carga
  • Utilice las bibliotecas de reescritura de imágenes para verificar que la imagen es válida y para quitar contenido extraño.
  • Establezca la extensión de la imagen almacenada como una extensión de imagen válida basada en el tipo de contenido detectado de la imagen desde el procesamiento de imágenes (por ejemplo, no solo confíe en el encabezado de la carga).
  • Asegúrese de que el tipo de contenido detectado de imagen esté dentro de una lista de tipos de imagen definidos (jpg, png, etc.) permitidos. Ver https://es.wikipedia.org/wiki/.htaccess.

Validación de dirección de correo electrónico

Validación del correo electrónico Basics

Muchas aplicaciones web no tratan las direcciones de correo electrónico correctamente debido a conceptos erróneos comunes sobre lo que constituye una dirección válida. Específicamente, es completamente válido tener una dirección de buzón que:

  • Es sensible a mayúsculas y minúsculas en la parte local de la dirección (izquierda del carácter @ más a la derecha)
  • Tiene caracteres no alfanuméricos en la parte local (incluidos + y @)
  • Tiene cero o más etiquetas

En el momento de escribir, RFC 5321 es el estándar actual que define SMTP y lo que constituye una dirección de buzón válida. Tenga en cuenta que las direcciones de correo electrónico deben considerarse datos públicos.

Muchas aplicaciones web contienen expresiones regulares computacionalmente caras e inexactas que intentan validar direcciones de correo electrónico. Los cambios recientes en el paisaje significan que el número de falsos negativos aumentará, particularmente debido a:

  • Mayor popularidad del subdireccionamiento por parte de proveedores como Gmail (comúnmente usando + como un token en la parte local para afectar la entrega)
  • Nuevos gTLD con nombres largos (muchas expresiones regulares comprueban el número y la longitud de cada etiqueta en el dominio)

Siguiendo el RFC 5321, la mejor práctica para validar una dirección de correo electrónico sería:

  • Compruebe la presencia de al menos un @ símbolo en la dirección
  • Asegúrese de que la parte local no es más de 64 octetos
  • Asegúrese de que el dominio no supera los 255 octetos
  • Asegúrese de que la dirección sea entregable

Para garantizar que se pueda entregar una dirección, la única manera de comprobarla es enviar al usuario un correo electrónico y hacer que el usuario tome medidas para confirmar la recepción. Más allá de confirmar que la dirección de correo electrónico es válida y entregable, esto también proporciona un reconocimiento positivo de que el usuario tiene acceso al buzón y es probable que esté autorizado a utilizarlo. Esto no significa que otros usuarios no puedan acceder a este buzón, por ejemplo, cuando el usuario hace uso de un servicio que genera una dirección de correo electrónico de desecho.

  • Los enlaces de verificación de correo electrónico solo deben satisfacer el requisito de verificar la propiedad de la dirección de correo electrónico y no deben proporcionar al usuario una sesión autenticada (por ejemplo, el usuario debe autenticarse normalmente para acceder a la aplicación).
  • Los códigos de verificación de correo electrónico deben expirar después del primer uso o caducar después de 8 horas si no se utilizan.

Normalización de dirección

Como la parte local de las direcciones de correo electrónico es, de hecho sensible a las mayúsculas y minúsculas, es importante almacenar y comparar las direcciones de correo electrónico correctamente. Para normalizar una entrada de dirección de correo electrónico, convertiría la parte de dominio SOLAMENTE a minúsculas.

Desafortunadamente esto hace y hará la entrada más difícil de normalizar y de emparejar correctamente a una intención de los usuarios. Es razonable aceptar solamente una capitalización única de una dirección por lo demás idéntica, sin embargo en este caso es crítico a:

  • Almacenar la parte de usuario como se ha proporcionado y verificado por la verificación de usuario.
  • Realizar comparaciones en minúsculas (siempre) == minúsculas (persistió).

Bibliografía
Este artículo ha sido escrito por Wikipedia. El texto está disponible bajo la licencia Creative Commons - Atribución - CompartirIgual. Pueden aplicarse cláusulas adicionales a los archivos multimedia.