Qt OpenAPI のセキュリティに関する考慮事項

外部ソースからの OpenAPI 仕様の取り扱い

OpenAPI仕様ファイルは、コード生成パイプラインの主要な入力となります。このファイルは、生成されるクライアントの全機能範囲（APIエンドポイント、データモデル、サーバーURL、認証方式、および動作パラメータ）を定義します。ジェネレータは仕様内容を直接C++ソースコードに変換するため、信頼できる入力のみを使用する必要があります。

ユーザーは、外部ソースから取得した OpenAPI 仕様について、コードを生成する前にその妥当性を確認する責任があります。サードパーティのサービスや公開リポジトリからダウンロードした仕様には、コンパイル後に予期しない動作や有害な動作を引き起こす可能性のある値が含まれている場合があります。外部仕様を使用する前に、以下の点について確認してください：

• 予期しない、または不審なほど複雑なサーバーURLのパターンや変数定義。
• 生成されたソースコードに現れてはならない内容を含む説明フィールドや拡張属性。
• 実行時の安定性に影響を与える可能性のある、過度に深い、または循環的なモデル参照。
• 意図したリクエスト先を変更する可能性のあるサーバー変数の列挙値やデフォルト値。

ジェネレータは、仕様から派生した文字列を介した直接的なコードインジェクションを防ぐためにエスケープ処理を適用しますが、悪意のある仕様は、クラス名、エンドポイントURL、データフロー、操作のセマンティクスを含め、生成されるクライアントの構造と動作を依然として制御します。事前の確認なしに、根本的に信頼できない仕様を安全に使用できるようにするほどのエスケープ処理は存在しません。

リソース枯渇からの保護

OpenAPI仕様の意味論的な内容をレビューすることに加え、信頼できないソースからの仕様を処理するユーザーは、コード生成および実行中に消費されるリソースを制限することを検討すべきです。

悪意を持って作成された仕様は、例えば、極めて複雑なスキーマ構造、膨大な数の参照、あるいは深くネストされたモデルなどを通じて、コード生成プロセスそのものの最中に過剰なリソース消費を引き起こす可能性があります。 さらに、そのような仕様から生成されたコードは、リソースを大量に消費するコードパスやデータ構造をトリガーするように仕様が設計されている場合、実行時に過剰なリソースを消費し、リソース枯渇やサービス拒否（DoS）状態を引き起こす可能性があります。

基盤となる YAML パーサーは、悪意のある YAML 入力（過度なエイリアスの展開（例：Billion Laughs 攻撃）、深くネストされたコレクション、再帰的なマッピングキー、または異常に大きなドキュメントなど）によって引き起こされるサービス拒否攻撃を軽減するのに役立つ、いくつかの設定オプションをサポートしています。 これらの制限は、JVM システムプロパティ（例: `JAVA_OPTIONS ` または `JAVA_TOOL_OPTIONS`）を通じて設定可能であり、以下が含まれます：

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

例：

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}
)

YAMLパーサーは構文レベルの攻撃を阻止しますが、リソース枯渇のあらゆるバリエーションを防ぐことはできません。パーサーもOpenAPI Generatorも、スキーマの複雑さを制限したり、$ref チェーンの深さを測定したり、生成されるC++構造体が消費するスタックスペースを計算したりすることはありません。したがって、コード生成とコンパイルが成功したとしても、実行時の安全性が保証されるわけではありません。 本番環境のネットワークトラフィックを処理する際、アプリケーションは以下の2つの重大な攻撃ベクトルに対して脆弱なままとなります：

• 水平拡張（広範囲なペイロード） - スキーマのネスト深さは最小限であっても、膨大な数の兄弟オブジェクトを許可する場合があります。これらを実行時に解析するには過剰なヒープ割り当てが必要となり、深刻なメモリ断片化やメモリ不足（OOM）によるクラッシュを引き起こします。
• 垂直的な深さ（深いペイロード） — スキーマでは、コンパイルを通過する深くネストされた配列の配列やオブジェクトチェーンを正当に定義できる場合があります。 しかし、この深さを悪用した悪意のあるペイロードがネットワーク経由で到着すると、ランタイムパーサーの再帰的な実行によりスレッドの固定スタック領域が急速に枯渇し、回復不可能なスタックオーバーフローを引き起こします。

信頼できないソースからの仕様を処理するアプリケーションの場合、ユーザーはジェネレータを呼び出す前に、仕様について追加の手動レビューを行う必要があります。以下の点を確認することを検討してください：

ネットワーク通信

生成されたクライアントは、QNetworkAccessManager を使用して HTTP リクエストを実行します。認証情報（API キー、ベアラー トークン、Basic 認証）は、送信リクエストに添付されます。このライブラリは HTTPS を強制しません。アプリケーション側で、認証情報が安全な接続を介してのみ送信されるようにする必要があります。