Presentacion Tema 2 3 Aut

Seguridad de aplicaciones online y bases de datos
Juan Ramón Bermejo Higuera
Tema 2: Seguridad en aplicaciones web: Autenticación

POLÍTICA DE
SEGURIDAD
VULNERABILIDES EN
APLICACIONES WEB
AMENAZAS Y ATAQUES
ESTÁNDARES DE
SEGURIDAD
SEGURIDAD ONLINE:
ANÁLISIS Y TEST DE SEGRUIDAD
DE LAS APLICACIONES WEB
CONTROL DE ACCESO: PROTECCIÓN
AUTENTICACIÓN MONITORIZACIÓN
GESTIÓN DE SESIONES ANÁLISIS ESTÁTICO
AUDITORÍA
ANÁLISIS DINÁMICO
AUTORIZACIÓN BACKUPS-RECUPERACIÓN
ANÁLISIS HÍBRIDO
RESPUESTA ANTE INCIDENTES
Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 2

Aplicaciones WEB: Control de acceso
AUTENTICACIÓN
GESTIÓN DE SESIONES
AUTORIZACIÓN
Ref. OWASP development guide

Ref. Web application Securrity: A beginners guide (Sullivan, Liu)
Ref. Hacking exposed Web Applications (Scambray, Liu, Sima)
Ref. The web applications hacker´s handbook (Sttutard, Pinto)

Autenticación
 Identificar al usuario de la aplicación
 Acceso restringido a zonas o datos sensibles y privados en la App-Web
 El objetivo final es tener controles de acceso granulares por usuario (o

grupo)
Autenticación Gestión de
Autorización
sesiones

Autenticación: tipos
 Autenticación básica (Basic) - HTTP
 Autenticación Digest - HTTP
 Autenticación integrada en dominio (directorio activo) - SSO
 SSL-TLS Certificados digitales cliente (https  443)
 Autenticación de múltiples factores
 Autenticación desde la aplicación Web (basada en formularios)

Autenticación http: basic
http://tools.ietf.org/html/rfc2617
 Credenciales enviadas “en claro” o codificadas (no cifradas) en base 64
 RFC 2617 - usuario y contraseña
 Cada petición HTTP incluye las credenciales

 Caché e historial del navegador Web (GET)
 Protegerlas con HTTPS (SSL/TLS)

- Transmisión insegura
- Exposición repetitiva
- Almacenamiento inseguro (cache del navegador)

Ejemplo:
The HTTP-Header of a standard client requests on some Document in a

protectedArea:

Ejemplo:
The HTTP-Header of a standard client requests on some Document in a

protectedArea OK. :
La contraseña es enviada en texto claro, se puede descodificar:

Autenticación http: digest
 RFC2617 – http 1.1 Challenge/Response
 Firma (hash) criptográfica: MD5
 Protección frente a reenvío (replay). Aleatoriedad del nonce y número de

petición
 Se debe emplear un “nonce” criptográfico sensible al tiempo (caducidad)
 Cada petición HTTP incluye las credenciales
 Protegerla con HTTPS (SSL/TLS)

Autenticación: digest
 Client request (no authentication)
GET /dir/index.html HTTP/1.0
Host: localhost
 Server response (no authentication)

HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:26:47 GMT
WWW-Authenticate: Digest realm="testrealm@host.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html Content-Length: 311

Autenticación http: digest  cliente
 Username
 realm: (parte de la aplicación) a la que el usuario quiere autenticarse
 qop: calidad de protección que establece el servidor
 cnonce: client generated unique data string
 nc: nonce-count - the count of requests sent by the client. It must be present if qop is
present. The nonce-count avoid reply-attacks
 response: the encrypted password

Autenticación http: digest  servidor
 realm: parte sitio-url a proteger
 qop: quality of protection

 - The value "auth" indicates authentication;
 - The value "auth-int" indicates authentication with integrity protection. Therefore the Hash value is
 calculated over the whole entity-body.

 nonce: server string generated each time a 401 response  se incluye en el cifrado con el
usuario/contraseña
 opaque: se usa para trazar la sesión por parte del servidor
 stale: Bandera establecida cuando el servidor solicita un nuevo valor NONCE, por haber
caducado
 algorithm: MD5, SHA
 The nonce value and the opaque value are sent in hexadecimal notation.

Autenticación http: digest  cálculo de response
If the algorithm directive's value is "MD5" or unspecified, then HA1 is
If the algorithm directive's value is "MD5-sess", then HA1 is
If the qop directive's value is "auth" or is unspecified, then HA2 is
If the qop directive's value is "auth-int", then HA2 is
If the qop directive's value is "auth" or "auth-int", then compute the response
is
If the qop directive is unspecified, then compute the response as follows:

Autenticación http: digest  cálculo de
response
HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" )
= 939e7578ed9e3c518a452acee763bce9
HA2 = MD5( "GET:/dir/index.html" )
= 39aff3a2bab6126f332b942af96d3366
Response = MD5( "939e7578ed9e3c518a452acee763bce9:\
dcd98b7102dd2f0e8b11d0f600bfb0c093:\
00000001:0a4f113b:auth:\
39aff3a2bab6126f332b942af96d3366" )
= 6629fae49393a05397450978507c4ef1

Autenticación http: digest
 Client request (username "Mufasa", password "Circle Of Life")
GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth, nc=00000001, cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41“
 Server response
HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984

Autenticación http: digest  reflexiones de seguridad
http://tools.ietf.org/html/rfc2617#section-4
 El cliente puede hacer otra solicitud, reutilizando el valor nonce del

servidor (tiene un tiempo de expiración,el servidor sólo emite un
nuevo nonce por cada respuesta "401")
 Corresponde al servidor asegurarse de que el contador (nc)

aumenta para cada uno de los valores nonce que ha emitido
 Cambiar el método, URI y/o valor del contador se traducirá en

un valor de respuesta (response) diferente
16
Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera
Autenticación: digest  reflexiones de seguridad
 El servidor debe recordar los valores nonce, no caducados.
 Si el cliente utiliza un valor caducado, el servidor debe responder con el "401" y

añadir steal = TRUE, lo que indica que el cliente debe volver a enviar el nuevo
nonce proporcionado, sin preguntar al usuario por otro nombre de usuario y
contraseña.
 El tiempo mínimo de vigencia asignable de valor nonce es de 10 seg. Tener en

cuenta que, cuando expira un nonce de servidor inmediatamente no
funcionará y el cliente ya no podrá usarlo.

Autenticación http: reflexiones de seguridad
 Autenticación Basic es muy insegura  MITM, sniffering
 MITM  HTTP-PROXY
 Replay attacks
 Si se requiere seguridad  Solamente DIGEST
 Seguridad autenticación Digest  depende de la implementación de

creación de CNONCE, NONCE

Autenticación: digest  ataques
 http basic authentication

 REPLAY ATTACKS  Spoofing  transmisión en claro user/pass método GET
 BRUTE FORCE
 DICTIONARY ATTACKS
 MITM
 http digest authentication

 MITM
 BRUTE FORCE (hay que requerir uso de cnonce  cambia response)
 DICTIONARY ATTACKS (hay que requerir uso de cnonce  cambia response)

Autenticación: directorio activo
(Windows  active directory, Linux open ldap)
 Active directory NTLM - Kerberos
 Transparente al usuario
 Dominios: INTRANET,s
 No es común en INTERNET
 No se necesita almacenar credenciales en la aplicación
20a
Autenticación:directorio activo
(Windows  active directory,Linuxopenldap)
NTLMv2
Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 20b

Autenticación: NTLM  ataques
 Caché de hashes / credenciales de los usuarios que han iniciado sesión
previamente en una máquina (por ejemplo, a través de la consola o RDP) se
pueden obtener por cualquiera que haya comprometido la máquina que
tenga privilegios de administrador  Configurar comportamiento caché.
 Volcado de credenciales de los usuarios autentificados almacenados por

Windows en la memoria del proceso lsass.exe. Las credenciales objeto de
dumping de esta manera pueden incluir los de los usuarios del dominio /
administradores, así como los que se hayan conectado a través de RDP.
 Volcado de la base de datos de usuarios (SAM).
 Captura de diálogos desafío-respuesta LM y NTLM entre el cliente y los

servidores y los hash capturados.
 MITM
Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 20c

Autenticación:NTLMv1
Ataque de repetición (blackhat 2010)

Autenticación:NTLMv1
Ataque de repetición (blackhat 2010)
Seguridad de aplicaciones online y BD- Juan Ramón Bermejo Higuera 20c

Autenticación: SSO
 Permite acceso a múltiple sitios.
 Puede ser centralizada (SAML, KERBEROS, OAuth2) o distribuida

(OPENID, GATEWAYS XML). http://www.mutuallyhuman.com/blog/2013/05/09/choosing-an-sso-strategy-
saml-vs-oauth2/
 Mas común en INTRANETS
 En INTERNET también proliferan: GOOGLE ACCOUNTS  youtube,

Gmail, Google talk … FACEBOOK  CNN, Vimeo …
 Único punto de fallo  proporcionar redundancia.
 Ejemplos: Oauth2 http://oauth.net/2/ , SAML,WSO2, CAS

21
Autenticación en aplicaciones web  Integración AD con Kerberos
KERBEROS vs NTLM
 La implementación de Microsoft del protocolo Kerberos V5 se basa en las

especificaciones de seguimiento de estándares recomendadas por el Grupo
de trabajo de ingeniería de Internet (IETF).
 Microsoft publica documentación de Protocolos de Windows para implementar

el protocolo Kerberos.
 Autenticación mútua: Al usar el protocolo Kerberos, una entidad que se

encuentra en cualquiera de los dos extremos de una conexión de red puede
comprobar que la otra entidad sea quien dice ser.
 NTLM no permite a los clientes comprobar la identidad del servidor ni habilita

a un servidor para comprobar la identidad de otro.
Seguridad en Aplicaciones Online – Juan Ramón Bermejo Higuera

Autenticación en aplicaciones web  Integración AD con Kerberos
Seguridad en Aplicaciones Online – Juan Ramón Bermejo Higuera

Autenticación: SSO  SAML
22
Autenticación:SSO  OAuth2
22b
Autenticación: SSO  OAuth2
 Todo el intercambio de token con el servidor de autorización debe hacerse bajo el protocolo de
comunicaciones TLS.
 El ámbito o acceso del token de acceso debe ser lo más limitado posible.
 El servidor de autorización es el encargado de autenticar al usuario de forma segura.
 La generación de los tokens por parte del servidor de autorización debe garantizar que no puedan ser
generados, modificados o adivinados por terceras partes.
 El tiempo de validez de los tokens o códigos de acceso debe ser de corto y de un solo uso.
 Los clientes que se autentiquen con el servidor de autorización deben validar el certificado TLS del servidor,
comprobando la identidad del mismo y evitando posibles ataques MITM que pueda sufrir el protocolo o de
Phishing que intenten suplantar la identidad del centro de autorización para obtener las credenciales del
usuario.
 Los clientes no deben almacenar los token en sitios vulnerables o accesibles.
 El servidor de autorización debe comprobar que las URIs de redireccionamiento usadas tanto al conseguir el
código de autorización como de acceso deben coincidir y validarse
22c
Autenticación: SSL (https)
 Certificados digitales en cliente y servidor

 Autentificación en ambos sentidos (HTTPS)
 Una de las opciones más seguras si se implementa correctamente
 Requiere una PKI (ej. DNIe)
 Soporte HTTPs
 Intercambio inicial y petición de certificado
 Intercambio de certificados (ambos)
 Negociación de algoritmos: cifrado y hashing

Autenticación: SSL  problemas
 Protección en la autenticación y no durante el resto de la sesión 
Secuestro de sesión firesheep http://codebutler.com/firesheep (BlackSheep:
detectar Firesheep)  se debe cifrar toda la sesión
 Reneg SSL/TLS iniciada por cliente = DoS  Las conexiones SSL/TLS con
reneg requieren de 10-35x más de rendimiento en el servidor  Solución: Reverse
ssl (carga en cliente) http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html#putting-more-work-
on-the-client-side - https://eprint.iacr.org/2006/212.pdf
 Mitigation techniques
 Disabling SSL renegotiation
 Rate limiting SSL handshakes
 Increasing server-side power processing
 Putting more work on the client side
 Ataques MITM (Gen. de certificados) (http://www.thoughtcrime.org/software/sslsniff/

https://www.schneier.com/blog/archives/2011/09/man-in-the-midd_4.html

Autenticación: Múltiples factores
 Autentificación de dos factores:

 Algo que sabes: contraseña o PIN
 Algo que tienes: token*, smart-card
* Generan criptograficamente un código a intervalos fijos basados en una semilla única para cada token.
Además requieren un PIN
 Autentificación de múltiples (tres o más) factores:

 Algo que eres: huella dactilar, retina ojo, cara, etc

Autenticación: desde la aplicación Web

 Si la password es correcta la aplicación asigna un ID de SESIÓN (en este caso
es una COOKIE que se utilizará para todas las subsiguientes peticiones a la
aplicación durante el tiempo permitido o hasta que se ejecute un logoff.

 No hace uso de las cabeceras
 Utiliza formularios HTML
 Flexibilidad en la BD de usuarios y credenciales  LDAP,

BD, RADIUS, fichero, etc

Autenticación: desde la aplicación
 Autentificación en cada petición o…
 … gestión de sesiones (ID de sesión o token que representa las credenciales

de autentificación e identifica la sesión del usuario)
 No importa como de avanzado es el método de autenticación o las

credenciales, se convierten en el ID de sesión. Por tanto, se debe aplicar
autenticación:
 Cuando los derechos de acceso del usuario cambian.

 Con las peticiones a datos o funcionalidades protegidas.
 Cuando se accede a un recurso de terceros.
 La aplicación debe validar los ID,s de sesión.
 HTTPS con certificado de cliente

99
Autenticación  checklist
 Identificar datos y funcionalidades a proteger (datos personales,
cuentas, filiaciones, fichas médicas, transferencias, etc.)
 Identificar dentro del código donde debería tener lugar la autenticación.
 Usar contraseñas fuertes (>12 16 caracteres)

 May-Min-Números-Símbolos …
 HASH + SALT* (append hash contraseña)
SALT: Pieza de información que se añade a la entrada una función hash para combinarla con la
password y añadir dificultad de ataques contra el almacenamiento de hashes. Se suele almacenar como
prefijo o sufijo a la password. Debido a que la longitud de SALT es conocida, no existe problema en la
verificación de la password suministrada por el usuario.

Autenticación  checklist
 Reseteo de contraseñas ante fallos de autenticación
 Tiempo máximo de expiración
 CAPTCHAs (ataques de fuerza bruta)
 Permitir deshabilitar cuentas
 Deshabilitar cuentas por defecto
 Evitar  recordar password  establece periodos de tiempo largos en

cookies

Autenticación  ataques
Pueden ser ataques online / offline (si se tiene acceso al almacen de contraseñas)
 Fuerza Bruta*
 Diccionario
 Replay
 MITM
 SQLI  BD usuarios/contraseñas
http://www.hoobie.net/brutus/
http://freeworld.thc.org/thc-hydra/

Sistemas de autenticación: ejemplos
 Acceso a aplicaciones desde dentro de una INTRANET:
 Autenticación en dominio con CERTIFICADO de cliente o

usuario/password
 Acceso a aplicaciones mediante formulario (usuario-
password) y SSL / sin certificado de cliente
 Acceso a aplicaciones desde INTERNET a una INTRANET:
 Acceso a través de VPN (ipsec + certificado de cliente) +

 autenticación en dominio (usuario/password) +
 Acceso a aplicaciones mediante formulario (usuario-
password) y SSL / sin certificado de cliente

REPASO:
 Tokens/nonces  de un solo uso.
 Tokens/nonces generados mediante funciones de generación de números aleatorios

criptográficas.
 Comprobar ruta de certificación en TLS  Certificate pinning
 Combinar distintos métodos de autenticación.
 TLS requerido para combinar con todos los demás métodos.
 No utilizar http basic,
 Digest y NTLM sólo si se combinan con TLS.
 Active directory mejor con KERBEROS que NTLM.
 Autenticación basada en formularios  Confiar en API,s framework de desarrollo.

www.unir.net

Presentacion Tema 2 3 Aut

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Presentacion Tema 2 3 Aut

Transféré par

Droits d'auteur :

Formats disponibles

Seguridad de aplicaciones online y bases de datos

Juan Ramón Bermejo Higuera

Tema 2: Seguridad en aplicaciones web: Autenticación

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

Ref. OWASP development guide

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

 Acceso restringido a zonas o datos sensibles y privados en la App-Web

 El objetivo final es tener controles de acceso granulares por usuario (o

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

 Autenticación básica (Basic) - HTTP

 Autenticación Digest - HTTP

 Autenticación integrada en dominio (directorio activo) - SSO

 SSL-TLS Certificados digitales cliente (https  443)

 Autenticación de múltiples factores

 Autenticación desde la aplicación Web (basada en formularios)

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

 Credenciales enviadas “en claro” o codificadas (no cifradas) en base 64

 RFC 2617 - usuario y contraseña

 Cada petición HTTP incluye las credenciales

 Protegerlas con HTTPS (SSL/TLS)

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

The HTTP-Header of a standard client requests on some Document in a

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

The HTTP-Header of a standard client requests on some Document in a

La contraseña es enviada en texto claro, se puede descodificar:

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

 RFC2617 – http 1.1 Challenge/Response

 Firma (hash) criptográfica: MD5

 Protección frente a reenvío (replay). Aleatoriedad del nonce y número de

 Se debe emplear un “nonce” criptográfico sensible al tiempo (caducidad)

 Cada petición HTTP incluye las credenciales

 Protegerla con HTTPS (SSL/TLS)

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

 Server response (no authentication)

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

 realm: (parte de la aplicación) a la que el usuario quiere autenticarse

 qop: calidad de protección que establece el servidor

 cnonce: client generated unique data string

 response: the encrypted password

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

 qop: quality of protection

 opaque: se usa para trazar la sesión por parte del servidor

 algorithm: MD5, SHA

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

If the algorithm directive's value is "MD5" or unspecified, then HA1 is

If the algorithm directive's value is "MD5-sess", then HA1 is

If the qop directive's value is "auth" or is unspecified, then HA2 is

If the qop directive's value is "auth-int", then HA2 is

If the qop directive is unspecified, then compute the response as follows:

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

 El cliente puede hacer otra solicitud, reutilizando el valor nonce del

 Corresponde al servidor asegurarse de que el contador (nc)

 Cambiar el método, URI y/o valor del contador se traducirá en

 El servidor debe recordar los valores nonce, no caducados.

 Si el cliente utiliza un valor caducado, el servidor debe responder con el "401" y

 El tiempo mínimo de vigencia asignable de valor nonce es de 10 seg. Tener en

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

 Si se requiere seguridad  Solamente DIGEST

 Seguridad autenticación Digest  depende de la implementación de

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

 http basic authentication

 http digest authentication