API8: インジェクション

Injectionとは

以下の性質を持つAPIは、インジェクション脆弱性の影響を受ける恐れがあります:

• フロントエンドからの入力を十分に検証しないと、後続プロセスに干渉する可能性のある任意の値が入力される危険性があります。

• APIへのリクエストに関しても同様です。データがプロセスに入る前に、必ず検証や確認を行う必要があります。特にログイン処理など、問題が発生しやすい部分では、入力が適切に検証・確認・整形されているか、十分に留意してください。

• ユーザからの直接の入力だけでなく、第三者サービス経由の入力やファイルアップロードなど、他の入力経路にも注意を払ってください。

• バッチ処理など、既存のプロセスがデータによって影響を受ける可能性も考慮する必要があります。

‍

攻撃シナリオの例

これまでの経験から、この脆弱性について度々報告してきた事例がございます。特に注目するのは、インポート機能を経由するSQLインジェクションと、予期しない起点からのOSコマンドインジェクションです。まずはSQLiについて説明します。

当該問題は、プライベートなバグバウンティプログラムで発見されました。直接の入力には十分な整形処理が施されていたものの、インポート機能が考慮されていなかったために発生しました。アプリの基本部分は、インポート機能実装の1年前に構築されていたためです。

Upload.csvは次のような内容でした:

name,address,email,phone
',',','

アップロード時にフィールド区切りとしてカンマを選択すると、SQLエラーが表示され、その後詳細を調査することになりました。

エラー内容は次の通りです:

Expects parameter 1 to be string, null given in /var/www/html/import.php

これにより、クエリを中断し、新たなクエリを実行しました。

name,address,email,phone
';select * from users;--,',','

この結果、アプリはエラーメッセージ内にusersテーブル全体を出力しました。これをもって問題を報告し、バウンティを獲得するに至りました。

次の例はやや複雑さが低いものです。'osParam'というパラメータにフラグらしきものが含まれていることに気付き、事前に用意したコマンドインジェクションリストを用いてburp suite intruderを起動したところ、burp suiteの9回目のリクエストでヒットがありました。コマンドの区切り文字として改行コード '\n' を使用し、pingコマンドが応答を遅延させました。

index.php?osParam=\\nping -c 10 127.0.0.1

そこで直ちにwhoamiを試し、その結果を報告、2日後に承認が下りました。

‍

Injection脆弱性に対する予防策

• 入力は全て危険視し、第三者からのものやファイルインポートなど、直接でない入力も含めて、すべてに対してフィルタリング、検証、確認を徹底する必要があります。

• これらの処理を実施する1つのシステムを構築し、全てのエンドポイントで一貫してそのシステムを利用するようにしてください。

• なるべく、テスト済みの有名なライブラリを利用し、自作は避けることが望ましいです。

• 特殊文字のフィルタリングには注意が必要です。多くの言語には、特殊文字を扱うための固有の構文が存在するため、その構文に則って実装してください。

• 複数のレコードを取得する場合、1回のクエリあたりの件数を制限し、大量の情報漏洩を防ぐようにしてください。

• 可能であれば、OpenAPIなどの仕様を利用し、フィルタ、検証、確認ルールに合致するリクエストのみを許可してください。

• 全ての文字列エンドポイントおよび変数の型に対して、APIが期待する内容を明確に定義してください。

不適切な実装により、XSSなどの脆弱性が生じるphpの例:

$id = $row['id']; 
$title = $row['title']; 
$des = $row['description']; 
$time = $row['date'];

正しい実装例

$id = htmlentities($row['id']); 
$title = htmlentities($row['title']);
$des = htmlentities($row['description']); 
$time = htmlentities($row['date']);

‍

‍

‍

結論

この種の問題は多様で、自動テストが容易でない場合もあります。目立たないエンドポイントも含め、全てのポイントを把握することが重要です。自動テストだけでは補いきれない部分を、手動テストで補完することが推奨されます。

全エンドポイントの把握は、隠れたパラメータの発見も含め非常に煩雑となり得ます。新規APIエンドポイントは文書に追加し、既存のものも可能な限りインデックス化してください。この課題はAPI Security Companyを活用することで解決可能です。

統計によれば、この脆弱性は2021年のOWASP Top 10で最上位に位置すると考えられます。