Qt Network Authorization Consideraciones de seguridad

Esta página cubre las consideraciones de seguridad para aplicaciones que utilizan Qt Network Authorization. Gran parte del contenido se centra en OAuth 2.0 Authorization Framework y OpenID.

Consulte el RFC 6749 para el flujo del protocolo OAuth 2.0 y el RFC 8252 para cuestiones de seguridad relativas a las aplicaciones nativas.

Control de acceso

El control de acceso implica la provisión de recursos a los usuarios mediante un sistema de comprobación de identidades y permisos. El control de acceso incluye servicios de autorización, autenticación y registro. Qt Network Authorization's API implementa el control de acceso centrándose en el marco de autorización OAuth 2.0. Qt Network Authorization admite el flujo de código de autorización (con PKCE) y el flujo de autorización de dispositivos.

Para los sistemas, una separación deliberada según privilegios y permisos es el primer paso del control de acceso. Las categorías de usuarios pueden dictar los grupos que pueden acceder a determinados recursos y servicios. Del mismo modo, los permisos sobre recursos o servicios pueden dictar las acciones disponibles sobre ellos. Solicita sólo los ámbitos de OAuth que tu aplicación necesita. Limitar el alcance reduce el impacto potencial si los tokens se ven comprometidos.

Los sistemas también deben implementar la gestión de acceso para la flexibilidad y la supervisión. El aprovisionamiento de acceso y servicios debe formar parte del diseño del sistema para que sea fácil añadir o eliminar usuarios y recursos sin comprometer la seguridad. Los registros de actividad facilitan las auditorías y los análisis de seguridad.

Un diseño muy conocido es el control de acceso basado en roles (RBAC).

Autenticación e inicio de sesión único

La autenticación consiste en comprobar la identidad de un usuario. Los métodos de autenticación débiles conducen a conceder acceso a los usuarios equivocados y pueden dar lugar a la exposición de datos privados y a la ejecución de acciones maliciosas.

Las aplicaciones conectadas necesitan verificar la identidad de los usuarios que utilizan recursos restringidos. Normalmente, las aplicaciones verifican a los usuarios comprobando sus credenciales, como el nombre de usuario y la contraseña, en una base de datos existente. Este método es vulnerable a falsas autenticaciones y violaciones de datos. Muchas técnicas de mitigación tienen que ver con el comportamiento del usuario y las aplicaciones pueden aplicar políticas de seguridad como exigir contraseñas seguras. Las aplicaciones pueden utilizar los validadores y widgets de Qt para guiar a los usuarios con mensajes y restringiendo la creación de contraseñas débiles.

El uso de un sistema de autenticación centralizado como un inicio de sesión único (SSO) puede minimizar la mala gestión de contraseñas e identidades.

Qt Network Authorization puede recuperar Tokens Web JSON (JWT) a través de OpenID Connect, una capa de identidad sobre OAuth 2.0. A menudo, la autenticación y la autorización forman parte del mismo sistema. Trate los tokens de acceso, los tokens de actualización y los tokens de identificación como datos confidenciales. Almacénalos de forma segura utilizando el almacenamiento seguro de la plataforma o el cifrado. No almacene los tokens en texto plano.

Autorización y provisión de recursos

La autorización consiste en comprobar si un usuario tiene acceso a un recurso basándose en los privilegios y permisos del usuario sobre ese recurso. Sin la autorización adecuada, los usuarios pueden acceder a un recurso y realizar acciones aunque no tengan el permiso. Los atacantes pueden modificar y reducir la integridad de los datos o abusar de los recursos, provocando una denegación de servicio.

Como precaución básica, realice comprobaciones de autorización antes de ejecutar acciones que puedan conducir a un uso indebido de los recursos. Esta comprobación puede realizarse siempre que los usuarios accedan a los recursos del servidor. Los privilegios de los usuarios y los permisos sobre los recursos determinan si el usuario puede ejecutar una acción sobre el recurso. Pueden ser necesarias comprobaciones de autorización adicionales en función del recurso. Revoca los tokens de acceso y actualización cuando los usuarios cierren sesión o cuando tu aplicación ya no los necesite.

Utilizar un agente de usuario externo

De acuerdo con el RFC 8252, las aplicaciones pueden utilizar un agente de usuario externo o integrado para el punto final de autorización, tal y como se define en OAuth 2.0. Los agentes de usuario integrados son normalmente las vistas web proporcionadas y controladas dentro de la aplicación. Los user-agents externos son los navegadores del sistema u otras aplicaciones no controladas por la aplicación solicitante.

El RFC 8252 recomienda utilizar agentes de usuario externos en lugar de vistas web incrustadas para la autorización. La aplicación controla el agente de usuario incrustado y no separa el acceso privilegiado entre la aplicación y el nodo de autorización. Esta configuración no es segura, ya que la aplicación puede registrar las pulsaciones de teclas y engañar a los usuarios con una falsa sensación de seguridad. Sin embargo, los navegadores integrados correctamente configurados como Qt WebEngine también se pueden utilizar cuando los agentes de usuario externos no son prácticos.

Además, con el navegador del sistema como agente de usuario externo, las pestañas del navegador y las credenciales almacenadas pueden simplificar la experiencia del usuario. Por ejemplo, los usuarios pueden utilizar sus nombres de usuario y contraseñas guardados en el navegador. Del mismo modo, el uso de gestores de contraseñas como agente de usuario externo aumenta la simplicidad y la confianza.

PKCE y parámetro de estado

Proof Key for Code Exchange (PKCE) protege contra ataques de interceptación de código de autorización en el flujo de código de autorización. Qt Network Authorization activa PKCE por defecto.

Qt Network Authorization genera valores de estado aleatorios de forma predeterminada para evitar ataques de falsificación de solicitud en sitios cruzados (CSRF). Si anula el parámetro de estado, evite utilizar cadenas codificadas.

Consideraciones sobre plataformas

La gestión de URI de redirección varía según la plataforma. En las plataformas móviles, los URI de redirección HTTPS se pueden gestionar de forma segura a través de URL reclamadas por la aplicación. En las plataformas de escritorio, los URI de redirección HTTP a localhost siguen siendo una opción válida para las aplicaciones nativas.

Recursos de seguridad para aplicaciones conectadas

Aquí tiene recursos de orientación sobre ciberseguridad:

• Common Weakness Enumeration - Un catálogo de problemas conocidos y posibles técnicas de mitigación.
• OWASP Cheat Sheet Series - Un listado de varios temas para asegurar aplicaciones.
• RFC 6749 - Marco de autorización OAuth 2.0
• RFC 8252 - OAuth 2.0 para aplicaciones nativas
• RFC 7636 - Clave de prueba para intercambio de código (PKCE)