Fehlende Autorisierung

Beschreibung

Fehlende Autorisierung tritt auf, wenn ein Produkt keine Autorisierungsprüfung durchführt, wenn ein Akteur versucht, auf eine Ressource zuzugreifen oder eine Aktion auszuführen. Während das Produkt möglicherweise eine Authentifizierung durchführt, um die Identität des Akteurs zu verifizieren, versäumt es zu überprüfen, ob der authentifizierte Benutzer tatsächlich berechtigt ist, auf die spezifische Ressource zuzugreifen oder die angeforderte Aktion durchzuführen. Dies ist die Grundursache für IDOR-Schwachstellen (Insecure Direct Object Reference), bei denen Benutzer auf Daten anderer Benutzer zugreifen können, indem sie Identifikatoren wie Benutzer-IDs, Dokument-IDs oder Bestellnummern manipulieren.

Risiko

Fehlende Autorisierung wird konstant in den CWE Top 25 der gefährlichsten Software-Schwachstellen geführt. CVE-2025-36367 in IBM i (Versionen 7.2-7.6) ermöglicht authentifizierten Angreifern die Eskalation von Privilegien zu Root durch fehlende Autorisierungsprüfungen in SQL-Diensten. CVE-2025-11154 im IDonate WordPress-Plugin erlaubt nicht authentifizierten Angreifern das Löschen beliebiger Benutzerkonten. CVE-2025-12980 im PostX WordPress-Plugin legt Passwort-Hashes über einen ungeschützten REST-API-Endpunkt offen (CVSS 7.5). Aktuelle Schwachstellen betreffen SonicWall SMA1000, Apple iOS 26 und zahlreiche WordPress-Plugins. IDOR-Schwachstellen haben zu massiven Datenpannen geführt, bei denen Millionen von Benutzerdatensätzen offengelegt wurden.

Lösung

Implementieren Sie Autorisierungsprüfungen für jeden Ressourcenzugriff und jede Aktion. Verwenden Sie rollenbasierte Zugriffskontrolle (RBAC) oder attributbasierte Zugriffskontrolle (ABAC). Überprüfen Sie die Ressourceneigentümerschaft, bevor Sie den Zugriff erlauben. Implementieren Sie die Autorisierung auf der Service-/Geschäftslogikebene, nicht nur in der Benutzeroberfläche. Verwenden Sie indirekte Referenzen (Zuordnung von benutzer-zugänglichen IDs zu internen IDs). Protokollieren Sie Autorisierungsfehler für die Sicherheitsüberwachung. Testen Sie die Autorisierung mit verschiedenen Benutzerrollen und Grenzfällen. Verlassen Sie sich niemals ausschließlich auf clientseitige Zugriffskontrollen.

Häufige Auswirkungen

AuswirkungDetails
ZugriffskontrolleBereich: Unbefugter Zugriff

Benutzer können auf Ressourcen und Daten zugreifen, die anderen Benutzern oder höher privilegierten Konten gehören.
IntegritätBereich: Datenmodifikation

Angreifer können Daten ändern oder löschen, auf die sie keinen Zugriff haben sollten.
VertraulichkeitBereich: Datenoffenlegung

Sensible Informationen werden durch IDOR-Schwachstellen für unbefugte Benutzer zugänglich.

Beispielcode + Lösungscode

Verwundbarer Code

# VERWUNDBAR: Keine Autorisierungsprüfung - klassisches IDOR
@app.route('/api/documents/<doc_id>')
@login_required
def get_document(doc_id):
    # Prüft nur, ob der Benutzer angemeldet ist, nicht ob er das Dokument besitzt!
    document = Document.query.get(doc_id)
    return jsonify(document.to_dict())

# VERWUNDBAR: Keine Autorisierung beim Löschen
@app.route('/api/users/<user_id>', methods=['DELETE'])
@login_required
def delete_user(user_id):
    # Jeder authentifizierte Benutzer kann jeden anderen Benutzer löschen!
    user = User.query.get(user_id)
    db.session.delete(user)
    db.session.commit()
    return 'Gelöscht'

# VERWUNDBAR: Admin-Funktionalität ohne Rollenprüfung
@app.route('/admin/users')
@login_required  # Prüft nur Authentifizierung, nicht Autorisierung!
def list_all_users():
    users = User.query.all()
    return jsonify([u.to_dict() for u in users])

Sicherer Code

# SICHER: Autorisierungsprüfung beim Dokumentzugriff
@app.route('/api/documents/<doc_id>')
@login_required
def get_document_safe(doc_id):
    document = Document.query.get_or_404(doc_id)

    # Verifizieren, dass der aktuelle Benutzer das Dokument besitzt oder Zugriff hat
    if document.owner_id != current_user.id and \
       not document.has_viewer(current_user.id):
        abort(403, 'Zugriff verweigert')

    return jsonify(document.to_dict())

# SICHER: Autorisierung beim Löschen - nur Eigentümer oder Admin
@app.route('/api/users/<user_id>', methods=['DELETE'])
@login_required
def delete_user_safe(user_id):
    # Nur Selbstlöschung oder Admin-Löschung erlauben
    if current_user.id != int(user_id) and not current_user.is_admin:
        abort(403, 'Zugriff verweigert')

    user = User.query.get_or_404(user_id)

    # Verhindern, dass andere Admins gelöscht werden
    if user.is_admin and current_user.id != int(user_id):
        abort(403, 'Andere Administratoren können nicht gelöscht werden')

    db.session.delete(user)
    db.session.commit()

    audit_log.info(f"Benutzer {user_id} gelöscht von {current_user.id}")
    return 'Gelöscht'

# SICHER: Rollenbasierte Autorisierung für Admin-Funktionalität
@app.route('/admin/users')
@login_required
@require_role('admin')  # Decorator prüft Benutzerrolle
def list_all_users_safe():
    audit_log.info(f"Admin {current_user.id} hat alle Benutzer aufgelistet")
    users = User.query.all()
    return jsonify([u.to_safe_dict() for u in users])

def require_role(role):
    def decorator(f):
        @wraps(f)
        def decorated(*args, **kwargs):
            if not current_user.has_role(role):
                abort(403, f'Erfordert {role}-Rolle')
            return f(*args, **kwargs)
        return decorated
    return decorator

Ausgenutzt in der Praxis

IBM i SQL Services Privilegieneskalation (IBM, 2025)

CVE-2025-36367 in IBM i Versionen 7.2-7.6 enthält eine ungültige Autorisierungsprüfung in SQL-Diensten, die authentifizierten Angreifern die Eskalation von Privilegien zu Root auf dem Host-Betriebssystem ermöglicht.

IDonate WordPress Plugin Benutzerlöschung (IDonate, 2025)

CVE-2025-11154 im IDonate WordPress-Plugin vor Version 2.1.13 ermöglicht nicht authentifizierten Angreifern das Löschen beliebiger Benutzerkonten aufgrund fehlender Autorisierungsprüfungen im Benutzer-Lösch-Handler.

PostX WordPress Plugin Passwort-Hash-Offenlegung (PostX, 2025)

CVE-2025-12980 (CVSS 7.5) im PostX WordPress-Plugin ermöglicht nicht authentifizierten Benutzern das Abrufen von Benutzer-Metadaten einschließlich Passwort-Hashes über einen ungeschützten REST-API-Endpunkt.


Tools zum Testen/Ausnutzen

  • Burp Suite — IDOR testen durch Manipulation von Objekt-IDs.

  • Autorize — Burp-Erweiterung für Autorisierungstests.

  • OWASP ZAP — automatisierte Autorisierungstests.


CVE-Beispiele


Referenzen

  1. MITRE. "CWE-862: Missing Authorization." https://cwe.mitre.org/data/definitions/862.html

  2. OWASP. "Broken Access Control." https://owasp.org/Top10/A01_2021-Broken_Access_Control/