OWASP Top 10とはWebアプリケーションのセキュリティのための啓発文書です。このTop10とは別にAPIに関するTop10もOWASPからリリースされています。
ココはOWASP Top 10を勉強した際の内容を記載します。
参考文献
Top10の詳細
A01:2021-Broken Access Control(アクセス制御の不備)
説明
アクセス制御とは、ユーザーが意図された権限を超えて行動できないようにポリシーを適用することをいう。障害はすべてのデータの不正な情報開示、変更、破壊、またはユーザーの制限を超えたビジネス機能の実行につながります。
一般的な例
詳細
- 誰でもアクセスできてしまう。
- 個人ごとにアクセスできる情報は違うはず
- アクセス制御チェックをバイパスできてしまう。
- URL、内部アプリケーションの状態、または HTML ページを変更する
- API リクエストを変更する攻撃ツールを使用する
- 他の人のアカウントの表示または編集を許可する
- 一意の識別子 (安全でない直接オブジェクト参照) を提供してしまう
- データを変更するAPI（POST、PUT、DELETE等）に対するアクセス制御の欠如
- 特権の昇格
- ログインせずにユーザーとして行動できてしまう
- ユーザーとしてログインしているときに管理者として行動できてしまう
- メタデータの操作により想定外のアクセスコントロールになる
- 未承認または信頼できないオリジンからのAPIアクセスが許可されてしまう
- CORS の構成ミスにより、未承認または信頼できないオリジンからのAPIアクセスが許可されます。
- 設計ミス
- 非認証ユーザーとして認証済みページを参照できてしまう
- 標準ユーザーとして特権ページを強制的に参照できてしまう
予防方法
詳細
- アクセス制御は、攻撃者がアクセス制御チェックやメタデータを変更できない、信頼できるサーバー側コードまたはサーバーレスAPIでのみ有効にする。
- 公開リソースへのアクセスを除いて、アクセスを原則として拒否する。
- アクセス制御メカニズムを一度実装すると、Cross-OriginResourceSharing(CORS)の使用を最小限に抑えるなど、アプリケーション全体で再利用する。
- モデルのアクセス制御では、ユーザーがレコードを作成、読み取り、更新、削除できることを認めるのではなく、レコードの所有権を強制する。
- 独自のアプリケーションビジネス制限要件は、ドメインモデルによって強制する。
- Webサーバーのディレクトリ一覧を無効にし、ファイルのメタデータ(.gitなど)とバックアップファイルがWebルート内に存在しないようにします。
- アクセス制御の失敗をログに記録し、必要に応じて管理者に警告する(失敗の繰り返しなど)。
- APIとコントローラーのアクセスをレート制限して、自動化された攻撃ツールによる被害を最小限に抑えます。
- ステートフルセッションIDは、ログアウト後にサーバー上で無効化する必要があります。ステートレスJWTトークンは、攻撃者が侵入する機会を最小限に抑えるために、有効期間を短くする必要があります。存続期間の長いJWTの場合は、OAuth標準に従ってアクセスを取り消すことを強くお勧めします。
A02:2021-Cryptographic Failures(暗号化の失敗)
説明
送信あるいは保存するデータが保護を必要とするか見極める。
例えば、パスワード、クレジットカード番号、健康記録、個人データやビジネス上の機密は特別な保護が必要になる。
また以下のような場合、データに対して特に注意が必要です
- EUの一般データ保護規則(GDPR)のようなプライバシー関連の法律が適用される場合
- PCIデータセキュリティスタンダード(PCI DSS)など金融の情報保護の要求があるような規定がある場合
一般的な例
詳細
- どんなデータであれ平文で送信していないか。
- 古いまたは脆弱な暗号アルゴリズムやプロトコルを初期設定のまま、または古いコードで使っていないか。
- 初期値のままの暗号鍵の使用、弱い暗号鍵を生成または再利用、適切な暗号鍵管理または鍵のローテーションをしていない。暗号鍵がソースコードリポジトリに含まれていないか。
- HTTPヘッダー（ブラウザ）のセキュリティに関するディレクティブやヘッダーが欠落しているなど、暗号化が強制されていない箇所はないか。
- 受け取ったサーバー証明書とその信頼チェーンが適切に検証されているか。
- 初期化ベクトルが無視されたり、再利用されたりしていないか。また、暗号利用モードにとって十分にセキュアではない状態で生成されていないか。 ECBといった安全でないモードが使用されていないか。 認証付き暗号がより適切な場合において、認証付き暗号でない暗号が使用されていないか。
- 鍵導出関数を使うことなしにパスワードを暗号鍵として使用していないか。
- 暗号学的要件を満たすように設計されていない目的でランダム性が使用されていないか。 適切な関数が選ばれている場合でも、関数は開発者による初期化が必要か。 必要でない場合、開発者が十分なエントロピーや予測不可能性を欠いたシードを用いて組み込みの強力な初期化機能を上書きしていないか。
- MD5やSHA1といった非推奨のハッシュ関数が使用されていないか。また暗号学的ハッシュ関数が必要とされる場合において、暗号学的でないハッシュ関数が使用されていないか。
- PKCS#1 v1.5といった非推奨の暗号学的パディング方式が使用されていないか。
- 暗号化時のエラーメッセージやサイドチャネルの情報が、パディングオラクル攻撃のような種類の攻撃に利用可能ではないか。
予防方法
詳細
最低限実施すべきことを以下に挙る。
- アプリケーションごとに処理するデータ、保存するデータ、送信するデータを分類する。
- そして、どのデータがプライバシー関連の法律・規則の要件に該当するか、またどのデータがビジネス上必要なデータか判定する。
- 必要のない機微な情報を保存しない。
- できる限りすぐにそのような機微な情報を破棄するか、PCI DSSに準拠したトークナイゼーションまたはトランケーションを行う。
- データが残っていなければ盗まれない。
- 保存時にすべての機微な情報を暗号化しているか確認する。
- 最新の暗号強度の高い標準アルゴリズム、プロトコル、暗号鍵を実装しているか確認する。
- 前方秘匿性(FS)を有効にしたTLS、サーバーサイドによる暗号スイートの優先度決定、セキュアパラメータなどのセキュアなプロトコルで、通信経路上のすべてのデータを暗号化する。
- HTTP Strict Transport Security (HSTS)のようなディレクティブで暗号化を強制する。
- 機微な情報を含むレスポンスのキャッシングを無効にする。
- データ分類に応じて必要なセキュリティ制御を適用する。
- FTPやSMTPといったレガシーなプロトコルを機密データの伝送に使用しない。
- パスワードを保存する際、Argon2、scrypt、bcrypt、PBKDF2のようなワークファクタ(遅延ファクタ)のある、強くかつ適応可能なレベルのソルト付きハッシュ関数を用いる。
- 初期化ベクトルは利用モードに応じて適切なものを選択しなければならない。
- これは多くのモードにおいてCSPRNG(暗号論的擬似乱数生成器)を使用することを意味する。
- nonceを必要とするモードの場合は、初期化ベクトル(IV)はCSPRNGを必要としない。
- すべての場合において、IVは単一の固定の鍵に対し二度使ってはならない。
- 単なる暗号ではなく、認証付き暗号を常に使用する。
- 鍵は暗号学的にランダムに生成し、またバイト配列としてメモリーに保存する。
- もしパスワードを使用する場合は、適切な鍵導出関数を用いて鍵へと変換されなければならない。
- 暗号学的乱数が適切な場所で使用されていること、またそれらが予測可能な方法や低いエントロピーによって初期化されていないことを確認する。
- 多くのモダンなAPIでは、セキュリティを確保するために開発者がCSPRNGを初期化する必要はない。
- MD5やSHA1、PKCS#1 v1.5といった非推奨の暗号学的関数やパディング方式の使用を避ける。
- 設定とその設定値がそれぞれ独立して効果があるか検証する。
A03:2021-Injection(インジェクション)
説明
一般的なインジェクションとしては、SQL、NoSQL、OS コマンド、オブジェクト・リレーショナル・マッピング（ORM）、LDAP、およびEL式（Expression Language）またはOGNL式（Object Graph Navigation Library）のインジェクションがあります。 コンセプトはすべてのインタープリタで同じです。ソースコードをレビューすれば、インジェクションに対してアプリケーションが脆弱であるか最も効果的に検出できます。すべてのパラメータ、ヘッダー、URL、Cookie、JSON、SOAP、およびXMLデータ入力の完全な自動テストが推奨されます。 また、組織は静的 (SAST)、動的 (DAST)、そしてインタラクティブ (IAST) アプリケーションセキュリティテストツールをCI/CDパイプラインに導入できます。 これにより、新たに作られてしまったインジェクション欠陥を稼働環境に展開する前に検出できます。
一般的な例
詳細
次のような状況では、アプリケーションはこの攻撃に対して脆弱です:
- ユーザが提供したデータが、アプリケーションによって検証、フィルタリング、またはサニタイズされない。
- コンテキストに応じたエスケープが行われず、動的クエリまたはパラメータ化されていない呼出しがインタープリタに直接使用される。
- オブジェクト・リレーショナル・マッピング（ORM）の検索パラメータに悪意を持ったデータが使用され、重要なレコードを追加で抽出してしまう。
- 悪意を持ったデータを直接または連結して使う。動的クエリ、コマンドまたはストアド・プロシージャにおいてSQLやコマンドがそのような構造と悪意を持ったデータを含む。
予防方法
詳細
インジェクションを防止するためにはコマンドとクエリからデータを常に分けておくことが必要
推奨される選択肢は安全なAPIを使用すること。
- インタープリタの使用を完全に避ける、パラメータ化されたインターフェースを利用する、または、オブジェクト・リレーショナル・マッピング・ツール（ORM）を使用するように移行すること。
- 注意: パラメータ化されていたとしても、ストアドプロシージャでは、PL/SQLまたはT-SQLによってクエリとデータを連結したり、EXECUTE IMMEDIATEやexec()を利用して悪意のあるデータを実行することによって、SQLインジェクションを発生させることができる。
ポジティブな、言い換えると「ホワイトリスト」によるサーバーサイドの入力検証を用いる。
- 特殊文字を必要とする多くのアプリケーション、たとえばモバイルアプリケーション用のテキスト領域やAPIなどにおいては完全な防御方法とはならない。
上記の対応が困難な動的クエリでは、そのインタープリタ固有のエスケープ構文を使用して特殊文字をエスケープする。
- 注意: テーブル名やカラム名などのSQLストラクチャに対してはエスケープができない。そのため、ユーザ指定のストラクチャ名は危険である。これはレポート作成ソフトウェアに存在する一般的な問題である。
クエリ内でLIMIT句やその他のSQL制御を使用することで、SQLインジェクション攻撃が発生した場合のレコードの大量漏洩を防ぐ。
A04:2021-Insecure Design(安全が確認されない不安な設計)
説明
安全が確認されない不安な設計とは、様々な脆弱性を表す広範なカテゴリーであり、「欠落した、あるいは不十分な制御設計」とも表される。 安全でない設計と安全でない実装は異なる。設計上の欠陥と実装上の欠陥を区別するのには理由は、根本的な原因と改善方法が異なるから。 安全な設計であっても、実装上の欠陥があると、それが悪用される可能性のある脆弱性につながる。 安全でない設計は、完璧な実装によって修正することができない。というのも、定義上、特定の攻撃を防御するために必要なセキュリティ制御が作成されたことはない。 安全でない設計の要因の一つとして、開発するソフトウェアやシステムに内在するビジネスリスクのプロファイリングが行われていないために、どのレベルのセキュリティ設計が必要なのかを判断できないことが挙げられる。
一般的な例
詳細
予防方法
詳細
- セキュリティおよびプライバシー関連の管理策の評価および設計を支援するために、アプリケーションセキュリティの専門家とともにセキュアな開発ライフサイクルを確立し使用する
- セキュアなデザインパターンまたは、信頼性が高く安全性も検証されているコンポーネントライブラリを構築し使用する
- 重要な認証、アクセスコントロール、ビジネスロジック、および暗号鍵の管理フローに脅威モデルを使用する
- ユーザーストーリーにセキュリティ言語とコントロールを組み込む
- (フロントエンドからバックエンドまで)アプリケーションの各層に妥当性チェックを統合する
- ユニットテストおよび統合テストを実施し、すべての重要なフローが脅威モデルに対して耐性があることを検証する。アプリケーションの各階層のユースケースとミスユースケースをまとめる。
- リスク管理における保護の必要性に応じて、システム層とネットワーク層の階層を分ける
- すべての階層でテナントを分離した堅牢な設計を行う
- ユーザーやサービスによる過剰なリソース消費を制限する
A05:2021-Security Misconfiguration(セキュリティの設定ミス)
説明
アプリケーションのセキュリティを設定するプロセスを協調して繰り返すことができなければ、システムはより高いリスクにさらされる。
一般的な例
詳細
アプリケーションが下記のようなら、恐らく脆弱です:
- アプリケーションスタックのいずれかの部分におけるセキュリティ堅牢化の不足、あるいはクラウドサービスでパーミッションが不適切に設定されている
- 必要のない機能が有効、あるいはインストールされている(例えば、必要のないポートやサービス、ページ、アカウント、特権)
- デフォルトのアカウントとパスワードが有効になったまま変更されていない
- エラー処理がユーザに対して、スタックトレースやその他余計な情報を含むエラーメッセージを見せる
- アップグレードしたシステムでは、最新のセキュリティ機能が無効になっているか正しく設定されていない
- アプリケーションサーバやアプリケーションフレームワーク(例えば、Struts、Spring、 ASP.NET)、ライブラリ、データベース等のセキュリティの設定が、安全な値に設定されていない
- サーバがセキュリテイヘッダーやディレクティブを送らなかったり、安全な値に設定されていなかったりする
- ソフトウェアが古いか脆弱である。(# A06:2021 – 脆弱で古くなったコンポーネント を参照)
予防方法
詳細
安全にインストールするプロセスにおいて、以下のことを実施すべきです:
- 繰り返し堅牢化するプロセスは、素早くかつ容易に他の環境に展開され、正しくロックダウンする。
- 開発やQA、本番環境は完全に同じように設定し、それぞれの環境で別々の認証情報を使用する。
- このプロセスを自動化し、新しい安全な環境をセットアップする際には、手間を最小限にする。
- プラットフォームは最小限のものとし、必要のない機能やコンポーネント、ドキュメント、サンプルを除く。
- 使用しない機能とフレームワークは、削除もしくはインストールしないこと。
- レビューを実施して、セキュリティ関連の記録と更新の全てに加え、パッチを管理するプロセスの一環としてパッチの設定を適切に更新すること(# A06:2021 – 脆弱で古くなったコンポーネント を参照)。
- セグメント化したアプリケーションアーキテクチャは、セグメンテーションやコンテナリゼーション、クラウドのセキュリティグループ(ACL)をともなったコンポーネントやテナント間に、効果的で安全な仕切りをもたらす。
- セキュリティディレクティブをクライアントへ送ること。
- プロセスを自動化して設定の有効性を検証し、環境すべてに適用すること。
A06:2021-Vulnerable and Outdated Components(脆弱で古くなったコンポーネント)
一般的な例
詳細
以下に該当する場合、脆弱と言えます。
- 使用しているすべてのコンポーネントのバージョンを知らない場合（クライアントサイド・サーバサイドの両方について）。 これには直接使用するコンポーネントだけでなく、ネストされた依存関係も含む。
- ソフトウェアが脆弱な場合やサポートがない場合、また使用期限が切れている場合。 これには、OSやWebサーバ、アプリケーションサーバ、データベース管理システム（DBMS）、アプリケーション、API、すべてのコンポーネント、ランタイム環境とライブラリを含む。
- 脆弱性スキャンを定期的にしていない場合や、使用しているコンポーネントに関するセキュリティ情報を購読していない場合。
- 基盤プラットフォームやフレームワークおよび依存関係をリスクに基づきタイムリーに修正またはアップグレードしない場合。 パッチ適用が変更管理の下、月次や四半期のタスクとされている環境でよく起こる。 これにより、当該組織は、解決済みの脆弱性について、何日も、場合によっては何ヶ月も不必要な危険にさらされることになる。
- ソフトウェア開発者が、更新やアップグレードまたはパッチの互換性をテストしない場合。
- コンポーネントの設定をセキュアにしていない場合。（A05-2021: セキュリティの設定ミス 参照）
予防方法
詳細
以下に示すパッチ管理プロセスが必要です。
- 未使用の依存関係、不要な機能、コンポーネント、ファイルや文書を取り除く。
- Versions Maven Plugin, OWASP Dependency Check, Retire.jsなどのツールを使用して、クライアントおよびサーバの両方のコンポーネント（フレームワークやライブラリなど）とその依存関係の棚卸しを継続的に行う。
- 安全なリンクを介し、公式ソースからのみコンポーネントを取得する。
- 変更された悪意あるコンポーネントを取得する可能性を減らすため、署名付きのパッケージを選ぶようにする。 (A08-2021: ソフトウェアとデータの整合性の不具合 参照)
- メンテナンスされていない、もしくはセキュリティパッチが作られていない古いバージョンのライブラリとコンポーネントを監視する。
- パッチ適用が不可能な場合は、発見された問題を監視、検知または保護するために、仮想パッチの適用を検討する。
いかなる組織も、アプリケーションまたはポートフォリオの存続期間は、モニタリングとトリアージを行い更新または設定変更を行う継続的な計画があることを確認する必要があります。
A07:2021-Identification and Authentication Failures(識別と認証の失敗)
説明
ユーザーのアイデンティ確認、認証そしてセッション管理は、認証関連の攻撃対策として極めて重要です。
一般的な例
詳細
もしアプリケーションに次に記載するような問題があれば、認証に問題があると言えます。
- パスワードリスト攻撃（クレデンシャル・スタッフィング攻撃）のような自動化された攻撃が出来てしまう。パスワードリスト攻撃とは、攻撃者が正当なユーザー名とパスワードの組み合わせを入手して行う攻撃手法のことです。
- ブルートフォース攻撃（総当たり攻撃）などの自動化された攻撃が出来てしまう。
- デフォルトのパスワード、弱いパスワード、良く使われるパスワードが利用できてしまう。たとえば「Password1」や「admin/admin」などです。
- クレデンシャルの復旧やパスワードを忘れた場合のプロセスが弱い、あるいは効果がない。
- たとえば「秘密の質問」のようなやり方は安全とは言えません。
- パスワードをデータストアに保存する際に、プレーンテキストのままで保存している、または暗号化して保存している。
- あるいはハッシュ化して保存していたとしても脆弱なハッシュ関数を利用している。（A02:2021-暗号化の失敗を参照）
- 多要素認証を採用していない。あるいは間違った使い方をしている。
- セッション識別子がURLの一部として露出してしまっている。
- ログイン後にセッション識別子を使いまわしている。
- セッションIDを正しく無効化していない。
予防方法
詳細
- 多要素認証を可能な限り実装する。これにより、パスワードリスト攻撃、ブルートフォース攻撃、盗用したクレデンシャルの再利用など多くの自動化された攻撃を防ぐことができる。
- デフォルトのクレデンシャルのままプログラム（サービス）をデプロイしない。
- 特に管理者ユーザーのパスワードをデフォルト設定のままデプロイするのは言語道断です。
- 弱いパスワードを設定していないかチェックする機能を実装する。
- たとえばパスワードの新規設定や更新時には、「弱いパスワード トップ10,000」などのリストを使って検証する。
- パスワードの「長さ」や「複雑さ」そして「定期的な変更」などのパスワードポリシーについては、米国国立標準技術研究所 (NIST) ガイドライン（800-63b セクション5.1.1:記憶シークレット）や、近代的で根拠に基づくポリシーに沿うようにする。
- 新規登録の場合、クレデンシャルリカバリーの場合、またAPI経由の場合など、どのような場合であってもアカウント列挙攻撃に対して強化されていることを確認する。
- 認証の際にはどのような結果であれ（成功でも失敗でも）同じメッセージを使うようにする。
- ログイン試行回数に制限を設けるか、ログインに繰り返し失敗するようなら徐々に処理を遅延させる。
- その際、サービス拒否の機会を作らないよう注意する。ログインの失敗はすべてログに記録する。
- そしてパスワードリスト攻撃やブルートフォース攻撃などの攻撃を検知した際には管理者に通知する。
- セッション管理はサーバ側で行い、安全でプログラム言語などに内蔵されているものを使います。
- ログイン毎にエントロピーの高いランダムなセッションIDを発行するセッション管理機構を利用する。
- セッション識別子はURLに含まれるべきではなく、安全に保管されなければなりません。また、セッション識別子はログアウトした際、一定期間アクセスが無い場合、タイムアウト時間を経過した場合には無効にしなければなりません。
A08:2021-Software and Data Integrity Failures(ソフトウェアとデータの整合性の不具合)
概要
説明
ソフトウェアとデータの整合性の不具合は、コードやインフラストラクチャが整合性違反から保護されていないことに関連しています。
一般的な例
詳細
例として、
- アプリケーションが信頼されていないソースに由来するプラグインやライブラリ、モジュール、コンテンツデリバリーネットワーク (CDNs) に依存している場合が挙げられる。
- 安全でないCI/CDパイプラインも、権限のないアクセスや悪意のあるコード、システムののっとりの可能性を高める。
- 今では多くのアプリケーションが自動更新の機能を備えていますが、そこで、十分な整合性の検証を行うことなくアップデートがダウンロードされ、信頼済みアプリケーションに対して適用される。
- 攻撃者は自前のアップデートをアップロードし、全てのインストール対象に対して配信を行う可能性があります。
- オブジェクトやデータが攻撃者が目で見て修正することが可能な構造としてエンコードまたはシリアライズされるような場合は、安全でないデシリアライゼーションに対して脆弱であると言える。
予防方法
詳細
- 署名あるいは類似のメカニズムを用いて、ソフトウェアやデータが意図されたソースから取得されたものであることを検証する。
- npmやMavenなど、ライブラリや依存関係が信頼されたリポジトリを使用していることを確認する。
- コンポーネントが既知の脆弱性を含まないことを検証するために、OWASP Dependency CheckやOWASP CycloneDXといったソフトウェアサプライチェーンセキュリティツールが使用されていることを確認する。
- 悪意のあるコードや設定がソフトウェアパイプラインに組み込まれる機会を最小化するために、コードや設定の変更に対するレビュープロセスが確立されていることを確認する。
- CI/CDパイプラインが適切に分離され、設定され、アクセス制御が行われていること、また、ビルドやデプロイのプロセスに至るコードフローの整合性が確保されていることを確認する。
- シリアライズされたデータの改ざんや再生成を検出する何らかの整合性確認やデジタル署名を行うことなしに、信頼されていないクライアントに対して未署名もしくは暗号化されていないシリアライズされたデータを送信しない。
A09:2021-Security Logging and Monitoring Failures(セキュリティログとモニタリングの失敗)
説明
アクティブな違反の検出、エスカレーション、および対応を支援するものです。 ロギングとモニタリングがなければ、侵害を検知することはできない。
一般的な例
詳細
ロギングや検知、モニタリング、適時の対応が十分に行われないという状況は、いつでも発生します:
- ログイン、失敗したログイン、重要なトランザクションなどの監査可能なイベントがログに記録されていない。
- 警告とエラーが発生してもログメッセージが生成されない、または不十分、不明確なメッセージが生成されている。
- アプリケーションとAPIのログが、疑わしいアクティビティをモニタリングしていない。
- ログがローカルにのみ格納されている。
- アラートの適切なしきい値とレスポンスのエスカレーションプロセスが整えられていない、または有効ではない。
- ペネトレーションテストやDAST(dynamic application security testing)ツール（OWASP ZAPなど）によるスキャンがアラートをあげない。
- アプリケーションがリアルタイム、準リアルタイムにアクティブな攻撃を検知、エスカレート、またはアラートすることができない。
予防方法
詳細
アプリケーションによって保存または処理されるデータのリスクに応じて対応する：
- ログイン、アクセス制御の失敗、サーバサイドの入力検証の失敗を全てログとして記録するようにする。
- ログは、不審なアカウントや悪意のあるアカウントを特定するために十分なユーザコンテキストを持ち、 後日、フォレンジック分析を行うのに十分な期間分保持するようにする。
- 統合ログ管理ソリューションで簡単に使用できる形式でログが生成されていることを確認する。
- 価値の高いトランザクションにおいて、監査証跡が取得されていること。
- その際、追記型データベースのテーブルなどのような、完全性を保つコントロールを用いて、改ざんや削除を防止する。
- DevSecOps チームが疑わしい活動をタイムリーに検知して対応できるように、効果的なモニタリングとアラートを確立する。
- NIST(National Institute of Standards and Technology) 800-61 rev 2（またはそれ以降）のような、インシデント対応および復旧計画を策定または採用する。
OWASP AppSensor、OWASP ModSecurity Core Rule Setを使用したModSecurityなどのWebアプリケーションファイアウォール、 カスタムダッシュボードとアラートを使用したログ相関分析ソフトウェア（Elasticsearch, Logstash, Kibana (ELK) ）など、商用およびオープンソースのアプリケーション保護フレームワークがある。
A10:2021-Server-Side Request Forgery(サーバーサイドリクエストフォージェリ(SSRF))
説明
SSRFの欠陥は、Webアプリケーション上からリモートのリソースを取得する際に、ユーザーから提供されたURLを検証せずに使用することで発生します。 ファイアウォールやVPNあるいはその他の種類のネットワークアクセス制御リスト(ACL)によってアプリケーションが保護されている場合であっても、SSRFによりアプリケーションに対して意図しない宛先へ細工されたリクエストを強制的に発行させることができる。
モダンなアプリケーションではエンドユーザーに便利な機能を提供するようになり、アプリケーション側でURLを取得することは珍しい状況ではなくなった。 そのためSSRFの発生が増加している。 またSSRFの深刻度も、クラウドサービスやアーキテクチャの複雑性を背景として、段々と大きくなりつつある。
一般的な例
詳細
予防方法
詳細
開発者は以下の多層防御の制御の一部ないし全てを実装することにより、SSRFを防ぐことができる。
ネットワーク層から
- SSRFの影響を減らすために、リモートのリソースへアクセスする機能を分離されたネットワークに切り出す。
- 必須のイントラネット通信を除き全ての通信をブロックするよう、「デフォルト拒否」のファイアウォールポリシーまたはネットワークアクセス制御を強制する。
- ヒント:
- ~ アプリケーションに応じて、ファイアウォールルールの所有権とライフサイクルを明確化する。
- ~ ファイアウォールにおいて許可されたネットワークフロー、そしてブロックされたネットワークフローを全てログとして記録します (A09:2021-セキュリティログとモニタリングの失敗を参照)。
アプリケーション層から:
- クライアントが提供した全ての入力データをサニタイズし、検証する。
- 明確な許可リスト用いてURLスキーム、ポート、宛先を強制する。
- 生のレスポンスをクライアントに送信しないようにする。
- HTTPのリダイレクトを無効化する。
DNSリバインディングや"time of check, time of use" (TOCTOU) 競合状態といった攻撃を防ぐために、URLの整合性に注意する。
拒否リストや正規表現を用いてのSSRF対策を実装する。攻撃者は拒否リストを回避するためのペイロードのリスト、ツール、そして技術を備えている。
検討すべき追加の対策:
- Don't deploy other security relevant services on front systems (e.g. OpenID). Control local traffic on these systems (e.g. localhost)
- For frontends with dedicated and manageable user groups use network encryption (e.g. VPNs) on independant systems to consider very high protection needs
