UNIVERSIDAD YACAMBÚ
VICE-RECTORADO DE ESTUDIOS VIRTUALES
CATEDRA: SISTEMAS DE INFORMACIÓN GERENCIAL
PROF: YAROS LÓPEZ
Seguridad para Aplicaciones Web
Realizado por:
Alexis
Velazco
Arelis Velazco
Marcos Ventre
Caracas, Agosto 2006
INTRODUCCIÓN
Son muchas las
organizaciones que no se atreven a dar el paso hacia la red, en su mayor parte
debido al desconocimiento de éste, tanto de la forma de operar en él como de
los procedimientos para instalarse. Muchos de los temores que enfrentan las
empresas, organismos, etc. al momento de pensar en realizar un Sistema vía Web
es el de la seguridad de los datos y las transacciones que realizará ese
sistema, en este presente trabajo se pretende de una manera resumida dar a
conocer algunos puntos importante a tomar en cuanta al momento de realizar un
desarrollo vía Web
Las aplicaciones Web presentan un conjunto complejo de aspectos de
seguridad que deben ser cubiertos por los arquitectos, diseñadores y
desarrolladores. Las aplicaciones más seguras y resistentes al hacking son aquellas en las cuales la seguridad se tuvo en
cuenta durante todo su proceso de desarrollo
CONSIDERACIONES DE DISEÑO PARA APLICACIONES WEB
Las aplicaciones Web presentan a los diseñadores y desarrolladores
muchos desafíos. La naturaleza del protocolo HTTP como un protocolo sin estado
implica que el seguimiento de la sesión para cada usuario pasa a ser
responsabilidad de la aplicación. Además, la aplicación debe permitir
identificar a un usuario usando algún mecanismo de autenticación. Dado que
todas las subsecuentes decisiones de autorización estarán basadas en la
identidad del usuario, es esencial que el proceso de autenticación sea seguro y
que el mecanismo de manejo de sesión del usuario autenticado esté igualmente
bien protegido. El diseño de los mecanismos de autenticación segura y
administración de sesión son solo un par de consideraciones con las que los
diseñadores y desarrolladores de aplicaciones Web tendrán que lidiar. Otro
desafío se presenta en el paso de datos de entrada y salida a través de redes
públicas. Prevenir la manipulación de parámetros y el acceso a datos sensibles
son otros de los aspectos a dar prioridad.
Algunos de los problemas a tratar con prácticas de diseño seguro se
muestran en la siguiente figura:
Consideraciones en
un diseño seguro para una aplicación Web.
CONSIDERACIONES EN UN DISEÑO SEGURO PARA UNA APLICACIÓN WEB
Las consideraciones en
el diseño se pueden organizar por categorías considerando las vulnerabilidades
de la aplicación. La experiencia muestra que un diseño pobre en estas áreas, en
particular, conducen a vulnerabilidades de seguridad. La Tabla 1 lista las
categorías de vulnerabilidades y para cada una resalta los problemas
potenciales que pueden darse debido a un mal diseño.
|
Categoría de vulnerabilidad |
Problema Potencial |
|
Validación de entrada |
Ataque ejecutado mediante inserción de
cadenas de texto maliciosas en Query Strings, campos de formularios, cookies,
y cabeceras HTTP. Esto incluye ejecución de comandos, cross-site scripting (XSS), SQL injection, y ataques para desborde de buffer (buffer overflow attacks). |
|
Autenticación |
Suplantación de identidad, password cracking, elevación de privilegios y acceso no
autorizado. |
|
Autorización |
Acceso a datos
confidenciales o restringidos, ejecución de operaciones no autorizadas. |
|
Administración de configuración |
Acceso no
autorizado a interfaces de administración, alteración de datos de
configuración, acceso no autorizado a cuentas de usuario y perfiles de
cuentas de usuarios. |
|
Datos sensibles |
Acceso a
información confidencial |
|
Administración de sesiones |
Captura de identificadores de sesión |
|
Encriptamiento |
Acceso a datos
confidenciales o credenciales de cuenta o a ambos. |
|
Manipulación de parámetros |
Ejecución de
comandos, elevación de privilegios, Denegación de servicios, etc. |
|
Manejo de Excepciones |
Denegación de
servicios y acceso a información de detalle en el nivel de sistema. |
|
Auditoria y registro de actividades |
Falla para
registro de pruebas de intrusión, acciones realizadas por el intruso y
dificultades en diagnosticar problemas. |
Tabla 1.
Vulnerabilidades en Aplicaciones Web y problemas potenciales debido a un mal
diseño.
CONSIDERACIONES DE DESPLIEGUE
Durante la fase de diseño, se deberían revisar los procedimientos y
políticas de seguridad corporativa junto con la infraestructura sobre la cual
será desplegada la aplicación. Frecuentemente, el entorno de destino no es
flexible, el diseño de la aplicación debe reflejar esas restricciones.
Compensaciones en el diseño se requieren algunas veces, por ejemplo, tener en
cuenta restricciones de protocolo o puerto, o topologías de despliegue
específicas. Identificar estas restricciones con anticipación en la fase de
diseño evita toparse con sorpresas posteriormente e involucra a los miembros de
los equipos de red e infraestructura para ayudarnos en el proceso.
Consideraciones de
despliegue.
POLÍTICAS Y PROCEDIMIENTOS DE SEGURIDAD
Las políticas de seguridad determinan que es lo que les está
permitido hacer a la aplicación y usuarios de aplicación. Más importante aún,
éstas definen restricciones que determinan que es lo que no puede hacer una
aplicación o usuario. Identificar y trabajar dentro del ámbito cubierto por las
políticas de seguridad corporativa mientras se diseña la aplicación asegura un
correcto despliegue.
Componentes de
infraestructura de red
Se debe familiarizar con la estructura
de red del entorno destino y los requerimientos de seguridad de la red en
términos de reglas de filtro, restricciones de puertos, protocolos soportados,
etc.
Identificar
como las políticas de los firewalls afectarían el diseño y despliegue de la
aplicación. Puede darse el caso de la existencia de firewalls delante del o los
servidores de base de datos. Estos pueden afectar los posibles puertos de
comunicación a usar y, por lo tanto, las opciones de autenticación desde el
servidor Web a los servidores de aplicaciones y de bases de datos. Por ejemplo
el modo de autenticación Windows requiere el uso de puertos adicionales.
Topologías de
despliegue
La topología de despliegue de la
aplicación y la necesidad de tener una capa de aplicación remota es uno de los
puntos clave a considerar e incorporar en el diseño. Si se tiene una capa de
aplicación remota, se debe tomar en cuenta como asegurar la red entre los
servidores para tratar las amenazas como escucha o alteración de datos, por lo
que se deben proporcionar mecanismos de protección y aseguramiento de
integridad de datos sensibles.
También es importante tener en cuenta los flujos de identidades e
identificar las cuentas que serán usadas para autenticación en la red cuando la
aplicación conecte a servidores remotos. Un enfoque común es el uso de una
cuenta lo menos privilegiada y el uso de una cuenta espejo o duplicada en el
servidor remoto con el mismo password. Otra alternativa es el uso de una cuenta
de dominio, la cual facilita la administración, pero con el costo adicional de
configurar el uso de la misma en toda la red. La presencia de un firewall o de
dominios separados sin relaciones de confianza algunas veces hace que la única
opción viable sea el uso de cuentas locales.
Intranet, Extranet e Internet
Cada uno de estos escenarios de aplicación presenta desafíos en su diseño.
Puntos a tener en cuenta pueden ser:
- ¿Cómo
fluirá la identidad de los llamadores por las múltiples capas de la
aplicación para poder obtener acceso a los recursos del back-end?
- ¿Dónde se realizará la autenticación?
MECANISMOS DE SEGURIDAD UTILIZADOS PARA
TRANSACCIONES VÍA WEB
Entre los sistemas de seguridad más utilizados
actualmente, encontramos los siguientes:
Servidores seguros: Un servidor seguro es
un procesador que permite que la información que viaja entre el Servidor y el
PC del usuario vaya "encriptada" y
"controlada" de forma que no pueda ser leída ni manipulada por
terceras personas.
Funcionamiento: Al conectarse a un
servidor seguro, éste le obliga a que se autentifique. La seguridad de estar en
un servidor seguro se obtiene mediante un certificado digital, el cual es expedido
por una compañía independiente, la cual está autorizada legalmente para
garantizar que un determinado servidor pertenece a una compañía determinada. A
través del certificado de seguridad el usuario obtiene la confirmación de que
está enviando la información al lugar correcto.
Incrementar la confidencialidad y la fiabilidad de las transacciones on-line y mantener en todo
momento la privacidad de los datos emitidos.
Este sistema de
protección criptográfica impide que los datos transmitidos puedan ser
reconocidos por un tercero ajeno a la transacción que logre infiltrarse
ilegalmente en la comunicación (como puede ser el caso de un hacker).
Pasarelas de Pagos: Las pasarelas de pago
son plataformas que realizan la función de procesamiento de tarjetas de crédito
desde internet a las redes privadas de los sistemas
VISA, Mastercard, American
Express, etc.
Las pasarelas de pago, generalmente conocidas como aplicaciones TPV (Terminal
Punto de Venta) virtual, permiten que los clientes puedan realizar una compra
utilizando una tarjeta de crédito y validando la operación de forma automática
y en línea.
Funcionamiento:
La operación de pago a través de una TPV consta de las siguientes fases:
·
El cliente utiliza una aplicación de comercio electrónico para
elegir los artículos que desea adquirir; la aplicación calcula el importe total
de la compra.
·
Cuando el cliente decide pagar, la aplicación de comercio
electrónico le redirige al servidor seguro del banco y le indica al TPV la
cantidad total a cobrar para que procese el pedido.
·
El cliente introduce el número de su tarjeta de crédito en un
formulario del servidor seguro del banco (los datos viajan debidamente encriptados).
·
El banco realiza una comprobación (en segundos) de la validez de la
tarjeta de crédito y de la existencia de fondos. Si la respuesta es afirmativa,
se realiza el cobro ingresando el dinero en la cuenta bancaria del vendedor.
·
El servidor seguro del banco redirige al cliente de vuelta a la
aplicación de comercio electrónico indicando si la operación se ha realizado o
no con éxito.
La función básica de las paralelas de pago es evitar que la información sobre
la tarjeta de crédito del comprador llegue directamente al vendedor, siendo
utilizada únicamente por la entidad bancaria. El vendedor únicamente recibe una
notificación informándole de si el pago ha sido hecho efectivo o no.
Este sistema de pago ofrece diversas ventajas, tanto para los compradores como
para los vendedores.
- Para el comprador:
- El
pago se realiza directamente en los servidores de cada banco.
- El
número de la tarjeta viaja encriptado, con lo
cual, el vendedor nunca llega a saber cual es el número de la tarjeta de
crédito del cliente.
- El
vendedor debe tener una cuenta en un banco donde consten sus datos
auténticos. Esto elimina en la práctica las posibilidades de ventas
fraudulentas.
- El
cliente puede elegir entre varias tarjetas de crédito para efectuar el
pago.
- Para el vendedor:
- Disponer de la TPV de un
banco significa seguridad total para sus clientes.
- El cobro se ingresa al
instante.
- El banco verifica que la
tarjeta de crédito del comprador sea válida y de que el cliente tenga
fondos suficientes.
- El sistema permite cobrar a
clientes desde cualquier lugar del mundo.
El sistema TPV también conlleva ciertas desventajas:
·
Las comisiones por este sistema de cobro son muy altas, alrededor
de un 4% del importe total de la operación, a diferencia del 2% que se carga
por los pagos realizados con la tarjeta en tiendas físicas.
·
Otro inconveniente que pueden encontrar los comerciantes que
utilicen este sistema es la posibilidad de reclamaciones a Visa u otra entidad
emisora por parte de compradores insatisfechos o con mala fe. Por ello, es
conveniente conservar toda la información posible que pruebe el envío real de
la mercancía vendida (por ejemplo, los resguardos de las agencias de
transporte).
Protocolos de seguridad: Existen dos protocolos
estándar de seguridad: el SET y el SSL, sistemas que encriptan
nuestros datos para que nadie pueda acceder a ellos.
El SET, es un conjunto de normas de seguridad que adjunta un certificado al
pago que se realiza mediante tarjeta de crédito. Mientras que, el SSL (más
conocido y más utilizado), tiene como función principal cifrar el número de las
tarjetas de crédito antes de que el mismo sea enviado.
Protocolo SET (Secure Electronic
Transaction)
Este
protocolo fue diseñado con la intención de asegurar y autenticar la identidad
de las personas que participan las transacciones efectuadas a través de
cualquier red en línea.
Fue desarrollado por
iniciativa de Visa y Mastercard, y con la
participación de diversas empresas como Microsoft, IBM, Netscape,
SAIC, GTE, RSA, VeriSign y otras empresas líderes en
tecnología.
El objetivo primordial de SET es mantener la confidencialidad de la información
intercambiada en una transacción, así como garantizar la integridad del mensaje
y la identidad de los participantes, con objeto de evitar los fraudes,
falsificaciones y uso ilegitimo de tarjetas de crédito en Internet.
El SET proporciona los medios para que consumidores y comerciantes se
identifiquen entre ellos antes de la realización de la transacción. Su
funcionamiento se basa en la utilización de certificados digitales1 y de la encriptación de claves públicas para proteger
la información financiera de los participantes.
Es importante recalcar
que, para evitar cualquier clase de fraude, SET esta diseñado de tal forma que
la empresa, en cuyo favor se realiza la transacción, nunca podrá tener acceso
ni conocerá el número de la tarjeta usada por el consumidor.
El mecanismo de una
transacción realizada utilizando el SET es similar al de las transacciones
ordinarias, celebradas utilizando como medio de pago una tarjeta de crédito.
Una transacción SET se desarrolla de la siguiente manera:
1. El protocolo SET da
inicio en el momento en que el cliente decide adquirir un determinado artículo
o servicio.
2. El servidor del comerciante
realiza una descripción del pedido, con lo cual pone en marcha la aplicación
"cartera del cliente".
3. Se cifra y se transmite
la orden de pago. Se incluyen tanto los datos del pedido como las instrucciones
de pago.
4. Se envía la petición
del pago al banco del comerciante.
5. El banco descifra la
información recibida, verifica la identidad del comprador y del comerciante, y
comprueba la integridad de los datos. Si todo es correcto, envía una petición
de autorización de pago al banco emisor (banco del cliente).
6. El banco del emisor
verifica los datos y si todo es correcto autoriza la transacción.
7. Después, se envía al
comerciante un testigo de transferencia de fondos, el cual comprueba que todo
se ha desarrollado correctamente.
8. El software del cliente
prepara y envía a éste un recibo de la transacción. A continuación se completa
el procesamiento del pedido (envío de mercancías o suministro de servicios).
9. Realizada con éxito la
transacción, el comerciante genera una petición de transferencia a su banco
solicitando el abono en su cuenta del precio pactado.
10. Se hace el cargo en la
cuenta correspondiente a la tarjeta de crédito utilizada.
El SET aún no esta completamente implantado en Internet debido, en primer
lugar, a la necesidad de utilizar un software especial (tanto para compradores
como para comerciantes) cuya distribución y comercialización se está
desarrollando muy lentamente.
La segunda y más importante razón es que el funcionamiento del SET resulta
complejo y confuso para los usuarios.
Desde el punto de vista
de los especialistas, SET es un mecanismo que irá creciendo paulatinamente,
pero de momento seguirá coexistiendo con el protocolo SSL.
ii. Protocolo SSL (Secure
Sockets Layer):
Este protocolo fue diseñado en el año de 1994 por Netscape
con el objetivo de proteger el acceso de personas no autorizadas a determinada
información confidencial.
El protocolo SSL proporciona los servicios de cifrado de datos, autenticación
de servidores, integridad de mensajes y, en menor grado, la identificación del
cliente para conexiones TCP/IP (Transmission Control Protocol/ Internet Protocol).
El protocolo SSL proporciona un canal de comunicaciones entre los servidores y
los navegadores a través del cual, cifrando los datos intercambiados, las
partes pueden celebrar transacciones electrónicas con seguridad.
El SSL funciona de forma sencilla, se basa en la encriptación de los datos
mediante la utilización de una clave de sesión y la aplicación de una clave
pública (normalmente la RSA).
El funcionamiento del
protocolo SSL puede resumirse en 4 fases:
1. La denominada
"Fase Hola", momento en el cual el navegador y el servidor se deben
poner de acuerdo respecto a los algoritmos necesarios para mantener la
confidencialidad y la autenticación.
2. Una vez alcanzado el
acuerdo se inicia la "Fase de Autentificación", etapa en la cual el
servidor envía al navegador el certificado que contiene su clave pública,
solicitando al mismo tiempo el certificado del cliente.
3. Después, el cliente
envía al servidor una clave maestra, con la cual se genera la clave de sesión
que cifrará los datos que las partes intercambien a través del algoritmo de
cifrado acordado. La clave de sesión es remitida por el usuario debidamente
cifrada gracias a la utilización de la clave pública del servidor. Esta parte
del proceso se conoce como "Fase de Creación de Clave de Sesión".
4. Por último, en la
"Fase de Verificación" se comprueba tanto la autenticidad del
servidor y del usuario, como la seguridad del canal establecido. Concluida esta
última fase, se da inicio a una sesión segura entre las partes.
Si bien es cierto que ofrece un sistema seguro para el envío y cifrado de los
números de tarjetas de crédito, también lo es que carece de la capacidad para
proteger otros aspectos de la actividad comercial (verificar que la tarjeta sea
valida, autorizar la transacción con los bancos, etc.)
Otra desventaja es la protección parcial que concede, ya que garantiza la
integridad y confidencialidad de los datos únicamente durante el tránsito de
los mismos, pero no los protege una vez que los mismos son recibidos por el
servidor.
A pesar de estas deficiencias, el SSL es un protocolo seguro cuya utilización
es altamente recomendable para proteger las transacciones electrónicas.
Sin embargo, para lograr una óptima protección, lo mejor es utilizar tanto el
protocolo SSL como el protocolo SET, pues así se gozaría al mismo tiempo de la
seguridad proporcionada por ambos sistemas.
CERTIFICADOS DE SEGURIDAD PARA
APLICACIONES Y TRANSACCIONES VÍA WEB.
Certificado de Seguridad
Un Certificado
de Seguridad es un conjunto de documentos electrónicos emitidos por una entidad
certificadora, que permiten encriptar la información
transmitida e identificar a la fuente de dicha información. Para que el
certificado sea fiable, la entidad certificadora debe ser un organismo de
confianza capaz de certificar la procedencia de la información, que es lo que
en cierta medida proporciona la seguridad.
Para que un
Certificado de seguridad se encuentre operativo es necesario instalarlo en el
servidor donde se encuentre alojado el dominio que se desea proteger
Certificado de Servidor (Secure Socket Layer SSL).
Permiten incorporar el protocolo SSL en un
servidor Web. Gracias a este protocolo toda comunicación entre el cliente y el
servidor permanece segura, cifrando la información que se envían ambas partes.
El nivel de cifrado depende normalmente de las posibilidades del navegador del
usuario, por ejemplo un Explorer 6 con el "Paquete de cifrado de alto
nivel para Internet Explorer" permite sesiones cifradas a 128 bits. El
certificado de servidor posibilita la "Autenticación Fuerte", es
decir, que el servidor puede exigir certificados personales de navegación a los
usuarios para acceder a determinadas carpetas, lo que repercute en la seguridad
y en la comodidad por la ausencia de login y password para la identificación de
los usuarios.
Para establecer una comunicación segura utilizando SSL se tienen
que seguir una serie de pasos. Primero se debe hacer una solicitud de
seguridad. Después de haberla hecho, se deben establecer los parámetros que se
utilizarán para SSL. Esta parte se conoce como SSL Handshake.
Una vez se haya establecido una comunicación segura, se deben hacer verificaciones
periódicas para garantizar que la comunicación sigue siendo segura a medida que
se transmiten datos. Luego que la transacción ha sido completada, se termina
SSL.
Solicitud de SSL: Antes de que se establezca SSL, se debe hacer una
solicitud. Típicamente esto implica un cliente haciendo una solicitud de un URL
a un servidor que soporte SSL. SSL acepta solicitudes por un puerto diferente
al utilizado normalmente para ese servicio.
Una vez se ha hecho la
solicitud, el cliente y el servidor empiezan a negociar la conexión SSL, es
decir, hacen el SSL Handshake.
SSL Handshake: Durante el hanshake se
cumplen varios propósitos. Se hace autenticación del servidor y opcionalmente
del cliente, se determina que algoritmos de criptografía serán utilizados y se genera
una llave secreta para ser utilizada durante el intercambio de mensajes
subsiguientes durante la comunicación SSL.
