Coders Conquer Security OWASP Top 10 API Series - Disabled Security Features/Debug Features Enabled/Improper Permissions
このリストのほとんどの脆弱性は、APIにかなり特化したものですが、セキュリティ機能の無効化／デバッグ機能の有効化／不適切なパーミッションの問題は、どこでも起こりうる問題です。APIではやや多いと思われますが、攻撃者は、パッチが適用されていない欠陥や保護されていないファイルやディレクトリをネットワーク上のどこかで見つけようとすることがよくあります。デバッグが有効になっていたり、セキュリティ機能が無効になっていたりするAPIに出くわすと、彼らの悪事が少しだけ楽になります。さらに悪いことに、セキュリティの設定ミスを検出して悪用するための自動化されたツールが用意されているため、あなたの環境にそれらがあれば、悪用される可能性が高く、それがこの脆弱性がOWASPの危険なAPI欠陥リストに入った理由です。
お楽しみの前に、このデバッグの課題を解決できるかどうか見てみましょう。
セキュリティ機能の無効化/デバッグ機能の有効化/不適切なパーミッションの欠陥は、どのようにしてAPIに忍び込むのでしょうか？
この多次元的なAPIの欠陥がどのようにしてネットワークに追加されていくのかを知るためには、その構成要素に分解する必要があります。まず、デバッグ機能の有効化の問題から始めましょう。デバッグは、アプリケーションが正しく動作しなかったり、エラーが発生したりする原因を開発者が把握するのに役立つ便利なツールです。デバッグ機能を有効にすると、エラーや例外発生時に詳細なエラーページが生成されるため、開発者は何が悪かったのかを確認し、問題を修正することができます。アプリケーションがまだ開発中の場合は、この機能を有効にしても問題ありません。
しかし、ほとんどのフレームワークでは、本番環境でのデバッグモードの実行に関する警告が表示されるのには理由があり、おそらくデバッグを有効にするコードの中に表示されています。例えば、以下のようなものです。
# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください
DEBUG = True
この例では、デバッグを有効にしています。Django アプリケーションは、例外が発生すると詳細なエラーページを生成します。これが本番環境で行われた場合、敵対者はこのエラーページにアクセスすることができ、その中には環境に関するメタデータ情報が含まれています。ほとんどのフレームワークでは、デフォルトでデバッグ機能がオフになっていますが、長い開発期間中に有効になっていると、元に戻すのを忘れてしまいがちです。その後、アプリケーションが本番環境に移行すると、アプリケーション、あるいはサーバやネットワーク全体を危険にさらす方法について、攻撃者に多くの情報を提供してしまいます。
デバッグモードを有効にすることは、ほとんどが単独の問題ですが、不適切なパーミッションと無効なセキュリティ機能の脆弱性は、しばしば連動します。例えば、OWASP が提供している実際のシナリオでは、攻撃者が検索エンジンを使用して、誤ってインターネットに接続されているデータベースを見つけました。人気のあるデータベース管理システムは、デフォルトの設定を使用していたため、認証が無効になっていました。このように、不適切なパーミッションと無効化されたセキュリティ機能の脆弱性を組み合わせることで、攻撃者はPII、個人の好み、認証データを含む数百万件の記録にアクセスすることができました。
無効化されたセキュリティ機能/デバッグ機能の有効化/不適切なパーミッションの脆弱性の解消
この脆弱性を排除するためには、おそらく2つのアプローチが必要です。問題のうち、デバッグが有効になっている部分を取り除くには、APIやアプリケーションを本番環境に移行する前に、デバッグが無効になっていることを確認するためのチェック機能を開発プロセスに追加するだけです。今回の例から、そのための適切なコマンドは次のようになります。
# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください。
DEBUG = False
現在、Django アプリケーションのデバッグ機能は、DEBUG フラグを False に設定すると無効になります。エラーに対応したエラーページは生成されません。もし敵がエラーページにアクセスできたとしても、有用なメタデータは含まれておらず、アプリケーションにリスクをもたらすことはありません。
無効化されたセキュリティ機能や不適切なパーミッションの脆弱性を排除することは、広範囲の特定の脆弱性を包含することができるため、少し困難です。これらを阻止する最善の方法は、ロックダウンされた資産を本番環境に迅速かつ容易に展開できるよう、標準的で反復可能なプロセスを開発することです。
その場合でも、オーケストレーション・ファイル、APIコンポーネント、Amazon S3バケットのパーミッションのようなクラウド・サービスが常にレビューされ、更新されるプロセスを作成する必要があります。このレビューでは、組織が常にAPIセキュリティを改善していることを確認するために、環境全体のセキュリティ設定の全体的な有効性を長期的に評価する必要があります。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
マティアス・マドゥ博士
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
セキュアコーディングに関する最新の知見をブログでご紹介しています。
当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。
開発者主導のセキュリティに関する最新の研究成果を入手する
ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。
Coders Conquer Security OWASP Top 10 API Series - Disabled Security Features/Debug Features Enabled/Improper Permissions
このリストのほとんどの脆弱性は、APIにかなり特化したものですが、セキュリティ機能の無効化／デバッグ機能の有効化／不適切なパーミッションの問題は、どこでも起こりうる問題です。APIではやや多いと思われますが、攻撃者は、パッチが適用されていない欠陥や保護されていないファイルやディレクトリをネットワーク上のどこかで見つけようとすることがよくあります。デバッグが有効になっていたり、セキュリティ機能が無効になっていたりするAPIに出くわすと、彼らの悪事が少しだけ楽になります。さらに悪いことに、セキュリティの設定ミスを検出して悪用するための自動化されたツールが用意されているため、あなたの環境にそれらがあれば、悪用される可能性が高く、それがこの脆弱性がOWASPの危険なAPI欠陥リストに入った理由です。
お楽しみの前に、このデバッグの課題を解決できるかどうか見てみましょう。
セキュリティ機能の無効化/デバッグ機能の有効化/不適切なパーミッションの欠陥は、どのようにしてAPIに忍び込むのでしょうか？
この多次元的なAPIの欠陥がどのようにしてネットワークに追加されていくのかを知るためには、その構成要素に分解する必要があります。まず、デバッグ機能の有効化の問題から始めましょう。デバッグは、アプリケーションが正しく動作しなかったり、エラーが発生したりする原因を開発者が把握するのに役立つ便利なツールです。デバッグ機能を有効にすると、エラーや例外発生時に詳細なエラーページが生成されるため、開発者は何が悪かったのかを確認し、問題を修正することができます。アプリケーションがまだ開発中の場合は、この機能を有効にしても問題ありません。
しかし、ほとんどのフレームワークでは、本番環境でのデバッグモードの実行に関する警告が表示されるのには理由があり、おそらくデバッグを有効にするコードの中に表示されています。例えば、以下のようなものです。
# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください
DEBUG = True
この例では、デバッグを有効にしています。Django アプリケーションは、例外が発生すると詳細なエラーページを生成します。これが本番環境で行われた場合、敵対者はこのエラーページにアクセスすることができ、その中には環境に関するメタデータ情報が含まれています。ほとんどのフレームワークでは、デフォルトでデバッグ機能がオフになっていますが、長い開発期間中に有効になっていると、元に戻すのを忘れてしまいがちです。その後、アプリケーションが本番環境に移行すると、アプリケーション、あるいはサーバやネットワーク全体を危険にさらす方法について、攻撃者に多くの情報を提供してしまいます。
デバッグモードを有効にすることは、ほとんどが単独の問題ですが、不適切なパーミッションと無効なセキュリティ機能の脆弱性は、しばしば連動します。例えば、OWASP が提供している実際のシナリオでは、攻撃者が検索エンジンを使用して、誤ってインターネットに接続されているデータベースを見つけました。人気のあるデータベース管理システムは、デフォルトの設定を使用していたため、認証が無効になっていました。このように、不適切なパーミッションと無効化されたセキュリティ機能の脆弱性を組み合わせることで、攻撃者はPII、個人の好み、認証データを含む数百万件の記録にアクセスすることができました。
無効化されたセキュリティ機能/デバッグ機能の有効化/不適切なパーミッションの脆弱性の解消
この脆弱性を排除するためには、おそらく2つのアプローチが必要です。問題のうち、デバッグが有効になっている部分を取り除くには、APIやアプリケーションを本番環境に移行する前に、デバッグが無効になっていることを確認するためのチェック機能を開発プロセスに追加するだけです。今回の例から、そのための適切なコマンドは次のようになります。
# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください。
DEBUG = False
現在、Django アプリケーションのデバッグ機能は、DEBUG フラグを False に設定すると無効になります。エラーに対応したエラーページは生成されません。もし敵がエラーページにアクセスできたとしても、有用なメタデータは含まれておらず、アプリケーションにリスクをもたらすことはありません。
無効化されたセキュリティ機能や不適切なパーミッションの脆弱性を排除することは、広範囲の特定の脆弱性を包含することができるため、少し困難です。これらを阻止する最善の方法は、ロックダウンされた資産を本番環境に迅速かつ容易に展開できるよう、標準的で反復可能なプロセスを開発することです。
その場合でも、オーケストレーション・ファイル、APIコンポーネント、Amazon S3バケットのパーミッションのようなクラウド・サービスが常にレビューされ、更新されるプロセスを作成する必要があります。このレビューでは、組織が常にAPIセキュリティを改善していることを確認するために、環境全体のセキュリティ設定の全体的な有効性を長期的に評価する必要があります。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
