Mejores Prácticas en Aplicaciones Web Banco

Seguridad de la Información y
Prevención del Fraude
Normativa de Desarrollo
Seguro para Aplicaciones Web
Julio 2015
INDICE
Seguridad de la Información y Normativa de Desarrollo Seguro de
Prevención del Fraude Aplicaciones Web
OBJETIVOS..............................................................................................................2
ALCANCE.................................................................................................................2
INTEGRACIÓN EN LA METODOLOGÍA..................................................................2
DESTINATARIOS.....................................................................................................2
Arquitectura Web...................................................................................................3
Consideraciones de la Arquitectura.......................................................................3
Acceso remoto de administración..........................................................................4
Uso de distintas Interfaces ....................................................................................4
CONTROL DE ERRORES........................................................................................5
Control de Excepciones.........................................................................................6
REGISTRO DE EVENTOS........................................................................................7
Especificación de las trazas de registro.................................................................7
Almacenamiento de registros ................................................................................8
Protección de los registros ....................................................................................8
PRIVACIDAD DE LA INFORMACIÓN ......................................................................9
Información CONFIDENCIAL ................................................................................9
Datos de carácter personal....................................................................................9
Caché de datos .....................................................................................................9
CONTROL DE SESIÓN..........................................................................................10
Aspectos generales.............................................................................................10
Uso de identificadores de sesión.........................................................................10
Detección de ataques..........................................................................................11
VALIDACIÓN DE LOS DATOS...............................................................................12
Filtrado de entrada de datos................................................................................12
Filtrado de salida de datos...................................................................................13
CODIFICACIÓN DE LOS DATOS...........................................................................14
FILTRADO DE LOS DATOS...................................................................................14
Estrategia de filtrado de datos.............................................................................15
Datos a prevenir ..................................................................................................15
Tipos de filtrado a aplicar.....................................................................................16
INFORMACION SENSIBLE....................................................................................18
Información Sensible en Páginas *SP .................................................................19
Seguridad de Archivos .........................................................................................19
Normalización de Path’s.......................................................................................20
Caracteres HTML y Caracteres Especiales como Entrada de Datos.................20
Uso del campo Referer.........................................................................................20
Uso de POST .........................................................................................................20
Opción Multilingüe................................................................................................21
Comandos de sistema..........................................................................................21
AUTENTICACIÓN...................................................................................................22
Autenticación basada en formularios...................................................................22
Autenticación sobre HTTP...................................................................................23
OBJETIVOS
Este documento expone una serie de principios globales para el diseño y desarrollo
seguro de aplicaciones Web para el Banco .
Página: 1
El objetivo de este documento es exponer una serie principios que describan los
aspectos más importantes que se deben tener en cuenta cuando se diseña o desarrolla
una aplicación Web. Mediante el seguimiento de estos principios, se pretende evitar los
problemas de seguridad más comunes.
ALCANCE
El alcance de este documento afecta a todas las aplicaciones Web a desarrollar para el
Banco .
DESTINATARIOS
Los destinatarios de este documento son los siguientes:
Unidad de Gestión de la Demanda - Diseño y Desarrollo de Software

Unidad de Seguridad de Información y Prevención del Fraude.
Unidad de Tecnología y Explotación.
Toda área que requiera diseño de software con proveedores ya sea
implementados dentro de equipos del Banco o como servicios externos.
INTEGRACIÓN EN LA METODOLOGÍA INTERNA DEL BANCO
En el ciclo de vida del desarrollo de aplicaciones, este documento aplica a las fases de
“Diseño del Sistema”, “Construcción y Pruebas Unitarias” y “Pruebas del Sistema
y Certificación de Calidad”.
(*)
(*)
Figura 1 Ciclo de vida del desarrollo de aplicaciones.
(*) En estas fases usar la herramienta de escaneo de vulnerabilidades AppScan

ARQUITECTURA WEB
Página: 2
Tradicionalmente, las aplicaciones se han desarrollado con diferentes arquitecturas. La

más conocida es la denominada arquitectura de tres capas. Está compuesta por:
Capa de presentación.
Capa de aplicación o de negocio.
Capa de datos.
Capa de Presentación: Esta capa es responsable de la presentación de la información

al usuario o sistema final. Mediante esta capa se sirven los datos a los clientes, y éstos
pueden interactuar con la aplicación.
Capa de Aplicación o de negocio: Es el motor de la aplicación Web. Se encarga de

aplicar la lógica de negocio, procesando las entradas, tomando decisiones y enviando
la información a la capa de presentación.
Capa de Datos: La capa de datos se utiliza para gestionar y almacenar los datos que
utilizará la aplicación Web.
CONSIDERACIONES DE LA ARQUITECTURA
Las aplicaciones Web deberán diseñarse sobre una arquitectura de tres capas.
• Las credenciales de los usuarios y el repositorio de datos serán almacenados en un

lugar distinto a la capa de presentación, de forma que si el servidor Web es
comprometido, estos no se vean afectados.
• La aplicación deberá diseñarse de forma modular, de manera que haya una

separación entre la funcionalidad propia de la lógica de negocio y la lógica de
presentación.
El objetivo es hacer que la aplicación se pueda mantener fácilmente y que sea

sencilla la incorporación de cambios y nuevas funcionalidades en sucesivas
versiones. Esto contribuirá en gran medida a garantizar el mantenimiento del nivel
de seguridad de la aplicación.
• La exposición a redes públicas requerirá medidas de seguridad más exigentes que

las necesarias en un entorno corporativo interno.
Es muy importante que las aplicaciones de Internet estén separadas de las

aplicaciones de intranet, en servidores y redes distintas. El nivel de riesgo y los
requisitos de seguridad son mucho mayores en aplicaciones de Internet.
• La funcionalidad de la aplicación estará claramente separada en directorios según

niveles / perfiles de seguridad.
Página: 3
El motivo es establecer controles de seguridad mediante ACL’s o mecanismos

equivalentes sobre los archivos estáticos que constituyen la aplicación.
• Los servidores se ejecutarán sobre un sistema securizado donde únicamente se

ejecuten los servicios necesarios por la aplicación.
• La aplicación deberá estar diseñada para que el servidor Web sólo acepte peticiones
desde un servidor proxy, salvo en aquellos entornos en los que no exista proxy.
El servidor Web sólo aceptará peticiones con la dirección IP origen del servidor
proxy. Si recibe peticiones de otra máquina devolverá un mensaje de error apropiado
y generará una traza en el archivo de log.
(no aplica para desarrollo de software implementado como servicios externos –

hosting)
• No deben existir enlaces simbólicos en el servidor Web.
El uso de enlaces simbólicos constituye una vulnerabilidad porque se podrían seguir

para solicitar, desde una URL, cualquier archivo del sistema en el que se ejecute la
aplicación Web.
ACCESO REMOTO DE ADMINISTRACIÓN
• Se recomienda no habilitar el acceso mediante administración remota a la aplicación,

utilizando el mismo protocolo del servicio web.
En el caso de que sea necesario, se utilizarán mecanismos de comunicación y

control de acceso seguros, como puede ser el filtrado de las ubicaciones que tienen
acceso (combinado con autenticación del usuario), empleo de contraseñas de un
solo uso, utilización de VPN’s, etc.
USO DE DISTINTAS INTERFACES
• La interfaz de administración no debe ser accesible por los usuarios de la aplicación.
Se recomienda el diseño de distintas interfaces de acceso, si fuese necesario un

interfaz de administración y uno de acceso de usuarios. El acceso a la interfaz de
administración es crucial en la seguridad de una aplicación, y deberá ser protegida.
CONTROL DE ERRORES
• Se deberán identificar y controlar todos los errores que se pueden producir en la

aplicación.
Página: 4
Es muy importante determinar las causas que pueden producir un error, con el fin
de resolver cualquier eventualidad en la aplicación. Como objetivo global se trata de
evitar las finalizaciones inesperadas del programa que puedan comprometer los
controles de seguridad.
• Los mensajes de error no mostrarán información innecesaria o confidencial:
Códigos de error relativos al funcionamiento interno de la aplicación.

Nombres de archivos, rutas de acceso, etc.
La estructura de archivos que constituye la aplicación.
El tipo de sistema operativo, servidor, versión, etc.
Volcados de pila.
Otros.
En el entorno de desarrollo esta información resulta útil para labores de depuración

de la aplicación, pero en el entorno de producción no es necesario, y puede revelar
información que permita realizar un ataque sobre la aplicación.
• Los Servlets, JSPs, CGI’s de la aplicación no utilizarán la salida estándar para

reportar errores o trazas que evidencien versiones, nombres, productos de la
tecnología usada.
Se utilizarán registros de auditoría desde el principio del desarrollo.
• Se deberá identificar el tipo de tratamiento de interacción con el usuario ante un error

durante la ejecución de la aplicación.
Para la interacción con el usuario, se optará entre uno de los siguientes tipos de
mensajes:
Mensaje descriptivo del error: Este mensaje ayudará al usuario a determinar y

resolver la causa del error.
El inconveniente de este tipo de mensajes es que ofrecen pistas a un posible

atacante sobre el tratamiento de la información y los controles de seguridad
que utiliza la aplicación.
Por ejemplo, si se devuelve un mensaje de error distinto cuando el usuario

se equivoca al introducir su identificador y cuando introduce su contraseña,
el atacante tiene más fácil la tarea de descubrir identificadores de usuario
válidos.
Mensaje genérico: Este mensaje indica al usuario que se ha producido un error

pero no desvela su causa.
Página: 5
Mensaje falso: Este mensaje trata de confundir a un posible atacante cuando

se ha detectado un error, pero también puede confundir a un usuario legítimo,
por lo que no se recomienda su uso.
Sin mensaje: En este caso no se devuelve confirmación al usuario sobre si se

ha llegado a efectuar o no una operación. Tampoco se recomienda su uso.
Se deberán utilizar mensajes descriptivos que no ofrezcan información confidencial

del sistema o de la aplicación a un posible atacante. En mecanismos de seguridad
en los que pueda haber una causa múltiple de error (ejemplo:
usuario o contraseña errónea) se utilizarán mensajes genéricos.
CONTROL DE EXCEPCIONES
• Se deberán capturar y controlar todas las excepciones que se puedan producir en la

aplicación.
La no captura de excepciones puede producir fallos de disponibilidad, fallos en el

método de control de acceso, presentación de información sensible al usuario, etc.
• Se deberá realizar un tratamiento de los códigos de retorno para comprobar la causa

de la excepción.
Se deberán tener especial cuidado entre otras con las operaciones de

entrada/salida, llamadas a bases de datos, operaciones con threads, llamadas a
funciones de API’s de terceros productos
REGISTRO DE EVENTOS
El registro de eventos es un aspecto esencial en la seguridad.
Toda aplicación deberá tener establecido un mecanismo de registro de eventos

que permita identificar qué es lo que ha sucedido en cada momento.
Es importante la generación de registros de acceso y de transacción debido a que:
Es la única forma de detectar comportamientos extraños en la aplicación.

Se pueden incluir dentro de sistemas de detección de intrusos.
Permite la creación de estadísticas.
Es necesario para la reconstrucción de eventos después de un problema.
Es necesario en algunos casos para procedimientos legales.
La no correcta habilitación o diseño de los mecanismos de registro de eventos en una

aplicación, puede complicar la detección de intentos de accesos no autorizados, y
facilitar el éxito de dichos intentos.
Página: 6
ESPECIFICACIÓN DE LAS TRAZAS DE REGISTRO
• Las trazas de auditoría de la aplicación deberán permitir reconstruir por completo

una sesión de la aplicación.
• Todos los registros de eventos deben estar sincronizados con un “TimeServer”,

de forma que permita consolidar la información entre los distintos sistemas.
(en el caso de desarrollos prestados como servicios externos, no se requiere un

TimeServer –salvo casos específicos definidos por Seguridad de Información- pero
debe cumplirse con el registro de trazas tal como se especifica en este documento)
Las trazas de registro deberán incluir la siguiente información, que vendrá definida en la
“Especificación de Requisitos” de la aplicación:
• Información de cada traza:
Fecha y hora.
Servicio, proceso o URL invocada.
Ubicación desde donde se accede.
Identificador de usuario y de sesión.
Parámetros de entrada (nombres de archivos, etc.).
• Información sobre eventos:
Arranque, inicialización y parada de la aplicación.

Invocación de programas: en el caso de aplicaciones Web se deberán
registran las llamadas a Servlets, CGI’s, EJB’s, JSP’s.
La lectura, la escritura, el borrado o cualquier tipo de modificación de
datos.
Todos los eventos de autenticación:
o Correctos (log-in, log-out).
o Incorrectos.
Todos los eventos de
autorización: o Usuario que
solicita la petición. o Correctos /
Incorrectos. o Función autorizada.
o Modificaciones.
Todas las funciones administrativas o uso de cuentas privilegiadas.
Todas las actualizaciones de archivos (en especial, archivos clave, de
configuración, etc.)
La impresión de información restringida o confidencial.
La activación y desactivación del registro de auditoría.
ALMACENAMIENTO DE REGISTROS
Página: 7
• Para el caso de aplicaciones desarrolladas por personal del Banco los registros de
eventos deben almacenarse en servidores dedicados para este fin.
• Para el caso de aplicaciones desarrolladas por terceros1 implementadas en servicios

externos, los registros de eventos deben guardarse y comprimirse en archivos
generados periódicamente. Luego se almacenarán en dispositivos que físicamente
estén protegidos contra escritura (CD-ROM, cintas, etc.)
El objetivo es evitar que se colapse el sistema si los archivos de log crecen

demasiado y llenen el disco, además de añadir un nivel de seguridad sobre los
registros en caso de que el sistema sea vulnerado.
• Los datos de los archivos logs deberán ser cifrados antes de su transmisión hacia
cualquier destino, previa validación del mecanismo de cifrado con el personal de
Seguridad de la Información del Banco para proteger la confidencialidad e integridad
de los mismos.
Los registros no deben permitir modificar la información contenida en él, únicamente

se permitirá añadir información.
PROTECCIÓN DE LOS REGISTROS
• Se limitará el acceso a los eventos registrados.
Con el fin de que estén suficientemente protegidos los archivos de traza, se deberá
comprobar que se corresponden con los siguientes permisos asignados:
Sólo el administrador de la aplicación deberá tener permiso de lectura sobre el

archivo de trazas.
Sólo el usuario con el que se arranca la aplicación deberá tener permiso de
escritura sobre el archivo de trazas.
PRIVACIDAD DE LA INFORMACIÓN
INFORMACIÓN CONFIDENCIAL
• No se facilitará información confidencial que pueda repercutir en la seguridad de la

aplicación.
Se deberá tener especial cuidado con comentarios en el código, con la información

que maneja la aplicación (por ejemplo, cuentas, direcciones de correos, etc). Toda
esta información podría ser utilizada por una atacante para vulnerar la seguridad de
la aplicación.
1
Proveedores contratados por Banco
Página: 8
DATOS DE CARÁCTER PERSONAL
Las aplicaciones que tratan datos de carácter personal necesitan medidas adicionales
para garantizar la privacidad de los datos.
• Se deberá cumplir con las medidas de seguridad que establece la normativa del Banco
y la legislación vigente.
CACHÉ DE DATOS
En los equipos multiusuario, existen ciertos peligros como son:
El almacenamiento de las páginas en la caché del navegador del usuario.

La permanencia de archivos temporales en el equipo del usuario.
Para evitar que información confidencial quede almacenada en las máquinas de los
usuarios, las páginas deberán tener activas las siguientes opciones:
Expiración de la sesión en un determinado periodo de tiempo.

El no almacenamiento en caché de las páginas, para lo cual las páginas HTML
deberán incluir los tags no-cache y no-pragma-cache.
CONTROL DE SESIÓN
El mecanismo de control de sesión es crucial en la seguridad de las aplicaciones Web.
• A la hora de diseñar la aplicación es preferible intercambiar un único parámetro entre

el cliente y el servidor (un identificador de sesión), en lugar de pasar todos los
parámetros asociados a la sesión (parámetros de entrada de formularios, rutas de
navegación, etc). Todos estos parámetros tienen que almacenarse en el servidor,
identificados mediante dicho ID de sesión.
• Se recomienda, proporcionar al cliente un identificador de sesión único que permita

al servidor relacionarle con peticiones previas, correspondientes a la misma sesión.
• Si hay un intercambio de varios datos de contexto entre cliente y servidor, deberá

comprobarse en el servidor la validez de cada uno de estos datos de entrada. Se ha
de tener en cuenta que esta comprobación puede ralentizar el servicio que ofrezca
la aplicación Web.
ASPECTOS GENERALES
Página: 9
Existen diversos mecanismos para que cliente y servidor HTTP establezcan una sesión,
en la que se mantenga un estado que relacione peticiones de un cliente sobre un mismo
servidor:
- Cookies.
- Campos ocultos en formularios. - URL rewriting.
- Cabeceras HTTP con formato propietario.
- Autorización de usuarios.
USO DE IDENTIFICADORES DE SESIÓN
Todo identificador de sesión debe:
o Ser único.
o Ser no predecible (se usará una fuente de aleatoriedad aprobada por
Seguridad de Información).
o Ser resistente a ingeniería inversa. o No incluir información confidencial.
o Ser suficientemente largos para evitar ataques de fuerza bruta.
• Las acciones críticas dentro de una aplicación deberán solicitar una reautenticación.
• Los identificadores de sesión se regenerarán de forma periódica para que la ventana

de uso sea mínima.
Un aspecto importante a asegurar es el período de validez del identificador de

sesión. Los identificadores de sesión que no expiran pueden permitir a un atacante
conseguir mediante fuerza bruta un identificador válido de sesión.
• Los identificadores de sesión deberán ser transmitidos de forma segura (mediante el

uso de criptografía. Por ejemplo, SSL) para evitar ataques de repetición o de
suplantación de sesión.
• Se deberán eliminar o sobrescribir los identificadores de sesión una vez que el

usuario realice logout de la aplicación.
DETECCIÓN DE ATAQUES
Se recomienda el uso de identificadores de sesión “booby trapped”. Se trata de registrar

el uso de identificadores de sesión que nunca son asignados y que permiten detectar si
se está realizando un ataque de fuerza bruta contra el identificador de sesión.
Página: 10
VALIDACIÓN DE LOS DATOS
La mayoría de los ataques comunes sobre aplicaciones y en especial sobre aplicaciones

Web se pueden prevenir mediante una validación apropiada de los datos.
La validación de los datos es uno de los aspectos más importantes a la hora de diseñar
una aplicación segura. Cuando se habla de validación de datos, se hace referencia tanto
a la entrada, como al proceso, como a la salida de datos.
Muchas aplicaciones validan los datos en cliente (utilizando por ejemplo Javascript en
clientes web). La validación de cliente favorece el rendimiento y la usabilidad (reduce la
cantidad de tráfico inválido al servidor), pero no introduce ningún beneficio desde el
punto de vista de la seguridad.
• Toda la validación se debe realizar en un servidor de confianza o bajo el control de

la aplicación (parte servidora).
La validación de datos en la parte cliente se puede falsear fácilmente. El motivo es

que un usuario no tiene por qué utilizar los formularios, applets y en general, la
interfaz de usuario de la aplicación para conectarse con el servidor. De este modo
podría saltarse cualquier validación que se pretendiera realizar en el cliente.
• Se procurará que todas las entradas recibidas y salidas emitidas sean tratadas como
datos y no como contenido ejecutable.
Existe una gran cantidad de ataques mediante la introducción de datos no esperados

en los campos de aplicaciones web. Estos ataques pueden producir, entre otros, los
bloqueos de páginas, la obtención de código sensible, la omisión de la autenticación
de la aplicación, el ataque de otros equipos clientes, la obtención y/o destrucción de
información, etc.
Filtrado de entrada de datos
• Es necesaria la validación de datos en la parte servidora para su protección frente a

ataques de manipulación de parámetros.
Las interfaces que se enumeran a continuación se considerarán validas, siempre que se

validen adecuadamente los datos:
Parámetros de entrada visibles y ocultos (HIDDEN) en formularios HTML.

Parámetros de entrada en applets Java, controles ActiveX y otras aplicaciones que
se ejecuten sobre el navegador.
URL’s en la barra de direcciones o en links.
Cookies.
Cabeceras HTTP.
Página: 11
Se deberá tener especial cuidado con:
Las cookies: se deberá comprobar si el dominio es correcto, ya que podría

realizarse un ataque de suplantación.
Los tags HTML: se deberá limitar su uso, ya que podrían producirse ataques de
cross site scripting.
Las URI’s / URL’s: se deberán validar primero, ya que de otro modo pueden
producirse ataques mediante spam.
Filtrado de salida de datos
• Se deberá vigilar que las páginas generadas dinámicamente no contienen tags no

deseados.
El filtrado de la salida en páginas Web deberá vigilar especialmente el uso de los

siguientes tags, y aplicará la conversión establecida en la columna de la derecha:
< <
> >
( (
) )
# #
& &
• Se deberán revisar todas las entradas y salidas de datos de las que haga uso la
aplicación, como pueden ser:
Líneas de comando.
Variables de entorno.
Contenido de archivos.
Cookies.
Cabeceras HTTP.
Datos de formularios HTML.
Mapa de memoria.
Sistema de archivos.
Tecnologías de acceso a bases de datos (OLE DB, ODBC, JDBC,...).
Otros.
Para prevenir datos maliciosos en las aplicaciones, se aplicarán dos técnicas:
Codificación
Página: 12
Filtrado
CODIFICACIÓN DE LOS DATOS
Muchos entornos soportan diferentes métodos de codificación de información. Es

necesario especificar un método de codificación que permita identificar de forma
correcta los caracteres.
• Se establecerá un método de codificación de caracteres para la aplicación. Se

recomienda el uso de la ISO-8859-1.
Mediante el uso de un método de codificación específico, se evitarán las distintas

representaciones que pueden tomar los caracteres, permitiendo un correcto filtrado
de los datos.
• Los parámetros se decodificarán antes de la validación. No se debe decodificar más

de una vez el mismo dato.
Si no se decodifican los datos antes de la validación, el código malicioso no será

detectado por el filtrado de datos. Lo mismo ocurrirá si se decodifican los datos más
de una vez.
• Se hará uso de la codificación de caracteres en la salida de datos.
Mediante la codificación de los datos de salida se consigue que los datos enviados
se traten como datos y no como código ejecutable, evitando de esta forma diversos
ataques, como es el conocido como “cross-site scripting”.
Existen varias formas de representación de caracteres. Por ejemplo:
US-ASCII.
Codificación UTF-8.
Codificación UCS-2 Unicode.
Codificación ISO-8859-1.
FILTRADO DE LOS DATOS
• Se recomienda el uso de un componente o librería centralizada que implemente un

filtrado de parámetros.
• Se establecerán procedimientos para responder a los errores de validación, que

registrarán el error que se haya producido.
• Se deberán filtrar tanto los datos de entrada como de salida en busca de código
malicioso que pueda afectar a la seguridad de la aplicación. Existen diversas
estrategias de filtrado que se pueden aplicar sobre los datos.
Página: 13
ESTRATEGIA DE FILTRADO DE DATOS
Existen tres modelos de referencia en el diseño de una estrategia de filtrado de datos:
Aceptar únicamente datos válidos
Esta es la estrategia más segura de las tres. Las aplicaciones sólo deben
aceptar entradas que son seguras y cumplen con lo esperado por la
aplicación. Se definirá qué datos son válidos, y se rechazará cualquier otro
tipo de dato.
Por ejemplo, para validar los identificadores de usuario, se deberá comprobar

que los valores se encuentran dentro de ASCII A-Z y 0-9, que se trata de una
cadena (no un objeto por ejemplo) y que tiene una longitud válida.
Rechazar datos no válidos
Esta estrategia se basa en el conocimiento de los datos que pueden ser

perjudiciales para la aplicación.
La debilidad de esta estrategia viene dada porque es muy difícil mantener

actualizadas todas las posibles entradas que pueden afectar a la aplicación.
Se rechaza toda entrada que se considere dañina.
Corregir los datos no válidos
Se trata de conseguir que los datos no válidos no afecten a la aplicación. Es

una técnica muy costosa y no se debería utilizar como la primera estrategia
a seguir. Se corrige la entrada de datos mediante la conversión o eliminación
de datos no válidos.
• Se aplicará la estrategia de “aceptar únicamente datos válidos” siempre que sea

posible técnicamente.
Si se acepta como válido alguno de caracteres descritos como “a prevenir”, se

aplicará además la estrategia de corrección de datos.
• Cada parámetro debe ser chequeado con un formato estricto que especifique
exactamente qué entradas están permitidas.
DATOS A PREVENIR
Se deberán tener en consideración los siguientes caracteres:
! @ $ % ^ & * ( ) - _ + ‘ ∼ \ | [ ] { } ; : ` “ ? / , . > < =
Página: 14
Además, se deberá tener especial cuidado con los caracteres de control, como por
ejemplo: [NULL] [New Line] [Enter]
TIPOS DE FILTRADO A APLICAR
1. Filtrado de datos de entrada

2. Filtrado del proceso interno de datos
3. Filtrado de datos de salida
1. Filtrado de los Datos de Entrada
• Se deberán validar todas las entradas procedentes de fuentes no confiables.
En este apartado se presentan una serie de recomendaciones para la verificación de la

sintaxis y semántica de los parámetros de entrada.
Se deberá seguir el orden expuesto para las comprobaciones que se inserten en el

código de la aplicación.
Para cada parámetro de entrada se probarán los siguientes casos:
1. Datos Obligatorios
En ciertas ocasiones la aplicación exige al usuario proporcionar de forma obligatoria

ciertos datos para que se pueda resolver una petición.
La aplicación deberá estar preparada para el caso en que el usuario no proporcione la

información necesaria:
Se comprobará que el dato no está vacío.

Se definirán valores por defecto para los datos de entrada o se detectará la
ausencia de un parámetro obligatorio. En este último caso, se mostrará una
página o alerta en la que se le pida al usuario que rellene los campos obligatorios.
2. Longitud
Se comprobará la longitud de los datos de entrada.
• Se limitará la longitud de los campos al mínimo posible. Todo campo tendrá definido
una longitud máxima de caracteres a aceptar.
• La aplicación debe comprobar la longitud de los datos de entrada antes de

procesarlos.
Página: 15
3. Formato
• Se comprobará el formato del dato de entrada, y que se corresponde con el dato

esperado.
Por ejemplo, si el dato esperado es un entero, se verificará que el dato introducido

se corresponde con un número entero, y no con cualquier otro tipo de dato, como
puede ser una cadena. Se utilizarán expresiones regulares para comprobar que el
dato cumple con el formato esperado.
4. Rango
• Se verificará la semántica de cada dato de entrada y se realizarán validaciones de

ese dato, para evitar valores, que, aunque sean admisibles por el tipo de variable,
(un número negativo en un “integer”) no sean válidos por el valor semántico de la
variable.
Si no se hiciera esta comprobación se podrían introducir datos inconsistentes en la

aplicación.
5. Otros casos
- Se comprobará si se permiten valores NULL.

- Se comprobará si el parámetro es necesario o no.
- Se comprobará si se permiten duplicados.
- Se comprobará si el conjunto de caracteres está permitido.
- Se comprobará qué datos faltan o están incompletos.
2. Filtrado del Proceso Interno de Datos

Los datos introducidos correctamente pueden corromperse por errores del proceso o por
actos deliberados. Se deberán incorporar a los sistemas comprobaciones de filtrado o
validación para detectar dicha corrupción. El diseño de las aplicaciones debe asegurar
la implantación de mecanismos que minimicen el riesgo de los fallos del proceso con
pérdidas de integridad.
Los aspectos a considerar son:
La ubicación y uso en los programas de funciones ‘añadir’ y ‘borrar’ para cambiar

los datos.
Los procedimientos para evitar programas que se ejecuten en orden equivocado o

después del fallo de un proceso anterior.
El uso de programas correctos de recuperación de fallos para asegurar el proceso

adecuado de los datos.
Página: 16
3. Filtrado de los Datos de Salida

Se deberán validar los datos de salida de una aplicación para garantizar que el proceso
de la información ha sido correcto y apropiado a las circunstancias. La validación de
salidas deberá comprobar:
La verosimilitud de los datos de salida.
El suministro de suficiente información al lector o a un sistema de proceso

subsiguiente para poder determinar la exactitud, completitud, precisión y
clasificación de la información.
Todas las salidas, códigos de retorno y de error deberán ser verificados y tratados.
INFORMACIÓN SENSIBLE EN EL CÓDIGO FUENTE
• Se evitará la inclusión de información sensible dentro del código de la aplicación, como

pueden ser:
URL’s absolutas.
Direcciones IP.
Path’s de directorios de la aplicación.
Nombres de usuario.
Contraseñas.
Es común que en las aplicaciones web, el usuario pueda inspeccionar algunos

elementos de la aplicación:
El código HTML se puede examinar de manera trivial.

Muchas vulnerabilidades de seguridad permiten la visualización de código
fuente, en un principio no visible, de CGI’s, ASP’s, JSP’s, etc.
Información almacenada en cookies como pueden ser usuarios,
contraseñas,...
A continuación se detallan los motivos por los que evitar cada uno de los puntos
enumerados anteriormente.
URL’s absolutas, direcciones IP y Path’s
La inclusión en el código de este tipo de información puede facilitar a un atacante

información valiosa sobre la estructura de la aplicación, direcciones de
máquinas, sistemas utilizados por la aplicación, ubicaciones de archivos,...
Mediante el uso de URL’s relativas, se posibilita además la migración de la

aplicación sin tener que modificar el código fuente.
Página: 17
Nombres de usuario y contraseñas
La introducción de usuarios y contraseñas dentro del código fuente de la

aplicación puede comprometer la seguridad de la aplicación si un usuario
malicioso es capaz de visualizarla. Una vez obtenida la contraseña de una
aplicación, el acceso es sencillo. Además, es casi imposible identificar que las
contraseñas han sido comprometidas.
Este aspecto es crucial en aquellos sistemas que realizan accesos a terceras

aplicaciones, y necesitan autenticación, como puede ser el acceso a una base
de datos.
• Se vigilará la información contenida en los comentarios de código.
Se deben evitar aquellos comentarios dentro de páginas HTML o scripts de cliente que
puedan contener información privada o sensible.
INFORMACIÓN SENSIBLE EN PÁGINAS *SP
*SP: nomenclatura utilizada para identificar tanto páginas JSP como ASP.
• Se hará uso de ubicaciones centralizadas para el almacenamiento de información

sensible (información sobre conexiones ODBC,..)
Dicha ubicación deberá:
Estar adecuadamente protegida.

Ser auditable.
Desde el punto de vista de seguridad, se han descubierto múltiples vulnerabilidades que

han permitido la visualización del código fuente de una página ASP o JSP, permitiendo
la visualización de credenciales e información sensible en un principio oculta a los
usuarios.
SEGURIDAD DE ARCHIVOS
• El modo de acceso desde una aplicación web a cualquier archivo se realizará con
los mínimos privilegios necesarios para la tarea prevista.
Cuando la aplicación necesite acceder en modo lectura a un archivo (ejemplo: archivo

de datos), se deberá especificar explícitamente que será de lectura. La mayoría de los
Página: 18
lenguajes de programación permiten especificar el modo de acceso al archivo (lectura,

escritura, añadir,...)
• Nunca se aceptarán nombres de archivos directamente de un formulario HTML.
Si se aceptaran nombres de archivos desde un formulario, podrían utilizarse para

solicitar a la aplicación archivos no autorizados. Se recomienda el uso de un índice que
identifique al archivo entre los archivos disponibles en una tabla en el servidor web. De
este modo el servidor sólo enviará al usuario los archivos que estén incluidos en dicha
tabla. Además, se deberá verificar que el cliente tiene los permisos necesarios sobre el
archivo que solicita.
• La aplicación no permitirá subir archivos al entorno de producción.
En el caso de que la aplicación requiera de esta funcionalidad, su uso tendrá que ser
autorizado por la Unidad de Seguridad de Información y Prevención del Fraude.
NORMALIZACIÓN DE PATH’S
• Para el acceso a ubicaciones de la aplicación web, se hará uso de las funciones que
provee el lenguaje de programación de normalización de path’s.
• Se eliminará además cualquier tipo de cadenas como "..”, “/", caracteres NULL o
cualquier variante Unicode en las rutas de acceso.
Mediante la normalización de los path’s, se evitará el acceso a ubicaciones no previstas

por la aplicación.
CARACTERES HTML Y CARACTERES ESPECIALES COMO ENTRADA DE

DATOS
• Se eliminarán o normalizarán los caracteres especiales y tags HTML en las entradas

de usuario.
El uso de tags HTML como entrada de datos, además de afectar a la seguridad del
servidor (utilizadas de cierta manera, pueden permitir visualizar código sensible de la
aplicación web), afecta a la seguridad de los usuarios de la aplicación web (ataques de
Cross-Site Scripting). Si se permite entradas de datos HTML, probablemente también
se está permitiendo el uso de tags Javascript, DHTML, JSP, etc.
Los caracteres especiales pueden ser interpretados de diversas formas por cada
aplicación, produciendo un comportamiento inesperado o no previsto. Se conocen
muchos tipos de ataques que aprovechan este tipo de comportamientos (poisoned
NULL, SQL injection,...)
Página: 19
USO DEL CAMPO REFERER
• El campo “referer” nunca se utilizará para propósitos de autenticación.
El campo “referer” se envía con la petición del cliente, para conocer de dónde obtuvo el
cliente la URI. Aparenta un método conveniente para determinar que el usuario ha
seguido un camino desde la aplicación o ha sido redirigido a través de un dominio de
confianza, pero el campo “referer” es implementado por el navegador, y por lo tanto es
modificable por el usuario.
USO DE POST
• Se optará por el uso del método POST para el envío de información.
• Se prohíbe el uso del método GET en solicitudes de datos privados o sensibles,

especialmente contraseñas.
Los motivos se explican a continuación:
Los formularios HTML pueden ser enviados mediante la utilización de dos métodos: GET
o POST.
El método GET envía toda la información como parte de la URL, y es visible en el

navegador web.
Otro problema adicional, y quizás más importante al uso de GET es, que la información
enviada se almacena en diferentes sitios, y por lo tanto es visible por terceros:
Registros del servidor.

En la caché y en el historial del navegador.
En los registros de los servidores proxy.
El método POST no envía la información como parte de la URL, sino como un flujo de
datos. La información no es almacenada en los registros de los sistemas por los que
pasa la petición (servidores web, de aplicaciones, proxies), y por lo tanto no es visible
por terceros.
OPCIÓN MULTILINGÜE
• Se tendrá especial cuidado con el soporte de los idiomas, sobre todo mediante una
validación de datos especialmente restringida.
La utilización de diferentes conjuntos de caracteres implica que una cadena lógica puede
tener múltiples representaciones, y dificulta sobremanera la validación de datos. Se han
Página: 20
producido una gran cantidad de vulnerabilidades de seguridad en las aplicaciones web

debido al uso de distintos lenguajes.
COMANDOS DE SISTEMA
• No se permitirá el uso de comandos de sistema directamente desde la aplicación.
El uso de comandos desde la aplicación puede repercutir de forma grave sobre la

seguridad tanto del sistema como de la infraestructura adyacente.
• Si la aplicación necesita hacer uso de comandos del sistema, se realizarán a través

de llamadas a las API’s que proporciona el lenguaje de programación.
Casi cualquier lenguaje de programación permite el uso de comandos de sistema a

través de API’s.
AUTENTICACIÓN
La autenticación es uno de los aspectos más importantes de la seguridad de una

aplicación. Existen diversas técnicas de autenticación utilizadas en aplicaciones Web.
Para el caso específico del Banco se deberán tener en cuenta los siguientes:
Basada en Formularios.
Basada en Certificados Digitales (en este caso deberá pasar por la revisión
previa del personal de Seguridad de la Información)
• Se deberán considerar las limitaciones del navegador de los clientes a la hora de

establecer un mecanismo de autenticación en la aplicación Web.
• La aplicación Web deberá pedir la autenticación del usuario cuando se soliciten

recursos privados, aunque dicho usuario no haya entrado en la aplicación por su
página inicial, sino que haya pedido directamente una URL privada.
• Se establecerá un mecanismo que no permita más de una sesión concurrente por

usuario (doble sesión).
• Se establecerá un mecanismo que permita finalizar la sesión de usuario.
La autenticación HTTP adolece de ciertos aspectos de seguridad como es el caso de

que no existe un mecanismo disponible en el servidor que permita finalizar la conexión
(eliminar las credenciales almacenadas del usuario). Este aspecto se deberá tener en
cuenta principalmente en las aplicaciones que hagan uso de equipos compartidos.
Página: 21
AUTENTICACIÓN BASADA EN FORMULARIOS
• Se delegará la identificación y autenticación en los mecanismos establecidos por la

infraestructura de seguridad de Banco.
• Los formularios de autenticación serán remitidos utilizando peticiones POST.
Las peticiones GET son visibles en el historial de navegación, por lo que es posible su
visualización por cualquier persona que tenga acceso al equipo.
Se recuerda que los formularios enviados a través de GET o POST envían el

identificador y la contraseña en claro, excepto si se hace uso del protocolo SSL o TLS.
Para el uso de SSL deberá validarse primero con personal de Seguridad de la
Información.
Si se hace uso de la autenticación en los formularios, será necesario implantar las

protecciones necesarias contra los ataques comunes del protocolo y las contraseñas se
deberán almacenar en un repositorio cifrado.
Se deberá prestar atención con el completado automático de los campos del formulario.
• Los campos de contraseñas nunca deben ser completados automáticamente.
AUTENTICACIÓN SOBRE HTTP
• Se deberá tener en cuenta el tipo de cliente utilizado, y si se especifica un único

método de acceso, que únicamente sea posible a través de este método definido.
• Se optará por el protocolo HTTP 1.1 siempre que no afecte al acceso de los clientes.
Página: 22

Mejores Prácticas en Aplicaciones Web Banco

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Mejores Prácticas en Aplicaciones Web Banco

Enviado por

Direitos autorais:

Formatos disponíveis

Seguridad de la Información y

Prevención del Fraude

Los destinatarios de este documento son los siguientes:

Unidad de Gestión de la Demanda - Diseño y Desarrollo de Software

INTEGRACIÓN EN LA METODOLOGÍA INTERNA DEL BANCO

Figura 1 Ciclo de vida del desarrollo de aplicaciones.

(*) En estas fases usar la herramienta de escaneo de vulnerabilidades AppScan

Tradicionalmente, las aplicaciones se han desarrollado con diferentes arquitecturas. La

Capa de Presentación: Esta capa es responsable de la presentación de la información

Capa de Aplicación o de negocio: Es el motor de la aplicación Web. Se encarga de

• Las credenciales de los usuarios y el repositorio de datos serán almacenados en un

• La aplicación deberá diseñarse de forma modular, de manera que haya una

El objetivo es hacer que la aplicación se pueda mantener fácilmente y que sea

• La exposición a redes públicas requerirá medidas de seguridad más exigentes que

Es muy importante que las aplicaciones de Internet estén separadas de las

• La funcionalidad de la aplicación estará claramente separada en directorios según

El motivo es establecer controles de seguridad mediante ACL’s o mecanismos

• Los servidores se ejecutarán sobre un sistema securizado donde únicamente se

(no aplica para desarrollo de software implementado como servicios externos –

• No deben existir enlaces simbólicos en el servidor Web.

El uso de enlaces simbólicos constituye una vulnerabilidad porque se podrían seguir

ACCESO REMOTO DE ADMINISTRACIÓN

• Se recomienda no habilitar el acceso mediante administración remota a la aplicación,

En el caso de que sea necesario, se utilizarán mecanismos de comunicación y

USO DE DISTINTAS INTERFACES

• La interfaz de administración no debe ser accesible por los usuarios de la aplicación.

Se recomienda el diseño de distintas interfaces de acceso, si fuese necesario un

• Se deberán identificar y controlar todos los errores que se pueden producir en la

• Los mensajes de error no mostrarán información innecesaria o confidencial:

Códigos de error relativos al funcionamiento interno de la aplicación.

En el entorno de desarrollo esta información resulta útil para labores de depuración

• Los Servlets, JSPs, CGI’s de la aplicación no utilizarán la salida estándar para

Se utilizarán registros de auditoría desde el principio del desarrollo.

• Se deberá identificar el tipo de tratamiento de interacción con el usuario ante un error

Mensaje descriptivo del error: Este mensaje ayudará al usuario a determinar y

El inconveniente de este tipo de mensajes es que ofrecen pistas a un posible

Por ejemplo, si se devuelve un mensaje de error distinto cuando el usuario

Mensaje genérico: Este mensaje indica al usuario que se ha producido un error

Mensaje falso: Este mensaje trata de confundir a un posible atacante cuando

Sin mensaje: En este caso no se devuelve confirmación al usuario sobre si se

Se deberán utilizar mensajes descriptivos que no ofrezcan información confidencial

• Se deberán capturar y controlar todas las excepciones que se puedan producir en la

La no captura de excepciones puede producir fallos de disponibilidad, fallos en el

• Se deberá realizar un tratamiento de los códigos de retorno para comprobar la causa

Se deberán tener especial cuidado entre otras con las operaciones de

El registro de eventos es un aspecto esencial en la seguridad.

Toda aplicación deberá tener establecido un mecanismo de registro de eventos

Es importante la generación de registros de acceso y de transacción debido a que:

Es la única forma de detectar comportamientos extraños en la aplicación.

La no correcta habilitación o diseño de los mecanismos de registro de eventos en una

ESPECIFICACIÓN DE LAS TRAZAS DE REGISTRO

• Las trazas de auditoría de la aplicación deberán permitir reconstruir por completo

• Todos los registros de eventos deben estar sincronizados con un “TimeServer”,

(en el caso de desarrollos prestados como servicios externos, no se requiere un

• Información de cada traza:

• Información sobre eventos:

Arranque, inicialización y parada de la aplicación.

• Para el caso de aplicaciones desarrolladas por terceros1 implementadas en servicios

El objetivo es evitar que se colapse el sistema si los archivos de log crecen

Los registros no deben permitir modificar la información contenida en él, únicamente

PROTECCIÓN DE LOS REGISTROS

• Se limitará el acceso a los eventos registrados.

Sólo el administrador de la aplicación deberá tener permiso de lectura sobre el

• No se facilitará información confidencial que pueda repercutir en la seguridad de la