最新Webセキュリティ事情まとめ
OWASP Top 10:2021を噛み砕く
次世代システム研究室のY.Cです。Webセキュリティ上の脅威を10のカテゴリに分類し概要と対応方法をまとめたOWASP Top 10をご存知ですか？ 昨年更改され、最新版がOWASP Top 10:2021となりました。ウェブ開発者なら一読の価値ありですが、いかんせん英語が堅苦しくて読みづらいです。今回は、OWASP Top 10:2021の内容を翻訳し、表形式にして関連した内容をまとめることで、少しでも読みやすくなるよう整理してみました。
目次
方針
今回はひとまず以下の方針でまとめています。- 原文はhttps://owasp.org/Top10/ (2021年版)
- 主にDescriptionとHow To Preventを翻訳し、それぞれ表の観点、対応、という列に配置
- 関係がありそうな項目は表の同じ行に配置。観点と対応で必ずしも対応関係があるわけではないです
A01:2021 – アクセスコントロールの不備
| 観点 | 対応 |
|---|---|
| 最小特権の原則やデフォルト拒否の原則に違反している。 | 公開リソースを除き、デフォルトで拒否する。 |
| アクセスコントロールのチェックのバイパス。URL(パラメータを改ざんしたり強制ブラウジングしたり)や、アプリケーションの内部状態、HTML ページの編集や、API リクエストを編集する攻撃ツールの使用などによるもの。 | アクセスコントロールのメカニズムを一度実装しておき、それをアプリケーション全体で再利用する。最小化したCORSの使用など。 |
| 危険なオブジェクトの直接参照。ユニークな id を使うことで他人のアカウントの閲覧や編集ができてしまうなど。 | モデルのアクセスコントロールでは、レコードに対する所有権をユーザーに設定することで、任意のレコードに任意の操作(create, read, update, delete)ができないようにする。 |
| POST、PUT、DELETE といった API でアクセスコントロールがない。 | アプリケーションに固有なビジネス制限の要件は、ドメインモデルによって強制されるべき。 |
| 権限の昇格。ログインせずにユーザーとして振舞ったり、一般ユーザーなのに管理者としてログインするなど。 | アクセスコントロールの失敗を記録し、必要に応じて管理者に報告する。(例：何度も失敗した場合) |
| メタデータの操作。JSON Web Token (JWT) のアクセスコントロールトークンの再生成や改ざん、クッキーや隠しフィールド等による権限の昇格など。 | ステートフルなセッション識別子をログアウト後にサーバ側で無効化する。ステートレスなJWTトークンは攻撃の機会を最小化するために、有効期限を短くする。長期間有効なJWTについてはOAuth規格に沿ってアクセスを無効にすることが強く推奨される。 |
| CORS(同一元生成ポリシー)の設定ミスで未認可 or 不明なオリジンからの API アクセスを許可してしまう | 自動攻撃ツールによる被害を最小化するため、APIにrate limitを設ける。 |
| 強制ブラウジング。権限が必要なページを権限のないユーザーで閲覧したり、管理者用のページを一般ユーザーが閲覧したりしてしまう | webサーバのディレクトリリスティング機能を無効にし、ファイルのメタデータ（例：.git）やバックアップファイルがWebルート内に存在しないようにする。 |
A02:2021 – 暗号化の不備
| 観点 | 対応 |
|---|---|
| ・平文で転送しているデータがないか？ これは、HTTP、SMTP、FTPなどのプロトコルに加え、STARTTLSのようなTLSのアップグレードを使用していても懸念事項にあたる。外部のインターネットトラフィックは危険。ロードバランサ、webサーバ、バックエンドシステム間などのすべての内部トラフィックを検証すること。 ・暗号化が強制されているか? HTTPヘッダのセキュリティディレクティブやヘッダーが欠落していないか？ | ・forward secrecyの有効化、サーバーによる暗号スイートの優先順位決定、そしてセキュアな引数をもつTLSのような安全なプロトコルで、転送中の全てのデータを暗号化する。HSTSのようなディレクティブを使って暗号化を強制する。 ・機密データを送信するためにFTPやSMTPといったレガシーなプロトコルを使わない。 |
| ・古い、もしくは脆弱な暗号化アルゴリズムまたはプロトコルが、デフォルトでもしくは古いコードで使われていないか？ ・デフォルトの暗号化鍵が使われていないか？弱い暗号化鍵が生成されたり再利用されていないか、正しい鍵管理や鍵のローテションがあるか？暗号化鍵がソースコードリポジトリに入っていないか？ ・暗号的なエラーメッセージやサイドチャンネル情報が悪用可能か？例えばパディングオラクルアタックのような形で | ・最新で強力な標準アルゴリズム、プロトコル、鍵を確実に導入し、適切な鍵管理を行うこと。 |
| ・受信したサーバの証明書と信頼のチェーンが正しく検証されているか？ | |
| ・暗号のモードや操作で、初期化ベクトルが無視されたり、再利用されたり、十分安全ではない状態で生成されていないか？ECBといった安全でないモードが使われていないか？認証つき暗号を使うべき場面で使っているか？ | ・初期化ベクトルは動作モードに適したものが選択されなければならない。多くのモードでは、 CSPRNG(暗号論的擬似乱数生成器)を使うことを意味する。ナンスが必要なモードでは、初期化ベクトルにCSPRNGは必要ない。全てのケースで、初期化ベクトルは固定鍵に対して二回使ってはいけない。 ・常に、ただの暗号化ではなく認証付き暗号を使う |
| ・パスワードベースの鍵導出関数がない場合、パスワードが暗号鍵として使用されていないか? | ・鍵は暗号学的にランダムに生成され、メモリにバイト配列として保存されるべき。パスワードが用いられる場合、適切なパスワードベースの鍵導出関数を用いて鍵に変換しなければならない。 ・パスワードを保存する際、 Argon2や scrypt, bcrypt or PBKDF2 といったワークファクター(遅延ファクター)を持つ強力に最適化されソルトされたハッシュ関数を使う。 |
| ・暗号学的な要件を満たすよう設計されていないランダムネスが暗号のために使われていないか？正しい関数が選択されていたとしても、開発者によってシードされる必要がないか？または開発者が十分なエントロピーや予測不可能性を持たないシードで、その関数に組み込まれた強力なシード機能を上書きしていないか？ | ・適切な場面で暗号論的なランダムネスが用いられ、予測可能な方法または低いエントロピーでシードされていないことを確認する。ほとんどのモダンなAPIでは、開発者がセキュリティのためにCSPRNGでシードする必要はない。 |
| ・非推奨なハッシュ関数であるMD5やSHA1が使われていたり、暗号学的ハッシュ関数が必要な場面でそうでない関数が使われていないか？ ・非推奨なパディングであるPKCS nember 1 v1.5が使われていないか？ | ・非推奨な暗号学的ハッシュ関数やパディングのスキーマを使わない。 |
| ・アプリケーションにより処理、保存、転送されるデータを分類する。個人情報に関わる法律、レギュレーションまたはビジネス上の要請により、どのデータが機密データにあたるのかを特定する。 ・必要ない機密データを保存しない。そういうものはできる限り早く削除するか、PCI DSSに準拠したトークン化またはトランケーションを使用する。保持しないデータは盗まれない。 ・全ての機密データは保存時に必ず暗号化する。 ・機密データを含むレスポンスのキャッシュを無効化する ・データの分類に応じて必要なセキュリティ管理を適用する。 |
|
| ・構成の有効性と設定値の有効性を独立に検証する。 |
A03:2021 – インジェクション
| 観点 | 対応 |
|---|---|
| ・ユーザーによる入力データがアプリケーションによってバリデーション、フィルター、サニタイズされていない。 ・動的なクエリや、コンテキストに応じたエスケープ処理なしのパラメータ化されない呼び出しがインタプリタで直接使われている。 ・敵性データがORMの検索パラメータの中で追加で機密データを抽出するために使われている。 ・敵性データが直接使われたり結合されたりしている。SQLまたはコマンドが構造に悪意のあるデータを含むよう、動的なクエリやコマンド、ストアドプロシージャによって組み立てられる。 | ・望ましいのは安全なAPIを使うこと。インタプリタを使用することを完全に避けたり、パラメータ化されたインターフェースを提供したり、もしくはORMツールへ移行するなど。注意：パラメータ化されていても、ストアドプロシージャはPL/SQLまたはT-SQLがクエリとデータを結合したり有害データをEXECUTE IMMEDIATE やexec()で実行した場合にSQLインジェクションを引き起こしうる。 ・サーバーサイドでホワイトリストを使って入力値をバリデーションする。多くのアプリケーションはテキストエリアやモバイルアプリケーション用のAPIで特殊な文字を使うため、これは完全な防御ではない。 ・それでも残った動的なクエリにおいては、インタプリタ固有のエスケープ構文を用いて特殊文字をエスケープする。注意: テーブル名、カラム名、などといったSQL構造はエスケープできないため、ユーザーの入力値による構造名は危険である。これはレポート執筆ソフトウェアにおいて一般的な問題である。 ・LIMITやその他のSQLの制御をクエリの中で使い、SQLインジェクションが発生した場合でも大量にレコードが漏洩することを防ぐ。 |
| 一般的なインジェクションとしてはSQL, NoSQL, OSコマンド、ORM, LDAP, そして Expression Language (EL) や Object Graph Navigation Library (OGNL) インジェクションがある。コンセプトは全てのインタプリタで同じ。 ・ソースコードレビューがインジェクションへの脆弱性を発見する上で最も効果的。 ・全てのパラメータ、ヘッダ、URL、クッキー、JSON, SOAP, そしてXMLデータの入力に対する自動テストが強く推奨される。 ・組織は静的(SAST)、動的(DAST)、そして対話的(IAST)なアプリケーションのセキュリティテストツールをCI/CDパイプラインに含めることで、インジェクションの欠陥を本番デプロイ前に発見できる。 |
A04:2021 – インセキュアデザイン
| 観点 | 対応 |
|---|---|
| 要件とリソースのマネジメント ・すべてのデータ資産の機密性、完全性、可用性そして真正性に関する保護要件や期待されるビジネスロジックなど、アプリケーションのビジネス要件を収集し、ビジネスサイドと交渉する。アプリケーションがどの程度公開されるか、(アクセス制御に加えて)テナントの分離が必要なのかを検討する。機能要件やセキュリティ上の非機能要件を含む技術的な要件をまとめる。セキュリティ活動を含む全ての設計、構築、テスト、そして運用を含む予算を計画し交渉する。 | ・ユーザーまたはサービスによるリソースの消費を制限する。 |
| セキュアデザイン ・セキュアデザインは、脅威を継続的に評価し、既知の攻撃手法を防ぐためコードを堅牢に設計しテストするための文化と方法論である。 ・脅威モデリングはリファインメントや類似の活動に統合されるべきである。データフローやアクセス制御、その他のセキュリティコントロールの変化を確認する。 ・ユーザーストーリーの開発では、正しいフローと障害状態を決定し、それらを責任者と影響を受ける関係者がよく理解し同意するようにする。 ・期待するフローと障害フローの前提条件と状態を分析し、それらを正確で望ましいものにする。 ・どのように前提条件を検証するかを決め、状態を正しい動作のために必要なものにする。 ・結果はユーザーストーリーに明文化する。 ・失敗から学び改善を促進するための積極的なインセンティブを提供する。 ・セキュアデザインはソフトウェアに追加できるアドオンでもツールでもない。 | ・重要な認証やアクセス制御、ビジネスロジック、そしてキーフローで脅威モデリングを使う。 ・ユーザーストーリーにセキュリティ言語とコントロールを組み込む。 ・全ての重要なフローが脅威モデリングに対して耐性があることを検証するために、ユニットテストと統合テストを書く。アプリケーションの各層でユースケースとミスユースケースをまとめる。 ・公開と保護の必要性に応じて、システムとネットワークのレイヤーを分離する。 ・全ての階層において、設計により強固にテナントを分離する。 |
| セキュア開発ライフサイクル ・セキュアなソフトウェアには、セキュア開発ライフサイクル、セキュアデザインパターン、舗装道路の方法論、安全なコンポーネントライブラリ、ツール、そして脅威モデリングが必要である。 ・ソフトウェアのプロジェクト開始時からプロジェクトとメンテナンスの全体に渡って、セキュリティスペシャリストと連携する。 ・セキュアソフトウェア開発の取り組みを構築するため、 OWASP Software Assurance Maturity Model (SAMM) を活用することを検討する。 | ・AppSecの専門家とともにセキュア開発ライフサイクルを確立して用いることでセキュリティとプライバシー関連のコントロールの評価と設計に役立てる ・セキュアデザインパターンのライブラリやすぐに使えるコンポーネントの舗装道路を確立して用いる。 ・フロントエンドからバックエンドにかけてアプリケーションの各層でふさわしいチェックを組み込む。 |
A05:2021 – セキュリティ上の構成ミス
| 観点 | 対応 |
|---|---|
| ・アプリケーションスタックの任意のパートで適切なセキュリティの堅牢化が欠如している、あるいはクラウドサービスのパーミッション設定が不適切である。 ・協調的で反復可能なアプリケーションセキュリティ設定プロセスがなければ、システムのリスクはより高まる。 | ・反復可能な堅牢化のプロセスが、適切にロックダウンされた別環境をデプロイするのを高速で簡単にする。開発環境、QA環境、そして本番環境は全て同一に構成し、それぞれ異なるクレデンシャルを利用する。このプロセスは新たにセキュアな環境をセットアップする際に必要な労力を最小化するために自動化する。 |
| ・不必要な機能が有効化されたりインストールされたりしている。例：不必要なポート、サービス、ページ、アカウント、特権 ・エラー時にスタックトレースやその他過度に詳細なエラーメッセージがユーザに表示される。 | ・不必要な機能、コンポーネント、ドキュメント、そしてサンプルのない最小限のプラットフォーム。不必要な機能やフレームワークは削除するか、インストールしない。 |
| ・更新されたシステムで、最新のセキュリティ機能が無効になっているかセキュアに設定されていない。 ・デフォルトのアカウントとそのパスワードが有効なまま、あるいは変更されていない。 ・アプリケーションサーバ、アプリケーションフレームワーク (例、Struts, Spring, ASP.NET)、ライブラリ、データベース、その他のセキュリティ設定でセキュアな値が設定されていない。 ・ソフトウェアが古い、または脆弱になっている。 | ・パッチ管理プロセスの一環として、全てのセキュリティ上の注意、更新そしてパッチに適した設定を確認し更新するタスク(A06: 脆弱性と古いコンポーネントを参照)。クラウドストレージのパーミッションを確認する(例: S3バケットのパーミッション)。 |
| ・サーバがセキュリティヘッダやディレクティブを送信しない、またはそれらにセキュアな値が設定されていない。 | ・セキュリティディレクティブをクライアントに送信する。例：Securityヘッダ |
| ・セグメンテーション、コンテナゼーション、またはクラウドセキュリティーグループ (ACLs)によってセグメントされたアプリケーションアーキテクチャは、コンポーネントまたはテナントを効果的かつセキュアに分離する。 |
A06:2021 – 脆弱で古いコンポーネント
| 観点 | 対応 |
|---|---|
| ・使用している全てのコンポーネントのバージョンを知らない場合。(サーバーサイドもクライアントサイドも)これは直接使用しているものも、依存関係にあるものも含む。 ・定期的に脆弱性をスキャンせず、使用しているコンポーネントに関係するセキュリティ情報をサブスクライブしない場合。 ・ソフトウェアが脆弱か、サポート外か、古い場合。これはOS、web/アプリケーションサーバ、DBMS、アプリケーション、APIと全てのコンポーネント、実行環境、そしてライブラリを含む。 | ・クライアントサイドとサーバサイドの両方のコンポーネント(フレームワーク、ライブラリ等)とその依存関係を、versions, OWASP Dependency Check, retire.js,といったツールを使って定期的に洗い出す。Common Vulnerability and Exposures (CVE) や National Vulnerability Database (NVD) を定期的に監視することでコンポーネントの脆弱性に関する情報を得る。ソフトウェア・コンポジション解析（SCA）ツールをつかってこれらのプロセスを自動化する。使用しているコンポーネントに関する脆弱性についてのアラートメールをサブスクライブする。 ・使用していない依存関係、不必要な機能、コンポーネント、ファイル、ドキュメントを削除する。 |
| ・基盤となるプラットフォーム、フレームワーク、そして依存関係を、リスクベースのタイムリーな手法で修正または更新しない場合。これはパッチ適用が月ごともしくは四半期ごとの変更管理によって行われている環境でよく起こる。組織は修正されるはずの脆弱性を不必要に数日もしくは数ヶ月公開することになる。 | |
| ・ソフトウェア開発者がアップデート、アップグレード、パッチ後のライブラリの互換性をテストしない場合。 | |
| ・コンポーネントの構成を保護しない場合(参照： A05:2021 セキュリティ上の構成ミス).。 | |
| ・公式のソースから安全なリンクを辿って得られるコンポーネントだけを取得する。改変され悪意あるコンポーネントを取り込まないよう、署名されたパッケージを利用するのが好ましい (参照：A08:2021-ソフトウェアとデータの完全性の不備)。 | |
| ・メンテナンスされていなかったり、古いバージョンへのセキュリティパッチが作成されていないライブラリやコンポーネントを監視する。パッチが不可能な場合、発見された問題を監視、検知、または保護する仮のパッチをあてることを検討する。 |
A07:2021 – 識別と認証の不備
| 観点 | 対応 |
|---|---|
| ・攻撃者が有効なユーザー名とパスワードのリストを持っているような場合に、クレデンシャルスタッフィング(パスワードリスト攻撃)のような自動攻撃を許してしまう ・総当たりやその他の自動攻撃を許してしまう。 ・多要素認証がない、または効果がない。 | ・可能な場合多要素認証を実装して、自動化されたクレデンシャルスタッフィング(パスワードリスト攻撃)、総当たり攻撃、そして盗まれたクレデンシャルを再利用する攻撃を防ぐ。 |
| ・パスワードとして、デフォルトや、弱いもの、"Password1" や "admin/admin”といったよく知られたものを許可してしまう。 ・平文や、弱く暗号化またはハッシュ化されたパスワードを保存している(参照： A02:2021-暗号化の不備)。 | ・特にアドミンユーザーについて、デフォルトのクレデンシャルのまま出荷やデプロイしない ・弱いパスワードのチェックを実装する。上位10000件の弱いパスワードのリストと照らし合わせる。 ・パスワードの長さ、複雑さ、およびローテーションのポリシーを、米国標準技術局 (NIST) の800-63 bガイドライン (5.1.1 記録された秘密) またはその他の最新のエビデンスベースのパスワードポリシーに合わせる。 |
| ・弱い、もしくは効果のないクレデンシャルのリカバリーとパスワード再設定を行ってしまう。例えば知識ベースの回答は、安全でない。 | ・登録、クレデンシャルのリカバリー、APIの経路が、全ての結果に対して同じメッセージを返すことで、アカウント列挙攻撃に対して対策されている。 |
| ・失敗したログイン試行に対して、制限をかけるか増加的な遅延時間をつける。しかしDoSのシナリオを作成しないよう注意する。クレデンシャルスタッフィング、総当たり、その他の攻撃を検知した場合は全ての失敗を記録し、管理者に通知する。 | |
| ・URLにセッション識別子が公開されている。 ・ログイン成功後にセッション識別子が再利用されている。 ・セッション識別子を正しく無効化していない。ユーザーセッションや認証トークン(主にシングルサインオンのトークン)がログアウト後や一定時間操作がない場合に正しく無効化されていない。 | ・サーバーサイドの、安全な組み込みのセッション管理を利用して、ログイン後に高いエンロトピーで新たにランダムなセッションIDを生成する。セッション識別子はURLに含めず、安全に格納し、ログアウトや無操作時、タイムアウト時に無効化する。 |
A08:2021 – ソフトウェアとデータの完全性の不備
| 観点 | 対応 |
|---|---|
| ・ソフトウェアとデータの完全性の不備は、完全性違反に対する保護のないコードとインフラストラクチャによる。この例として、アプリケーションが信用できないソース、レポジトリ、CDNから取得したプラグイン、ライブラリ、またはモジュールに依存している場合がある。 | |
| ・安全でないCI/CDパイプラインは、不正アクセス、悪意あるコード、システム侵害の可能性をもたらす。現在の多くのアプリケーションは自動更新機能を備えており、更新情報が十分な完全性の検証なくダウンロードされ、前の信頼できるアプリケーションに適用されてしまう。攻撃者は自らの更新情報をアップロードし、それらが配布され全てのインストールで実行されてしまう可能性がある。 | ・デジタル署名やその他のメカニズムを使うことで、ソフトウェアやデータが期待通りのソースから得られており改変もされていないことを検証する。 ・npmやMavenといったライブラリと依存関係が信頼できるレポジトリを利用していることを確認する。リスクが高い場合、内部の検証済みでよく知られたリポジトリを使うことを検討する。 ・OWASP Dependency Check やOWASP CycloneDXといったソフトウェアサプライチェーンセキュリティツールを、コンポーネントが既知の脆弱性を含まないことを確認するために使う |
| ・他の例として、オブジェクトやデータが攻撃者が閲覧・改変可能な構造にエンコードまたはシリアライズされると、安全でないデシリアライゼーションに対して脆弱である。 | ・なんらかの形の完全性検証や改ざん・リプレイを検出するためのデジタル署名なしで、署名なしまたは暗号化されていないシリアライズされたデータが、信用できないクライアントに送られていないことを確認する。 |
| ・悪意あるコードや構成がソフトウェアパイプラインに入り込む機会を最小化するため、コードや構成の変更のレビュープロセスがある。 | |
| ・CI/CDパイプラインに正しい分離、構成、アクセスコントロールがあり、ビルドやデプロイのプロセス中に流れるコードの完全性を保つ。 |
A09:2021 – セキュリティロギングとモニタリングの不備
| 観点 | 対応 |
|---|---|
| ・ログイン、失敗したログイン、高価値なトランザクション等の監査可能なイベントのログがない。 | ・全てのログイン、アクセス制御やサーバーサイドの入力値バリデーションの失敗を、怪しい・悪意あるアカウントを特定できるようなユーザーコンテキストとともに記録し、後にフォレンジック解析できるよう十分な期間保持する。 ・高価値なトランザクションに対して、改ざんや削除を防ぐための完全性制御を行うとともに、監査証跡を取る。例えば追加専用のデータベースや類似のものを使う。 |
| ・ログを、ログ管理ソリューションが簡単に処理できる形式で生成する。 ・ログデータが、ロギングまたはモニタリングシステムへのインジェクションや攻撃を防ぐよう正しくエンコードされている。 |
|
| ・警告やエラーがない、または不十分であったり不明瞭なログメッセージを生成する。 | |
| ・アプリケーションやAPIで怪しい行動のログがモニタリングされていない。 ・OWASP ZAPのような動的アプリケーションセキュリティテスト (DAST) ツールによるペネトレーションテストやスキャンがアラートを引き起こさない。 ・リアルタイムまたはそれに近いアクティブな攻撃に対して、アプケーションが検知、エスカレーション、アラートできない。 | ・DevSecOpsチームは、怪しい行動を検知し即座に対応するために、効果的なモニタリングとアラートを確立すべき。 |
| ・ログがローカルのみに保存されている。 | |
| ・適切な閾値の変更や、対応のエスカーレションプロセスがない、または効果的でない。 | ・米国標準技術局 (NIST) 800-61r2 以降のような、インシデント対応と復旧のプランを採用または策定する。 |
A10:2021 – サーバーサイドリクエストフォージェリ (SSRF)
| 観点 | 対応 |
|---|---|
| SSRFの欠陥は、webアプリケーションがリモートリソースを検証していないユーザー提供のURLから取得するような場合に起こる。 これは、アプリケーションがファイアウォール、VPN、その他ネットワークのアクセスコントロールリスト(ACL)で保護されていても、攻撃者が予期せぬ宛先に改変されたリクエストを送信させることを可能にする。 モダンなウェブアプリケーションはエンドユーザに便利な機能を提供しており、URLからの取得は一般的なシナリオとなっている。結果として、SSRFの発生件数は増加している。またクラウドサービスや複雑なアーキテクチャのためにSSRFの危険度も上昇している。 | |
| ネットワークレイヤーから ・SSRFのインパクトを軽減するため、リモートリソースアクセス機能をネットワーク毎にセグメント化する。 ・重要なイントラネットのトラフィック以外の全てをブロックするため、ファイアウォールポリシーやネットワークのアクセスコントロールルールを“デフォルト拒否”に強制する。 ヒント： ・アプリケーションに基づいたファイアウォールルールのオーナーシップとライフサイクルを確立する。 ・ファイアウォールで、受理またはブロックした全てのネットワークフローをログにとる。(参照：A09 セキュリティロギングとモニタリングの不備) |
|
| アプリケーションレイヤーから ・全てのクライアントからの入力値を無害化し検証する ・ホワイトリストでURLスキーマ、ポート、宛先を扱う ・クライアントにrawなレスポンスを送らない ・HTTPリダイレクションを無効化する ・DNSリバインディング攻撃や“time of check, time of use” (TOCTOU) 競合状態を避けるため、URLの一貫性に注意する ・拒否リストや正規表現を使ってSSRFを緩和しようとしない。攻撃者はペイロードリスト、ツール、そしてスキルを駆使してリストを回避する。 |
|
| 検討すべき追加の施策 ・フロントシステム上に別のセキュリティ関連のサービスをデプロイしない(例OpenID)。これらのシステムのローカルトラフィックを制御する。 ・専用の管理可能なユーザーグループを持つフロントエンドで非常に高い保護ニーズがある場合、独立したシステムでVPNのようなネットワークの暗号化を使うことを検討する。 |
感想
思ったよりは読みやすくなっていない気もしますが、原文を読む前の取っ掛かりにはなるかと思います。しばしば日本語にはない表現に出会えたのは面白かったです。舗装道路(paved road)とか、、日本語で知の高速道路という言い回しは最近よく聞きますが、少しニュアンスは違う気がします。また数年後に更改された際には、超訳OWASP Top 10とでも称して、スラスラ読めるようなものを作れたらいいな。次世代システム研究室では、 Web アプリケーション開発を行うアーキテクトを募集しています。募集職種一覧 からご応募をお待ちしています。
