Coders Conquer Security OWASP Top 10 APIシリーズ - セキュリティ機能の無効化 / デバッグ機能の有効化 / 不適切な権限設定

このリストにある脆弱性の多くはAPI特有のものですが、セキュリティ機能の無効化、デバッグ機能の有効化、不適切な権限設定といった問題は、どこで発生してもおかしくありません。APIで特に多く見られますが、攻撃者はネットワーク上のあらゆる場所で、修正されていない脆弱性や保護されていないファイル、ディレクトリを探し出そうとします。デバッグが有効になっていたり、セキュリティ機能が無効化されていたりするAPIは、攻撃者にとって格好の標的となります。さらに悪いことに、セキュリティ設定の不備を検出し悪用するための自動化ツールが存在するため、環境内にこうした不備があれば悪用される可能性が高く、これがOWASPのAPI脆弱性リストに挙げられている理由です。

本題に入る前に、このデバッグに関する課題を解けるか試してみましょう。

セキュリティ機能の無効化、デバッグ機能の有効化、不適切な権限設定といった脆弱性は、どのようにしてAPIに紛れ込むのでしょうか？

この多面的なAPIの脆弱性がネットワークにどのように入り込むのか、その構成要素を分解して見ていきましょう。まずは「デバッグ機能の有効化」という問題から始めます。デバッグは、アプリケーションが正しく動作しない理由やエラーの原因を開発者が特定するための便利なツールです。デバッグを有効にすると、エラーや例外が発生した際に詳細なエラーページが生成されるため、開発者は何が問題だったのかを確認し、修正することができます。アプリケーションの開発段階であれば、これを有効にしておくことは全く問題ありません。

しかし、ほとんどのフレームワークが本番環境でのデバッグモード実行に対して警告を発するのには理由があります。その警告は、デバッグを有効にするコードのすぐ近くに記載されていることが一般的です。例を挙げます。

# セキュリティ警告: 本番環境でデバッグを有効にしたまま実行しないでください！
DEBUG = True

この例では、デバッグが有効になっています。Djangoアプリケーションは、例外が発生すると詳細なエラーページを生成します。これを本番環境で行うと、攻撃者はこれらのエラーページにアクセスできてしまい、環境に関するメタデータ情報まで知られてしまいます。ほとんどのフレームワークではデフォルトでデバッグがオフになっていますが、長期にわたる開発プロセスで有効にしたまま、オフに戻し忘れることはよくあります。その状態でアプリケーションを本番環境に移行すると、攻撃者にアプリケーション、さらにはサーバーやネットワーク全体を侵害するための多くの情報を提供することになってしまいます。

デバッグモードの有効化は単独の問題であることが多い一方、不適切な権限設定とセキュリティ機能の無効化という脆弱性は、しばしば組み合わさって発生します。例えば、OWASPが紹介した実際の事例では、攻撃者が検索エンジンを使用して、誤ってインターネットに接続されたままのデータベースを見つけ出しました。一般的なデータベース管理システムがデフォルト設定のまま使用されていたため、認証が無効になっていたのです。このように、不適切な権限設定とセキュリティ機能の無効化という脆弱性が組み合わさった結果、攻撃者は個人情報（PII）、個人の好み、認証データを含む数百万件のレコードにアクセスしてしまいました。

セキュリティ機能の無効化、デバッグ機能の有効化、不適切な権限設定という脆弱性の排除

この脆弱性を排除するには、二段構えのアプローチが必要です。「デバッグ機能の有効化」という問題を取り除くには、APIやアプリケーションを本番環境に移行する前に、デバッグが無効になっていることを確認するチェック工程を開発プロセスに追加するだけで十分です。先ほどの例で言えば、適切なコマンドは以下のようになります。

# セキュリティ警告: 本番環境でデバッグを有効にしたまま実行しないでください！
DEBUG = False

これで、DEBUGフラグがFalseに設定され、Djangoアプリケーションのデバッグ機能は無効になりました。エラーが発生してもエラーページは生成されません。万が一、攻撃者がエラーページにアクセスできたとしても、そこには有用なメタデータは含まれておらず、アプリケーションへの脅威にはなりません。

セキュリティ機能の無効化や不適切な権限設定という脆弱性の排除は、より広範囲にわたる特定の脆弱性を含んでいる可能性があるため、少し難易度が高くなります。これらを防ぐ最善の方法は、保護された資産を本番環境へ迅速かつ容易にデプロイできるよう、標準化された再現可能なプロセスを構築することです。

さらに、オーケストレーションファイル、APIコンポーネント、Amazon S3バケットの権限設定などのクラウドサービスを常にレビューし、更新するプロセスを構築すべきです。このレビューでは、組織が常にAPIセキュリティを向上させられるよう、環境全体にわたるセキュリティ設定の有効性を定期的に評価する必要があります。

この脆弱性に関する詳細や、その他のセキュリティ上の欠陥から組織や顧客を守る方法については、Secure Code Warriorのブログをご覧ください。また、デモを試して、Secure Code Warriorのトレーニングプラットフォームでサイバーセキュリティスキルを常に最新の状態に保つことも可能です。