WEB 10 のセキュリティ脆弱性 (OWASP トップ 10) とペネトレーション テストの記録

1 はじめに

        OWASP (Open Web Application Security Project) は毎年、トップ 10 のセキュリティ脆弱性を発表しています。これは、Web アプリケーションの最も重要なセキュリティ リスクに関する幅広いコンセンサスを表しています。WEB 脆弱性の上位 10 種類を理解し、侵入テストで脆弱性を発見できることは、セキュリティ業界担当者にとっての基本要件です。

2.OWASPトップ10

2.1 OWASP トップ 10 2022

1. 壊れたアクセス制御
2. 無効な暗号化メカニズム
3. インジェクション
4. 安全でない設計
5. セキュリティの構成
ミス 6. 脆弱で古いコンポーネント
7. 識別と認証の失敗
8. ソフトウェアとデータの整合性の失敗
9. セキュリティのログと監視の失敗
10. サーバーサイドリクエストフォージェリ（SSRF）

2.2 OWASP Top10 の概要

2.2.1 壊れたアクセス制御

        アクセス制御は、ユーザーが指定された権限を超えて操作できないようにポリシーを適用します。アクセスの脆弱性により、認証されていないユーザーまたは望ましくないユーザーが機密データ、プロセス、およびユーザー権限設定にアクセスする可能性があります。JSON Web Token (JWT) アクセス コントロール トークンの改ざんや再生、Cookie や隠しフィールドの変更による特権昇格や JWT 無効化の悪用などのメタデータ操作は、アクセス コントロールの脆弱性の例です。2 番目の例は、デフォルトの拒否原則への違反です。アクセスは特定の役割、機能、またはユーザーにのみ付与する必要がありますが、全員がアクセスできます。このようなバグにより、攻撃者は必要なものすべてに簡単にアクセスできるようになる可能性があります。ただし、不適切なアクセス セキュリティ メカニズムや ID またはパスワード管理の問題は、安全なコーディング方法を適用し、管理者アカウントと制限の無効化、多要素認証のインストールなどの予防策を講じることによって回避できます。

        その他の予防手法には次のようなものがあります。

        - アクセス制御メカニズムを 1 回だけ適用し、アプリケーション中に再利用して、クロスオリジン リソース共有 (CORS) を削減します。
       - ドメイン モデルは、アプリケーションのビジネス制約とは異なる制約を課す必要があります。
       - 自動攻撃ツールの影響を軽減するために、アプリケーション プログラミング インターフェイス (API) とコントローラーへのアクセスを制限します。
       - アクセス制御に失敗を記録し、必要に応じて管理者に警告します。
       - モデルのアクセス制御では、情報を作成、表示、変更、削除する権限をユーザーに付与するのではなく、レコードの所有権を強制する必要があります。

2.2.2 機密性メカニズムの失敗

        ここで重要なのは、パスワードのエラーまたはパスワードの欠落により、機密データが漏洩することがよくあるということです。以下は機密情報の開示の典型的な例です。

        セッション トークン
        ログイン ID とパスワード
        オンライン トランザクション
        個人情報 (交換サービス ネットワークまたは SSN、健康記録など)
        たとえば、アプリケーションは自動データベース暗号化を使用して、クレジット カード データを安全に暗号化できます。残念ながら、この情報にアクセスすると、すぐに暗号化が解除され、SQL インジェクション エラーが発生してクレジット カード情報がクリア テキストで抽出され、侵入者によって悪用される可能性があります。

これらの障害は、次の予防手法を使用することで回避できます。

        - パスワードは、scrypt、Argon2、PBKDF2、または bcrypt などの、遅延係数を備えた堅牢でソルト化された適応型ハッシュ アルゴリズムを使用して保存する必要があります。 - 機密データを転送する場合は、ファイル転送プロトコル (FTP) および簡易メール転送プロトコル (SMTP) を使用しないでください
        。 SMTP などの古いプロトコルでは
        、単に暗号化を使用するのではなく、認証された暗号化を実装することが推奨されています
        。暗号化ランダム キーを生成し、それをバイト配列として保存する必要があります。パスフレーズを使用する場合は、パスフレーズベースの鍵作成アルゴリズムを使用して、パスフレーズを鍵のようなものに変更する必要があります。

2.2.3 注入

インジェクション (または SQL インジェクション) は、構造化照会言語 (SQL) を使用して情報を取得したり、通常は認証されたユーザー アカウントを必要とするアクティビティを実行したりする、Web サイトに対するデータベース攻撃です。プログラムが独自のコードからこれらのコードを解釈することは困難であるため、攻撃者がインジェクション攻撃を実行して、信頼できるユーザーを装って保護領域や機密データにアクセスすることが可能になります。インジェクションには、SQL インジェクション、コマンド インジェクション、CRLF インジェクション、LDAP インジェクションなどが含まれます。

いくつかの予防手法には次のようなものがあります。

        - より望ましい代替方法は、インタプリタを完全に回避するか、パラメータ化された API を提供するか、オブジェクト リレーショナル マッピング (ORM) ツールに移動する API を使用することです。
       - サーバー側で入力を積極的に検証することをお勧めします。モバイル アプリケーション用のテキスト フィールドや API など、多くのアプリケーションでは特殊文字が必要です。
        - クエリで LIMIT およびその他の SQL 制約を使用することは、SQL インジェクションの場合に大量のデータの露出を回避する優れた方法です。

2.2.4 安全でない設計

        これは、設計とアーキテクチャの欠陥に焦点を当てた 2021 年の新しいカテゴリであり、脅威モデリング、設計セキュリティの推奨事項、およびリファレンス アーキテクチャをより活用する必要があります。安全でない設計は、「制御設計の欠落または不適切」などの問題を含む幅広いカテゴリです。それは、安全でない設計が他のトップ 10 のリスク カテゴリすべての根本にあるという意味ではありません。

        安全でない設計は、安全でない実装と同じではありません。設計が安全であっても、実装上の欠陥が脆弱性につながる可能性があります。一方、特定の脅威から保護するために必要なセキュリティ保護が存在しないため、欠陥のある設計を完璧な実装で補うことはできません。

        これらの脅威は、次の予防手法を採用することで回避できます。

        -AppSec 専門家の支援を受けて安全な開発ライフサイクルを設定して使用し、セキュリティとプライバシー保護を評価および構築します。
        - 脅威モデリングは、キー認証、アクセス制御、アプリケーション ロジック、および基本的なプロセスに推奨されます。
        - ユーザーストーリーにセキュリティ用語と管理を含めます。
        - すべての層でのテナント分離設計は、実用的な予防アプローチとしても見られます。

2.2.5 セキュリティ設定エラー

        アクセス制御の構成ミスなどの一般的なセキュリティ設定の問題は、攻撃者に重要なデータやサイト領域への迅速かつ簡単なアクセスを提供することにより、重大な危険を引き起こします。

一般的な解決策:

        - 体系的な強化プロセスにより、安全な環境を迅速かつ簡単に導入できます。開発環境、品質管理環境、および運用環境の構成は類似している必要がありますが、ユーザー権限は異なります。
        - 新しい安全な環境をセットアップするプロセスを自動化し、必要な時間と労力を節約するのに最適です。使用しない機能とフレームワークは削除するか、インストールしないでください。不要な機能、コンポーネント、ドキュメント、デモのないプライマリ プラットフォームでは、構成の脆弱性が発生する可能性が低くなります。

2.2.6 脆弱なコンポーネントと古いコンポーネント

        アクセス制御の構成ミスなどの一般的なセキュリティ設定の問題は、攻撃者に重要なデータやサイト領域への迅速かつ簡単なアクセスを提供することにより、重大な危険を引き起こします。

一般的な解決策:

        - 体系的な強化プロセスにより、安全な環境を迅速かつ簡単に導入できます。開発環境、品質管理環境、および運用環境の構成は類似している必要がありますが、ユーザー権限は異なります。
        - 新しい安全な環境をセットアップするプロセスを自動化し、必要な時間と労力を節約するのに最適です。使用しない機能とフレームワークは削除するか、インストールしないでください。不要な機能、コンポーネント、ドキュメント、デモのないプライマリ プラットフォームでは、構成の脆弱性が発生する可能性が低くなります。

2.2.7 識別および認証の失敗

        識別問題に関連する CWE が含まれるようになりました。攻撃者がユーザー情報、パスワード回復、ID セッション、その他のログイン認証情報にアクセスすると、セキュリティ上の懸念が生じます。名前が示すように、ID および認証の失敗には、ハッカーがそのような脆弱性を悪用して不十分な認証を悪用することが含まれます。

        アプリケーションが資格情報スタッフィング (攻撃者が実際のユーザーとパスワードのリストにアクセスできる場合) や、事前に定義された脆弱な一般的なパスワード (「Password1」や「admin/admin」など) などの自動化された攻撃を許可する場合、これらは不正行為の兆候である可能性があります。認証の欠陥

        このような落とし穴を避けるには、次の予防措置を考慮する必要があります。

        - 自動認証情報スタッフィング、ブルート フォース攻撃、盗まれた認証情報の再利用を回避するために、可能な場合は多要素認証を使用する必要があります。
        - 新しいパスワードまたは変更されたパスワードを、最悪のパスワード 10,000 個のデータベースと照合してチェックすることにより、パスワードのセキュリティを向上させます。
        - 各結果に同じメッセージを使用すると、パスワードの回復、登録、および API パスに対するアカウント列挙攻撃を防ぐことができます。
特に管理ユーザーの場合は、デフォルトの資格情報をインストールしないでください。

2.2.8 ソフトウェアとデータの整合性の問題

        データベースに保存される機密情報が増え、セキュリティ侵害に対して脆弱になるため、ソフトウェアにとってデータの整合性の問題が重要になります。

        これは、ソフトウェア更新プログラム、重要なデータ、CI/CD プログラムの整合性を検証せずに想定することに重点を置いた新しいカテゴリです。例としては、アプリケーションがコンテンツ配信ネットワーク (CDN) または無許可のソースからの拡張機能、モジュール、またはリポジトリを使用する場合が挙げられます。保護されていない継続的インテグレーション/継続的デリバリー (CI/CD) プロセスは、悪意のあるコード、システムの侵害、または不正アクセスのリスクを高める可能性があります。

予防手法には次のようなものがあります。

        - データやソフトウェアが改ざんされることなく意図されたソースからのものであることを確認するために、デジタル署名などの手段を使用する場合があります。
        - OWASP CycloneDX や OWASP dependency-Check などのソフトウェア サプライ チェーンのセキュリティ ツールを使用して、コンポーネントに設計上の欠陥が含まれていないことを確認できます。
        - CI/CD ワークフローに必要なセグメンテーション、アクセス制御、およびパラメータ化が設定されていて、セットアップおよびデプロイメント操作全体を通じてコードの整合性が保護されていることを確認する必要があります。
        - 署名または暗号化されていないコンパイル済みデータは、データの変更や重複を識別するための整合性テストまたはデジタル署名が行われていない限り、信頼できないクライアントに送信しないでください。

2.2.9 セキュリティログの監視と記録に失敗する

        不審な動作やイベントが存在する場合に追跡が行われないと、監視されない期間が広がる可能性があり、適切なログを記録した場合よりもセキュリティ侵害が長期間気づかれない可能性があります。この OWASP トップ 10 2021 セクションは、最近の侵害の特定、エスカレーション、解決に役立つように設計されています。ログ記録と監視がなければ、セキュリティ侵害を検出することは不可能です。

        - すべての認証、アクセス セキュリティ システム、サーバー側のデータ検証の問題が、疑わしいアカウントや不正なアカウントを検出するのに十分なユーザー情報とともに記録され、完全な調査が遅れても十分な期間保存されていることを確認します。
        - ログがログ管理システムで使用できる形式で作成されていることを確認します。
        - インシデントの回復と対応の取り組みのためのポリシー (NIST 800-61r2 以降など) を作成または適用します。
        -監視システムへの侵入やサイバー脅威を回避するために、ログ データが適切にエンコードされていることを確認します。

2.2.10 サーバー リクエスト フォージェリ (SSRF)

        このカテゴリの結果は、平均を上回るテスト カバレッジ、適度に低い発生率、平均を上回る影響と使用率の評価を示しています。SSRF は、サーバー側のクエリがユーザー指定の URL を認証しないように開発されました。これにより、攻撃者は、その場所が仮想プライベート ネットワーク (VPN)、ファイアウォール、またはネットワーク アクセス コントロール リスト (ACL) によって保護されている場合でも、アプリケーションをだまして偽のリクエストを望まない場所に送信させることができます。

        新しいオンライン アプリケーションがエンド ユーザーに便利な機能を提供するため、URL を取得することは一般的な状況になっています。その結果、SSRFの有病率は増加しています。また、クラウド サービスと設計の複雑さにより、SSRF の強みは増大しています。これを念頭に置いて、次の予防手法を採用することで、このような攻撃を回避できます。

        - SSRF の影響を制限するには、リモート リソース アクセス機能を異なるネットワークに分離する必要があります。
       - 「デフォルトで拒否」ファイアウォール設定またはネットワーク アクセス コントロール ルールをインストールして、必要な内部トラフィックを除くすべての Web トラフィックをブロックします。
        - (TOCTOU) の場合、DNS の再マッピングと「時間の確認、時間の使用」攻撃を防ぐために、URL の精度に注意を払うことが最善です。

2.3 参考

Web アプリケーションのトップ 10 のセキュリティ脆弱性_Ten Web Vulnerabilities_crazy_itman のブログ-CSDN ブログ

OWASP トップ 10 2022 の紹介 - 世界の終わりとあなたのブログ - CSDN ブログ

3. WEBペネトレーションテストの記録

        最近、WEBペネトレーションテストを実施しました。ここで検出された問題の概要を記録します。

1. 正規ユーザの特定の URL をコピーし、不正ユーザがログインしていることが判明した後、その URL をコピーした内容に変更すると、ログインできることがわかります。(アクセス制御が壊れている)

2. 顧客 A のアカウントでログインし、ログ検索機能を使用し、postman を使用して HTTP リクエスト内のアカウント ID を顧客 B のアカウントに変更すると、B のログが表示されることがわかります。(アクセス制御が壊れている)

3. jwt ペイロードを任意に偽造でき、メッセージが BASE64 でデコードおよびエンコードできることを確認し、「alg」が配置されている中括弧のデコードを取得し、プレーン テキストの「alg」の値を「none」に変更します。 」を記述し、「ey****」に再エンコードし、jwtヘッダー(Authorization)の値を「ey****」に置き換えると、jwtペイロードを任意に設定できるようになります。(アクセス制御が壊れている)

4. ロール ID を使用してパブリック API を呼び出します。応答ヘッダーからロール ID を取得します。新しいロール ID を使用して API を再度呼び出し、新しいロール ID をリクエスト ヘッダーに追加します。結果は変わります。(アクセス制御が壊れている)

5. パブリック API の入力顧客 ID は、「customer - ID」ヘッダーを通じて挿入できます。入力ヘッダーは使用前に検証されません。これは重大なデータ漏洩の問題です。顧客 ID が取得された場合にのみ、1 つのテナントがパブリック API を呼び出して他のテナントのデータを取得できます。(アクセス制御が壊れている)

1. テナントAとテナントBの2つのテナントを用意します。
2. "cid": "cid of A" を使用して API "https://....../audit/logs " を呼び出します
3. ヘッダーに「***-customer-id」:「B の cid」を追加します。
4. Bの監査ログ情報の取得に成功しました。

6. 入力ヘッダーは使用前に検証されません。これは重大なデータ漏洩の問題です。顧客 ID を取得できる限り、テナントはパブリック API を呼び出して他のテナントからデータを取得できます。(アクセス制御が壊れている)

1. ヘッダーで正しい uic_token を使用して API「http://..../notifications/counts」を呼び出します。
2. 応答から顧客 ID を取得します
3. 手順2で取得した顧客IDをヘッダーに入れてAPIを呼び出します。

7. 攻撃者は、ロール ID を変更することで、さまざまなロール権限を取得できます。(アクセス制御が壊れている)

        1. ロール ID の権限を使用して API を呼び出します。

        2. 応答ヘッダーからロール ID を取得します。

        3. 新しいロール ID (ステップ 2 で取得) を使用して API を再度呼び出し、新しいロール ID を要求ヘッダーに入れます。権限が変更されます。

8. ui-token を指定せずにクエリを実行する場合でも、リクエストをクエリできます。(アクセス制御が壊れている)

Uic-token は CSRF チェックに使用されます。このトークンが指定されていない場合、CSRF 攻撃が発生する可能性があります。

9. セッションが適切に終了されませんでした。ログアウト後もセッションは有効であり、UI API リクエストの作成に使用できます。(識別認証に失敗しました)

1. まず、現在のセッションからログアウトします。

2. 古い Cookie と UI トークンを使用して API を呼び出します。リクエストは引き続き成功します。

10. デバッグモードでは、コンソールにパスワードが表示されます（識別および認証に失敗しました）

パスワードは機密情報であるため、攻撃者はこのパスワードを取得した後、コンソールに直接ログインできます。

        1. 「権限なし」のロールでポータルにログインします。

        2. リンク https://....../#/admin/logs を開きます。

        3. デバッグ モードをオンにして、コンソールを選択します。       

        4. いくつかのキーワードを入力して「検索」すると、Web コンソールにパスワードが表示されます。

11. Cookie を使用せずにフロントエンド認証 API を呼び出すと、「x-account-id」が欠落しているという応答が表示されます。認証が必要ない場合は、x-account-id ヘッダーを通じてアカウント ID を設定できます。(識別認証に失敗しました)

12. フロントエンド製品コネクタ API を呼び出します。応答には、ページで使用されていないトークン フィールドがあります。認証情報の漏洩の問題。(識別認証に失敗しました)

13. 監査ログは削除可能（安全でない設計）

ハッカーは、危険な操作を実行するときに監査ログを削除する可能性があります (DELETE https://…)。

14. 攻撃者はテスト電子メールを頻繁に送信する可能性があり、DOS やスパムを引き起こす可能性があります。(安全ではない設計)

        「Camp Admin」からポータルを起動します。「アカウント」->「通知」に移動し、項目を選択して、1 分以内に「テストメールの送信」を頻繁にクリックします。

15. リフレクティブ クロスサイト スクリプティング (XSS) インジェクション。（注入）

これは、反射型クロスサイト スクリプティング インジェクションです。XSS を使用すると、脆弱なドメインで Cookie を盗み、ユーザーの認証セッションに不正にアクセスしたり、脆弱な Web ページのコンテンツを変更/破壊したり、ユーザーの Web ブラウザを侵害したりする可能性があります。攻撃者がリクエストのタイム ゾーン フィールドを変更し、Cookie を盗む JavaScript を挿入した場合、被害者を URL にアクセスさせることができれば制御を得ることが可能です。

        1. コンソール設定で、設定を保存するとき。POST リクエストのペイロードには、注入に使用できるフィールド値があります。

<script>alert(\"0\");</script>

16. Web アプリケーション コンポーネントは、クロスサイト スクリプティング (XSS) 攻撃に対して脆弱です。（注入）

Web アプリケーション コンポーネントは、クロスサイト スクリプティング (XSS) 攻撃に対して脆弱です。この問題を悪用すると、攻撃者はアプリケーションの入力パラメータに任意のクライアント側サイト コード (JavaScript、VBScript など) を提供し、最終的にはエンド ユーザーの Web ブラウザでレンダリングおよび実行される可能性があります。

info.html ページは DOM ベースのリンク インジェクションに対して脆弱であり、クリックされるとクロスサイト攻撃につながる可能性があります。XSS を使用すると、脆弱な Web ページのコンテンツが侵害された後、またはユーザーの Web ブラウザが侵害された後、脆弱なドメインで Cookie を盗み、ユーザーの認証セッションに不正にアクセスできる可能性があります。一般的な戦術は、実際のセッション タイムアウトやログイン ページを偽装してユーザー パスワードを取得するために、信頼できるドメイン上の脆弱なページを再ペイントすることです。

        1. 「Camp Admin」ロールでポータルにログインします。、

        2. ポータルからログアウトします

        3. URL https://********/info.html#/redirect?url=javascript:alert(0) を入力してスクリプトを挿入します

17. 応答の詳細からアプリケーションに関する情報が明らかになり、既存の脆弱性が発見される可能性が高まります。(セキュリティの設定ミス)

応答の詳細からアプリケーションに関する情報が明らかになる可能性があり、既存の脆弱性を発見する可能性が高まります。

間違った本文で API を呼び出すと、応答結果にアプリケーションの詳細が含まれます。

18. CSP ヘッダーが安全な値として追加または構成されていないため、信頼できないサイト情報にリソースが読み込まれ、XSS およびその他の関連する脆弱性が発生します。(セキュリティの設定ミス)

コンテンツ セキュリティ ポリシー (CSP) は、特定の種類の攻撃の検出と軽減に役立つ追加のセキュリティ層です。クロスサイト スクリプティング (XSS) 攻撃やデータ インジェクション攻撃が含まれます (ただしこれらに限定されません)。これらの攻撃は、データの盗難から Web サイトの改ざん、マルウェアの配布まで、あらゆる目的で使用されます。CSP は、Web サイト所有者が、ブラウザがそのページにロードできるコンテンツのソースを宣言できる HTTP ヘッダーの標準セットを提供します。対象となるタイプには、JavaScript、CSS、HTML フレーム、フォント、画像、埋め込み可能オブジェクトが含まれます

19. Web サーバー上の Cross Origin Resource Sharing (CORS) の構成が間違っているため、Web ブラウザーはデータをロードできない可能性があります。Access-Control-Allow-Origin: *機密データには安全ではありません。(セキュリティの設定ミス)

Web サーバー上の CORS の構成が間違っていると、認証されていない API が使用される任意のサードパーティ ドメインからのクロスオリジン読み取りリクエストが許可されます。ただし、Web ブラウザーの実装では、任意の第三者が認証された API からの応答を読み取ることはできません。これによりリスクがある程度軽減されます。この構成ミスは、攻撃者によって、認証されていない方法で利用可能な、IP アドレスのホワイトリストなどの他の形式のセキュリティを使用するデータにアクセスするために悪用される可能性があります。

20. HSTS セキュリティ ポリシーを使用していない(セキュリティの設定ミス)

HTTP Strict Transport Security (HSTS) は、Web サーバーが従うと宣言したユーザー エージェント (Web ブラウザなど) が安全な HTTPS 接続 (つまり、HTTP 層は TLS/SSL 経由) を使用してのみ対話する Web セキュリティ ポリシー メカニズムです。HSTS は、RFC 6797 で指定された IETF 標準トラック プロトコルです。

このヘッダーがないと、Web サーバーが通常の HTTP トラフィックに使用できなくなる危険があります。

21. 誰もが任意のファイルをサーバーにダウンロードできます。ファイルが置き換えられてアプリケーションに影響を与える可能性があり、他のクライアントがそのファイルをウイルスに感染させて実行される可能性があります。(セキュリティの設定ミス)

       1. 「管理者」ロールで v1 ポータルを開きます。

        2. ポータルからファイルの取得 URL を見つけます。

        3. PUT メソッドを使用して、任意のファイルを URL に送信します (例: test.js)。このファイルはgetメソッドで取得できます。

22. HTTP を使用して API 呼び出しを行うことができる(セキュリティ構成エラー)

API は Postman を使用して http リクエストを送信できます

応答ヘッダーには「Strict-Transport-Security」ヘッダーがありません。「Strict-Transport-Security」ヘッダーはサイトを HTTPS のみに制限しており、今後 HTTP を使用してサイトにアクセスしようとすると、自動的に HTTPS に変換される必要があります。

4. 最後に

        Web セキュリティの主要な種類は年ごとに若干変化します。最も一般的なタイプの WEB 脆弱性を熟知することは、侵入作業を開発するための重要な基盤です。