published on marco de desarrollo de la junta de andalucía ... · recogiendo una serie de...
TRANSCRIPT
Published on Marco de Desarrollo de la Junta de Andalucía (http://127.0.0.1/servicios/madeja)
Control de Acceso y AutenticaciónCódigo: SEG_AccesoSe analizan la vulnerabilidades que pueden darse en las aplicaciones a la hora de identificar sus usuarios y los permisos queestos poseen. Recogiendo una serie de recomendaciones para el desarrollo de aplicaciones, que tenidas en cuenta, ayuden amitigar los riesgos de producirse situaciones como el escalado de privilegios o la suplantación de identidad.
Hay dos procesos distintos que intervienen cuando se trata de permitir a un usuario acceder a páginas específicas de un sitioweb:
La autenticación es el proceso de identificación de un individuo sobre la base de sus credenciales (normalmente nombre deusuario y contraseña)El objetivo de la autenticación es decidir si "alguien es quien dice ser". Hay tres formas de reconocer a un usuario, quese conocen como factores:
Algo que saben, como una contraseña o PIN
Algo que tienen, tal como una licencia de conducir o tarjeta de crédito
Algo que son, como las huellas digitales o la inserción de los patrones
El control de acceso es el proceso de decidir si el usuario tiene permiso para ejecutar algo o no.También llamado autorización, se refiere a la gestión del acceso a los recursos protegidos y al proceso de determinar si unusuario está autorizado a acceder a un recurso particular. Por ejemplo, muchas aplicaciones web cuentan con recursos quesólo están disponibles para los usuarios autenticados, recursos que sólo están disponibles para los administradores, y losrecursos que están disponibles para todos.Así, al establecer privilegios de acceso a los usuarios podemos asegurar laconfidencialidad y disponibilidad de la información; pero, además, podemos:
Que sólo las personas autorizadas podrán acceder a ciertos recursos (sistemas, equipos, programas, aplicaciones,bases de datos, redes, etc…) por sus funciones laborales.
Nos permiten identificar y auditar los accesos realizados, estableciendo controles de seguridad internos.
Documentar los procedimientos de acceso a las diferentes aplicaciones que tratan datos personales.
En definitiva, controlar los accesos desde diferentes vertientes: red, sistemas y aplicaciones.Hoy en día es muy común la escalada de privilegios, que no es más que la obtención de los privilegios del administrador.Por ello, debe existir una política o normativa específica que establezca el uso de mecanismos para impedir intentos deescalado de privilegios en nuestras aplicaciones web.Se considera que un sistema aplica políticas para evitar el escalado deprivilegios cuando: No es posible acceder a información del sistema que pueda ser utilizada para la escalada de privilegios, noes posible ejecutar acciones haciéndose pasar por otro usuario, etc.
ObjetivosAsegurar la identidad de los usuarios que acceden a las aplicaciones
Garantizar el acceso a recursos protegidos
Código Título Tipo CarácterLIBP-0271 API's privilegiadas Directriz Obligatoria
LIBP-0253 Autenticación Directriz Obligatoria
PAUT-0234 Autorizaciones personalizadas Directriz No Recomendada
LIBP-0269 Canal de comunicación Directriz Obligatoria
LIBP-0272 Contraseñas Directriz Obligatoria
LIBP-0254 Control de acceso Directriz Obligatoria
LIBP-0263 Listas de control Directriz Recomendada
LIBP-0285 Manejo de contraseñas perdidas Directriz Obligatoria
LIBP-0258 Nombres de usuario Directriz Recomendada
LIBP-0264 Uso de permisos en recursos críticos Directriz Obligatoria
Código Título Tipo CarácterRECU-0563 Ataques de reflexión sobre la autenticación en Java Ejemplo Obligatorio
RECU-0559 Autenticación Referencia Obligatorio
RECU-0564 Cacheo del resultado de una operación privilegiada en Ejemplo Obligatorio1
RECU-0564 Java Ejemplo Obligatorio
RECU-0562 Canal accesible por un punto no final en Java Ejemplo Obligatorio
RECU-0667 Comprobación de la perdida de autenticación sobrefunciones significativas en Java Ejemplo Obligatorio
RECU-0555 Comprobar los permisos de un nodo específicoutilizando node_access en Drupal Ejemplo Obligatorio
RECU-0566 Comprobar los permisos mediante la funciónuser_access en Drupal Ejemplo Obligatorio
RECU-0210 Conceptos de seguridad en la capa de negociomediante Spring Referencia Recomendado
RECU-0213 Configuración de Spring Security Referencia Recomendado
RECU-0556 Consultas para el acceso a nodos restringidos enDrupal Ejemplo Recomendado
RECU-0622 Controlador Java del DNI electrónico Referencia Recomendado
RECU-0675 Envío de credenciales por correo electrónico enDrupal Ejemplo No recomendado
RECU-0664 Limitación del número de autenticaciones en Java Ejemplo Recomendado
RECU-0565 Manejar los permisos mediante la función hook_perm()en Drupal Ejemplo Obligatorio
RECU-0582 Manejo de las contraseñas perdidas en PHP Ejemplo Obligatorio
RECU-0544 Manejo de permisos en métodos de EJB Ejemplo Obligatorio
RECU-0621 Portal CERES Referencia Recomendado
RECU-0666 Retardo tras autenticación fallida en PHP Ejemplo Recomendado
RECU-0650 Sistemas anti-bots Referencia Recomendado
RECU-0603 Uso de getPermissions() Ejemplo Obligatorio
RECU-0601 Uso de java.security.AllPermission Ejemplo Obligatorio
RECU-0674 Uso del modulo Login Security en Drupal Ejemplo Obligatorio
RECU-0602 Variables externas en bloques doPrivileged Ejemplo Obligatorio
Source URL: http://127.0.0.1/servicios/madeja/contenido/subsistemas/desarrollo/control-acceso-y-autenticacion
2
API's privilegiadasÁrea: Control de Acceso y AutenticaciónTipo de pauta: DirectrizCarácter de la pauta: Obligatoria
Código: LIBP-0271
Aspectos a tener en cuenta a la hora de utilizar API's privilegiadas
Las APIs privilegiadas son aquellas que tienen métodos encargados de acceder a los datos sensibles de la aplicación y de losusuarios, por lo que para poder utilizarlas es necesario disponer de privilegios específicos.
Un atacante podría obtener estos privilegios si la llamada a uno de estos métodos no se realiza de acuerdo a lo establecido en laAPI.
A la hora de llamar a la API hay que tener en cuenta lo siguiente:
Asegurar que las suposiciones hechas por la API son válidas, como la validez de los argumentos.
Tener en cuenta las debilidades conocidas en el diseño / implementación de la API.
Llamar a la API desde un contexto seguro
Si no se cumplen estos requisitos al llamar a la API, puede que un atacante eleve sus privilegios, secuestre el proceso o robedatos confidenciales.
PautasTítulo CarácterLlamada a la API Obligatoria
Llamada segura Obligatoria
Control de errores Obligatoria
Liberación de privilegios Obligatoria
Llamada a la API
Comprobar que el usuario que llama a la API privilegiada tiene los permisos específicos necesarios
Antes de efectuar la llamada a un método de la API privilegiada debemos comprobar que el usuario que lo llama tiene lospermisos necesarios para hacerlo.
Volver al índice
Llamada segura
Comprobar que el entorno es seguro antes de la llamada a la API
Antes de realizar la llamada a la API se debe verificar que el entorno se encuentra en un estado fuerte, coherente y esperado.Volver al índice
Control de errores
Controlar la salida en caso de error
Controlar que un fallo o un error no deja el sistema en un estado inseguro, donde los privilegios no son correctos y posibilitenuna escalada de privilegios.
Volver al índice
Liberación de privilegios
Liberar los privilegios después de la llamada a la API
Verificar que, una vez la API finaliza la llamada, se restablece el entorno correctamente.Volver al índice
Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/libro-pautas/2713
4
AutenticaciónÁrea: Control de Acceso y AutenticaciónTipo de pauta: DirectrizCarácter de la pauta: Obligatoria
Código: LIBP-0253
Se deben tener en cuenta las siguientes recomendaciones para garantizar la autenticación segura de los usuarios
PautasTítulo CarácterAutenticación negativa Obligatoria
Cabecera de referencia No Recomendada
Nombre de usuario en las consultas Recomendada
Número de registros devueltos Obligatoria
Pérdida de autenticación sobre funciones significativas Obligatoria
Uso de POST en los procesos de autenticación Obligatoria
Limitar el número de autenticaciones fallidas Obligatoria
Retardo tras autenticación fallida Recomendada
Autenticaciones en el cliente No Recomendada
Tokens en el cliente No Recomendada
Asociación de tokens de autorización con identificador de sesión Obligatoria
Envío de tokens Obligatoria
Firma electrónica Recomendada
Uso de certificados digitales Recomendada
Uso de DNIe Recomendada
Sistemas anti robots Recomendada
Geolocalización Recomendada
Sistemas de coordenadas Recomendada
Uso de Single Sign-On de escritorio Recomendada
Autenticación negativa
Utilizar la autenticación negativa
A la hora de comprobar la autenticación del usuario, debe partirse del caso en el que, por defecto, el intento de autenticaciónes incorrecto, debiendo confirmarse en el proceso de autenticación la corrección del intento. Mediante este enfoque, en casode producirse algún tipo de error durante la autenticación, siempre se negará el acceso.
Volver al índice
Cabecera de referencia
Evitar la utilización de cabeceras de referencia
En una cabecera de referencia se almacena información acerca de la ubicación previa de la que vino el navegador. En la mayorparte de los casos, el uso de esta cabecera de referencia no es recomendable, ya que es muy fácil que su información seamodificada o falsificada por los atacantes. No puede asignarse confianza a su valor, y puede ser difícil de limpiar y usarcorrectamente. Los programas que desplieguen el contenido de cabeceras de referencia, como un analizador de registrosWeb, deben protegerse cuidadosamente contra XSS y otros ataques de inyección HTML.
Si la aplicación tiene que usar cabecera de referencia, deberá únicamente hacerlo con un mecanismo de defensa enprofundidad, y no tratar de limpiar su contenido, solo rechazarlo si no es correcto. Todo código tiene errores, así que debeminimizarse la cantidad de código que trata con la cabecera de referencia.
Volver al índice
Nombre de usuario en las consultas
Usar sólo el nombre de usuario como clave para las consultas
5
Se debe evitar la búsqueda por varias claves dado que, de esta forma, aumentamos las posibilidades de que una de estasclaves sea vulnerable.
Se recomienda que siempre que haya que hacer una búsqueda se haga con el mínimo número de claves posibles. Esrecomendable protegerse de esta situación utilizando sólo el nombre de usuario como clave para las consultas.
Volver al índice
Número de registros devueltos
Verificar que sólo se devuelve un registro
En el proceso de autenticación, cuando se consultan los datos del usuario que está realizando el intento de acceso, debecomprobarse que sólo se devuelve un registro o ninguno, no permitiendo el acceso si se recupera más de un registro
Volver al índice
Pérdida de autenticación sobre funciones significativas
Comprobar la autenticación sobre las funciones significativas
La pérdida de autenticación sobre funciones significativas sucede cuando el software no realiza ninguna comprobación deautenticación al acceder a una funcionalidad significativa (que requiere una identificación del usuario) o que consume unacantidad significativa de recursos.
Las consecuencias de no realizar esta comprobación puede ir desde la ejecución de funcionalidades restringidas, como lalectura o modificación de datos sensibles, el acceso a la funcionalidad privilegiada administrativa o incluso la denegación delservicio debido a la gran cantidad de recursos que el usuario malintencionado puede demandar.
Se deben controlar que no existen funciones significativas de negocio fuera del marco de la autenticación.Volver al índice
Uso de POST en los procesos de autenticación
Utilizar siempre métodos POST en los procesos de autenticación.
Si elegimos emplear un método GET, todas las variables se enviarán por la dirección html y serán visibles desde la URL. Esdecir, cuando se recargue la página web, al haber enviado el formulario, podrán obtenerse los valores de las variables. Esto noes aceptable si estamos hablando del proceso de autenticación, por lo que es recomendable utilizar métodos POST, que seencargan de ocultar los valores del envío proporcionando así una mayor seguridad.
Volver al índice
Limitar el número de autenticaciones fallidas
Limitar el número de accesos fallidos consecutivos
Limitar el número de fallos consecutivos permitidos en una autenticación es una protección bastante eficaz para prevenir losataques de fuerza bruta.
Hay que tener especial cuidado del entorno en el que se aplica, ya que este mecanismo de seguridad puede ser utilizado pararealizar ataques de denegación de servicio contra otros usuarios. Sólo podría aplicarse en contexto donde el usuario puedacontactar directamente con el administrador, como por ejemplo una empresa, organismo de la Junta, etc
Volver al índice
Retardo tras autenticación fallida
Introducir un retardo tras un intento de autenticación fallido
Introduciendo un retardo que obligue a que pase un tiempo determinado antes de volver a intentar una autenticación sereducen las posibilidades de éxito de los ataques de fuerza bruta.
Volver al índice
Autenticaciones en el cliente
No validar la autenticación o autorización en el lado cliente
No llevar a cabo ningún tipo de autenticación o autorización en el lado cliente mediante cabeceras, cookies, campos deformulario escondidos o argumentos en la dirección URL.
Volver al índice
Tokens en el cliente6
Desconfiar de tokens de autorización o autenticación en el lado del cliente
Los tokens de autorización o autenticación que se encuentren en el lado del cliente pueden ser fácilmente modificados confines maliciosos. Por tanto, estos tokens no deben ser considerados como confiables.
Volver al índice
Asociación de tokens de autorización con identificador de sesión
Asociar el identificador de sesión con los tokens de autenticación, flags o estados.
Cuando la aplicación confirme que un usuario se autentica, asocie el identificador de sesión con los tokens de autenticación,flags o estados.
Volver al índice
Envío de tokens
No enviar tokens a través de medios no seguros.
No enviar ningún tipo de token de autenticación o autorización en cabeceras, cookies, campos de formulario ocultos o comoargumentos de la dirección URL.
Volver al índice
Firma electrónica
Usar la firma digital para firmar documentos telemáticamente.
La firma electrónica va mucho más allá de la firma manuscrita en cuanto a su potencial y a las capacidades que posee. Es unaherramienta universal que puede ser utilizada en diversos ámbitos y escenarios. Además, la firma electrónica es otro de loselementos básicos que necesitamos para poder realizar un trámite de forma completamente electrónica. La mayoría detrámites, transacciones y operaciones que realizamos en Internet no precisan de nuestra firma.
Para que los trámites en los que es necesaria la firma también estén disponibles a través de Internet, es fundamental que eseúltimo paso, donde llevamos a cabo la firma de un documento, podamos realizarlo también de forma electrónica.
Desde el momento en que un documento es firmado, adquiere un conjunto de propiedadesVolver al índice
Uso de certificados digitales
Usar certificados digitales para evitar suplantaciones de identidad de usuarios.
Se trata de disponer de un documento oficial, expedido por una entidad reconocida y acreditada, que nos permitaidentificarnos y demostrar nuestra identidad.
Un certificado electrónico puede emitirlo en principio cualquier organización que disponga de la infraestructura necesaria, perosi esta entidad no está acreditada como emisor de certificados electrónicos o CA (Certification Authority), los certificados queemita no serán reconocidos y, por tanto, no podremos acreditar una identidad reconocida con ellos
El certificado digital permite autentificar y garantizar la confidencialidad de las comunicaciones entre ciudadanos, empresasu otras instituciones públicas a través de las redes abiertas de comunicación. Se recomienda el uso de certificados digitalespara garantizar que únicamente el usuario que se identifica puede acceder a la información, evitando así las suplantaciones.
Volver al índice
Uso de DNIe
Usar el DNIe como mecanismo de autenticación para evitar suplantaciones de identidad de usuarios.
El DNIe además de su uso tradicional, nos permite acceder a los nuevos servicios de la Sociedad de la Información, ampliandonuestras capacidades de actuar a distancia con las Administraciones Públicas, con las empresas y con otros ciudadanos.Gracias a que incorpora un chip, capaz de guardar y procesar internamente información de forma segura, se pueden recudir loscasos de suplantación de identidad y de fraude.
Volver al índice
Sistemas anti robots
Garantizan que quien envía el formulario es una persona y no una máquina
7
Los captchas se utilizan en los envíos de formularios e intentan garantizar que quien los envían son verdaderamente personas,en lugar de máquinas.
Volver al índice
Geolocalización
Controlar desde donde se suele conectar el usuario.
Es un mecanismo que registra las localizaciones desde las que se conecta el usuario. En caso de que se acceda desde algunadirección no registrada, el sistema alertará al usuario y preguntará si desea registrar la dirección. En algunos casos podrásolicitar información personal al usuario para tratar de garantizar la identidad de la persona que esta accediendo. Ademásnotificará posteriormente mediante correo electrónico del registro o el acceso desde esa posición.
Volver al índice
Sistemas de coordenadas
Solicitar al usuario que introduzca el valor de una coordenada de una tarjeta cada vez que quiera acceder a un recursocrítico
La Tarjeta de Coordenadas contiene una matriz o serie de números única para cada usuario.
A la hora de acceder a un recurso crítico protegido por una Tarjeta de Coordenadas el sistema requerirá el número que seencuentra impreso en alguna celda.
Volver al índice
Uso de Single Sign-On de escritorio
Utilizar Single Sing-On de escritorio como mecanismo de autenticación
El Single-Sign-On (SSO) de escritorio permite al usuario acceder a las aplicaciones que estén configuradas, identificándoseuna única vez para acceder a las aplicaciones. El SSO es una solución que permite simplificar el uso diario de los sistemas yaplicaciones por parte de los usuarios, simplifica la administración de credenciales y permite incrementar los niveles deseguridad.
Volver al índice
PautasÁrea: Arquitectura » Arquitectura de Sistemas de Información » GUIA: Gestión Unificada de Identidades de Andalucía
Código Título Tipo CarácterLIBP-0202 Integración en Autenticación Directriz Recomendada
LIBP-0208 Integración de aplicaciones con el Single Sign-On de Escritorio Directriz Obligatoria
Área: Desarrollo » Seguridad
Código Título Tipo CarácterLIBP-0360 Uso de applets Directriz Obligatoria
RecursosÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterRECU-0563 Ataques de reflexión sobre la autenticación en Java Ejemplo Obligatorio
RECU-0559 Autenticación Referencia Obligatorio
RECU-0667 Comprobación de la perdida de autenticación sobrefunciones significativas en Java Ejemplo Obligatorio
RECU-0210 Conceptos de seguridad en la capa de negociomediante Spring Referencia Recomendado
RECU-0622 Controlador Java del DNI electrónico Referencia Recomendado
RECU-0664 Limitación del número de autenticaciones en Java Ejemplo Recomendado
RECU-0650 Sistemas anti-bots Referencia Recomendado
RECU-0621 Portal CERES Referencia Recomendado
RECU-0666 Retardo tras autenticación fallida en PHP Ejemplo Recomendado
RECU-0674 Uso del modulo Login Security en Drupal Ejemplo Obligatorio
8
Autenticidad ENS LOPD Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/libro-pautas/253
9
Autorizaciones personalizadasÁrea: Control de Acceso y AutenticaciónTipo de pauta: DirectrizCarácter de la pauta: No Recomendada
Código: PAUT-0234
Evitar codificar procedimientos de autorización de forma personalizada
Evitar que, en la medida de lo posible, el equipo de desarrollo codifique sus propios métodos de acceso a los distintos recursospara agilizar la programación de la aplicación y evitar de esta manera que se escriba más código de la cuenta y la posibilidadgenerar errores de codificación.En su lugar, se recomienda la utilización de frameworks de seguridad (como Spring Segurity) que permiten manejar de manerafácil y efectiva los procesos principales de la seguridad de un sistema y cubrir los vacíos y puntos débiles de estos.
RecursosÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterRECU-0213 Configuración de Spring Security Referencia Recomendado
Autenticidad ENS Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/pauta/234
10
Canal de comunicaciónÁrea: Control de Acceso y AutenticaciónTipo de pauta: DirectrizCarácter de la pauta: Obligatoria
Código: LIBP-0269
Asegurar el canal de comunicación
Para establecer una comunicación segura entre dos partes, es importante verificar adecuadamente la identidad de las entidadesen cada uno de los extremo del canal de comunicación. Si no se hace adecuadamente, esta situación puede tenerconsecuencias negativas, como perder la confianza en la entidad en el otro extremo del canal.
Un atacante puede aprovechar esta falta de comprobaciones para interponerse entre las entidades y hacerse pasar por laentidad original.
PautasTítulo CarácterUso de claves diferentes para diferentes entidades Obligatoria
Certificados Obligatoria
Auto aprobación Recomendada
Envío seguro de credenciales de autenticación Obligatoria
Uso de claves diferentes para diferentes entidades
Usar diferentes claves para las diferentes entidades
Debemos usar diferentes claves para diferentes entidades ya que, si se emplea la misma clave precompartida para lacomunicación con un número de entidades diferentes, se puede comprometer este protocolo sin tener la clave correctamediante el empleo de un ataque de reflexión.
Volver al índice
Certificados
Utilizar certificados para las entidades
Se deben utilizar certificados ya que estos vinculan una identidad a una clave criptográfica, permitiendo autenticar a uncomunicador.
Normalmente los certificados contienen la identidad del sujeto, la clave pública, la fecha de emisión y/o expiración cifradamediante una función de hash usando la clave privada del emisor.
Volver al índice
Auto aprobación
Probar nuestro propio certificado antes de establecer el canal de comunicación
Es recomendable que la parte que establece el canal de comunicación pruebe su propio certificado de identidad antesde iniciar la petición.
Volver al índice
Envío seguro de credenciales de autenticación
Utilizar el protocolo https(SSL) para protegerse de los escaneos de información
El uso de SSL es una manera eficaz de proteger la exposición del contenido de las peticiones HTTP y sus respuestascorrespondientes.
Toda solicitud, que para obtener un recurso utiliza el esquema https, está protegida contra el escaneo de contraseña. Es unabuena práctica utilizar siempre SSL para el envío de credenciales de autenticación, siendo, además, recomendable considerarel uso de SSL para todas las solicitudes que contienen un identificador de sesión, porque esto ayuda a proteger a los usuarioscontra secuestros de sesión.
Volver al índice
11
RecursosÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterRECU-0562 Canal accesible por un punto no final en Java Ejemplo Obligatorio
Área: Desarrollo » Seguridad » Cifrado
Código Título Tipo CarácterRECU-0570 Conexión sin encriptación de la información Ejemplo Obligatorio
ENS Integridad LOPD Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/libro-pautas/269
12
ContraseñasÁrea: Control de Acceso y AutenticaciónTipo de pauta: DirectrizCarácter de la pauta: Obligatoria
Código: LIBP-0272
Utilizar contraseñas para evitar que las personas sin autorización puedan acceder al sistema.
Es necesario proteger la aplicación mediante el uso de contraseñas, ya que de esta manera, se puede controlar quién accede ala aplicación.
A continuación se muestran una serie de indicaciones sobre el manejo de dichas contraseñas.
PautasTítulo CarácterCambio de contraseña Obligatoria
Asegurar el cambio de contraseña Obligatoria
Auto-completar No Recomendada
Contraseñas irreversibles Obligatoria
Contraseñas en blanco No Recomendada
Longitud Obligatoria
Caracteres especiales Recomendada
Periodo de validez Recomendada
Cambio de contraseña
Dar al usuario la opción de cambiar de contraseña.
Se debe dar al usuario la posibilidad de cambiar la contraseña, ya que esta puede haber sido desvelada por el propio usuario orota por algún agente externo malintencionado.
Volver al índice
Asegurar el cambio de contraseña
Requerir la contraseña anterior y la confirmación de la contraseña nueva.
Para poder cambiar la contraseña actual, la función debe solicitar:
La contraseña anterior. Para evitar que alguien que no conozca la contraseña la cambie
La nueva contraseña
Una confirmación de la nueva contraseña. Para evitar que se produzcan errores por haber introducido la nueva contraseñade forma incorrecta.
Volver al índice
Auto-completar
Desactivar la función auto-completar para prevenir que los navegadores recuerden cualquier información que se hayaintroducido.
Se debe desactivar la función auto-completar para prevenir que los navegadores guarden nuestra información y esta quede,de forma involuntaria, almacenada en el equipo que se ha empleado para acceder a la aplicación.
Volver al índice
Contraseñas irreversibles
Garantizar que las contraseñas sean irreversibles.
Las contraseñas son secretas. No hay razón para descifrarlas bajo ninguna circunstancia. Por lo tanto, no hay razón paraalmacenar contraseñas en forma reversible.
Las contraseñas se deben proteger mediante mecanismos de cifrado.13
Volver al índice
Contraseñas en blanco
No permitir el uso de contraseñas en blanco
La aplicación no debe permitir introducir contraseñas en blanco. Si se permitieran, no habría seguridad en la aplicación, ya quecualquiera que conociese nuestro usuario seria capaz de acceder al sistema.
Volver al índice
Longitud
Exigir un número mínimo de caracteres a las contraseñas
Si bien la longitud mínima requerida para una contraseña puede variar en función de la criticidad del sistema que protege, serecomienda que se establezca siempre un número mínimo de caracteres, con el fin de dificultar un intento de ruptura de lacontraseña mediante el enfoque de fuerza bruta.
Volver al índice
Caracteres especiales
Emplear caracteres especiales en la contraseña.
Se recomienda que las contraseñas contengan caracteres especiales como (*,#,@...), ya que el empleo de estos caracteresdisminuye la efectividad de los algoritmos de descifrado de contraseñas que emplean diccionarios de datos.
Volver al índice
Periodo de validez
Establecer un periodo máximo de validez de la contraseña
Se debería establecer un periodo máximo a partir del cual una contraseña debe ser cambiada, ya que cuanto más tiempo seemplee la misma contraseña, mayores son las posibilidades de que sea desvelada a otro usuario por accidente o de que searota por un proceso malintencionado.
Se deberá avisar al usuario que su contraseña va a expirar y darle un tiempo para que la cambie.Volver al índice
Autenticidad ENS LOPD Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/libro-pautas/272
14
Control de accesoÁrea: Control de Acceso y AutenticaciónTipo de pauta: DirectrizCarácter de la pauta: Obligatoria
Código: LIBP-0254
Se deben tener en cuenta las siguientes indicaciones para el control de acceso y privilegios de los usuarios en lasaplicaciones
PautasTítulo CarácterManejo de permisos y privilegios Obligatoria
Asignación incorrecta de privilegios Obligatoria
Cacheo del resultado de una operación privilegiada No Recomendada
Rutinas de autorización Recomendada
Manejo de permisos por defecto Obligatoria
Cuentas de usuarios Obligatoria
Acceso a base de datos Obligatoria
Manejo de permisos y privilegios
Garantizar que los permisos y privilegios sean suficientes y que, además, sean los correctos.
La aplicación puede tener un mal funcionamiento si no tiene suficientes privilegios para acceder a recursos o funciones segúnlo especificado por sus permisos.
Esto puede provocar que siga caminos inesperados en el código, existiendo la posibilidad de dejar la aplicación en un estadono válido.
Es necesario revisar que se tiene éxito al acceder a un recurso o una funcionalidad del sistema desde la aplicación, y el usoadecuado del manejo del error si no se realiza correctamente.
Realizar esta comprobación incluso si se está operando en un modo muy privilegiado, porque los errores o las condiciones deentorno aún podrían provocar un error.
Volver al índice
Asignación incorrecta de privilegios
Controlar que un proceso no asigne privilegios inadecuados a un actor
Si un proceso asigna incorrectamente un privilegio a un actor en particular, se está permitiendo un espacio de control nodeseado para ese actor.
Volver al índice
Cacheo del resultado de una operación privilegiada
No cachear los resultados de una operación privilegiada
Un resultado cacheado no debe pasarse a un contexto en el que no tiene los permisos suficientes para generarlo.
Es necesario asegurar que el resultado generado en un contexto no tiene más permisos que los contextos donde puededevolverse.
Volver al índice
Rutinas de autorización
Centralizar lar rutinas de autorización.
Mediante una biblioteca de comprobaciones de la autorización con las llamadas estandarizadas se centralizan las rutinas decontrol de acceso, por lo que si se encuentra algún fallo o vulnerabilidad, pueden arreglarse todas las ocurrencias realizandouna única modificación en el código.
Con ello se minimiza el impacto de la vulnerabilidad que permite crear brechas de seguridad en una autorización replicada en el15
código.Volver al índice
Manejo de permisos por defecto
Aplicar el principio de mínimos privilegios, asociando los permisos más restrictivos por defecto
Es necesario asegurar que existe una compartimentación adecuada integrada en el diseño del sistema y que lacompartimentación sirve para permitir y reforzar aún más la funcionalidad de separación de privilegios.
Los arquitectos y los diseñadores deben basarse en el principio de mínimo privilegio para decidir cuándo es apropiado utilizar yabandonar los privilegios del sistema.
Para ello, durante el arranque del programa, establezca explícitamente los permisos por defecto o asocie la configuración másrestrictiva posible. Asimismo, establezca los permisos apropiados durante la instalación del programa. Esto evitará heredarpermisos inseguros de todo usuario que instala o ejecuta el programa.
Volver al índice
Cuentas de usuarios
Asignar mínimos privilegios en las cuentas de usuarios.
Las cuentas de usuario deben poseer únicamente los privilegios necesarios en la aplicación para realizar sus tareas asignadas.Bajo ningún concepto deben ser administradores, ni utilizar funciones que excedan de sus competencias.
Volver al índice
Acceso a base de datos
Limitar las acciones de los usuarios sobre la base de datos
El acceso a base de datos debe realizarse mediante procedimientos almacenados parametrizados (o similar) para permitir quetodos los accesos a una tabla sean revocados (por ejemplo, selección, eliminación, actualización, inserción, etc.) utilizando unacuenta de la base de datos con pocos privilegios. Esta cuenta no deben tener un rol SQL mayor al de “usuario” (o similar).
Volver al índice
PautasÁrea: Arquitectura » Arquitectura de Sistemas de Información » GUIA: Gestión Unificada de Identidades de Andalucía
Código Título Tipo CarácterLIBP-0203 Integración en Autorización Directriz Recomendada
RecursosÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo Carácter
RECU-0564 Cacheo del resultado de una operación privilegiada enJava Ejemplo Obligatorio
RECU-0566 Comprobar los permisos mediante la funciónuser_access en Drupal Ejemplo Obligatorio
RECU-0556 Consultas para el acceso a nodos restringidos enDrupal Ejemplo Recomendado
RECU-0565 Manejar los permisos mediante la función hook_perm()en Drupal Ejemplo Obligatorio
RECU-0544 Manejo de permisos en métodos de EJB Ejemplo Obligatorio
RECU-0603 Uso de getPermissions() Ejemplo Obligatorio
RECU-0601 Uso de java.security.AllPermission Ejemplo Obligatorio
RECU-0602 Variables externas en bloques doPrivileged Ejemplo Obligatorio
Autenticidad Confidencialidad ENS LOPD Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/libro-pautas/254
16
Listas de controlÁrea: Control de Acceso y AutenticaciónTipo de pauta: DirectrizCarácter de la pauta: Recomendada
Código: LIBP-0263
Utilizar las listas de control para garantizar que no se producen accesos indebidos
Las listas de control se utilizan para fomentar la separación de privilegios.
Se deben crear listas de control de acceso que reafirmen los privilegios para cada recurso de la manera más ajustada posible.Para mejorar este aspecto se deben tener en cuenta las siguientes indicaciones:
PautasTítulo CarácterNegación de privilegios Obligatoria
Acceso a red Obligatoria
Acceso al sistema Obligatoria
Acceso de usuarios Obligatoria
Negación de privilegios
Inicialmente denegar todos los permisos.
Comenzar siempre las listas de control de acceso utilizando “deny all” (“denegar todo”) y, seguidamente, ir añadiendoúnicamente los privilegios y roles necesarios.
Volver al índice
Acceso a red
Utilizar filtros basado en el host y cortafuegos.
Para garantizar el acceso seguro a la red mediante listas de control, se deben utilizar filtros basados en host y cortafuegos.Volver al índice
Acceso al sistema
Utilizar permisos en los ficheros y en los directorios.
Para garantizar el acceso seguro a los ficheros y a los directorios se les deben asignar permisos en el sistema.Volver al índice
Acceso de usuarios
Utilizar seguridad en las plataformas de usuarios y grupos.
Para garantizar el acceso de los usuarios se deben utilizar mecanismos de seguridad en las plataformas de usuarios y gruposde usuarios.
Volver al índice
Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/libro-pautas/263
17
Manejo de contraseñas perdidasÁrea: Control de Acceso y AutenticaciónTipo de pauta: DirectrizCarácter de la pauta: Obligatoria
Código: LIBP-0285
En el caso de pérdida u olvido de la contraseña debemos tener en cuenta las siguientes indicaciones
PautasTítulo CarácterDirección de correo electrónico registrada Obligatoria
Datos sensibles en el correo electrónico No Recomendada
Autenticación con contraseña cognitiva No Recomendada
Restablecimiento de contraseñas en sistemas de transacciones de alto valor No Recomendada
Mensaje de restablecimiento de contraseña Obligatoria
Dirección de correo electrónico registrada
Utilizar una dirección de correo electrónico registrada para ese usuario
Si se guardan las contraseñas encriptadas de forma irreversible, como se recomienda, y un usuario olvida su contraseñaentonces no se le podrá proporcionar acceso. En estos casos, debemos generar una nueva contraseña y enviarla a la direcciónde correo electrónico registrada para ese usuario.
En ningún caso debemos enviar la contraseña a una dirección de correo electrónico no registrada para ese usuario ya quepodría ser un atacante que intenta suplantar al usuario real.
Volver al índice
Datos sensibles en el correo electrónico
Evitar incluir el nombre de usuario en el correo electrónico
Debemos evitar incluir el nombre de usuario en el mensaje del correo electrónico que contiene la nueva contraseña, que va sincifrar, para reducir las probabilidades de que un atacante pueda robar tanto la contraseña como el nombre de usuario.
Volver al índice
Autenticación con contraseña cognitiva
No utilizar la autenticación con contraseña cognitiva.
Para evitar la divulgación de una nueva contraseña por correo electrónico, se podría permitir al usuario autenticarse sincontraseña, respondiendo a una o más preguntas personales cuyas respuestas hayan sido registradas previamente por elusuario, dando la opción al propio usuario, una vez identificado, de proporcionar una nueva contraseña.
En cualquier caso, los sistemas de restablecimiento/recuperación de contraseñas son métodos poco seguros, por lo que sedesaconseja su utilización. En general, las respuestas a las preguntas requeridas por los sistemas de restablecimiento decontraseñas son fáciles de obtener de registros públicos (ej: apellido materno de la madre, color de coche, etc).
Volver al índice
Restablecimiento de contraseñas en sistemas de transacciones de alto valor
No usar sistemas de restablecimiento de contraseñas en sistemas de transacciones de alto valor.
Los sistemas de transacciones de alto valor no deben usar sistemas de restablecimiento de contraseñas. Para las demásaplicaciones no es recomendable su utilización.
Volver al índice
Mensaje de restablecimiento de contraseña
Enviar un mensaje al usuario con la petición de restablecimiento de la contraseña.
18
La aplicación debe enviar un mensaje al usuario explicando que alguien ha activado la funcionalidad de restablecimiento decontraseña. Si el usuario no lo solicitó se reportará una incidencia. Si fue solicitado, se proporcionará un token corto,criptográficamente único y limitado en el tiempo que será introducido en la aplicación para poder cambiar la contraseña. Alfinalizar se mandará un correo al usuario y al administrador.
Volver al índice
RecursosÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo Carácter
RECU-0675 Envío de credenciales por correo electrónico enDrupal Ejemplo No recomendado
RECU-0582 Manejo de las contraseñas perdidas en PHP Ejemplo Obligatorio
Autenticidad ENS Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/libro-pautas/285
19
Nombres de usuarioÁrea: Control de Acceso y AutenticaciónTipo de pauta: DirectrizCarácter de la pauta: Recomendada
Código: LIBP-0258
Recomendaciones para fortalecer los nombres de usuario.
PautasTítulo CarácterCreación de nombres de usuario personalizados Recomendada
Nombres de usuarios protegidos Recomendada
Información personal o pública No Recomendada
Cuentas predeterminadas No Recomendada
Cuentas predeterminadas activas Obligatoria
Credenciales en el código No Recomendada
Credenciales en el instalador No Recomendada
Cuentas especificadas por el usuario Obligatoria
Ejemplos en la documentación No Recomendada
Creación de nombres de usuario personalizados
Permitir al usuario elegir su propio nombre
Cuando sea posible, permita al usuario crear su propio nombre de usuario, verificando que el nombre de usuario sea único.Volver al índice
Nombres de usuarios protegidos
Permitir sólo caracteres en los rangos A..Z, a..z, y 0-9
Los nombres de usuario deben estar protegidos de ataques basados en inyección de HTML, SQL y LDAP”
Se recomienda permitir sólo caracteres en los rangos A..Z, a..z, y 0-9.
Si desea permitir espacios, símbolos '@' o apóstrofos, asegurese que el nombre de usuario está protegido apropiadamentedel uso de caracteres especiales.
Volver al índice
Información personal o pública
Evitar el uso de información personal o de uso público en el nombre de usuario.
Evite el uso de una combinación de nombre, apellido, dirección de correo electrónico, números de tarjeta de crédito, númerode cliente, número de empleado o cualquier información semi-pública o similar.
Volver al índice
Cuentas predeterminadas
No generar cuentas predeterminadas
Una vulnerabilidad común son las cuentas predeterminadas (cuentas con nombres de usuario y/o contraseñas bien conocidas).Al ser conocidas, los atacantes pueden conseguir una autenticación de forma muy sencilla.
Las nuevas aplicaciones no deberían tener cuentas predeterminadas.Volver al índice
Cuentas predeterminadas activas
Documentar que la infraestructura no tenga cuentas predeterminadas activas
20
Asegurar que la documentación diga que hay que determinar que la infraestructura no tenga cuentas predeterminadas activas(como Administrator, root, sa, ora, dbsnmp, etc)
Volver al índice
Credenciales en el código
No incluir credenciales predeterminadas, especiales o de depuración en el código
No permitir que el código contenga ninguna credencial predeterminada, especial o de depuración.Volver al índice
Credenciales en el instalador
No crear ninguna credencial predeterminada, especial o de depuración en el instalador
Cuando se crea el instalador, asegurar que el instalador no cree ninguna credencial predeterminada, especial o de depuraciónVolver al índice
Cuentas especificadas por el usuario
Todas las cuentas deben estar especificadas por el instalador / usuario
Asegurar que todas las cuentas, particularmente las administrativas, están completamente especificadas por elinstalador/usuario.
Volver al índice
Ejemplos en la documentación
No incluir ejemplos o imágenes en la documentación con nombres de usuario
Debe asegurarse que, en los ejemplos o imágenes de la documentación de las aplicaciones, no se muestran los nombres deusuario
Volver al índice
PautasÁrea: Arquitectura » Arquitectura de Sistemas de Información » GUIA: Gestión Unificada de Identidades de Andalucía
Código Título Tipo Carácter
LIBP-0207 Gestión de la información de usuarios enaplicaciones integradas Directriz Obligatoria
Autenticidad ENS LOPD Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/libro-pautas/258
21
Uso de permisos en recursos críticosÁrea: Control de Acceso y AutenticaciónTipo de pauta: DirectrizCarácter de la pauta: Obligatoria
Código: LIBP-0264
Garantizar que los permisos requeridos para utilizar un recurso son los correctos.
Cuando a un recurso se le asigna una configuración de permisos que proporciona acceso a una gama de actores más amplia delo requerido, existe el riesgo de que se revele información sensible a usuarios que no deberían tener acceso a ella o que elrecurso sea modificado por partes no deseadas.
Esto es especialmente peligroso cuando el recurso está relacionado con la configuración del programa, la ejecución o datosconfidenciales de usuario.
PautasTítulo CarácterPermisos de los recursos Obligatoria
Configuración por defecto Obligatoria
Documentación Obligatoria
Permisos de los recursos
Comprobar que los recursos no poseen permisos inseguros.
Cuando se utiliza un recurso crítico, como un archivo de configuración, ejecutable o biblioteca, comprobar que el recurso notenga permisos inseguros, como ser modificable por cualquier usuario normal del sistema, sino que se ubiquen en zonasseguras del servidor o con privilegios especiales.
También comprobar que sólo los usuarios con el perfil "Administrador" tienen permisos de lectura y escritura sobre el recurso,y generar un error o incluso salir de la aplicación si existe la posibilidad de que el recurso pudiese haber sido modificado poruna parte no autorizada.
Volver al índice
Configuración por defecto
La configuración por defecto de las aplicaciones debe ser segura
Las aplicaciones deben tener una configuración de inicio que sea segura.Volver al índice
Documentación
No sugerir cambios inseguros en la documentación
No se deben sugerir cambios de configuración inseguros en la documentación, especialmente si esas configuraciones sepuede extender a los recursos y otros programas que están fuera del alcance de su propio software.
Volver al índice
RecursosÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo Carácter
RECU-0555 Comprobar los permisos de un nodo específicoutilizando node_access en Drupal Ejemplo Obligatorio
Confidencialidad ENS LOPD Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/libro-pautas/264
22
Ataques de reflexión sobre la autenticación en JavaÁrea: Control de Acceso y AutenticaciónCarácter del recurso: ObligatorioTecnologías: Java
Código: RECU-0563Tipo de recurso: Ejemplo
DescripciónUn ejemplo de código vulnerable a este tipo de ataque sería el siguiente:
EjemplosString command = new String("some cmd to execute & the password");MessageDigest encer = MessageDigest.getInstance("SHA");encer.update(command.getBytes("UTF-8"));byte[] digest = encer.digest();
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0253 Autenticación Directriz Obligatoria
Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/563
23
AutenticaciónÁrea: Control de Acceso y AutenticaciónCarácter del recurso: Obligatorio
Código: RECU-0559Tipo de recurso: Referencia
DescripciónEntendemos por autorización como una parte del sistema operativo que protege los recursos del sistema permitiendo quesólo sean usados por aquellos consumidores a los que se les ha concedido derecho para ello.
El proceso de autorización se usa para decidir si la persona, programa o dispositivo determinado tiene permiso para acceder aldato, funcionalidad o servicio determinado.
La autorización tiene como objetivos:
Asegurar que únicamente usuarios autorizados puedan realizar acciones permitidas con su correspondiente nivel deprivilegio.
Controlar el acceso a recursos protegidos mediante decisiones basadas en el rol o el nivel de privilegio.
Prevenir ataques de escalada de privilegios, como por ejemplo utilizar funciones de administrativas siendo un usuarioanónimo o incluso un usuario autenticado.
Obviamente presenta una serie de vulnerabilidades que se catalogan de la siguiente manera:
Violación del Principio de menor privilegio , que se basa en la otorgación de privilegios a determinados usuariospara realizar acciones dentro del sistema de forma fraudulenta. El atacante accede y otorga privilegios de manera dota dehabilidades y opciones de control para las que no tiene privilegios.
Acceso indebido a las listas de control de acceso . Muchos controles de acceso son inseguros al implantarse.Normalmente las aplicaciones mantienen una listas que permiten controlar el acceso a determinados recursos. El atacantebasa su ataque sobre estas listas y modifica la misma, permitiéndose acceder a recursos para los que no esta autorizado.
Ruptura de los controles de autorización personalizados. La mayoría de los entornos aplicativos tienenmecanismos bien desarrollados de autorización. Muchas aplicaciones contienen sus propios mecanismos personalizadospara la gestión de la autorización. Esto añade complejidad y posibles fallos. A menos que exista una razón explicita deevitar las funcionalidades ya incluidas, el código debería dejar paso al soporte propio del entorno.
Crear brecha de seguridad en una comprobación de autorización replicada. En el código, un error común esla de llevar a cabo una comprobación de la autorización copiando y pegando un trozo de código, o incluso peor,reescribiéndola cada vez. El atacante si crea una brecha de seguridad en esta comprobación puede atacar el código desdevarios puntos de entrada Falta de Matrices de autorización. El atacante aprovecha la circunstancia de que no existencomprobaciones asociadas a la autorización de la ejecución de una función o vista y consigue ejecutar una determinadaacción o código. Con ello puede provocar grandes fallos en el sistema.
Uso de tokens de autorización. Muchos desarrolladores de aplicaciones Web son reacios a utilizar almacenamientode sesiones, por lo que recurren al lado del cliente, tanto en forma de cookies, como cabeceras o campos escondidos enformularios. Estos tokens son vulnerables a los atacantes por los que resulta mas sencillo obtener información, esrecomendable hacer uso de tokens de autorización de manera que el usuario debe autenticarse previamente a obtener laautorización.
Acceso no controlado a un recurso protegido . Muchas aplicaciones realizan una comprobación para ver si tienenel permiso para realizar una acción en particular, pero no realizan la comprobación de si se permite pedir un recurso. Unatacante aprovecha esta debilidad y solicita recursos para los que no esta autorizado pero puede introducir los datoscorrectos para que se ejecute la acción solicitada Por ejemplo, en una aplicación de banca online podría ser el caso decomprobar si se permite transferir dinero, pero no valida si la cuenta desde la cual se transferirá es nuestra.
Acceso a información privilegiada de recurso protegido . Algunas aplicaciones generan contenido estático(pongamos el ejemplo de un informe de una transacción, en formato PDF), y permiten al servidor Web servir dichocontenido. A menudo, esto implica que un informe confidencial pueda resultar disponible para usuarios no autorizados.
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0253 Autenticación Directriz Obligatoria
ENS LOPD
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/559
24
25
Cacheo del resultado de una operación privilegiada en JavaÁrea: Control de Acceso y AutenticaciónCarácter del recurso: ObligatorioTecnologías: Java
Código: RECU-0564Tipo de recurso: Ejemplo
DescripciónEl cálculo de los privilegios correspondientes a un usuario puede llevar a error. Por ello, es recomendable utilizar la APIAccessController para asegurar que la restricción de permisos de realiza de forma correcta.
Ejemplosprivate static final Map cache; public static Thing getThing(String key) { //Try cache.CacheEntry entry = cache.get(key); if (entry != null) { // Asegurando que se requieren permisos antes de devolver un resultado cacheado. AccessController.checkPermission(entry.getPermission()); return entry.getValue(); } // Asegurando que no se elevan privilegios. Permission perm = getPermission(key); AccessController.checkPermission(perm); // Creando un nuevo valor con los permisos exactos. PermissionCollection perms = perm.newPermissionCollection(); perms.add(perm); Thing value = AccessController.doPrivileged(new PrivilegedAction() { public Thing run() { return createThing(key); }}, new cache.put(key, new CacheEntry(value, perm)); return value; }
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0254 Control de acceso Directriz Obligatoria
ENS LOPD
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/564
26
Canal accesible por un punto no final en JavaÁrea: Control de Acceso y AutenticaciónCarácter del recurso: ObligatorioTecnologías: Java
Código: RECU-0562Tipo de recurso: Ejemplo
DescripciónMediante escuchas en el canal de comunicación o haciéndose pasar por el punto final, un atacante sería capaz de leer todoslos datos transmitidos.
EjemplosSocket sock;PrintWriter out;
try { sock = new Socket(REMOTE_HOST, REMOTE_PORT); out = new PrintWriter(echoSocket.getOutputStream(), true);
// Write data to remote host via socket output stream. ...}
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0269 Canal de comunicación Directriz Obligatoria
ENS LOPD
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/562
27
Comprobación de la perdida de autenticación sobre funcionessignificativas en Java
Área: Control de Acceso y AutenticaciónCarácter del recurso: ObligatorioTecnologías: Java
Código: RECU-0667Tipo de recurso: Ejemplo
DescripciónEjemplo en el que se comprueba que el usuario se encuentra logado antes de un acceso a un recurso crítico.
Ejemplosprivate boolean isUserAuthentic = false; /*** Método que comprueba si la autenticación del usuario es correcta* @param username nombre del usuario* @param password contraseña del usuario* @return correcto en caso de que la autenticación sea correcta*/public boolean authenticateUser(String username, String password) { ... }
/*** Método que crea una cuenta bancaria* @param accountNumber numero de cuenta* @param accountType tipo de cuenta* @param accountName nombre de cuenta* @param accountSSN ssn de la cuenta* @param balance balance la cuenta* @return BankAcount con los parametros de entrada* @throws UserAutenticationException error que se lanza en caso de que el usuario no este debidamente autenticado*/public BankAccount createNewBankAccount(String accountNumber, String accountType, String accountName, String accountSSN, double balance) throws UserAutenticationException{ BankAccount account = null; if (isUserAuthentic) { account = new BankAccount(); account.setAccountNumber(accountNumber); account.setAccountType(accountType); account.setAccountOwnerName(accountName); account.setAccountOwnerSSN(accountSSN); account.setBalance(balance); } else { // Lanza una excepcion para indicar que el usuario no se ha logado correctamente throw new UserAutenticationException(); } return account; }
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0253 Autenticación Directriz Obligatoria
Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/667
28
Comprobar los permisos de un nodo específico utilizando node_accessen Drupal
Área: Control de Acceso y AutenticaciónCarácter del recurso: ObligatorioTecnologías: PHP
Código: RECU-0555Tipo de recurso: Ejemplo
DescripciónLa función db_rewrite_sql es una solución para obtener listados de nodos pero, para determinar qué usuario tiene acceso aun nodo específico, es un poco complejo.
Ejemplos$node = node_load(arg(2));$access = db_result(db_query(db_rewrite_sql(“SELECT n.nid FROM {node}n WHERE n.nid = %d“), $node->nid));if ($access) {drupal_set_message(check_plain($node->title));}
Es facil simplificar el uso de la función node_access:
$node = node_load(arg(2));if (node_access(’view’, $node)) {drupal_set_message(check_plain($node->title));}
Usando node_access, el primer parámetro es la operación que se quiere tratar, pudiendo ser una vista, actualización, borradoo alta. Esta función es útil para determinar si se crean enlaces como "crea más productos" o "borre este producto"
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0264 Uso de permisos en recursos críticos Directriz Obligatoria
ENS LOPD
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/555
29
Comprobar los permisos mediante la función user_access en DrupalÁrea: Control de Acceso y AutenticaciónCarácter del recurso: ObligatorioTecnologías: PHP
Código: RECU-0566Tipo de recurso: Ejemplo
DescripciónLa función user_access() puede ser llamada con sólo un parámetro para comprobar si tiene permiso para ejecutar unafunción
Ejemplosif (user_access(’Tiene permiso’)) { // El código solo se ejecuta si el usuario tiene permiso }
La función comprueba que el usuario tenga el permiso y devuelve un booleano que permite la ejecución del trozo de código oimpide la misma. El parámetro que se le pasa a la función es el permiso requerido. También pueden comprobarse los permisosestablecidos para un usuario mediante el siguiente código:
if (user_access(’administer nodes’, $account)) { return TRUE; }
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0254 Control de acceso Directriz Obligatoria
ENS LOPD
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/566
30
Conceptos de seguridad en la capa de negocio mediante SpringÁrea: Control de Acceso y AutenticaciónCarácter del recurso: RecomendadoTecnologías: Spring, Java
Código: RECU-0210Tipo de recurso: Referencia
Descripción
IntroducciónUno de los principales aspectos a tratar en el desarrollo de una aplicación es la seguridad de la misma. Un principio básico acumplir por cualquier aplicación se basa en la comprobación de la identidad del usuario. Es decir, comprobar que alguien esrealmente quien dice ser. Una vez contrastado, hay que pensar que tipo de privilegios tiene ese participante y ajustar suscapacidades a sus necesidades
Existe un estándar JAAS (Java Authorization and Authentication Service) cuyo objetivo principal es definir y cubrir losaspectos relacionados con la autorización y la autenticación. Existen problemas contrastados con este estándar entrediferentes implementaciones y cada contenedor asociado necesita una configuración individual.
Si hablamos de seguridad dentro de la capa de negocio, es muy habitual, pensar en el Spring Security que es un frameworkíntimamente ligado al proyecto Spring .Este framework facilita las tareas a adoptar como medidas de seguridad enaplicaciones Java, ya sean aplicaciones standalone o aplicaciones web. La arquitectura de Spring Security está fuertementebasada en interfaces y en patrones de diseño, proporcionando las implementaciones más comúnmente utilizadas y numerosospuntos de extensión donde se pueden añadir nuevas funcionalidades.
AutenticaciónPara utilizar los servicios de autenticación, por lo general será necesario que configurar un filtro web, junto con unAuthenticationProvider y AuthenticationEntryPoint. En el web.xml de la aplicación se necesita un sólo filtro a fin deutilizar el FilterChainProxy. Casi todas las aplicaciones tendrán una entrada, y se ve así:
<filter> <filter-name>filterChainProxy</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class></filter>
<filter-mapping> <filter-name>filterChainProxy</filter-name> <url-pattern>/*</url-pattern></filter-mapping>
Las declaraciones anteriores harán que cada solicitud web pase a través del bean llamado filterChainProxy y por ahí realizarel tratamiento que asegure la autenticación.
<bean id="filterChainProxy" class="org.springframework.security.util.FilterChainProxy"> <security:filter-chain-map path-type="ant"> <security:filter-chain pattern="/**" filters="httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,basicProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor,switchUserProcessingFilter" </security:filter-chain-map></bean>
Uno de los aspectos a considerar es el orden de creación de los filtros. Hay que tener en cuenta en esta etapa que, si sedeclaran una serie de filtros, se llevarán a cabo en el orden especificado en la declaración y comprobar que cada uno de losfiltros son realmente el id de otro bean en el contexto de aplicación
Para poder tomar decisiones sobre el acceso a los recursos, es necesario que el participante se identifique para realizar lascomprobaciones necesarias sobre su identidad. Mediante la interfaz Authentication, se pueden acceder a tres objetos biendiferenciados:
principal, normalmente hace referencia al nombre del participante
credenciales, las credenciales del usuario que permiten comprobar su identidad, normalmente su contraseña, aunquetambién puede ser otro tipo de métodos como certificados, etc...
autorizaciones, un lista de los roles asociados al participante.
Si un usuario inicia un proceso de autenticación, crea un objeto Authentication, con los elementos Principal y Credenciales. Sirealiza la autenticación mediante el empleo de contraseña y nombre usuario, se crea un objeto
31
UsernamePasswordAuthenticationToken. El framework Spring Security aporta un conjunto de clases que permite queesta autenticación se realice mediante nombre de usuario y contraseña. Para ello, utiliza la autenticación que proporciona elcontenedor o utiliza un servicio de identificación basado en Single Sign On (sólo se identifica una vez).
A continuación podemos observar en la figura el ciclo de vida de la autenticación:
AuthenticationManagerSi seguimos el modelo gráfico, una vez se ha obtenido el objeto Authentication se envía al AuthenticationManager. Unavez aquí, se realiza una comprobación del contenido de los elementos del objeto principal y las credenciales. Se compruebanque concuerdan con las esperadas, añadiéndole al objeto Authentication las autorizaciones asociadas a esa identidad encaso afirmativo, creando una excepción de tipo AuthenticationException en caso contrario.
El propio framework ya tiene implementado un gestor de autenticación que es válido para la mayoría de los casos, elProviderManager. El bean AuthenticationManager es del tipo ProviderManager, lo que significa que actúa de proxycon el AuthenticationProvider. Este es el encargado de realizar la comprobación de la validez del nombre deusuario/contraseña asociada y de devolver las autorizaciones permitidas a dicho participante(roles asociados). Esta clasedelega la autenticación en una lista que engloba a los proveedores y que, por tanto, es configurable. Cada uno de losproveedores tiene que implementar el interfaz AuthenticationProvider.
<bean id="authenticationManager" class="paquete.MiAuthenticationManager"> <property name="providerString" value="userDaoProvider" /></bean>
public class MiAuthenticationManager extends ProviderManager {protected String providerString;public void setProviderString(String providerString) { this.providerString = providerString; } /** *; Agrega al Manejador de Proveedores un listado **/ public void afterPropertiesSet() throws Exception { if (providerString != null) { List<authenticationprovider> providers = new LinkedList(); String[] names = providerString.split(","); for (String providerUnit : names) { AuthenticationProvider provider = (AuthenticationProvider) applicationContext .getBean(providerUnit.trim()); if (provider == null) { throw new EnMeExpcetion("AuthenticationProvider " + providerUnit + " don't exist"); } providers.add(provider);
32
} setProviders(providers); } super.afterPropertiesSet(); }} </authenticationprovider>
AuthenticationEntryPointComo es lógico, cada aplicación web tendrá una estrategia de autenticación por defecto. Cada sistema de autenticación tendrásu aplicación AuthenticationEntryPoint propia, que realiza acciones como enviar avisos para la autenticación.
Cuando el navegador decide presentar sus credenciales de autenticación (ya sea como un puesto de forma HTTP o HTTPheader) tiene que existir algo en el servidor que "recoge" estos datos de autenticación. A este proceso se le denomina"mecanismo de autenticación". Una vez que los detalles de autenticación se recogen en el agente de usuario, un objeto"solicitud de autenticación" se construye y se presenta a una AuthenticationProvider.
AuthenticationProviderEl último paso en el proceso de autenticación de seguridad es un AuthenticationProvider. Es el responsable de tomar unobjeto de solicitud de autenticación y decidir si es o no válida. El Provider decide que sea una excepción o devolver unobjeto de autenticación totalmente lleno.
Cuando el mecanismo de autenticación recibe de nuevo el objeto de autenticación, si se considera la petición válida, debeponer la autenticación en el SecurityContextHolder, y hacer que la solicitud original se ejecute. Si, por el contrario, laAuthenticationProvider rechazó la solicitud, el mecanismo de autenticación mostrara un mensaje de error.
DaoAuthenticationProviderSe trata de una implementación de la interfaz de autenticación centrada en el acceso a los datos que se encuentranalmacenados dentro de una base de datos. Este proveedor específico requiere una atención especial. Esta implementacióndelega a su vez en un objeto de tipo UserDetailsService, un interfaz que define un objeto de acceso a datos con un únicométodo loadUserByUsername que permite obtener la información de un usuario a partir de su nombre de usuario.
<bean id="userDaoProvider" class="org.springframework.security.providers.dao.DaoAuthenticationProvider"> <property name="userDetailsService" ref="dbUserService" /> </bean>
UserDetailsServicePara evitar que Spring acceda directamente al contenido de las bases de datos, es posible configurar un DAO particularmediante una implementación de la interfaz UserDetailsService. Esta interfaz describe un objeto que realiza un acceso adatos con un único método loadUserByUsername que devuelve la información de un usuario a partir de su nombre deusuario.
<bean id="dbUserService" class="paquete.MiUserServiceImp"> <property name="userDao" ref="userDao" /> </bean>
public class MiUserServiceImp implements UserDetailsService { ...... public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException, DataAccessException { SecUsers user = userDao.getUser(username); if (user == null) { log.info("no encontrado..."); throw new UsernameNotFoundException("username"); } return convertToUserDetails(user); } ...... protected UserDetails convertToUserDetails(SecUsers user){ //lista de permisos, List<string> listPermissions = new ArrayList</string><string>(); ........... GrantedAuthority[] authorities = new GrantedAuthority[listPermissions .size()]; int i = 0; for (String permission : listPermissions) {
33
authorities[i++] = new GrantedAuthorityImpl(permission.trim()); } User userDetails = new User(user.getUsername(), user.getPassword(), user.isStatus() == null ? false : user.isStatus(), true, true, true, authorities); log.info("userDetails "+userDetails); return userDetails; }}</string>
AutorizaciónFinalizado el proceso para la autenticación del usuario, se comprueban las autorizaciones que están asociadas al mismo paradecidir sobre la veracidad del acceso. Con ello logramos definir a qué recursos tiene acceso el usuario autenticado. Medianteel uso de SpringSecurity, podremos realizar intercepciones de las llamadas a objetos o las peticiones de http. Para elloemplea proxies dinámicos, filtros o aspectos basados en AspectJ. De esta forma , es bastante sencillo restringir el acceso adeterminados recursos.
Tras la interceptar el evento, transcurre una secuencia de acciones que concluyen con el acceso al recurso solicitado o con lacreación de una excepción interpretable para denegar el acceso al recurso. En primer lugar se crea un objeto tipoAccessDecisionManager. SpringSecurity ya proporciona tres tipos de implementaciones de AccessDecisionManager quemantienen un concepto de votación, pero diferenciando las reglas de decisión:
UnanimousBased: permite el acceso si no hay votos negativos
AffirmativeBased: permite el acceso si un voto es afirmativo
ConsensusBased: permite el acceso si el número de votos positivos es mayor o igual que el de negativos
AccessDecisionManagerEs una interfaz que atiende la llamada AbstractSecurityInterceptor producida tras interceptar un evento. Esta interfaz es laresponsable de la toma de decisiones final sobre el control de acceso. La interfaz de contiene tres métodos:
void decide(Authentication authentication, Object secureObject, ConfigAttributeDefinition config) throws AccessDeniedException; boolean supports(ConfigAttribute attribute); boolean supports(Class clazz);
Como puede verse en el primer método, el AccessDecisionManager pasa, a través de parámetros del método, toda lainformación que pueda ser de valor en la evaluación de una decisión de autorización. En particular, pasando el objeto seguro(secureObject) se permite inspeccionar los argumentos contenidos en la invocación del objeto real.
Por ejemplo, supongamos que el objeto era una llamada a método seguro (MethodInvocation). Sería fácil consultar elMethodInvocation para cualquier argumento del cliente, y luego implementar una especie de lógica de la seguridad en elAccessDecisionManager para garantizar que está autorizado a operar en ese cliente. Las implementaciones esperan quelance una AccessDeniedException si se deniega el acceso.
El método es llamado por el AbstractSecurityInterceptor al inicializarse para determinar si el AccessDecisionManagerpuede procesar la ConfigAttribute pasada. Se llama al método de aplicación por un interceptor de seguridad para garantizarque AccessDecisionManager configurado apoya el tipo de objeto asegurado.
AccessDecisionManager delega la facultad de emitir votos en objetos de tipo AccessDecisionVoter. Se proporcionandos implementaciones de éste último interfaz:
RoleVoter, que comprueba que el usuario presente un determinado rol, comprobando si se encuentra entre susautorizaciones (authorities).
BasicAclEntryVoter, que a su vez delega en una jerarquía de objetos que permite comprobar si el usuario supera las reglasestablecidas como listas de control de acceso.
Es más común que se elija un RoleVoter, proporcionando una autenticación basada en grupos o roles, donde se permite elacceso a un recurso si el usuario pertenece a alguno de los roles que tienen acceso al mismo. En el segundo caso se permiterestringir el acceso a objetos a nivel de instancia. En ambos casos, el sistema que intercepta las llamadas debe serconfigurado. En el caso de las aplicaciones web se hará mediante la configuración de un filtro en el fichero web.xml.
FiltrosLos filtros se encargan de la seguridad de la aplicación. Existen tres filtros fundamentales que se encadenan juntos medianteun objeto llamado “filterChainProxy”, que crea e inicializa los tres filtros; como se ve en el siguiente diagrama.
34
El filtro AuthenticationProcessingFilter maneja la petición o requerimiento (request) que chequea la autenticación -Authentication Request Check- (”el login de la aplicación”). Para ello usa el AuthenticationManager .
El filtro HttpSessionContextIntegrationFilter mantiene el objeto Authentication entre varios requests y se lo pasa alAuthenticationManager y al AccessDecisionManager cuando sea necesario.
El filtro ExceptonTranslationFilter verifica la existencia de autenticación, maneja las excepciones de seguridad y ejecuta laacción apropiada. El ExceptonTranslationFilter depende del filtro siguiente, FilterSecurityInterceptor.
FilterSecurityInterceptor controla el acceso restricto a recursos determinados, y el chequeo de autorización conoce quérecursos son seguros y qué roles tienen acceso a ellos. FilterSecurityInterceptor usa el AuthenticationManager y elAccessDecisionManager para hacer su trabajo.
AuthenticationProcessingFilterEs el primer filtro al que llega la petición HTTP. Este filtro está especializado en manejar la autentificación de la petición, realizala validación asociada al usuario y la contraseña. Además es importante conocer:
authenticationFailureUrl: En el caso de fallo, algún lugar debe de ir cuando no se logea el usuario.
defaultTargetUrl: Es el URL por defecto, generalmente es la raiz.
filterProcessesUrl: Es a quien le encarga la responsabilidad de verificar si el usuario se logea o no..
<bean id="authenticationProcessingFilter" class="org.springframework.security.ui.webapp.AuthenticationProcessingFilter"> <property name="authenticationManager"> <ref bean="authenticationManager" /> </property> <property name="authenticationFailureUrl"> <value>/login.me</value> </property> <property name="defaultTargetUrl"> <value>/</value> </property> <property name="filterProcessesUrl"> <value>/j_spring_security_check</value> </property> </bean>
HttpSessionContextIntegrationFilterEs el filtro que se encarga del contexto de seguridad asociado a la autenticación. Es bastante sencillo de configurar ya que notiene propiedades de configuración.
<bean id="httpSessionContextIntegrationFilter" class="org.springframework.security.context.HttpSessionContextIntegrationFilter" />
ExceptionTranslationFilterIntercepta cualquier error de autenticación o autorización, por ejemplo UsernameNotFoundException oDataAccessException.
Si la excepción fue causada por una excepción de autorización lanzada por el filtro FilterSecurityInterceptor (puede serporque no tiene permisos para acceder a un Recurso Web, una imagen o un URL), el filtro lanzará un HTTP 403 al navegador, elcual mostrará una página de acceso no autorizado.
35
<bean id="formExceptionTranslationFilter" class="org.springframework.security.ui.ExceptionTranslationFilter"> <property name="authenticationEntryPoint"> <ref local="formEntryPoint" /> </property> </bean> <bean id="formEntryPoint" class="org.springframework.security.ui.webapp.AuthenticationProcessingFilterEntryPoint"> <property name="loginFormUrl" value="/login.me" /> </bean>
FilterSecurityInterceptorEs donde se protegen todos los recursos, donde se decide que rol tiene acceso a ciertos recursos y cuales pueden seraccedidos por usuarios anónimos. Todo esto se configura en el objectDefinitionSource. Se necesitan dos referencias paraconfigurar este Filtro, el authenticationManager y el bean accessDecisionManager.
<bean id="filterInvocationInterceptor" class="org.springframework.security.intercept.web.FilterSecurityInterceptor"> <property name="authenticationManager" ref="authenticationManager" /> <property name="accessDecisionManager" ref="voteAccessDecisionManager" /> <property name="objectDefinitionSource"> <value> CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /=ENCUESTAME_ANONYMOUS /pages/**=ENCUESTAME_USER /pages/admon/**=ENCUESTAME_ADMIN /user/**=ENCUESTAME_ANONYMOUS,ENCUESTAME_USER,ENCUESTAME_ADMIN </value> </property> </bean>
FilterChainProxyEs el filtro inicializador. Su función principal es indicar o personalizar, qué recursos ejecutarán los filtros deseados enfilterInvocationDefinitionSource, por ejemplo, si tenemos un sevlet /uploadFile y sólo nos interesa aplicar algunosfiltros:
<bean id="springSecurityFilterChain" class="org.springframework.security.util.FilterChainProxy"> <property name="filterInvocationDefinitionSource"> <value> CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /**=httpSessionContextIntegrationFilter,logoutFilter,basicProcessingFilter,authenticationProcessingFilter.... /uploadFile= basicProcessingFilter,OtroFiltroPersonalizado </value> </property></bean>
Enlaces externosPágina de Spring Security
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0253 Autenticación Directriz Obligatoria
Seguridad LOPD ENS
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/210
36
37
Configuración de Spring SecurityÁrea: Control de Acceso y AutenticaciónCarácter del recurso: Recomendado
Código: RECU-0213Tipo de recurso: Referencia
Descripción
IntroducciónSpring Security es un framework de apoyo al marco de trabajo Spring, que dota al mismo de una serie servicios de seguridadaplicables para sistemas basados en la arquitectura basados en J2EE, enfocado particularmente sobre proyectos construidosusando SpringFramework. De esta dependencia, se minimiza la curva de aprendizaje si ya es conocido Spring.
Los procesos de seguridad están destinados principalmente, a comprobar la identidad del usuario mediante la autenticación ylos permisos asociados al mismo mediante la autorización. La autorización es dependiente de la autenticación ya que seproduce posteriormente a su proceso.
Por regla general muchos de estos modelos de autenticación son proporcionados por terceros o son desarrollados porestándares importantes como el IETF adicionalmente, Spring Security proporciona su propio conjunto de características deautenticación. Específicamente, Spring Security actualmente soporta integración de autenticación con todas las siguientestecnologías:
HTTP BASIC authentication headers (an IEFT RFC-based standard).
HTTP Digest authentication headers (an IEFT RFC-based standard).
HTTP X.509 client certificate exchange (an IEFT RFC-based standard).
LDAP (un enfoque muy comun para necesidades de autenticación multiplataforma, especificamente en entornos extensos).
Form-based authentication (necesario para interfaces de usuario simples).
OpenID authentication.
Computer Associates Siteminder.
JA-SIG Central Authentication Service.
Transparent authentication context propagation for Remote Method Invocation (RMI) and HttpInvoker.
Automatic "remember-me" authentication.
Anonymous authentication.
Run-as authentication.
Java Authentication and Authorization Service (JAAS)
Container integration with JBoss, Jetty, Resin and Tomcat (tambien podemos usar autenticación gestionada por elcontenedor)
Java Open Source Single Sign On (JOSSO)*
OpenNMS Network Management Platform*
AppFuse*
AndroMDA*
Mule ESB*
Direct Web Request (DWR)*
Grails*
Tapestry*
JTrac*
Jasypt*
Roller*
Elastic Plath*
Atlassian Crowd*
Nuestros propios sistemas de autenticación.
(*Indica proporcionado por un tercero)
Spring Security tiene un alto grado de aceptación entre la comunidad de desarrolladores por su gran flexibilidad sobre losmodelos de autenticación. De esta manera, permite una rápida integración de las soluciones que presentan ante losrequerimientos de los clientes potenciales, sin implicar una migración de los sistemas a un determinado entorno. Además esuna plataforma abierta y en constante evolución, lo que permite ir añadiendo nuevos mecanismos de autenticación, o
38
directamente programar los propios de manera poco compleja
En ocasiones un proceso simple de autenticación no es eficiente. Hay que controlar como se relaciona el usuario con laaplicación. Puede resultar interesante como llegan las solicitudes , si son automatizadas o por medio de una persona, asegurarque se realizan mediante el protocolo Http. Para completar estos objetivos, Spring Security proporciona "canales de seguridad"automáticos integrándose con JCaptcha para detección de usuarios humanos.
SpringSecurity también facilita el proceso de la autorización. Para ello, aporta tres características esenciales: Autorización enbase a solicitudes web, autorización en base a llamadas, autorización en base al acceso a instancias.
Espacio de nombres (Namespace) de seguridadUn elemento del namespace puede ser usado para permitir configurar de forma concisa un bean , de forma individual, o paradefinir una sintaxis de configuración más cercana al dominio del problema escondiendo la complejidad de la misma al usuario.Un elemento simple puede ocultar el hecho de que múltiples beans y pasos del procedimiento han sido añadidos al contextode la aplicación
Para empezar a usar el namespace en el contexto de su aplicación ese necesario que añada el esquema siguiente al contextode su aplicación:
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:security="http://www.springframework.org/schema/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd"> ...</beans>
Diseño del espacio de nombresEl espacio de nombres está diseñado para capturar los usos más comunes del framework y para proporcionar una simple yconcisa sintaxis para adaptarlos a la aplicación. El diseño se basa en la gran escala de dependencias en el framework, y puedeser dividido en las siguientes áreas:
Web/HTTP Security La parte mas compleja. Configura los filtros y los "service beans" usados para aplicar losmecanismos de autenticación.
Business Object Security Opciones para asegurar la capa de servicio
AuthenticationManager Maneja las peticiones de autenticación de otras partes del framework
AccessDecisionManager Proporciona acceso a las decisiones para la web y la seguridad del método. Una por defectoserá registrada, pero también se puede optar por utilizar una personalizada, declarada con la sintaxis normal de springbean
AuthenticationProviders Mecanismos con los que el AuthenticationManager autentica los usuarios
UserDetailsService estrechamente relacionada con los AuthenticationProviders, pero a menudo también requiere deotros beans.
Configurando el Namespace de seguridadEn primer lugar es necesario modificar el "web.xml" y añadir los filtros de seguridad
<filter> <display-name>seguridadSpring</display-name> <filter-name>springSecurityFilterChain</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter> <filter-mapping> <filter-name>springSecurityFilterChain</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
Se añaden los usuarios mediante el proveedor de servicios, asignándole un password y los criterios de autorización depermisos. Esta información será utilizada por el authentication-manager en los procesos de autenticación
<authentication-manager> <authentication-provider> <user-service> <user name="jimi" password="jimispassword" authorities="ROLE_USER, ROLE_ADMIN" />
39
<user name="bob" password="bobspassword" authorities="ROLE_USER" /> </user-service> </authentication-provider></authentication-manager>
El authentication-provider puede ser configurado para que sea una base de datos, o la implementación de seguridad queconfiguremos.
Mediante el http introducimos los patrones a controlar con los permisos asociados por el framework de seguridad. Aquí sepueden indicar la página de inicio, la situación tras un intento de login, etc
<sec:http auto-config="true"> <sec:intercept-url pattern="/cambio.jsp" access="ROLE_ADMIN"/> <sec:form-login login-page="/conexion.jsp" authentication-failure-url="/error.jsp" login-processing-url="/seguridad"/> </sec:http>
Otros aspectos de la configuración de Spring SecurityA continuación se ofrecen diversos aspectos configurables en Spring Security
Control sobre la sesiónSe puede controlar el acceso de sesión minimizando a una única sesión activa. Para ello es necesario modificar el web.xml eincluir un listener específico:
<listener> <listener-class> org.springframework.security.web.session.HttpSessionEventPublisher </listener-class></listener>
y a continuación indicarle la restricción en el contexto de la aplicación
<http> ... <concurrent-session-control max-sessions="1" /></http>
OpenID LoginEL Namespaces soporta OpenID Login con una leve modificación. Es necesario tener nuestro propio servidor de OpenID
<http> <intercept-url pattern="/**" access="ROLE_USER" /> <openid-login /></http>
Añadir criptografía al password de usuarioA menudo pueden ser codificadas las claves de usuario a partir de un algoritmo de hashing. Esto es soportado por el<password-encoder>. En el ejemplo siguiente , con SHA
<authentication-provider> <password-encoder hash="sha"/> <user-service> <user name="jimi" password="d7e6351eaa13189a5a3641bab846c8e8c69ba39f" authorities="ROLE_USER, ROLE_ADMIN" /> <user name="bob" password="4e7421b1b8765d8f9406d87e7cc6aa784c4ab97f" authorities="ROLE_USER" /> </user-service></authentication-provider>
Tabla de filtrosA continuación se ofrece la tabla de filtros básicos de configuración. Los filtros se ejecutan de forma ordenada, así que esinteresante situar en la parte alta los más solicitados para mejorar la ejecución
Filtro Clase Elemento del NamespaceCHANNEL_FILTER ChannelProcessingFilter http/intercept-url
http/concurrent-session-40
CONCURRENT_SESSION_FILTER ConcurrentSessionFilter http/concurrent-session-control
SESSION_CONTEXT_INTEGRATION_FILTER HttpSessionContextIntegrationFilter httpLOGOUT_FILTER LogoutFilter http/logoutX509_FILTER X509PreAuthenticatedProcessigFilter http/x509
PRE_AUTH_FILTER AstractPreAuthenticatedProcessingFilterSubclasses N/A
CAS_PROCESSING_FILTER CasProcessingFilter N/AAUTHENTICATION_PROCESSING_FILTER AuthenticationProcessingFilter http/form-loginBASIC_PROCESSING_FILTER BasicProcessingFilter http/http-basicSERVLET_API_SUPPORT_FILTER SecurityContextHolderAwareRequestFilter http/@servlet-api-provisionREMEMBER_ME_FILTER RememberMeProcessingFilter http/remember-meANONYMOUS_FILTER AnonymousProcessingFilter http/anonymousEXCEPTION_TRANSLATION_FILTER ExceptionTranslationFilter httpNTLM_FILTER NtlmProcessingFilter N/AFILTER_SECURITY_INTERCEPTOR FilterSecurityInterceptor httpSWITCH_USER_FILTER SwitchUserProcessingFilter N/A
EjemplosA continuación vamos a realizar un breve ejemplo de configuración de Spring Security.
Añadir dentro del fichero Web.xml la dirección de la configuración de seguridad y añadir los filtros
<context-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/applicationContext-security.xml</param-value> </context-param><filter> <filter-name>springSecurityFilterChain</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter> <filter-mapping> <filter-name>springSecurityFilterChain</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
Crear el fichero con la configuración de seguridad, applicationContext-security.xml
<!-- CONFIGURACION VALIDA PARA SPRING SECURITY 2.0 con JDBC --> <?xml version="1.0" encoding="UTF-8"?><beans:beans xmlns="http://www.springframework.org/schema/security" xmlns:beans="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-2.0.1.xsd"> <!-- CONFIGURACION VALIDA PARA SPRING SECURITY 2.0 con JDBC --> <http auto-config="true" access-denied-page="/web/error.do"> <intercept-url pattern="/" access="IS_AUTHENTICATED_ANONYMOUSLY" /> <intercept-url pattern="/login.do" access="IS_AUTHENTICATED_ANONYMOUSLY" /> <intercept-url pattern="/j_spring_security_switch_user" access="ROLE_SUPERVISOR" /> <intercept-url pattern="/web/css/**" access="ROLE_WEBMASTER" /> <intercept-url pattern="/templates/**" access="ROLE_WEBMASTER" /> <intercept-url pattern="/web/error/**" access="ROLE_USER" /> <form-login login-page="/login.do" default-target-url='/web/index.do' authentication-failure-url="/login.do?login_error=1" />
41
<logout logout-success-url="/" invalidate-session="true"/> </http> <authentication-provider user-service-ref="userService" /> <!-- MYSQL --> <beans:bean id="securityDataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> <beans:property name="driverClassName" value="org.gjt.mm.mysql.Driver" /> <beans:property name="url" value="jdbc:mysql://localhost/test" /> <beans:property name="username" value="root" /> <beans:property name="password" value="" /> </beans:bean> <jdbc-user-service id="userService" data-source-ref="securityDataSource" group-authorities-by-username-query="SELECT g.nombre, a.rol FROM dbo.bm_usuario u
Enlaces externosPagina de Spring Security
Ejemplo de configuración
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterPAUT-0234 Autorizaciones personalizadas Directriz No Recomendada
Seguridad LOPD ENS
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/213
42
Consultas para el acceso a nodos restringidos en DrupalÁrea: Control de Acceso y AutenticaciónCarácter del recurso: RecomendadoTecnologías: PHP
Código: RECU-0556Tipo de recurso: Ejemplo
DescripciónA continuación se muestra un ejemplo para consultar el acceso a nodos restringidos en Drupal
EjemplosSi se tiene como ejemplo lo siguiente, la página principal de Drupal tiene una lista de nodes y links que te llevan al contenido delos citados nodos. Imagine que esta instalado el modulo Private y se han creado dos nodos, el nodo1 visible para todos losusuarios y el nodo 2 que tiene el acceso restringido mediante el modulo Private. La consulta para listar los nodos de la paginaprincipal es ejecutada en el pager_query:
SELECT DISTINCT(n.nid), n.sticky, n.createdFROM node nWHERE n.promote = 1AND n.status = 1ORDER BY n.sticky DESC, n.created DESCLIMIT 0, 10
Despues de habilitar y configurar el modulo Private, la consulta se reescribe para incluir los limites. Estas condicionesespecíficas son añadidas por un usuario que no es el autor del módulo, por lo que puede que se le deniegue el acceso al nodo
SELECT DISTINCT(n.nid), n.sticky, n.createdFROM node n INNER JOIN node_access na ON na.nid = n.nidWHERE (na.grant_view >= 1 AND ((na.gid = 0 AND na.realm = 'all’)OR (na.gid = 0 AND na.realm = 'private_author’)))AND ( n.promote = 1 AND n.status = 1 )ORDER BY n.sticky DESC, n.created DESC LIMIT 0, 10
En la primera consulta, solo las condiciones aseguran que los nodos son promocionados desde la pagina de inicio y publicados.En la segunda consulta, hay un conjunto mucho mas complejo de condiciones y un join a la tabla node access. Se puedeespecificar las condiciones después, pero db_rewrite_sql esta modificando la consulta para añadir controles para mostrar sololos nodos que debe de permitir el usuario
El modulo Vulnerable provee una pagina que lista los nodos que no usa el sistema. Dentro de la función vulnerable_node_listesta la consulta
$results = db_query(“SELECT n.nid, n.title, nr.body FROM {node} nINNER JOIN {node_revisions} nr ON n.vid = nr.vid“);
Cuando es ejecutado por un usuario autenticado o un usuario anónimo, el resultado es que todos los datos se muestranindependientemente de los permisos del usuario. Varios cambios son necesarios para hacer esta función de seguridad. Unaopción simple es agregar una restricción al menú para que sólo los usuarios con el permiso para la administración de losnodos,pueden acceder a la página. Esto funciona, pero no es la meta. En cambio,la consulta debe ser modificado de variasmaneras. Lo primero es introducir una condición WHERE para chequear que el nodo esta publicado:
$results = db_query(“SELECT n.nid, n.title, nr.body FROM {node} nINNER JOIN {node_revisions} nr ON n.vid = nr.vid WHEREn.status = 1“);
Lo siguiente sería envolver la consulta con una llamada a db_rewrite_sql:
$results = db_query(db_rewrite_sql(“SELECT n.nid, n.title, nr.bodyFROM {node} n INNER JOIN {node_revisions} nr ON n.vid = nr.vidWHERE n.status = 1“));
Ahora cuando la consulta es ejecuta por un usuario sin privilegios , es transformado para que contenga los limites propuestos,justo como pagina de inicio mostraba previamente
43
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0254 Control de acceso Directriz Obligatoria
Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/556
44
Controlador Java del DNI electrónicoÁrea: Control de Acceso y AutenticaciónCarácter del recurso: RecomendadoTecnologías: Java
Código: RECU-0622Tipo de recurso: Referencia
DescripciónEl siguiente enlace nos redirige a la web del PAE (Portal Administración Electrónica), el cual nos facilita información acerca de uncontrolador Java del DNI electrónico que es una pieza software que permite exportar servicios de acceso a los mecanismos yfuncionalidades del DNI electrónico, normalizados conforme a la arquitectura de seguridad Java.
Enlaces externosPAE (Portal de Administración Electrónica)
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0253 Autenticación Directriz Obligatoria
ENS LOPD
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/622
45
Envío de credenciales por correo electrónico en DrupalÁrea: Control de Acceso y AutenticaciónCarácter del recurso: No recomendado
Código: RECU-0675Tipo de recurso: Ejemplo
DescripciónPor defecto, Drupal transmite las contraseñas de las cuentas por correo electrónico. Esto suele suceder cuando se crea unanueva cuenta de usuario. La plantilla predeterminada de correo electrónico enviado a los usuarios incluye el nombre de usuario,contraseña y un enlace a una página de inicio de sesión.
El peligro en el envío de contraseñas a través del correo electrónico es que el correo electrónico se transmite generalmente através de canales no cifrados. Con el fin de mitigar esta amenaza, es importante eliminar la inclusión de la contraseña en laplantilla de correo electrónico, editando dicha página y modificando los elementos a incluir.
En el caso de que la cuenta sea creada por un administrador, será necesario desmarcar la casilla "Notificar al usuario de lanueva cuenta" y hacerle llegar por medios seguros al usuario su contraseña.
46
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0285 Manejo de contraseñas perdidas Directriz Obligatoria
Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/675
47
Limitación del número de autenticaciones en JavaÁrea: Control de Acceso y AutenticaciónCarácter del recurso: RecomendadoTecnologías: Java
Código: RECU-0664Tipo de recurso: Ejemplo
DescripciónEl siguiente código muestra como se puede limitar el número de intentos fallidos al intentar logarse en una aplicación. Elcontador en cada intento se va incrementando hasta el momento en el que alcanza el valor de MAX_ATTEMPTS. Una vezalcanzado se le impide el acceso a la aplicación hasta que recupere la contraseña
int validateUser(string host, int port) {...int count = 0; while (isValidUser && (count < MAX_ATTEMPTS)) { if (getNextMessage(socket, username, USERNAME_SIZE) > 0) { if (getNextMessage(socket, password, PASSWORD_SIZE) > 0) { isValidUser = AuthenticateUser(username, password); } } count++; } if (isValidUser) { return(SUCCESS); } else { return(FAIL); }}
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0253 Autenticación Directriz Obligatoria
Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/664
48
Manejar los permisos mediante la función hook_perm() en DrupalÁrea: Control de Acceso y AutenticaciónCarácter del recurso: ObligatorioTecnologías: PHP
Código: RECU-0565Tipo de recurso: Ejemplo
DescripciónEs recomendable proteger los accesos a las funciones críticas de los módulos mediante permisos.
EjemplosLa función hook_perm() permite a todos los módulos añadir permisos para su administración.
function blog_perm() { return array(‘create blog entries’, ‘delete own blog entries’, ‘delete any blog entry’, ‘edit own blog entries’, ‘edit any blog entry’);}
Crear un nuevo permiso para el módulo es tan simple como añadir una nueva entrada en el array que se retorna. Un ejemplo dela implementación en el modulo node sería el siguiente:
function node_perm() { $perms = array(‘administer content types’, ‘administer nodes’, ‘access content’, ‘view revisions’, ‘revert revisions’, ‘delete revisions’); foreach (node_get_types() as $type) { if ($type->module == ‘node’) { $name = check_plain($type->type); $perms[] = ‘create ’. $name .‘ content’; $perms[] = ‘delete own ’. $name .‘ content’; $perms[] = ‘delete any ’. $name .‘ content’; $perms[] = ‘edit own ’. $name .‘ content’; $perms[] = ‘edit any ’. $name .‘ content’; } } return $perms;}
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0254 Control de acceso Directriz Obligatoria
ENS LOPD
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/565
49
Manejo de las contraseñas perdidas en PHPÁrea: Control de Acceso y AutenticaciónCarácter del recurso: Obligatorio
Código: RECU-0582Tipo de recurso: Ejemplo
DescripciónEn este ejemplo se describe, en PHP, cómo generar una nueva contraseña, utilizando un número aleatorio y un algoritmo hashsha256 para encriptarla. Enviándola por email a un usuario que ha perdido su anterior contraseña.
Ejemplos<?php/* Generate new password. */
$new_password = '';for ($i = 0; $i < 8; $i++) { $new_password .= chr(mt_rand(33, 126));}/* Define a salt. */define('SALT', 'flyingturtle');
/* Encrypt new password. */$encrypted_password = hash('sha256',SALT . $new_password);
/* Save new encrypted password to the database. */$st = $db->prepare('UPDATE users SET password = ? WHERE username = ?');$st->execute(array($encrypted_password, $clean['username']));/* Email new plain text password to user. */
mail($clean['email'], 'New Password', "Your new password is: $new_password");?>
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0285 Manejo de contraseñas perdidas Directriz Obligatoria
ENS Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/582
50
Manejo de permisos en métodos de EJBÁrea: Control de Acceso y AutenticaciónCarácter del recurso: ObligatorioTecnologías: EJB3, Java
Código: RECU-0544Tipo de recurso: Ejemplo
DescripciónSi los derechos de acceso que se asignan a los métodos EJB no son restrictivos, entonces un atacante puede aprovecharse delos permisos para explotar el sistema. Es recomendable, seguir principio de mínimo privilegio en la asignación dederechos de acceso a métodos EJB. El permiso para invocar métodos EJB no se debe conceder a roles que no tenganasignados roles específicos (no utilizar ANYONE o cosas similares). Si el descriptor de despliegue EJB contiene uno o máspermisos de métodos que garantizan el acceso al rol especial ANYONE, indica que el control de acceso de aplicación no hasido plenamente tenido en cuenta. Un ejemplo de mala definición a evitar sería el siguiente.
Ejemplos// El siguiente descriptor garantiza a ANYONE el permiso para invocar el método de getSalary de la clase Employee
<ejb-jar> ... <assembly-descriptor> <method-permission> <role-name>ANYONE</role-name> <method> <ejb-name>Employee</ejb-name> <method-name>getSalary</method-name> </method-permission> </assembly-descriptor> ...</ejb-jar>
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0254 Control de acceso Directriz Obligatoria
ENS LOPD
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/544
51
Portal CERESÁrea: Control de Acceso y AutenticaciónCarácter del recurso: Recomendado
Código: RECU-0621Tipo de recurso: Referencia
DescripciónCERES (Certificación Española) es un proyecto que lidera la Fábrica Nacional de Moneda y Timbre (FNMT) que consiste enestablecer una Entidad Pública de Certificación que permita autentificar y garantizar la confidencialidad de lascomunicaciones entre ciudadanos, empresas u otras instituciones y administraciones públicas a través de las redes abiertasde comunicación.
Enlaces externosPortal CERES
Buenas prácticas en el uso del certificado digital y la firma electrónica
ENS LOPD
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/621
52
Retardo tras autenticación fallida en PHPÁrea: Control de Acceso y AutenticaciónCarácter del recurso: RecomendadoTecnologías: PHP
Código: RECU-0666Tipo de recurso: Ejemplo
DescripciónTras un intento de autenticación fallido, el usuario no puede volver a intentar logarse hasta haber transcurrido un tiempodeterminado.
Ejemplos <?php/* mysql_connect() *//* mysql_select_db() */$clean = array();$mysql = array();
$now = time();$max = $now - 15;
$salt = 'SHIFLETT';
if (ctype_alnum($_POST['username'])) { $clean['username'] = $_POST['username']; }else { /* ... */ }
$clean['password'] = md5($salt . md5($_POST['password'] . $salt));$mysql['username'] = mysql_real_escape_string($clean['username']);$sql = "SELECT last_failure, password FROM users WHERE username = '{$mysql['username']}'";
if ($result = mysql_query($sql)) { if (mysql_num_rows($result)) { $record = mysql_fetch_assoc($result); if ($record['last_failure']> $max) { /* Less than 15 seconds since last failure */ } elseif ($record['password'] == $clean['password']) { /* Successful Login */ }
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0253 Autenticación Directriz Obligatoria
Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/666
53
Sistemas anti-botsÁrea: Control de Acceso y AutenticaciónCarácter del recurso: Recomendado
Código: RECU-0650Tipo de recurso: Referencia
DescripciónEl sistema anti-bot permite proteger los formularios de ataques realizados por programas robot. Estos robots localizan losformularios y realizan peticiones descontroladas de forma automática. La protección frente a estos ataques radica en forzaruna acción humana antes del envió del formulario, por ejemplo, la copia de un texto deformado, transcripción de una frasesonora distorsionada, respuesta a una pregunta lógica o una acción mecánica que implique mover un objeto de un lugar a otro.Estas acciones son difíciles de mecanizar por un programa robot.
Existen distintas técnicas que enumeramos a continuación
Captcha gráficoMostrar un texto alfanumérico distorsionado en una imagen que una máquina no sea capaz de entender.
Se trata del elemento más habitual y consiste en una imagen en la que se muestran una serie de caracteres alfanuméricosmanipulados para dificultar su percepción.
Provoca que nuestra página deje de ser accesible a personas con deficiencias visuales, ya que los intérpretes no losreconocen. Como solución, se propone dar como la alternativa los captchas auditivos.
Captcha auditivoReproducir un archivo auditivo con ruido de fondo que una máquina no sea capaz de entender.Se trata de un archivo de sonidoequivalente al captcha gráfico. Este archivo indica una serie de caracteres alfanuméricos al reproducirse mediante sonidosdistorsionados o con ruido de fondo.
Al igual que el método anterior hace nuestra página no accesible, como solución se debe facilitar una alternativa a estesistema, por ejemplo, el captcha lógico.
Captcha lógicoRealizar una pregunta lógica sencilla que una máquina no sea capaz de responder.
Este mecanismo es el que facilita el acceso a un mayor número de usuarios y en consecuencia el mejor desde el punto devista de la accesibilidad, siempre y cuando las preguntas que se realicen no sean difíciles de comprender o requieran deconocimientos especiales.
Acción mecánicaConsiste en solicitar al usuario que desplace un objeto de una parte a otra de la pantalla. El formulario permanecerá bloqueadohasta que el usuario desplace el objeto a donde se le solicita.
54
Enlaces externosWeb oficial (en ingles)
Pautas
Área: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0253 Autenticación Directriz Obligatoria
Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/650
55
Uso de getPermissions()Área: Control de Acceso y AutenticaciónCarácter del recurso: ObligatorioTecnologías: Java
Código: RECU-0603Tipo de recurso: Ejemplo
DescripciónAl escribir un cargador de clases personalizadas, a veces es conveniente reemplazar el método getPermissions(). En lamayoría de los casos se recomienda consultar la política por defecto de la aplicación antes de asignar permisos arbitrarios enel código fuente.
Esto puede controlarse de forma automática al invocar explícitamente el método getPermissions() de la superclase.
EjemplosEl siguiente ejemplo de código no cumple lo recomendado. Muestra un fragmento de un cargador de clases personalizadasque extiende la clase URLClassLoader. Se reemplaza el método getPermissions () y no requiere el métodogetPermissions más restrictivo de la superclase. Tenga en cuenta que el método getPermissions() de la claseURLClassLoader llama al método getPermissions() de la clase Policy de forma que, por defecto, usa la política globalde todo el sistema de archivos para aplicar al control de acceso.
En consecuencia, una clase definida usando el cargador de clases personalizadas tiene permisos que son completamenteindependientes de los especificados en el archivo de política en todo el sistema y, en efecto, los permisos de la clase sonsobrescritos.
protected PermissionCollection getPermissions(CodeSource cs) { PermissionCollection pc = new Permissions(); pc.add(new RuntimePermission("exitVM")); //allow exit from the VM anytime return pc;}
La manera recomendada sería la del ejemplo siguiente, donde el método que reemplaza getPermissions() llama asuper.getPermissions() y, por tanto, se consulta la directiva de seguridad predeterminada para todo el sistema ademásde la directiva personalizada.
protected PermissionCollection getPermissions(CodeSource cs) { PermissionCollection pc = super.getPermissions(cs); pc.add(new RuntimePermission("exitVM")); return pc;}
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0254 Control de acceso Directriz Obligatoria
Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/603
56
Uso de java.security.AllPermissionÁrea: Control de Acceso y AutenticaciónCarácter del recurso: Obligatorio
Código: RECU-0601Tipo de recurso: Ejemplo
DescripciónLa clase java.security.AllPermission engloba todos los permisos definidos para una politica de permisos determinada. Setrata de un permiso cuya utilidad principal es la de permitir acceder a la totalidad de una aplicación durante la etapa de pruebas.Por tanto, es un permiso que no debe ser empleado fuera de la etapa de pruebas, salvo en casos en los que una aplicación oapplet sea totalmente confiable y la política de permisos sea demasiado compleja como para realizar una asignación de todoslos permisos existentes.
EjemplosUn ejemplo de código vulnerable es el siguiente:
protected PermissionCollection getPermissions(CodeSource cs) { PermissionCollection pc = new Permissions(); pc.add(new java.security.AllPermission()); // other permissions return pc;}
Que podría solucionarse si utilizamos el siguiente código que no concede todos los permisos
protected PermissionCollection getPermissions(CodeSource cs) { PermissionCollection pc = super.getPermissions(cs); // add fine-grained permissions return pc;}
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0254 Control de acceso Directriz Obligatoria
ENS LOPD
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/601
57
Uso del modulo Login Security en DrupalÁrea: Control de Acceso y AutenticaciónCarácter del recurso: Obligatorio
Código: RECU-0674Tipo de recurso: Ejemplo
DescripciónEl módulo de Drupal, Login security se puede utilizar en todos los sitios del portal. El módulo avisa a los administradorescuando existen fallos en los intentos de autenticación e impone un retraso para cada nuevo intento.
Este módulo no viene instalado por defecto en Drupal 6.2.6, sino que hay que descargarlo desde la página de Drupalhttp://drupal.org/project/login_security y configurarlo posteriormente.
Una vez descargado, es necesario descomprimirlo en la carpeta “modules” de Drupal y entonces aparecerá en la consola deadministración para su utilización.
Después de un número determinado de intentos puede bloquear la cuenta sobre la que se intenta acceder. Este módulopuede prevenir los ataques de adivinación de contraseñas contra los sitios Drupal y supervisar los inicios de sesión para alertara los administradores de problemas potenciales.
58
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0253 Autenticación Directriz Obligatoria
Seguridad
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/674
59
Variables externas en bloques doPrivilegedÁrea: Control de Acceso y AutenticaciónCarácter del recurso: ObligatorioTecnologías: Java
Código: RECU-0602Tipo de recurso: Ejemplo
DescripciónEs importante no permitir las operaciones de las entradas externas en un bloque doPrivileged (). Esto se debe a que unatacante podría suministrar entradas maliciosas que pueden provocar ataques de escalada de privilegios y proporcionarle uncontrol no deseado sobre la aplicación.
EjemplosUn código vulnerable sería el siguiente, que acepta un argumento de entrada:
private void privilegedMethod(final String filename) throws FileNotFoundException { try { FileInputStream fis = (FileInputStream) AccessController.doPrivileged( new PrivilegedExceptionAction() { public FileInputStream run() throws FileNotFoundException { return new FileInputStream(filename); } } ); // do something with the file and then close it } catch (PrivilegedActionException e) { // forward to handler and log }}
Un atacante podría proporcionar el nombre de un archivo de contraseñas sensibles, con la ruta de acceso y, por tanto, forzar arealizar las operaciones en el archivo incorrecto.
Una manera de protegerse de ataques de este tipo sería de la siguiente manera:
Indicando explícitamente el nombre del archivo y limitando las variables utilizadas en el bloque privilegiado en el mismométodo. Esto asegura que ningún archivo malicioso se puede cargar mediante la explotación de los privilegios del códigocorrespondiente:
private void privilegedMethod() throws FileNotFoundException { try { FileInputStream fis = (FileInputStream) AccessController.doPrivileged( new PrivilegedExceptionAction() { public FileInputStream run() throws FileNotFoundException { return new FileInputStream("/usr/home/filename"); } } ); // do something with the file and then close it } catch (PrivilegedActionException e) { // forward to handler and log }}
PautasÁrea: Desarrollo » Seguridad » Control de Acceso y Autenticación
Código Título Tipo CarácterLIBP-0254 Control de acceso Directriz Obligatoria
ENS LOPD Seguridad60
Source URL: http://127.0.0.1/servicios/madeja/contenido/recurso/602
61