Diapositiva 1

Seguridad de aplicaciones online y bases de datos
Juan Ramón Bermejo Higuera
Presentación de la asignatura
+ TEMA 1
Seguridad en aplicaciones online y BD
Juan Ramón Bermejo Higuera
Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 2

Contenido asignatura:
1. Arquitectura de las aplicaciones y bases de

datos
2. Seguridad de las aplicaciones online
3. Seguridad de los servicios web
4. Seguridad en sistemas gestores de bases de

datos

Tema 1. Arquitectura de las aplicaciones web y
BD (3 semanas)
 Introducción. Problemas de seguridad de las aplicaciones

 Arquitecturas y tecnologías de desarrollo de las aplicaciones
web
 Arquitecturas de almacenes de datos
 Problemas de seguridad en las aplicaciones web
 Seguridad en el cliente, navegadores web, concepto de
sandbox
 Seguridad en los servidores de aplicaciones y de bases de
datos
 Seguridad en la comunicación
 Seguridad física y del personal
 Seguridad en la aplicación. Actividades de seguridad en el
SSDLC
 Seguridad en la fase de despliegue y de producción online

Tema 1: Arquitectura de las aplicaciones y bases de
datos
Aplicaciones web y
bases de datos:
Vulnerabilidades
Ataques
Arquitecturas Navegadores
Problemas Arquitecturas web
de
inherentes a las de Almacenes
Aplicaciones Servidores de
aplicaciones de datos
web aplicaciones
web
Servidores de
El protocolo http Bases de datos
El concepto de n-CAPAS SERVICIOS
Comunicación
W EB 2.0 XML LDAP SGBD,s
SANBOX MVC W EB

Tema 1. Arquitectura de las aplicaciones web y
BD
ACTIVIDADES
 Seguridad en aplicaciones RIA-AJAX (OB)
 TEST

Tema 2. Seguridad de las aplicaciones online (5 semanas)
 Política de seguridad. Principios de seguridad

 Estándares de seguridad de aplicaciones
 Vulnerabilidades de seguridad. OWASP TOP TEN, SANS TOP 25
 Vulnerabilidades de seguridad en aplicaciones web. Análisis y
características
 Protocolo http: problemas
 Control de acceso. Aut-Sesiones-Auth
 Evaluación de la seguridad de las aplicaciones web
 Seguridad online

Tema 2. Seguridad de las aplicaciones online
POLÍTICA DE
SEGURIDAD
SGSI
ESTÁNDARES DE
SEGURIDAD
PROBLEMAS DE ANÁLISIS Y TEST DE

SEGURIDAD SEGURIDAD ONLINE:
PROTOCOLO HTTP SEGRUIDAD
Y VULNERABILIDES GESTION DE SESSIONES DE LAS APLICACIONES WEB
EN APLICACIONES AUTENTICACION Protección
WEB AUTORIIZACIÓN ANÁLISIS ESTÁTICO Monitorización
AMENAZAS Y
ANÁLISIS DINÁMICO
ATAQUES Auditoría
ANÁLISIS HÍBRIDO
Backups-Recuperación
Respuesta ante incidentes
8
Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera
Tema 2. Seguridad de las aplicaciones online
ACTIVIDADES
 Test de penetración de la aplicación BADSTORE (OB)
 Instalar y configurar un firewall de aplicaciones web open source:

MODSECURITY (OB)
 TEST


Tema 3. Seguridad de los servicios web (4 semanas)
 Introducción a la seguridad de los servicios web
 Requisitos, elementos y tecnologías de la seguridad de los servicios

web
 Evaluación de la seguridad de los servicios web
 Protección online. Firewalls XML

Tema 3. Seguridad de los servicios web
SERVICIOS WEB:
Arquitectura
Dimensiones seguridad
Requisitos de seguridad
Amenazas y riesgos
FUNCIONES DE
SEGURIDAD SEGURIDAD ONLINE:
TEST
Autenticación Monitorización y auditoría
Evaluación de la
Gestión de identidad y relación seguridad SW Disponibilidad Seguridad
de confianza servicio
Autorización y control de descubrimiento
acceso Protección online:
Confidencialidad e integridad GATEWAYS XML
Firewalls XML

Tema 3. Seguridad de los servicios web
ACTIVIDADES
 Configurar la seguridad de servicios web (OB)
 Foro: seguridad de servicios web (OB)
 TEST

Tema 4. Seguridad en sistemas gestores de bases de
datos (3 semanas)
 Amenazas y vulnerabilidades
 Elementos de seguridad comunes
 Requisitos de seguridad comunes
 Seguridad online
 Seguridad en LDAP

Tema 4. Seguridad en sistemas gestores bases datos
SEGURIDAD EN SGBD,s - LDAP:
Amenazas
vulnerabilidades
ELEMENTOS DE REQUISITOS DE
SEGURIDAD COMUNES SEGURIDAD COMUNES
SEGURIDAD ONLINE
Autenticación Diseño de la seguridad y configuración Auditoría
Replicación
Autorización Control de acceso Clustering
Backup y recuperación
Confidencialidad e integridad Seguridad del entorno (capas
aplicación)
Protección Online:
Disponibilidad Seguridad perimetral Firewalls DB
Continuidad

Tema 4. Seguridad en sistemas gestores de bases de
datos
ACTIVIDADES
 Trabajo: Instalar y configurar un firewall de base de datos (Re)
 TEST (OB)

Secuencia de actividades
Ob Trabajo: Seguridad en AJAX
Ob Trabajo: Test de penetración BADSTORE
Ob Trabajo: Instalar y conf firewall APP WEB
Ob Trabajo: Configurar Seg SW.
Ob Foro:Seguridad en SW…
Re Trabajo: Instalar y conf Firewall SGBD

Actividades: recomendaciones
 CONTENIDOS. Para la realización de los trabajos se deben consultar varias
fuentes para después contrastarlas, sintetizarlas y generar un trabajo y opinión
personalizados.
 ESTRUCTURA DEL DOCUMENTO. Debe ser planificada previamente y tener

un índice, apartado de conclusiones y de referencias al final.
 PRESENTACIÓN acorde con la categoría del curso.
 EXTENSIÓN variable dependiendo de la actividad.
 REFERENCIAS. Se deben especificar en un apartado al final todas las fuentes

consultadas, URL,s de INTERNET, papers, artículos o libros especificando
todos los datos de la publicación disponibles.
 Recalcar la obligatoriedad de la especificación de las REFERENCIAS

consultadas.

Pilares
 SGSI (ISO 27001, ENS…)
 Política de seguridad
 SSDLC
 Monitorización continua  análisis y gestión

dinámica del riesgo

SGSI  Risk Framework NIST 800-53-r4 Monitorización Continua
• S'tarting •
•
• •
• •
Step 1
RIISK
t MANAGEMENT
+
Step 4

Política de Seguridad (I):

Bien definida, implantada, gestionada por procesos.
 Normas clave que estarán en cualquier política

 Normas de uso aceptable de equipos y servicios.
 Normas de acceso remoto.
 Normas de protección de la información.
 Normas sobre la seguridad perimetral.
 Normas básicas de seguridad física y del personal.
 Normas sobre respuestas a incidentes.
 Encriptación aceptable.

Política de Seguridad (II):

Bien definida e implantada y gestionada por
procesos.
 Proveedores de conexión a Internet aceptables.

 Proveedores de software aceptables.
 Seguridad en las adquisiciones.
 Auditoria.
 Valoración de riesgos
 Contraseñas aceptables.
 Seguridad de portátiles.
 Seguridad de equipos en las zonas DMZ

Política de Seguridad (III):

Bien definida e implantada y gestionada por
procesos.
 Redes Privadas Virtuales.

 Seguridad de los servidores.
 Laboratorios de prueba de problemas de
seguridad.
 Anti-virus.
 Seguridad de encaminadores y conmutadores
 Comunicaciones wireless
 Cortafuegos aceptables.

Ciclo de vida de desarrollo seguro de

software (SSDLC) (McGraw)

SSDLC: Mejores prácticas o touchpoints en

orden de eficacia e importancia:
1. Revisión de código
2. Análisis de riesgo arquitectónico
3. Pruebas de penetración
4. Pruebas de seguridad basados en riesgo
5. Casos de abuso
6. Requisitos de Seguridad
7. Operaciones de Seguridad
8. Revisión externa

Objetivos seguridad sistemas TIC (I):

 Identificar
 Autenticar
 Controlar el acceso a la información
 Proporcionar confidencialidad

Objetivos seguridad sistemas TIC (II):
 Proporcionar integridad a la información
 Mantener la disponibilidad
 No repudio.
 Trazabilidad, quién hizo qué y en qué

momento.

Tema 1: Arquitectura APP y BD
 Introducción. Problemas de seguridad de las

aplicaciones
 Arquitecturas y tecnologías de desarrollo de las

aplicaciones web
 Arquitectura servicios web
 Arquitecturas de almacenes de datos

Tema 1: Arquitectura de las aplicaciones y bases de
datos
Aplicaciones web y
bases de datos:
Vulnerabilidades
Ataques
Problemas
Arquitecturas Navegadores web
inherentes a Arquitecturas
las de Servidores de
de Almacenes aplicaciones
aplicaciones Aplicaciones
de datos
web web Servidores de
Bases de datos
El protocolo Comunicación
http
n-CAPAS SERVICIOS
W EB 2.0 XML LDAP SGBD,s
El concepto de MVC W EB
SANBOX

Problemas de seguridad
 Problemas funcionales de seguridad como autorización,

control de accesos, etc. (diseño)
 Vulnerabilidades de seguridad en el código.

(implementación)
 Vulnerabilidades de seguridad debidos a fallos de

configuración. Servidores, comunicaciones…(operación)
 Problemas de seguridad debidos a la gestión de la

seguridad una vez desplegada la aplicación. (operación)

Fuente: Graff M.

https://www.owasp.org/index.php/Top_10_2013
OWASP TOP TEN 2013

A1-Injection
A2-Broken Authentication and Session Management
A3-Cross-Site Scripting (XSS)
A4-Insecure Direct Object References
A5-Security Misconfiguration
A6-Sensitive Data Exposure
A7-Missing Function Level Access Control
A8-Cross-Site Request Forgery (CSRF)
A9-Using Components with Known Vulnerabilities
A10-Unvalidated Redirects and Forwards

Vulnerabilities trend [HP-report, 2102]

Vulnerability disclosures [IBM XFORCE 2015 1Q]

SCADA Vulnerabilities trend [HP-report, 2102]

MOBILE Vulnerabilities trend [HP-report, 2102]
Top 10 mobile vulnerabilities in 2012

Unauthorized access 18%
Cross site scripting 15%
Insecure session handling 11%
Cookie handling vulnerabilities 9%
Improper encryption 9%
Poor logging practices 8%
Autocomplete on sensitive form fields 6%
Cleartext credentials 6%
Poor error messages 6%

Ataques
 Robo de credenciales
 Ingeniería social
 Vulnerabilidades en el código
 Fallos en la configuración
 Fallos en los protocolos
 Information Leakage
 Virus, troyanos, rootkits
 Denegación de servicio
 Botnets
 Hombre en medio: suplantación

Types of targeted data by [Trustwave, 2013]
Types of targeted data by attacks
Customer Records (Payment Card Data, PII,

96%
Email Addresses)
Confidential Information & Intellectual
2%
Property
Electronic Protected Health Information
1%
(ePHI)
Business Financial Account Numbers 1%

Types of targeted data by [IBM X-FORCE 20151Q]

Localizaciones ataques [Trustwave, 2013]

Métodos de entrada [Trustwave, 2013]
Attack ENTRY methods

Remote Access 47%
SQL Injection 26%
Unknown 18%
Remote code execution 3%
Client-side-attack 2%
Remote file inclusion 2%
Authorization flaw 1%
Phisical theft 1%

Métodos de entrada [Trustwave, 2013]
Attack ENTRY methods

Remote Access 47%
SQL Injection 26%
Unknown 18%
Remote code execution 3%
Client-side-attack 2%
Remote file inclusion 2%
Authorization flaw 1%
Phisical theft 1%

TOP 10 WHID attack methods [Trustwave, 2013]
TOP 10 WHID Attack methods
Unknown 46%
Denial of service 29%
Sql injection 11%
Stolen credentials 3%
Brute force 3%
Banking trojan 2%
Cross site scripting 1%
Predictable resource location 1%
DNS hijacking 1%
Cross site request forgery 1%

Common attacks [IBM X-FORCE 2015 1Q]

Seguridad en aplicaciones online
Estándares de seguridad en aplicaciones online
• OWASP
• Top 10
• Cheat Sheets
• ZAP Proxy
• SAMM
• Development Guide
• Testing Guide
• ModSecurity Ruleset (FW)
• Benchmark Project
• Appsensor
Seguridad de aplicaciones online - Juan Ramón Bermejo Higuera 42

• WASC
• Distributed Open Proxy Honeypots

• Script Mapping
• Static Analysis Technologies Evaluation Criteria
The Web Security Glossary
• Web Application Firewall Evaluation Criteria
• Web Application Security Scanner
Evaluation Criteria
• Web Application Security Statistics
• Web Hacking Incidents Database
• WASC Threat Classification

• SANS
• Top 25 vulnerabilidades
https://www.sans.org/top25-software-errors/
• Recursos
• https://www.sans.org/security-resources/

• MITRE
• MITRE CWE
• MITRE CVE
• MITRE CAPEC
• MITRE OVAL
https://oval.mitre.org/repository/data/search/in
dex
• OSVDB Open Sourced Vulnerability Database

http://www.osvdb.org/
• NIST
• Guías seguridad SO, servidores web, …
• Ciclo de vida SSDLC SP 800 53 rev4
• Monitorización contínua SP 800 137
• SAMATE  benchmarks evaluación de
herramientas (SRD)
• NVD https://nvd.nist.gov/
• SCAP
• NSA
• Guías de seguridad SGBD,s, LDAP,
navegadores
• https://www.iad.gov/iad/library/ia-
guidance/security-configuration/?page=1
SCAP (Secure Content Automation Protocol
• Common Vulnerabilities and Exposures (siglas CVE): Es una lista de información de seguridad sobre
vulnerabilidades con el objetivo de proveer una nomenclatura común para el conocimiento público de este
tipo de problemas. Antes de publicar una vulnerabilidad o exposición pasa por ciertas etapas previas por lo
que la lista no contiene vulnerabilidades recién descubiertas.
• Common Configuration Enumeration (siglas CCE).- Es similar a CVE pero contienen vulnerabilidades de
seguridad e incosistencias de interfaces encontradas en configuraciones de sistemas. Provee la información en
forma narrativa y normalmente recomienda soluciones.
• Common Platform Enumeration (siglas CPE).- Se ocupa de la correcta nomenclatura del software y ofrece una
estructura jerárquica. De esta forma se facilita la gestión del nombre del software.
• eXtensible Configuration Checklist Description Format (siglas XCCDF).- Es una plantilla XML que facilita la
preparación estandarizada de documentos guia de seguridad que presentan vulnerabilidades de seguridad del
software
• Open Vulnerability and Assessment Language (siglas OVAL).- Es un lenguaje para representar información de
configuración, evaluación de los estados de la máquina e informes de resultados de la evaluación.
• Common Vulnerability Scoring System (siglas CVSS).- Es un algoritmo que tiene en cuenta distintos parámetros
relativos al software y da una expresión del nivel de seguridad calculado.
• Open Checklist Interactive Language (siglas OCIL) (desde versión 1.1).- Es un lenguaje para representar
controles que recogen información sobre gente o datos existentes almacenados.
• Asset Identification (siglas AI) (desde versión 1.2).- Formato para identificar de forma única activos basados en
conocidos identificadores y/o información sobre los activos
• Asset Reporting Format (siglas ARF) (desde versión 1.2).- Formato para expresar información sobre activos y
las relaciones entre activos e informes.
• Common Configuration Scoring System (siglas CCSS) (desde versión 1.2).- Sistema para medir la importancia
relativa de una configuración de seguridad de un sistema.
• Trust Model for Security Automation Data (siglas TMSAD) (desde versión 1.2).- Especificación para usar firmas
digitales en un modelo de confianza común aplicado a las espeficaciones del SCAP.

Evolucion de la arquitectura de las aplicaciones
1990 2000

Tipos de aplicaciones
 No web
 Web / servicios web
 Móviles

Non-Web Applications
 Client-Server
 Service Oriented to Architecture (SOA), (java-

RMI, Corba, etc.)
 Embedded Systems for avionics, Supervision

Control Systems as SCADA or Air Defense
commander and control systems, etc.

Web Applications
 Traditional N-tier Web Applications
 Rich Internet Applications (RIA)

 Flash
 Ajax
 JavaFX
 Microsoft SilverLight
 HTML5
 Web services (SOA)

Mobile Applications
 Native Applications
 Web Applications
 Hybrid Applications

Mobile applications: ¿elección de arquitectura?
 Si la aplicación requiere el procesamiento local y debe

trabajar en un escenario de conexión ocasional, considerar
el diseño de un cliente pesado. Una aplicación de cliente
enriquecido será más complejo de instalar y mantener.
 Si la aplicación puede depender de procesamiento del

servidor y siempre estará completamente conectado,
considerar el diseño de un cliente ligero.
 Si la aplicación requiere una rica interfaz de usuario, un

acceso limitado a los recursos locales, y debe ser
portable a otras plataformas, el diseño de un cliente RIA.

Capas de una aplicación web:
 Capas de presentación: Servidores web (Apache,

IIS, etc.)
 Capa de aplicación: Servidor de aplicación

(Weblogic, Tomcat, WebSphere, Struts, .NET,
ColdFusion, etc).
 Capa de persistencia: Base de datos (Oracle, MS

SQL Server, MySQL, PostgreSQL, etc)
 Clientes Web: principal objetivo.


Arquitectura Aplicaciones Móviles

Arquitectura Orientada a Servicios

Arquitectura Rich Internet Applications (RIA)

Evolución tecnologías desarrollo Aplicaciones Web
 Common Geteway interface (CGI). marco de desarrollo de programas

externos escritos en C/C++ que pueden ser llamados por las aplicaciones
web.
 Lenguajes de scripting. Lenguajes interpretados: Phyton, ColdFusion,

PHP, etc. (Menor tiempo de desarrollo, mayor tiempo de ejecución, menos
escalabilidad y seguridad, más difíciles de mantener)
 Especificaciones de desarrollo:
 J2EE (Standard, IBM, SUN, HO, AOL, etc. La plataforma J2EE está
controlada por el Java Community Process (http://www.jcp.org) )
 .NET (Producto Microsoft)

Los requisitos de las plataformas de desarrollo:
 Escalabilidad: Ha de ofrecer una buena escalabilidad tanto horizontal como

vertical de modo que si aumenta la carga del sistema podamos añadir
servidores o ampliar los existentes sin que sea necesario realizar
modificaciones.
 Mantenibilidad: Ha de permitir añadir, modificar o eliminar componentes

existentes sin que se modifique el comportamiento del sistema.
 Fiabilidad: Debe ser capaz de seguir ofreciendo servicios a sus clientes a

pesar de posibles fallos de los componentes del sistema.
 Disponibilidad: Debe tener el soporte de arquitecturas tolerantes a fallos,

sistemas de redundancia, etc., que aseguren que los sistemas estarán
siempre disponibles.

Los requisitos de las plataformas de desarrollo:
 Extensibilidad: Ha de ser posible añadir nuevos componentes y

capacidades al sistema sin que se vean afectados el resto de componentes.
 Manejabilidad: Los sistemas han de ser fácilmente manejables y

configurables.
 Seguridad: Se han de proporcionar buenos sistemas de seguridad

tanto a nivel de autenticación, como de autorización y como de
transporte.
 Rendimiento: Se ha de ofrecer automáticamente soporte de clustering,

balanceo de carga, pools de objetos, pools de conexiones, caches, y en
general mecanismos que permitan aumentar el rendimiento de manera
transparente al usuario.

.NET
La plataforma de desarrollo empresarial de Microsoft tiene algunas ventajas:
 Soporte de múltiples lenguajes: Aunque no soporte todas sus características,

lo cierto es que con .NET es posible desarrollar aplicaciones utilizando
simultáneamente varios lenguajes de programación.
 Ideal para entornos Microsoft: Si en nuestra empresa disponemos de gran
cantidad de software y hardware dependiente de Microsoft, probablemente la
mejor opción para continuar desarrollando sea esta plataforma, ya que su
integración con los productos de la empresa es perfecta.
 Visual Studio .NET: La plataforma .NET dispone de esta gran herramienta que
además de su potencia ofrece un entorno homogéneo de desarrollo.
 Requiere desarrolladores poco experimentados: Bajo la plataforma de
desarrollo de Microsoft es posible utilizar lenguajes como VB .NET que hacen
muy sencilla la creación de aplicaciones empresariales. De este modo es
posible tener un equipo de desarrolladores poco experimentados y sin embargo
que estos puedan crear fácilmente aplicaciones.

.NET
La plataforma de desarrollo empresarial de Microsoft tiene algunas desventajas:
 No soporta múltiples sistemas operativos: El mundo de .NET gira en torno al

sistema operativo Windows y aunque se están intentando trasladar partes
importantes de la plataforma, como el CLR (Common Language Runtime) o C#, a
otros sistemas operativos, lo cierto es que estas partes forman una parte ínfima de
la totalidad de la plataforma de Microsoft.
 Un único dueño: La plataforma .NET está dominada única y exclusivamente por

Microsoft. Esto supone un grave problema ya que es una única empresa la que
puede añadir y quitar características según crea conveniente. Además esto hace
que la competencia sea nula y no se estimula la evolución de la plataforma.
 Pocas soluciones libres: No existe una correspondencia exacta entre las partes
de la plataforma .NET y soluciones libres. Existen proyectos como Mono[18] o
dotGNU que están portando algunas de sus partes, aún así, no se puede crear una
arquitectura completa utilizando solamente productos basados en software libre.

J2EE
La plataforma de desarrollo J2EE es un STANDARD que tiene algunas ventajas:
 Soporte de múltiples sistemas operativos: Al ser una plataforma basada en el

lenguaje Java, es posible desarrollar arquitecturas basadas en J2EE utilizando
cualquier sistema operativo donde se pueda ejecutar una máquina virtual Java.
 Organismo de control: La plataforma J2EE está controlada por el Java
Community Process (http://www.jcp.org) que es un organismo formado por más de
500 empresas. (SUN, IBM, Oracle, SAP, HP, AOL, etc.) garantiza la evolución
 Competitividad: Muchas empresas crean soluciones basadas en J2EE y ofrecen
características como rendimiento, precio, etc., muy diferentes. De este modo el
cliente tiene una gran cantidad de opciones a elegir.
 Madurez: Creada en el año 1997, J2EE tiene ya bastantes años de vida y una
gran cantidad de proyectos importantes a sus espaldas.
 Soluciones libres: En la plataforma J2EE es posible crear arquitecturas
completas basadas única y exclusivamente en productos de software libre. No solo
eso, sino que los arquitectos normalmente disponen de varias soluciones libres
para cada una de las partes de su arquitectura.

J2EE
La plataforma de desarrollo J2EE es un STANDARD que tiene algunas desventajas:
 Depende de un único lenguaje: La plataforma J2EE depende exclusivamente del

lenguaje Java. Solo se puede utilizar este lenguaje para desarrollar aplicaciones lo
que puede suponer un gran problema si nuestro equipo no dispone de los
conocimientos suficientes o tiene otras preferencias.
 Complejidad: no existe un VB .NET en Java. La creación de aplicaciones bajo
J2EE requiere normalmente desarrolladores más experimentados que los
necesarios para desarrollar bajo .NET
 Heterogeneidad: Existe una gran heterogeneidad en las soluciones de desarrollo.
No existe en J2EE un símil a Visual Studio .NET. La gran cantidad de herramientas
disponibles causa confusión dentro de los desarrolladores y puede crear
dependencias dentro de las empresas.
 Hay muchas implementaciones de J2EE disponibles.

J2EE vs .NET
CARACTERISTICAS J2EE .NET
TIPO DE TECNOLOGÍA STANDARD PRODUCTO
VENDEDORES Más de 30 Microsoft
INTÉRPRETE JRE CLR
COMPONENTES DE LA EJB ADMINISTRADOR
CAPA MEDIA COMPONENTES .NET
ACCESO BASE DATOS JDBC SQL/J ADO.NET
SOAP, WSDL,UDDI SI SI
LENGUAJES JAVA C/C++, C#, Vbasic .NET
…
MIDDLEWARE SI SI
IMPLÍCITO
(Balanceador de carga
…)

Patrón de desarrollo Model View Controller (MVC)

Estadísticas de uso de lenguajes [Veracode.com]

Seguridad por defecto en lenguajes:
Prevención
 Son un hecho los problemas de seguridad debido a vulnerabilidades

existentes en el código derivadas de validaciones y mecanismos de
autorización deficientes o inexistentes. Las diferencias en este sentido,
pueden inducir en la elección de una tecnología u otra, las pueden marcar
las características inherentes al lenguaje utilizado por una especificación
concreta.
 Conviene utilizar un lenguaje de programación que fuerce la

comprobación de tipos y de memoria de forma que su gestión sea
segura. C#, Java, Python, Ruby o dialectos de C como CCured y
Cyclone son lenguajes de este tipo.

Arquitectura Rich Internet Applications (RIA)

Clásicas Aplicaciones Web – Aplicaciones RIA

Problemas de seguridad AJAX:
 Aumento de la superficie de ataque
 Revelación de lógica de aplicación
 Dificultad de la auditoría de aplicaciones
 Acceso al DOM  Cookies, credenciales …
 XSS nuevas posibilidades, SQLI
 Revelación de información

Medidas de seguridad AJAX:
 PROTEGER el entorno de ejecución del cliente: SANDBOX
 Validación campos de entrada – salida código lado servidor - cliente (DOM)
 CONTROLAR ACCESOS a sitios distintos de aquel desde el que se

descargó el
script. (CROSS ORIGIN RESOURCE SHARING)
 CONTROLES DE SEGURIDAD (autenticación, autorización en el lado servidor y
del cliente en el acceso al DOM)
 Prestar especial atención a los ataques de tipo XSS (DOM)
 Utilizar SSL para transmitir datos confidenciales entre cliente y servidor
 Nunca deben almacenarse datos confidenciales en el cliente
 Minimizar la lógica de negocio expuesta (debe estar lo más posible en lado

servidor)

Arquitecturas Orientadas a Servicios
-------
WSD
L ....
r
I ->I
,. I
I
~ ' t
.,, ., .i' ~
,.,, , ... ...
. . .,.
>' ~
~
--- ~-
rr-
Agented
SOAP
Aplicaci6
Aplicaci
nde . SOAI
)l,
e
viaje
SOAP
s
cliente
client
. P Servicio
We
b
'\
' \
' l.rea..
WSDL
~'.:ICe>r a
Servicio
Web


Mensajes SOAP con estructura XML:
 Una envoltura.
 Una cabecera con datos

descriptivos.
 Un body o contenido
SOAP (Simple Object Access

Protocol)
XML
HTTP-SMTP-JMS

UDDI (servicio de descripción universal, descubrimiento e
integración):
Proporciona un mecanismo estándar para registrar y encontrar

servicios web. Un registro UDDI contiene la información sobre los
negocios (empresas) y servicios que ofrecen.
 Entidad de negocio (Información básica, contacto,

descripción, etc.)
 Servicio de negocio (Lista de servicios entidad)
 Patrones de enlace (como usar el servicio)
 Tipo se servicio -> fichero WSDL

WSDL (Lenguaje de Descripción de Servicios Web):
WSDL: vocabulario XML para describir un servicio Web. Un

documento WSDL describe qué funcionalidad ofrece un servicio
Web, cómo se comunica y dónde es accesible (es decir, indica el
punto de acceso). WSDL proporciona un mecanismo estructurado
que describe:
 Las operaciones que un servicio Web puede realizar.
 Los formatos de los mensajes que puede procesar.
 Los protocolos que soporta.
 El punto de acceso al servicio.
Normalmente cualquier herramienta de desarrollo SOAP puede usar

una descripción WSDL de forma automática para generar un interfaz
que se pueda usar (y enlazar) en una aplicación cliente. Una
descripción WSDL define una colección de puntos de acceso de red
o puertos

Proceso de búsqueda de un Servicio WEB:
1. Se publica su descripción y se construye un enlace o apuntador a

un depósito UDDI (Universal Description, Discovery and
Integration) para que los potenciales usuarios lo puedan utilizar.
2. Cuando alguien piensa en utilizar este Web Service, solicita el

archivo WebServicesDL para conocer la ubicación del servicio, la
invocación de funciones, y cómo acceder al Web Service.
3. Luego se utiliza la información en el archivo WSDL para construir

una petición SOAP (Simple Object Access Protocol) y enviarla
hacia el proveedor de servicio vía HTTP, SMTP…


Almacenes de datos:
 Sistemas Gestores Bases de Datos (SGBD,s)
 Repositorios XML
 Directorios LDAP

SGBD,s: Niveles de abstracción
 Nivel físico: el nivel más bajo de abstracción;

describe cómo se almacenan realmente los datos.
 Nivel lógico o conceptual: describe los datos que

se almacenan en la BD y sus relaciones, los
objetos del mundo real, sus atributos y sus
propiedades, y las relaciones entre ellos.
 Nivel externo o de vistas: describe la parte de la

BD a la que los usuarios pueden acceder.

Sistema Gestor de Bases de datos (SGBD)
Usuario
s
Nivel
Vist
Vis n
enemo o
-:
a
de V1S10n
Nivel
16gio
Nvel
Tabla Tabla Tabla 3 Tabl n
o
concept
u 1 2 a
Nivel Nive
intemo
o fisi:co
Disc 1 Disco 2 Disco 3 l
o fisic
o

Modelo Entidad-Relación
 Entidades: tablas, campos, atributos, claves…
 Relaciones: asociación entre diferentes entidades.

Modelo Entidad-Relación

Arquitectura BB. DD. (Oracle)
C:opiai de los arcrh- ,

...... ivos ....,
.,_ ,die ...,
Ardhivos; R·edo_Log
de

Seguridad SGBD,s: Usuarios

 Los usuarios de la categoría DBA (Database Administrator)
 Los usuarios de la categoría RESOURCE, que pueden crear sus

propios objetos y tienen acceso a los objetos para los que se les
ha concedido permiso.
 Los usuarios del tipo CONNECT, que solamente pueden utilizar

aquellos objetos para los que se les ha concedido permiso de
acceso.
 Usuario AUDITOR  Monotorización incluido el DBA.

Seguridad SGBD,s: DBA user

El DBA tiene una gran responsabilidad ya que posee el máximo
nivel de privilegios. Será el encargado de crear los usuarios que se
conectarán a la BD. En la administración de una BD siempre hay
que procurar que haya el menor número de administradores, a ser
posible una sola persona. incluye una serie de tareas como:
 Instalar SGBD en el sistema informático.

 Crear las BBDD que se vayan a gestionar.
 Crear y mantener el esquema de la BD.
 Crear y mantener las cuentas de usuario de la BD.
 Arrancar y parar SGBD, y cargar las BBDD con las que se ha de
trabajar.
 …

Ataques a SGBD,s

Light Directory Access Protocol (LDAP)
LDAP es particularmente utilizable para almacenar

información:
 Accesible desde muchas localizaciones
 No actualizada frecuentemente

Light Directory Access Protocol

 El listín de teléfonos de empleados de la empresa y el
esquema organizacional
 Información de contacto de clientes externos
 Información de la infraestructura de servicios, incluyendo

mapas NIS, alias de email, y demás
 Información de configuración para paquetes de software

distribuidos
 Certificados públicos y claves de seguridad

Light Directory Access Protocol

LDAP injection

LDAP injection (I)
DirectorySearcher src = new DirectorySearcher("(manager=" +

managerName.Text + ")");
src.SearchRoot = de;
src.SearchScope = SearchScope.Subtree;
foreach(SearchResult res in src.FindAll()) {... }
However, because the filter is constructed dynamically by concatenating a

constant base query string and a user input string, the query only behaves
correctly if managerName does not contain any LDAP meta characters. If
an attacker enters the string Hacker, Wiley)( | (objectclass=*) for
managerName, then the query becomes the following:
(manager=Hacker, Wiley)(|(objectclass=*))

LDAP injection (II)
Based on the permissions with which the query is executed, the addition
of the | (objectclass=*) condition causes the filter to match against all
entries in the directory, and allows the attacker to retrieve information
about the entire pool of users. Depending on the permissions with
which the LDAP query is performed, the breadth of this attack may be
limited, but if the attacker can control the command structure of the query,
such an attack can at least affect all records that the user the LDAP query
is executed as can access.

eXtended Marked Language (XML)
Impulsado por el World Wide Web Consortium (W3C) a finales de los

años 90. Aplicaciones:
 Archivo electrónico y gestión de contenidos,
 Publicación Web, configuraciones
 Intercambio electrónico de documentos (Servicios Web)
 Formato interno de herramientas, software, comercio electrónico,

educación, química, sanidad, turismo, derecho, etc.

XML injection – XPATH injection
Imagine that you have user data stored in an XML file, and that XML file
looks something like this:
<users>
<user ID =1>
<username>Admin</username>
<password>MyPassword</password>
<role>admin</role>
</userid>
</users>

Looking at the code the site uses to log in, it dynamically builds an XPath
query in PHP, after a user has given username and password in a form
(with user and pass variables):
<?php $login = simplexml_load_file("users.xml"); $result=$login-

>xpath("//User[username/test()='".$_POST['user']." AND
password/text()='".$_POST['pass']."'"; ?>

The main problem above is that data from the user is not sanitized; the
POST variable is being used to pull data directly from the login form, and
placing it into the XPATH query. At this point, an attacker could try
putting in a special string for username:
' or 1=1 or '

Problemas de seguridad de las aplicaciones web.
Pasan por los problemas de seguridad que todos sus componentes
puedan tener, es decir, problemas que tienen:
 Defectos de seguridad intrínsecos a la aplicación web.
 Los navegadores web.
 Los servidores web, servidores de aplicaciones.
 Los Sistemas de Gestión de Bases de Datos.
 Problemas de seguridad en la comunicación.
 Problemas de seguridad física: Instalaciones, Personal,
Documentación.

Los problemas intrínsecos de las aplicaciones web

están relacionados con:
 Problemas relacionados con el protocolo HTTP de comunicación.
 Problemas de validación de la entrada en el código el lado del

servidor.
 Problemas de validación de la salida en el código del lado del

servidor que pueden causar redirecciones a servidores controlados por
el atacante y que estos aprovechan para conseguir acceso a datos
personales. (prevenir XSS)  encode campos con URL,s
 Problemas de validación de la entrada y de la salida en el código

del lado de cliente en aplicaciones web 2.0 de cliente enriquecido
que utilizan motor AJAX. (prevención XSS DOM)

Ejemplo de ataque XSS (CROSS SITE SCRIPTING):

Seguridad en los servidores:
Han de contemplarse todos los aspectos de seguridad que tienen que

están relacionados con el servidor:
 Seguridad en el sistema operativo plataforma:

comprobación de configuraciones por defecto,
autenticación, autorización, control de accesos,
cifrado de datos, PKI, SSH, etc.
 Seguridad en los propios servidores de

aplicaciones y gestores de bases de datos que
dan soporte a la aplicación, autenticación,
autorización, control de accesos, etc.

Seguridad en la comunicación:
 Protocolo Secure Socket Layer (SSL) aplicado a protocolos como por

ej: HTTP => HTTPS. Protocolo TLS (variante de SSL).
 Protrocolo SSH, para accesos a administración de servicios.
 Redes Privadas Virtuales (VPN,s), implementadas mediante varios

protocolos: IPSEC, L2TP, PPTP, etc.
 Public Key Infraestructure (PKI), necesaria para administración de

certificados digitales para su uso en las tareas de autenticación, firma y
cifrado de datos, para asegurar las características de no repudio,
integridad y confidencialidad de los datos dentro de los protocolos
anteriormente indicados

Seguridad en el cliente (Navegadores Web):

La seguridad en los navegadores web hay que enfocarla desde dos
puntos de vista:
1. Las propias vulnerabilidades de seguridad que contiene el código

con el que está construido un determinado navegador.
2. La implementación de medidas de seguridad que el propio

usuario puede administrar y configurar dentro del navegador y en
las aplicaciones para proteger la ejecución del código en la parte
cliente con sus propias vulnerabilidades de seguridad que hay que
intentar mitigar.

Seguridad en los navegadores:
 Ejecución de código y privilegios  SANDBOX S.O.

 restricted security Token.
 IMPEDIR ACCESOS a sitios distintos de aquel desde el que se

descargó el script. (SAME ORIGIN POLICY) (CORS ORIGIN
RESOURCE SHARING)
 Prevenir ejecutar respuestas de javascript. Como el cliente

legítimo puede modificar los datos antes de ejecutarlos cuando los
recibe, el servidor cuando serializa los datos puede incluir un
prefijo y sufijo que solo el cliente conoce y que elimina antes de
ejecutarlos.
 Clicjacking

Navegadores Web – Arquitectura monolítica:

Navegadores Web – Arquitectura modular [Silic et al]:
<iframe sandbox src="frame1.html"></iframe>

Estadísticas de uso de lenguajes (veracode.com)

Lenguajes seguros: PREVENCIÓN
C#, Java, Python, Ruby ó dialectos de C como

CCured y Cyclone
Realizan comprobaciones en tiempo de ejecución

para impedir a los programas violar los límites de la
memoria asignada. Seguridad de memoria y
seguridad de tipo.

Java es un lenguaje “seguro” [long, 2005]:
 No tiene explícita manipulación de punteros.
 Límites de arrays, strings se comprueban

automáticamente.
 Intentos de referencias a un objeto null se capturan.
 Las operaciones aritméticas están bien definidas.
 Control de acceso a ficheros, sockets mediante JVM

-> Security Manager.
Seguridad en la fase de producción online:
MEDIDAS
 Preventivas:
 Protección física: Controles de acceso, Protección hardware
 Medidas técnicas: Test de seguridad SSDLC, Firewalls
 Medidas Procedimentales: Cursos de actualización
(programación segura, seguridad SO,s etc.), concienciación
 Detectivas:
 Protección física: Sistemas de vigilancia
 Medidas técnicas: Control acceso lógico
 Medidas Procedimentales: Monitorización y auditoría
 Correctivas:
 Protección física: Respaldo de fuente de alimentación
 Medidas técnicas: Antivirus, auditorías, respaldo de seguridad
 Medidas Procedimentales: Planes de contingencia, respuesta

Seguridad en la fase de producción online:
 Configuración correcta de los parámetros que afectan a la seguridad de
toda la aplicación contenidos en los archivos correspondientes al servidor,
servidor de aplicaciones, aplicación y base de datos. Gestión de la
autenticación, autorización y control de accesos.
 Mecanismos de protección externos como firewall de aplicaciones web,

de bases de datos, firewalls XML o herramientas de protección de
vulnerabilidades en tiempo real que ofrecen ya varias empresas como
Fortify HP (RTA).
 Seguridad física: Instalaciones, del personal y de la documentación.
 Monitorización Contínua, auditoría y gestión de logs.
 Redundancia: clustering, Centro de respaldo
 Gestión de backups-recuperación, desastres. Respuesta ante

incidentes..

Seguridad online: MONITORIZACIÓN CONTINUA
 SGSI  Implementación controles  Monitorización contínua
NIST 800-53-R4 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
NIST 800-137 http://csrc.nist.gov/publications/nistpubs/800-137/SP800-137-Final.pdf
ENS https://www.ccn-cert.cni.es/publico/seccion-ens/index.html
ISO 270001 http://www.iso27000.es/sgsi.html#home
 SIEM:
 Sistemas de detección y de prevención de intrusiones que analizan el tráfico de
red buscando patrones que puedan suponer un ataque a la aplicación.
HP ArcSight Enterprise Security Manager IDS http://www8.hp.com/es/es/software-
solutions/arcsight-esm-enterprise-security-management/
Macafee : http://www.mcafee.com/es/products/siem/index.aspx
Siem comparativa: https://www.alienvault.com/marketing/siem-magic-quadrant-
2014?utm_source=Google&utm_medium=CPC&utm_term=%2Barcsight&utm_campaign=MQ-
WW-GGL-SE&gclid=CJiQjp3gtsQCFSXnwgodC4sAbQ
Qualys Guard Continuous monitoring:
https://www.qualys.com/enterprises/qualysguard/continuous-monitoring/
 Sistemas de gestión de eventos.

(HP TippingPoint Enterprise Security Manager eventos-log,s)

Seguridad online: MONITORIZACIÓN CONTINUA
 SGSI  Implementación controles  Monitorización contínua
NIST 800-53-R4 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
NIST 800-137 http://csrc.nist.gov/publications/nistpubs/800-137/SP800-137-Final.pdf
ENS https://www.ccn-cert.cni.es/publico/seccion-ens/index.html
ISO 270001 http://www.iso27000.es/sgsi.html#home
 SIEM:
 Sistemas de detección y de prevención de intrusiones que analizan el tráfico de
red buscando patrones que puedan suponer un ataque a la aplicación.
HP ArcSight Enterprise Security Manager IDS http://www8.hp.com/es/es/software-
solutions/arcsight-esm-enterprise-security-management/
Macafee : http://www.mcafee.com/es/products/siem/index.aspx
Siem comparativa: https://www.alienvault.com/marketing/siem-magic-quadrant-
2014?utm_source=Google&utm_medium=CPC&utm_term=%2Barcsight&utm_campaign=MQ-
WW-GGL-SE&gclid=CJiQjp3gtsQCFSXnwgodC4sAbQ
Qualys Guard Continuous monitoring:
https://www.qualys.com/enterprises/qualysguard/continuous-monitoring/
 Sistemas de gestión de eventos.

(HP TippingPoint Enterprise Security Manager eventos-log,s)

SGSI  Risk Framework NIST 800-53-r4 Monitorización Continua
• S'tarting •
•
• •
• •
Step 1
RIISK
t MANAGEMENT
+
Step 4

Seguridad física: Seguridad de las
instalaciones:
 Subsistema eléctrico
 Subsistema de detección y extinción de incendios.
 Subsistema de racks, canalización y cableado
estructurado.
 Subsistema de seguridad y control de accesos.
 Subsistema de monitorización y gestión de
infraestructura
 Subsistema de iluminación
 Subsistema de infraestructura dedicada

Seguridad física: Seguridad del personal
Es necesario que todo el personal que está

relacionado con los sistemas tenga la formación en
concienciación de seguridad necesaria para evitar
fugas de información que puedan comprometer el
sistema. De la forma más inverosímil un sistema puede
verse comprometido debido a descuidos en el personal
y los altos costes que implica implementar la seguridad
en todos los aspectos, comunicación, servidores,
sistemas operativos, etc. no habrán servido de nada.

Seguridad física: Seguridad en la

documentación
 La documentación de la organización debe estar

clasificada atendiendo a determinados niveles de
seguridad.
 La información solamente debe ser accedida por quién

tenga “necesidad de conocer” y tenga la acreditación en
regla para acceder a ella.

www.unir.net

Diapositiva 1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Diapositiva 1

Cargado por

Copyright:

Formatos disponibles

Seguridad de aplicaciones online y bases de datos

Juan Ramón Bermejo Higuera

Juan Ramón Bermejo Higuera

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 2

1. Arquitectura de las aplicaciones y bases de

2. Seguridad de las aplicaciones online

3. Seguridad de los servicios web

4. Seguridad en sistemas gestores de bases de

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 3

 Introducción. Problemas de seguridad de las aplicaciones

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 4

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 5

 Seguridad en aplicaciones RIA-AJAX (OB)

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 6

 Política de seguridad. Principios de seguridad

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 7

PROBLEMAS DE ANÁLISIS Y TEST DE

 Test de penetración de la aplicación BADSTORE (OB)

 Instalar y configurar un firewall de aplicaciones web open source:

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 9

 Introducción a la seguridad de los servicios web

 Requisitos, elementos y tecnologías de la seguridad de los servicios

 Evaluación de la seguridad de los servicios web

 Protección online. Firewalls XML

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 10

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 11

 Configurar la seguridad de servicios web (OB)

 Foro: seguridad de servicios web (OB)

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 12

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 13

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 14

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 15

Ob Trabajo: Test de penetración BADSTORE

Ob Trabajo: Instalar y conf firewall APP WEB

Ob Trabajo: Configurar Seg SW.

Re Trabajo: Instalar y conf Firewall SGBD

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 16

 ESTRUCTURA DEL DOCUMENTO. Debe ser planificada previamente y tener

 PRESENTACIÓN acorde con la categoría del curso.

 EXTENSIÓN variable dependiendo de la actividad.

 REFERENCIAS. Se deben especificar en un apartado al final todas las fuentes

 Recalcar la obligatoriedad de la especificación de las REFERENCIAS

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 17

 SGSI (ISO 27001, ENS…)

 Monitorización continua  análisis y gestión

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 18

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 112

Política de Seguridad (I):

 Normas clave que estarán en cualquier política

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 19

Política de Seguridad (II):

 Proveedores de conexión a Internet aceptables.

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 20

Política de Seguridad (III):

 Redes Privadas Virtuales.

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 21

Ciclo de vida de desarrollo seguro de

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 22

SSDLC: Mejores prácticas o touchpoints en

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 23

Objetivos seguridad sistemas TIC (I):

 Controlar el acceso a la información

Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 24

Objetivos seguridad sistemas TIC (II):