Autentificacion

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.

Navegador Servidor
Login: Aladdin, pass: open sesame

“Aladdin:open sesame”
QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Base64
Aladdin
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

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
Hashing
Message Digest (MD4, MD5, …)

Un algoritmo produce como resultado
una secuencia de bits de tamaño fijo
al aplicarlo sobre unos datos
digest = hash(datos, longitud)
digest tiende a ser aleatorio y
uniformemente distribuido
Solo funciona en un sentido
No existe datos = hash-1(digest)
nov-08 Alberto M.F.A. 12

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
Cualquier cambio en los datos, por
mínimo que sea, producirá otro digest
impredeciblemente diferente

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.
Seguridad para WEB (HTTPS)
HTTPS = HTTP Secure

HTTP sobre un protocolo de
transporte seguro
HTTP SSL TCP
SSL también es conocido como TLS

según IETF

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 certificado
Confidencialidad
Integridad
No repudio
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 ( )
m = f (m*, k )
−1
Con:
m, mensaje original
m*, mensaje cifrado
k, clave
Esquema

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 ( 1)
Con: m = f (m*, k 2 )
−1
k1 y k2, claves pública y privada

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:
Su clave privada
Las claves públicas de los demás
Solo N + 1 claves escala mucho
mejor
¿Qué se consigue con clave

asimétrica?
Confidencialidad
Solo lo ve aquel a quien va dirigido
Firma digital
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

Confidencialidad

Firma digital

Autentificación

Intercambio de claves simétricas

Autoridades certificadoras
¿Cómo sé que la clave pública que

tengo es de quien realmente dice
ser?
Puede ser alguien suplantando al original
Las autoridades certificadoras (CAs)
actúan como notarios de la red.
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
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
Verificable con la clave pública de la CA
¡Se debe conocer la clave pública de la
CA!

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
Verising, Tawte, Microsoft, Verizon, etc.
Claves públicas de CA’s

Vienen en:
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

Alerta de seguridad

SSL y claves públicas
1. CA root dan sus claves públicas a

los fabricantes de navegadores

2. Los fabricantes de navegadores

ponen las CA’s en sus navegadores

3. Los sitios WEB obtienen certificados

firmados con la clave privada de
una CA

4. Los sitios WEB

mandan su certificado
con SSL. El navegador
los verifica contra sus
claves de CA’s

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
Web.xml
Colección de recursos, roles y

métodos
Si no hay método todos

están protegidos
Web.xml
Roles
Técnicas
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
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
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
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.
Interfaz filter y ciclo de vida

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
Ejemplo, redirección a login

Ejemplo, redirección, web.xml
<url-pattern> o
<servlet-name>
Los filtros siempre se declaran El orden en el que se forma

antes que los servlets a los que la cadena de filtros es el orden
se aplican. 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.
Interceptores, esquema
API en ActionInvocation
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
LoginInterceptor, ejemplo
struts.xml: declarar el interceptor y
global-results
struts.xml: declarar la pila de
interceptores
Resumen

Autentificacion

Transféré par

Informations du document

Titre original

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

Autentificacion

Transféré par

Droits d'auteur :

Formats disponibles

Autentificación y

El tráfico en Internet puede ser

Autentificación HTTP Básica

Desde el protocolo HTTP 1.0

Autentificación HTTP Básica

Autentificación HTTP Básica

Login: Aladdin, pass: open sesame

Los caracteres ASCII

Cada grupo de 6 bits

Autentificación HTTP digest (hash)

Incorporada en la versión 1.1 de la

Autentificación HTTP digest

Challenge: “nonce” en Base64

nonce(client-IP ":" time-stamp ":" private-key )

MD5: Algoritmo de hash, genera una cadena

Message Digest (MD4, MD5, …)

nov-08 Alberto M.F.A. 12

Si digest es suficientemente largo

nov-08 Alberto M.F.A. 13

Es el más seguro de los disponibles

Seguridad para WEB (HTTPS)

HTTPS = HTTP Secure

SSL también es conocido como TLS

nov-08 Alberto M.F.A. 15

Cifrado con clave simétrica

nov-08 Alberto M.F.A. 18

También conocidos como Sistemas

k1 y k2, claves pública y privada

nov-08 Alberto M.F.A. 19

¿Qué se consigue con clave

nov-08 Alberto M.F.A. 21

nov-08 Alberto M.F.A. 22

nov-08 Alberto M.F.A. 23

nov-08 Alberto M.F.A. 24

Intercambio de claves simétricas

nov-08 Alberto M.F.A. 25

¿Cómo sé que la clave pública que

nov-08 Alberto M.F.A. 27

Las CA raíz autorizan a otras CA

Claves públicas de CA’s

nov-08 Alberto M.F.A. 29

nov-08 Alberto M.F.A. 30

SSL y claves públicas

1. CA root dan sus claves públicas a

nov-08 Alberto M.F.A. 31

SSL y claves públicas

2. Los fabricantes de navegadores

nov-08 Alberto M.F.A. 32

SSL y claves públicas

3. Los sitios WEB obtienen certificados

nov-08 Alberto M.F.A. 33

SSL y claves públicas

4. Los sitios WEB

nov-08 Alberto M.F.A. 34

Autentificación por Programa

Todo lo tenemos que programar

Colección de recursos, roles y

Si no hay método todos

Consultar documentación del

Tipos de autenticación soportados

Autentificación por Formulario

No es segura por sí sola, es necesario

Filtros Servlet HTTP