Sicherheitsaspekte bei Qt OpenAPI

Umgang mit OpenAPI-Spezifikationen aus externen Quellen

Die OpenAPI-Spezifikationsdatei ist die wichtigste Eingabe für die Codegenerierungspipeline. Sie definiert die gesamte Oberfläche des generierten Clients: API-Endpunkte, Datenmodelle, Server-URLs, Authentifizierungsschemata und Betriebsparameter. Da der Generator den Inhalt der Spezifikation direkt in C++-Quellcode übersetzt, sollte er nur mit vertrauenswürdigen Eingaben verwendet werden.

Benutzer sind dafür verantwortlich, jede aus einer externen Quelle bezogene OpenAPI-Spezifikation zu überprüfen, bevor sie daraus Code generieren. Eine von einem Drittanbieter-Dienst oder einem öffentlichen Repository heruntergeladene Spezifikation kann Werte enthalten, die sich nach der Kompilierung unerwartet oder schädlich verhalten. Bevor Sie eine externe Spezifikation verwenden, überprüfen Sie diese auf:

• Unerwartete oder verdächtig komplexe Server-URL-Muster und Variablendefinitionen.
• Beschreibungsfelder oder Erweiterungsattribute, die Inhalte enthalten, die im generierten Quellcode nicht vorkommen sollten.
• Übermäßig tiefe oder zirkuläre Modellverweise, die die Laufzeitstabilität beeinträchtigen könnten.
• Enum-Werte oder Standardwerte von Servervariablen, die die beabsichtigten Anforderungsziele verändern könnten.

Zwar wendet der Generator Escaping an, um eine direkte Code-Injektion über aus der Spezifikation abgeleitete Zeichenfolgen zu verhindern, doch kontrolliert eine bösartige Spezifikation weiterhin die Struktur und das Verhalten des generierten Clients – einschließlich Klassennamen, Endpunkt-URLs, Datenfluss und Betriebssemantik. Kein noch so umfassendes Escaping kann eine grundsätzlich nicht vertrauenswürdige Spezifikation ohne vorherige Überprüfung sicher nutzbar machen.

Schutz vor Ressourcenerschöpfung

Neben der Überprüfung des semantischen Inhalts einer OpenAPI-Spezifikation sollten Nutzer, die Spezifikationen aus nicht vertrauenswürdigen Quellen verarbeiten, erwägen, die während der Codegenerierung und -ausführung verbrauchten Ressourcen zu begrenzen.

Eine böswillig gestaltete Spezifikation kann bereits während des Codegenerierungsprozesses selbst zu übermäßigem Ressourcenverbrauch führen, beispielsweise durch extrem komplexe Schemastrukturen, eine große Anzahl von Verweisen oder tief verschachtelte Modelle. Darüber hinaus kann der aus einer solchen Spezifikation generierte Code zur Laufzeit übermäßige Ressourcen verbrauchen, wenn die Spezifikation so konzipiert ist, dass sie ressourcenintensive Codepfade oder Datenstrukturen auslöst, was möglicherweise zur Ressourcenerschöpfung oder zu Denial-of-Service-Zuständen führen kann.

Der zugrunde liegende YAML-Parser unterstützt mehrere Konfigurationsoptionen, die dazu beitragen, Denial-of-Service-Angriffe durch böswillige YAML-Eingaben abzuwehren, wie beispielsweise übermäßige Alias-Erweiterung (z. B. „Billion Laughs“-Angriffe), tief verschachtelte Sammlungen, rekursive Zuordnungsschlüssel oder ungewöhnlich große Dokumente. Diese Grenzwerte können über JVM-Systemeigenschaften (z. B. mit ` JAVA_OPTIONS ` oder ` JAVA_TOOL_OPTIONS`) konfiguriert werden, darunter:

// Declaration (also called an anchor)
original: &name "John"
// Usage
copy: *name

Beispiel:

qt_add_openapi_client(Example
    SPEC_FILE
        ${CMAKE_CURRENT_SOURCE_DIR}/unstructed-source-spec.yaml
    JAVA_OPTIONS
        -DmaxYamlAliasesForCollections=10
        -DmaxYamlDepth=100
        -DmaxYamlCodePoints=5000000
        -DmaxYamlReferences=10
        -DsupportYamlAnchors=false
    OUTPUT_DIRECTORY
        ${CMAKE_CURRENT_BINARY_DIR}
)

Der YAML-Parser wehrt zwar Angriffe auf Syntaxebene ab, kann jedoch nicht alle Varianten der Ressourcenerschöpfung verhindern. Weder der Parser noch der OpenAPI-Generator begrenzen die Schemakomplexität, messen die Tiefe von $ref -Ketten oder berechnen den Stack-Speicherplatz, den die resultierende C++-Struktur beanspruchen wird. Folglich garantieren eine erfolgreiche Codegenerierung und Kompilierung keine Laufzeitsicherheit. Bei der Verarbeitung von Netzwerkverkehr in der Produktion bleibt die Anwendung anfällig für zwei kritische Angriffsvektoren:

• Horizontale Erweiterung (breite Payloads) – Ein Schema kann eine minimale Verschachtelungstiefe aufweisen, aber eine immense Anzahl von gleichrangigen Objekten zulassen. Das Parsen dieser Objekte zur Laufzeit erfordert eine übermäßige Heap-Zuweisung, was zu schwerer Speicherfragmentierung oder „Out-of-Memory“-Abstürzen (OOM) führt.
• Vertikale Vertiefung (tiefe Payloads) – Ein Schema kann gültig tief verschachtelte Arrays von Arrays oder Objektketten definieren, die die Kompilierung bestehen. Wenn jedoch eine bösartige Nutzlast, die diese Tiefe ausnutzt, über das Netzwerk eintrifft, wird die rekursive Ausführung des Laufzeit-Parsers den festen Stack-Speicherplatz des Threads rasch erschöpfen und einen nicht behebbaren Stack-Überlauf auslösen.

Bei Anwendungen, die Spezifikationen aus nicht vertrauenswürdigen Quellen verarbeiten, sollten Benutzer vor dem Aufruf des Generators eine zusätzliche manuelle Überprüfung der Spezifikation durchführen. Berücksichtigen Sie dabei folgende Punkte:

Netzwerkkommunikation

Generierte Clients führen HTTP-Anfragen über QNetworkAccessManager durch. Anmeldeinformationen (API-Schlüssel, Bearer-Token, Basic-Auth) werden an ausgehende Anfragen angehängt. Die Bibliothek erzwingt kein HTTPS; Anwendungen müssen sicherstellen, dass Anmeldeinformationen ausschließlich über sichere Verbindungen übertragen werden.