Qt Network Sicherheitserwägungen zur Autorisierung

Diese Seite behandelt Sicherheitsüberlegungen für Anwendungen, die Qt Network Authorization verwenden. Ein Großteil des Inhalts konzentriert sich auf das OAuth 2.0 Authorization Framework und OpenID.

Siehe RFC 6749 für den Ablauf des OAuth 2.0-Protokolls und RFC 8252 für Sicherheitsfragen in Bezug auf native Anwendungen.

Zugriffskontrolle

Die Zugriffskontrolle umfasst die Bereitstellung von Ressourcen für Benutzer mithilfe eines Systems zur Überprüfung von Identitäten und Berechtigungen. Die Zugriffskontrolle umfasst dann Autorisierungs-, Authentifizierungs- und Protokollierungsdienste. Qt Network Die API von Authorization implementiert die Zugriffskontrolle mit Schwerpunkt auf dem OAuth 2.0 Authorization Framework. Qt Network Authorization unterstützt den Authorization Code Flow (mit PKCE) und den Device Authorization Flow.

Für Systeme ist eine bewusste Trennung nach Privilegien und Berechtigungen der erste Schritt der Zugriffskontrolle. Benutzerkategorien können die Gruppen festlegen, die auf bestimmte Ressourcen und Dienste zugreifen dürfen. Ebenso können Berechtigungen für Ressourcen oder Dienste die verfügbaren Aktionen für diese festlegen. Fordern Sie nur die OAuth-Bereiche an, die Ihre Anwendung benötigt. Die Begrenzung des Umfangs verringert die potenziellen Auswirkungen einer Kompromittierung der Token.

Systeme müssen auch ein Zugriffsmanagement für Flexibilität und Überwachung implementieren. Die Bereitstellung von Zugriff und Diensten muss Teil des Systemdesigns sein, damit es einfach ist, Benutzer und Ressourcen hinzuzufügen oder zu entfernen, ohne die Sicherheit zu beeinträchtigen. Aktivitätsprotokolle helfen bei Audits und Sicherheitsanalysen.

Ein bekanntes Konzept ist die rollenbasierte Zugriffskontrolle (RBAC).

Authentifizierung und Einmalanmeldung

Beider Authentifizierung wird die Identität eines Benutzers überprüft. Schwache Authentifizierungsmethoden führen dazu, dass den falschen Benutzern Zugang gewährt wird, was zur Offenlegung privater Daten und zur Ausführung bösartiger Aktionen führen kann.

Verbundene Anwendungen müssen die Identität von Benutzern überprüfen, die eingeschränkte Ressourcen nutzen. Normalerweise überprüfen Anwendungen die Benutzer, indem sie die Benutzerdaten wie Benutzername und Passwort in einer bestehenden Datenbank überprüfen. Diese Methode ist anfällig für falsche Authentifizierungen und Datenverstöße. Viele Abschwächungstechniken beziehen sich auf das Benutzerverhalten und Anwendungen können Sicherheitsrichtlinien durchsetzen, wie z. B. die Forderung nach starken Passwörtern. Anwendungen können die Validatoren und Widgets von Qt verwenden, um Benutzer mit Meldungen zu leiten und die Erstellung schwacher Passwörter einzuschränken.

Die Verwendung eines zentralisierten Authentifizierungssystems wie Single Sign-On (SSO) kann die falsche Verwaltung von Passwörtern und Identitäten minimieren.

Qt Network DieAutorisierung kann JSON Web Tokens (JWT) über OpenID Connect abrufen, eine Identitätsschicht, die auf OAuth 2.0 aufbaut. Häufig sind Authentifizierung und Autorisierung Teil desselben Systems. Behandeln Sie Zugangs-, Aktualisierungs- und ID-Tokens als sensible Daten. Speichern Sie sie sicher, indem Sie plattformsichere Speicherung oder Verschlüsselung verwenden. Speichern Sie Token nicht im Klartext.

Autorisierung und Ressourcenbereitstellung

Beider Autorisierung wird geprüft, ob ein Benutzer Zugriff auf eine Ressource hat, basierend auf den Benutzerprivilegien und -berechtigungen für diese Ressource. Ohne eine ordnungsgemäße Autorisierung können Benutzer auf eine Ressource zugreifen und Aktionen durchführen, obwohl sie keine Berechtigung haben. Angreifer können die Integrität von Daten verändern und beeinträchtigen oder Ressourcen missbrauchen, was zu einer Dienstverweigerung führt.

Als grundlegende Vorsichtsmaßnahme sollten Sie vor der Ausführung von Aktionen, die zu einem Missbrauch von Ressourcen führen können, eine Berechtigungsprüfung durchführen. Diese Prüfung kann immer dann erfolgen, wenn Benutzer auf serverseitige Ressourcen zugreifen. Die Privilegien der Benutzer und die Berechtigungen für die Ressourcen bestimmen, ob der Benutzer eine Aktion auf der Ressource ausführen darf. Je nach Ressource können zusätzliche Berechtigungsprüfungen erforderlich sein. Entziehen Sie Zugriffs- und Aktualisierungs-Tokens, wenn sich Benutzer abmelden oder wenn Ihre Anwendung sie nicht mehr benötigt.

Verwenden Sie einen externen Benutzer-Agenten

Gemäß RFC 8252 können Anwendungen entweder einen externen oder einen eingebetteten Benutzer-Agenten für den Autorisierungsendpunkt verwenden, wie in OAuth 2.0 definiert. Eingebettete User-Agents sind in der Regel die Webviews, die innerhalb der Anwendung bereitgestellt und gesteuert werden. Externe Benutzer-Agenten sind die Systembrowser oder andere Anwendungen, die nicht von der anfragenden Anwendung kontrolliert werden.

RFC 8252 empfiehlt die Verwendung von externen User-Agents anstelle von eingebetteten Webviews für die Autorisierung. Die Anwendung kontrolliert den eingebetteten User-Agent und versäumt es, den privilegierten Zugriff zwischen der Anwendung und dem Autorisierungsknoten zu trennen. Diese Konfiguration ist unsicher, da die Anwendung Tastatureingaben aufzeichnen und den Benutzern ein falsches Gefühl der Sicherheit vermitteln kann. Richtig konfigurierte eingebettete Browser wie Qt WebEngine können jedoch auch verwendet werden, wenn externe User-Agents nicht praktikabel sind.

Wenn der Systembrowser als externer Benutzer-Agent fungiert, können Browser-Tabs und gespeicherte Anmeldeinformationen die Benutzererfahrung vereinfachen. So können die Benutzer beispielsweise ihre gespeicherten Benutzernamen und Kennwörter im Browser verwenden. Auch die Verwendung von Kennwortmanagern als externer Benutzer-Agent erhöht die Einfachheit und das Vertrauen.

PKCE und Zustandsparameter

Proof Key for Code Exchange (PKCE) schützt vor Angriffen zum Abfangen von Autorisierungscodes im Autorisierungscodefluss. Qt Network Die Autorisierung aktiviert PKCE standardmäßig.

Qt Network Die Autorisierung generiert standardmäßig zufällige Statuswerte, um Cross-Site Request Forgery (CSRF)-Angriffe zu verhindern. Wenn Sie den Status-Parameter überschreiben, vermeiden Sie die Verwendung von hart kodierten Zeichenketten.

Überlegungen zur Plattform

Die Behandlung von Redirect-URIs variiert je nach Plattform. Auf mobilen Plattformen können HTTPS-Redirect-URIs sicher durch App-Claimed-URLs gehandhabt werden. Auf Desktop-Plattformen sind HTTP-Redirect-URIs zu localhost weiterhin eine gültige Option für native Anwendungen.

Sicherheitsressourcen für vernetzte Anwendungen

Hier finden Sie Ressourcen für Cybersecurity-Anleitungen:

• Common Weakness Enumeration - Ein Katalog bekannter Probleme und möglicher Entschärfungstechniken.
• OWASP Cheat Sheet Series - Eine Auflistung verschiedener Themen zur Sicherung von Anwendungen.
• RFC 6749 - OAuth 2.0 Autorisierungsrahmen
• RFC 8252 - OAuth 2.0 für native Anwendungen
• RFC 7636 - Proof Key für Codeaustausch (PKCE)