La primera pareja de mensajes es entre el cliente y el servidor de autentificación. Primeramente, el cliente inicia una petición al KDC (centro de distribución de claves) con AS_REQ. Esta petición estará formada por el cliente principal, el principal de servicio que corresponderá con TGS que siempre será el mismo, la lista de IPs válidas (la cual puede estar vacía, esto indicará que el ticket se podrá utilizar en cualquier ubicación), y por último, el tiempo máximo de vida.AS_REQ =( Principal_client, Principal_service, IP_list, Lifetime) En cuanto a la respuesta AS_REP, el AS comprobará que existe tanto el cliente como el servicio TGS. Se generará una clave de sesión entre ambos, y se creará el ticket temporal TGT. Así pues, la respuesta contendrá el principal servicio TGS, la marca de tiempo, el tiempo de vida, la clave de sesión TGS, todo ello cifrado con la clave de usuario. AS_REP = {krbtgt/REALM@ REALM,Timestamp, Lifetime, SKtgs} Kuser + {TGT} Ktgs El cliente podrá leer la primera parte una vez tenga su propia clave, pero no podrá leer ni modificar el ticket ya que la clave del servicio TGS no la tiene. Así pues, el cliente generará su propia clave solicitando la contraseña de usuario y utilizando la función de creación de clave el argumento de la función.
La segunda pareja de mensajes es entre el cliente y el servidor de tickets. Ahora el cliente ya tiene un ticket temporal válido y una clave de sesión TGS. Por tanto, primero se hace la petición TGS_REQ que está formada por: TGS_REQ = (Principal_service, Lifetime, Authenticator ) + {TGT} Ktgs
El principal servicio que solicita, un tiempo de vida y el autenticador (este formado por el cliente principal y una marca de tiempo, todo esto cifrado con la clave de sesión TGS). Además del ticket temporal cifrado con la clave del TGT. Esta petición llegará al servidor de tickets el cual verificará y con su clave descifrará el ticket temporal y accederá a la clave de sesión que tiene con el cliente. Con la clave SKtgs podrá descifrar el autenticador. Una vez todo es correcto, el servidor de tickets generará una clave de sesión entre cliente y servidor de aplicaciones. Además podrá generar el ticket (TService) definitivo e incluir una respuesta al cliente TGS_REP {Principal_s, Timestamp,Lifetime,Skservice} SKtgs + {Tservice} Kservice. La tercera pareja de mensajes es entre cliente y servidor de aplicaciones. El cliente se autentifica con el ticket, para ello realiza una solicitud al servidor. El método de realizarlo es, primero el cliente genera un nuevo autenticador con la clave de sesión cliente servicio, y luego, el cliente genera la petición con el autenticador y el ticket cifrado que recibió en la etapa anterior. AP_REQ = Authenticador + {Tservice} Kservice. Esta petición llega al servidor el cual dispone de la clave para descifrar el ticket, así obteniendo la clave de sesión cliente servicio. Con esta clave Skservice puede descifrar a la vez el autenticador. Así pues, se comprobará el ticket (que no haya caducado, que el principal C coincide con el ticket y autenticador…). Una vez comprobado el usuario conseguirá acceso a los recursos del servidor.
INYECCION SQL + EJEMPLO
La inyección de SQL es un ataque que afecta a los servidores que tienen acceso a base de datos y pasan los parámetros como consultas SQL.
Ejemplo:
consulta.asp?Nombre=Jeff
SQL =”SELECT * FROM Usuarios WHERE nombre=’”+Texto+”’”%
La consulta será
SELECT * FROM Usuarios WHERE nombre=‘Jeff’
Pero consulta.asp?Nombre=tu’ OR 1=1 OR nombre=‘yo
La consulta será
SELECT * FROM Usuarios WHERE nombre=‘tu’ OR 1=1 OR nombre=‘yo’
DNSBL
DNSBL es una lista negra que está formada por un conjunto de direcciones IP desde las cuales no se debe aceptar correo debido a que son origen de envío de SPAM
MECANISMOS DE SEGURIDAD BASICOS EN HTTP
AUTENTICACIÓN BÁSICA: La autenticación básica de acceso (BA) es un mecanismo que proporciona credenciales a la hora de realizar una petición. Es una técnica simple para reforzar el control de acceso a recursos web, que además no requiere de cookies, identificadores de sesión y páginas login. BA usa cabeceras HTTP estáticas y estándar. En cambio, BA no proporciona confidencialidad a la hora de transmitir las credenciales ya que sólo son codificadas en Base64 pero no son encriptadas o hasheadas. Si se quiere esta confidencialidad se debe usar conjuntamente HTTPS. La función del servidor es mandar una petición de autentificación con el código de respuesta HTTP 401 Not Authorized conteniendo la cabecera WWW-Authenticate. Esta cabecera contiene un ‘realm’ (identificador de grupo). Por otra parte, el cliente construye el Authorization Header combinando en un String las credenciales “username:password”. Ese resultado se codifica en Base64 y se le añade un método de autenticación y un espacio delante. En el caso que el usuario no se autentica correctamente, el servidor le devuelve: Error 401 (No autorizado): las credenciales son incorrectas, Error 403 (prohibido): denegación de la operación sin negociación.
- HTTPS
Es un protocolo de aplicación basado en HTTP que utiliza el cifrado SSL/TLS para crear un canal seguro de comunicación. La diferencia entre HTTP es que las URLs son ahora https y HTTP utiliza el protocolo 80 que en cambio HTTPS utiliza TCP 443.
Este protocolo se aplica en la transmisión de la información confidencial y en la autenticación del servidor web por uso de certificado.
El protocolo de seguridad opera en una subcapa más baja que HTTP, este cifra el mensaje HTTP antes de enviarlo y cuando llega al otro extremo se descifra. Además, utiliza claves públicas y privadas entre cliente y servidor.
Para garantizar la comunicación entre los extremos es necesario el uso de autoridades de certificación como el uso de una PKI para que el usuario pueda examinar el certificado del servidor y el uso de certificados X.509