サーバーサイドリクエストフォージェリ (Server-Side Request Forgery/SSRF)とは何か | OWASP 2021

2021年に改訂されたOWASP Top 10:2021の中で、10位の項目として挙げられたのが、「Server-Side Request Forgery(SSRF)」です。
日本語では、「サーバーサイドリクエストフォージェリ 」と呼ばれます。

 

前回の改定時の2017年度版では、TOP10含まれていませんでしたが、問題の発生率は比較的低いものの、問題が起きた場合の影響が大きいことから、2021年度版で10位となったと考えられます。

 

サーバーサイドリクエストフォージェリ(SSRF)とは

企業のアプリケーションは一般的に複数台のサーバーを使用しています。
SSRFの欠陥がウェブアプリケーションに存在する場合、攻撃者はターゲットのサーバーになりすましながら、別のサーバーにリクエストが送信できるようになります。

外部公開サーバーに対し、想定されていない操作を行うことで、内部のサーバー通しの通信をとして不正な処理を実行する攻撃が、サーバーサイドリクエストフォージェリと呼ばれます。

CSRF(クロスサイト・リクエストフォージェリ)との違い

CSRFは攻撃者が被害者となるユーザーに意図しないリクエストを送信される一方、
SSRFでは、ユーザではなくターゲットとなるサーバに意図しないリクエストを送信させ、外部に公開していないサーバに処理を実行させてしまうという点です。

 

対策

SSRFを防ぐには、ネットワーク層においてはアクセス許可リストの設定が必要です。

基本的にはデフォルト拒否のファイアウォールポリシー/ネットワークアクセス性g長を行い、適切な外部リソースが特定の場所からのアクセスが分かっている場合は、そのIPアドレスまたはホスト名のみを許可します。

アプリケーション層については、入力データのサニタイズやHTTPリダイレクトの無効か、生のレスポンスをクライアントに送信しないなどの対策が有効です。

 

 

セキュリティログとモニタリングの失敗(Security Logging and Monitoring Failures)とは何か | OWASP 2021

2021年に改訂されたOWASP Top 10:2021の、9位は「Security Logging and Monitoring Failures」です。
日本語では、「セキュリティログとモニタリングの失敗」「セキュリティログと監視の失敗」となどと訳されています。

前回の改定時の2017年度版では、10位の「不十分なロギングとモニタリング(Insufficient Logging & Monitoring)」としてランクインしており、2021年版ではわずかに順位をあげています。

 

セキュリティログとモニタリングの失敗とは

アプリケーションへの攻撃はゼロにすることができないため、攻撃があった際にそれを検知してさらなる攻撃を防ぐ対策を行ったり、攻撃者に関して調査をする必要があります。そのためにセキュリティログとモニタリングが重要です。

ロギングとモニタリングに不備があると、説明責任やインシデントアラート、フォレンジックなどに影響がでます。

secure-ver01.hatenablog.com

攻撃者が攻撃する際の各ステップにおいて、ロギングとモニタリングは、攻撃者を足止めする機会を与えてくれます。適切なログは以下のような情報を含みます。

  • 特定のファイルを閲覧したりダウンロードしたりしたのは誰か?
  • 不正な認証の試みが行われたことはあるか?
  • 最近ログインしたのは誰か?
  • 予期しない時間帯、予期しない場所から認証イベントが発生していないか?

上記の情報をはじめ必要な情報が含まれていなかったり、怪しいアクテビティについてアラートがモニタリングされていない・アラートが発生しなかったりすることを、「セキュリティログとモニタリングの失敗」と呼びます。

 

対策

セキュリティ被害の怖さとして、数週間、数カ月、あるいは数年間も発見されないことがよくあることが挙げられます。

発見されない期間が長ければ長いほど、攻撃者はより多くの手段を講じることができ、より多くの悪影響を及ぼす可能性があります。

ログ、監視、警告をて適切に行う設定にすることで、攻撃者がシステムに侵入したことを発見し、被害が拡大する前に阻止できる可能性が高まります。

ログに必要な情報の理解と、正しく記録されているかの確認が重要です。

 

ソフトウェアとデータの整合性の不具合(Software and Data Integrity Failures)とは何か | OWASP 2021

2021年に改訂されたOWASP Top 10:2021の、8位は「Software and Data Integrity Failures」です。
日本語では、「ソフトウェアとデータの整合性の不具合」「ソフトウェアとデータの整合性の失敗」と訳されています。

2021年度版より新設されたカテゴリーと言われていますが、2017年度版の同順位(8位)の「安全ではないデシリアライゼーション」と関連しています。

 

ソフトウェアとデータの整合性の不具合とは

近年では、多くのアプリケーションに自動更新機能があり、十分な検証がされないまま更新ファイルがダウンロードされることがあります。

ソフトウェアのビルドやテスト・デリバリー・デプロイメントを自動化し、継続的に行う開発手法である「CI/CD(継続的インテグレーション/継続的デリバリー)」やDevOpsなどの開発手法は、セキュリティの観点では安全でないものを自動的にソフトウェアに取り込む可能性があるなどの問題があります。

OWASP2021の6位である「脆弱で古くなったコンポーネント(Vulnerable and Outdated Components)」と似ていますが、8位の「ソフトウェアとデータの整合性の不具合」は、ベンダーから定期的よりメンテナンスがなされるという点に重点を置いています。

 

OWASP2017のTop10であった「デシリアライゼーション」は本項目について適切に対応を行わないと発生するという意味で、本項目の指摘事項に含まれます。

対策

ソフトウェアとデータの整合性の不具合を防ぐためには、ソフトウェア開発のライフサイクルにおける自動化されたプロセスに注目し、そのアプリケーションと開発プロセスが安全であることを確実にします。

また、そもそも使用を開始する際に、計画段階から意図してた(問題のない)ソースから取得される仕組みになっているのか、安全なライブラリを使用しているかのような検証を行います。

 

デシリアライズについては、信頼されていないクライアントに対して、未署名もしくは暗号化されていないシリアライズされたデータを送信をしないように設定することで対策をします。

識別と認証の失敗(Identification and Authentication Failures)とは何か | OWASP 2021

2021年に改訂されたOWASP Top 10:2021の、7位は「Identification and Authentication Failures」です。
日本語では、「識別と認証の失敗」「識別と認証の不備」と訳されています。

前回の改定時の2017年度版では、2位の「認証の不備」としてランクインしていましたが、2021年度版では順位を下げつつもTop10に含まれています。

 

識別と認証の失敗とは

Webアプリケーションはユーザーを識別し、適切に認証する必要があります。つまり、アクセスの際にユーザー自身が提示している通りの人物であることを確認必要があります。
デフォルトや弱いパスワードを利用していたり、暗号化がされていないなどが原因で、本人以外のユーザーがパスワードを簡単に入手出来てしまうという問題は、本項目にあたります。

 

例えば、パスワードを忘れたとき、「パスワードを忘れた」をクリックし、ユーザー本人であることを証明するために、事前に登録したSMSやメールアドレスで受け取った確認用コードを入力するというフローが広く使われています。この際に、確認用コードの入力手順を省略された場合や不正確に行われた場合、任意のIDすべてのパスワードが誰でも変更できることになります。これが「識別と認証の失敗」の一例です。

また、ソフトウェアが証明書を提供するホストと通信する際に、そのホストの証明書が実際にそのホストと関連付けられているかの確認を適切に行わないことも「識別と認証の失敗」の例として挙げられます。つまり、識別・認証の手順は存在するが、提示された情報が正しいものかの検証に不備があるケースです。

さらに、Webアプリが古いセッションを閉じない場合も例として挙げられます。セッションが無期限にアクティブであると、別のユーザーが利用しようとした際に、前のユーザーの認証情報で操作ができるという状況が発生してしまいます。

 

対策

ユーザー本人だけが適切にアクセスできる状態を保つために、パスワードの長さ・複雑さ・変更頻度についてポリシーを設定します。

可能な限り多要素認証を実装することも、自動化による攻撃への対策になります。

 

セッション管理についても、タイムアウト設定を正しく行うことや、ログインごとにランダムなセッションIDの発行を行うこと、そのセッションIDをURLに含まず、安全に保管することなども重要です。

 

脆弱で古くなったコンポーネント(Vulnerable and Outdated Components)とは何か | OWASP 2021

2021年に改訂されたOWASP Top 10:2021の、Top6は「Vulnerable and Outdated Components」です。
日本語では、「脆弱で古くなったコンポーネント」「脆弱で古いコンポーネント」と訳されています。

前回の改定時の2017年度版では、Top9でしたがメンテナンスがされていない古いコンポーネントを使用して作成されたアプリケーションなどが、更新されずに使用されているケースが増加していることなどの理由で、順位が上がったと考えられます。

 

脆弱で古くなったコンポーネントとは

Webアプリケーションの大半は、オープンソースやサードパーティのコンポーネントを使用して構築されています。そのため、Webアプリケーションを構築するためのコンポーネントが脆弱であれば、Webアプリケーションも脆弱であることになります。

使用しているコンポーネントのバージョンを把握していない場合、サポートされていない買ったり脆弱であったりする場合、攻撃の対象となり、データの流出や改ざんの可能性が高まります。

 

対策

使用しているコンポーネントが安全であることを把握するため、すべてのソフトウェア・コンポーネントとそのバージョンについて、常に完全で最新のリストを持っている必要があります。

そして、既知の脆弱性を調査したり、アプリケーションを積極的にテストすることで各コンポーネントが脆弱でないかを確認します。

また、古くなったソフトウェアを更新し、既知の脆弱性にパッチを適用する必要があります。

「脆弱で古くなったコンポーネント」の問題は、技術的な問題ではなく、むしろ組織の意思決定プロセスの問題であることが多いとされています。この解決策としては、上記の手順を適切に繰り返し行えるようなプロセスを確立することが大切です。

セキュリティの設定ミス(Security Misconfiguration)とは何か | OWASP 2021

2021年に改訂されたOWASP Top 10:2021の中で、5位の項目として「Security Misconfiguration」が挙げられています。
日本語では、「セキュリティの設定ミス」「セキュリティ上の構成ミス」「セキュリティの誤った設定」など呼ばれています。

前回の改定時の2017年度版では、6位でしたが、高度な設定が可能なソフトウェアの増加の結果、順位が上がったと考えられます。

 

セキュリティの設定ミスとは

各アプリケーションやソフトウェアには、様々な設定項目があります。セキュリティの設定ミスとは、その設定項目についてデフォルトから変更しないなど、安全でない状態であることを指します。

その他に、Webアプリケーションのセキュリティの設定ミスの例として、不要なサービスや機能を有効にする、クラウドサービスのアクセス許可を適切に設定しない、ソフトウェアの更新をしないなどが挙げられます。

身近な例では、使用しているスマートフォンのパスコードをオフの設定にし、紛失した際に誰でも使用できるといったケースも、セキュリティの設定ミスです。

 

対策

それぞれの組織や各アプリケーションによって、満たすべき要件やリスクの許容度が異なるため、一概にどのような設定にすべきかという答えはありません。関係するチームがセキュリティの設定ミスについて理解し、各設定についてリスクを考慮の上、意図的に決定していくことが大切です。

 

安全が確認されない不安な設計(Insecure Design)とは何か | OWASP 2021

2021年に改訂されたOWASP Top 10:2021の中で、4番目の脅威として挙げられたのが、「Insecure Design」です。
日本語では、「安全が確認されない不安な設計」「インセキュアデザイン」「安全でない設計」など呼ばれています。

前回の改定時の2017年度版では、TOP10には含まれておらず2021年から新たに指摘されたカテゴリーです。

安全が確認されない不安な設計とは

その他のコード面のカテゴリーとは異なり、「Insecure Design」はより全体的な構造に焦点が当てられています。様々なケースを含む幅広いカテゴリーです。

デザイン面の安全でない設計の例として、詳細なエラーメッセージが表示される仕組みなどがあります。
開発時には詳細なエラーメッセージはトラブルシューティングに役立ちますが、悪意のあるユーザーが攻撃に利用する可能背もあります。

また、パスワードがテキストで保存されているケースなども「安全性が確認されない不安な設計」にあたります。この種の脆弱性は、暗号化実装のミスではなく、パスワードを暗号化しないという意図的な設計上の決定が問題です。

 

対策

セキュリティは、プログラムの手法だけではなく、データをどのように扱うかの設計段階から重要です。安全な設計をするため、Webアプリケーション開発の早い段階で、セキュリティの専門家に相談し、安全な開発ライフサイクルを確立することが対策となります。

 

例:

  • 本番環境へリリースする際は、エラーメッセージの不要な情報・詳細な情報は取り除く
  • パスワードを忘れた際の「秘密の質問と答え」による回復フローを廃止し、MFAなどを使用したより安全な設計に置き換える