Autenticación en aplicaciones Web

Autentificación y
Seguridad en
Aplicaciones
Web
Autenticación en Web
El tráfico en Internet puede ser
espiado y alterado con mucha
facilidad
¿Cómo intercambiar datos
confidenciales?
Packet Sniffing
Login y pass
van en caberas
HTTP.
Contenidos en
HTML (texto)
Cabeceras
HTTP en texto
plano
Seguridad, alternativas
… o emplear un
canal seguro
Codificar el mensaje …
Tipos de autenticación
autentificación HTTP > básica
Autentificación HTTP Básica
Desde el protocolo HTTP 1.0
Muy simple
Poco seguro
Cuando el navegador solicita un recurso
(jsp, por ejemplo), el servidor solicita
usuario y contraseña, que viajan codificadas
en base 64 bits.
Se puede reforzar combinándola con
protocolo HTTPs, de forma que las peticiones
HTTP viajen encriptadas.
autentificación HTTP > básica
Autentificación HTTP Básica
Navegador
Servidor
autentificación HTTP > básica
Autentificación HTTP Básica
Login: Aladdin, pass: open sesame
“Aladdin:open sesame”
QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Base64
Aladdin
autentificación HTTP > básica
Codificación Base64
Los caracteres ASCII
se secuencian y se
tomas de 6 en 6
bits.
Cada grupo de 6 bits
es índice de la tabla
de caracteres
Base64
autentificación HTTP > digest
Autentificación HTTP digest (hash)
Incorporada en la versión 1.1 de la
especificación del protocolo HTTP.
Algo más complicada internamente que la
autentificación básica.
La codificación va en base al timestamp
generado por el servidor en el momento de
la petición -> Más difícil de decodificar ->
Más seguro.
No está totalmente difundida ni aceptada por
todos los navegadores y servidores.
autentificación HTTP > digest
Autentificación HTTP digest
Navegador
Servidor
Challenge: “nonce” en Base64
nonce(client-IP ":" time-stamp ":" private-key )
MD5: Algoritmo de hash, genera una cadena
de 32 char a partir de cualquier longitud de mensaje
autentificación HTTP > digest
Hashing
Message Digest (MD4, MD5, …)
Un algoritmo produce como resultado
una secuencia de bits de tamaño fijo
al aplicarlo sobre unos datos
Solo funciona en un sentido
nov-08
digest = hash(datos, longitud)
digest tiende a ser aleatorio y
uniformemente distribuido
No existe datos = hash-1(digest)
Alberto M.F.A.
12
autentificación HTTP > digest
Hashing
Si digest es suficientemente largo
(>= 128 bits) se puede usar como
identificador único de un documento
Prácticamente ningún otro
documento con la misma función
hash() producirá el mismo digest
nov-08
Cualquier cambio en los datos, por
mínimo que sea, producirá otro digest
impredeciblemente diferente
Alberto M.F.A.
13
autentificación HTTP > HTTPS (SSL)
Autentificación HTTPs
Es el más seguro de los disponibles
hoy en día.
Se basa en mecanismos de Clave
Pública (PKI): SSL (aka TLS)
Requiere certificado(s) generado(s)
por una autoridad certificadora (CEA)
Hay un proceso “complicado” de
handshake que garantiza la conexión
segura.
autentificación HTTP > HTTPS (SSL)
Seguridad para WEB (HTTPS)
HTTPS = HTTP Secure
HTTP sobre un protocolo de
transporte seguro
nov-08
HTTP SSL TCP
SSL también es conocido como TLS
según IETF
Alberto M.F.A.
15
autentificación HTTP > HTTPS (SSL)
SSL (o TLS)
El servidor tiene un certificado
opcionalmente el cliente tiene el suyo
Permite intercambio seguro de
datos (p.e. claves de sesión)
Usa algoritmos de clave simétrica y
asimétrica
Del servidor siempre,
Ofrece:
del cliente si tiene
Autentificación
Confidencialidad
Integridad
No repudio
certificado
autentificación HTTP > HTTPS (SSL)
Cifrado con clave simétrica
Ambas partes (A y B) conocen la
clave
Existe una pareja de funciones, de
forma que: m* = f m, k
( )
−1
m = f (m*, k )
Con:
nov-08
m, mensaje original
m*, mensaje cifrado
k, clave
Alberto M.F.A.
17
autentificación HTTP > HTTPS (SSL)
Esquema
nov-08
Alberto M.F.A.
18
autentificación HTTP > HTTPS (SSL)
Claves asimétricas
También conocidos como Sistemas
de clave pública (PKI)
Cada parte tiene una pareja de
claves
Se cumple que m* = f m, k
Con:
nov-08
( 1)
−1
m = f (m*, k 2 )
k1 y k2, claves pública y privada
Alberto M.F.A.
19
autentificación HTTP > HTTPS (SSL)
Claves asimétricas
Lo que se cifra con una se puede
descifrar con la otra y viceversa
La clave pública se da a todos los
interlocutores
La clave privada se guarda bajo 7
llaves
Cada interlocutor tiene:
nov-08
Su clave privada
Las claves públicas de los demás
Solo N + 1 claves escala mucho
mejor
Alberto M.F.A.
20
autentificación HTTP > HTTPS (SSL)
¿Qué se consigue con clave
asimétrica?
Confidencialidad
Firma digital
nov-08
Solo lo ve aquel a quien va dirigido
Si se combina con hash
El que lo recibe puede estar seguro de
que lo envió el poseedor de la clave
privada
No repudio
Autentificación
Alberto M.F.A.
21
autentificación HTTP > HTTPS (SSL)
Confidencialidad
nov-08
Alberto M.F.A.
22
autentificación HTTP > HTTPS (SSL)
Firma digital
nov-08
Alberto M.F.A.
23
autentificación HTTP > HTTPS (SSL)
Autentificación
nov-08
Alberto M.F.A.
24
autentificación HTTP > HTTPS (SSL)
Intercambio de claves simétricas
nov-08
Alberto M.F.A.
25
autentificación HTTP > HTTPS (SSL)
Autoridades certificadoras
¿Cómo sé que la clave pública que
tengo es de quien realmente dice
ser?
Las autoridades certificadoras (CAs)
actúan como notarios de la red.
nov-08
Puede ser alguien suplantando al original
Dan fe de que el poseedor de la clave
privada es quien dice ser
Tienen sus protocolos de autentificación
No generan las claves solo las firman
Alberto M.F.A.
26
autentificación HTTP > HTTPS (SSL)
Certificados
Las claves públicas validadas por CA
Contienen
La clave pública
Datos de identificación del propietario
Fecha de expiración
Firma digital de la CA
nov-08
Verificable con la clave pública de la CA
¡Se debe conocer la clave pública de la
CA!
Alberto M.F.A.
27
autentificación HTTP > HTTPS (SSL)
Jerarquías de CA
Las CA raíz autorizan a otras CA
Esas CA pueden autorizar a otras,
etc
Al recibir un certificado se debe
recorrer toda la cadena de
certificaciones hasta llevar a una
raíz en la que se confíe
Claves públicas raíz no hay muchas
nov-08
Verising, Tawte, Microsoft, Verizon, etc.
Alberto M.F.A.
28
autentificación HTTP > HTTPS (SSL)
Claves públicas de CA’s
Vienen en:
nov-08
Los sistemas operativos
Los navegadores, etc
Necesidad de actualizarse, cada
nueva versión actualiza las claves
públicas
Si se recibe certificado de CA
desconocida hay que “Depositar
confianza” expresamente
Alberto M.F.A.
29
autentificación HTTP > HTTPS (SSL)
Alerta de seguridad
nov-08
Alberto M.F.A.
30
autentificación HTTP > HTTPS (SSL)
SSL y claves públicas
1.
nov-08
CA root dan sus claves públicas a
los fabricantes de navegadores
Alberto M.F.A.
31
autentificación HTTP > HTTPS (SSL)
SSL y claves públicas
2.
nov-08
Los fabricantes de navegadores
ponen las CA’s en sus navegadores
Alberto M.F.A.
32
autentificación HTTP > HTTPS (SSL)
SSL y claves públicas
3.
nov-08
Los sitios WEB obtienen certificados
firmados con la clave privada de
una CA
Alberto M.F.A.
33
autentificación HTTP > HTTPS (SSL)
SSL y claves públicas
4.
nov-08
Los sitios WEB
mandan su certificado
con SSL. El navegador
los verifica contra sus
claves de CA’s
Alberto M.F.A.
34
autentificación por programa
Autentificación por Programa
Todo lo tenemos que programar
La aplicación coteja la contraseña contra su
propio sistema de control de usuarios
Hay que basarla en protocolos seguros de
comunicación como HTTPs (SSL) para evitar
que nadie “escuche” la contraseña
interpretando los paquetes HTTP.
Más tedioso de programar
Ventajas: No dependemos de la
autentificación del entorno Más portable.
Ejemplo por
programa
autentificación por contenedor
Especificación
En web.xml
Una colección de recursos (URLs)
solo podrán ser accedidos por
usuarios que actúen bajo
determinado rol usando
determinados métodos HTTP
La autenticación para cada ámbito
de seguridad (realm) se hará
usando alguna de las técnicas
establecidas por la especificación de
servlets
autentificación por contenedor
Web.xml
Colección de recursos, roles y
métodos
Si no hay método todos
están protegidos
autentificación por contenedor
Web.xml
Roles
Técnicas
autentificación por contenedor
Usuario y roles
BDD de usuarios y roles
El contenedor consulta los datos de una
fuente directamente
Tipos de fuentes y configuración
dependen de la implementación del
contenedor
Base de datos (tablas: usuarios, roles)
Ficheros XML
Ficheros de propiedades
. . .
Consultar documentación del
contenedor
autentificación por contenedor
Tipos de autenticación soportados
BASIC
DIGEST
FORM
CLIENT-CERT
autentificación por contenedor > formulario
Autentificación por Formulario
No es segura por sí sola, es necesario
combinarla con HTTPs (SSL – Secure Socket
Layer)
Permite controlar la apariencia de la pantalla
de login
La pantalla de login es HTML estándar, sigue
un convenio de nombres
Action: j_security_check
Login: j_username
Pass: j_password
autentificación por servlet > filtros
Filtros Servlet HTTP
Incorporados en la versión 2.3 de la
especificación de servlets.
Interceptan la invocación del servlet ANTES
de que sea invocado el propio servlet.
Permiten examinar y modificar la request
antes de que le llegue al servlet.
Permite modificar el response y redirigir, en
caso necesario, la petición a otro recurso
distinto.
Ideales para el control de acceso de
usuarios autentificados
autentificación por servlet > filtros
Filtros, ventaja
Permiten hacer autenticación por
programa de forma transversal a la
aplicación el código de la
aplicación no se modifica
Lo habitual es redireccionar a
formulario necesario HTTPs
Sigue siendo autenticación por
formulario
A parte de autenticación permiten
añadir de forma genérica “aspectos”
a la aplicación
autentificación por servlet > filtros
Filtros Servlet HTTP
Interfaz javax.servlet.Filter
Tres métodos:
void init(FilterConfig config) throws
ServletException Invocado antes de que el filtro
entre en servicio. Permite configurar el filtro.
void destroy() Invocado cuando el filtro dejar de
estar en servicio.
void doFilter(ServletRequest req,
ServletResponse res, FilterChain chain) throws
IOException, ServletException: Método que
implementará el filtrado.
autentificación por servlet > filtros
Interfaz filter y ciclo de vida
autentificación por servlet > filtros
Procesamiento típico en un filtro
―
Examinar las cabeceras de request
[Si procede]Preprocesar la petición
Invocar al resto de la cadena de filtros
[Si procede]Postprocesar la petición
A la ida puede:
―
―
―
Responder él a la request y terminar proceso
Abortar la ejecución UnavailableException
Redirigir a otra URL
Añadir info a session, request o contexto
A la vuelta puede:
Examinar la respuesta, modificarla
Examinar las cabeceras añadidas
autentificación por servlet > filtros
Ejemplo, redirección a login
autentificación por servlet > filtros
Ejemplo, redirección, web.xml
<url-pattern> o
<servlet-name>
Los filtros siempre se declaran
antes que los servlets a los que
se aplican.
El orden en el que se forma
la cadena de filtros es el orden
de la declaración de
<filter-mapping> para cada
recurso afectado
autentificación por servlet > struts interceptor
Struts interceptor
Mismos conceptos que Servlet Filters
pero incrustado en el Stack de
interceptores de Struts2
Ciclo de vida similar
Recibe todo en ActionInvocation
Action, Stack, etc.
InvocationContext: Session, request, etc.
autentificación por servlet > struts interceptor
Interceptores, esquema
autentificación por servlet > struts interceptor
API en ActionInvocation
autentificación por servlet > struts interceptor
Pasos para la creación de
interceptores Struts
Crear la clase interceptora
Hereda de AbstractInterceptor
Implementa StrutStatics
Para heredar constantes declaradas en el
interfaz
Declarar el interceptor
Añadirlo al Stack de interceptores
Añadir global-result
En struts.xml
autentificación por servlet > struts interceptor
LoginInterceptor, ejemplo
struts.xml: declarar el interceptor y
global-results
struts.xml: declarar la pila de
interceptores
Resumen