10 の最も一般的な Web セキュリティの脆弱性

OWASP または Open Web Security Project は、ソフトウェアと Web アプリケーションのセキュリティの向上に重点を置いた非営利の慈善団体です。

この組織は、さまざまなセキュリティ組織からのデータに基づいて、Web セキュリティの主要な脆弱性のリストを公開しています。

Web セキュリティの脆弱性は、悪用可能性、検出可能性、およびソフトウェアへの影響に応じて優先順位が付けられます。

• 悪用可能性 –セキュリティの脆弱性を悪用するには何が必要ですか? 攻撃に Web ブラウザのみが必要な場合は悪用可能性が最も高く、高度なプログラミングとツールが必要な場合は最も悪用されます。
• 検出可能性 – 脅威を検出するのはどの程度簡単ですか? URL、フォーム、エラー メッセージに表示される情報が最も簡単に検出でき、ソース コードが最も簡単に検出できます。
• 衝撃または損傷 –セキュリティの脆弱性が暴露されたり攻撃されたりした場合、どの程度の被害が生じるのでしょうか? 最高は完全なシステムクラッシュ、最低は何も起こらないことです。

OWASP Top 10 の主な目的は、開発者、設計者、管理者、アーキテクト、組織に最も重要なセキュリティの脆弱性について教育することです。

OWASP Top 10 によるセキュリティ脆弱性のトップ 10 は次のとおりです。

SQLインジェクション

説明

インジェクションは、攻撃者がバックエンドを変更できるようにするセキュリティ上の脆弱性です。 SQL ユーザーが指定したデータを操作してステートメントを作成します。

インジェクションは、ユーザー入力がコマンドまたはクエリの一部としてインタープリターに送信されるときに発生し、インタープリターを騙して意図しないコマンドを実行させ、未承認のデータへのアクセスを与えます。

Web アプリケーションによって実行される SQL コマンドは、バックエンド データベースを公開することもできます。

含意

• 攻撃者は、脆弱なフィールドに悪意のあるコンテンツを挿入する可能性があります。
• ユーザー名、パスワードなどの機密データをデータベースから読み取ることができます。
• データベースのデータを変更（挿入/更新/削除）できます。
• 管理部門 Operaデータベース上で実行できる

脆弱なオブジェクト

• 入力フィールド
• データベースと対話する URL。

例：

• SQLインジェクション ログインページで

有効な資格情報を持たずにアプリケーションにログインする。

有効なユーザー名は使用できますが、パスワードは使用できません。

テスト URL: http://demo.testfire.net/default.aspx

ユーザー名: sjones

パスワード: 1=1' または pass123

以下のように SQL クエリが作成され、インタープリターに送信されます

SELECT * FROM ユーザー WHERE ユーザー名 = sjones AND パスワード = 1=1' または pass123;

クライアントの声

1. 入力フィールドのホワイトリスト化
2. 攻撃者にとって有益な詳細なエラー メッセージを表示しないようにします。

クロスサイトスクリプティング

説明

クロスサイト スクリプティングは、略して XSS とも呼ばれます。

XSS の脆弱性は、サーバー側ではなくクライアント側、つまりユーザーのブラウザーで実行されるページに埋め込まれたスクリプトをターゲットとしています。 これらの欠陥は、アプリケーションが信頼できないデータを取得し、適切な検証を行わずに Web ブラウザに送信した場合に発生する可能性があります。

攻撃者は XSS を使用して、ユーザー (この場合は被害者のブラウザ) 上で悪意のあるスクリプトを実行する可能性があります。 ブラウザはスクリプトが信頼できるかどうかを判断できないため、スクリプトが実行され、攻撃者はセッション Cookie をハイジャックしたり、Web サイトを改ざんしたり、ユーザーを望ましくない悪意のある Web サイトにリダイレクトしたりする可能性があります。

XSS は、攻撃者が被害者のブラウザ上でスクリプトを実行できるようにする攻撃です。

含意：

• このセキュリティの脆弱性を利用して、攻撃者はアプリケーションにスクリプトを挿入したり、セッション Cookie を盗んだり、Web サイトを改ざんしたり、被害者のマシン上でマルウェアを実行したりすることができます。

脆弱なオブジェクト

• 入力フィールド
• URLは

例

1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script>

上記のスクリプトをブラウザで実行すると、サイトが XSS に対して脆弱な場合はメッセージ ボックスが表示されます。

攻撃者がセッション Cookie を表示または保存したい場合は、より深刻な攻撃が行われる可能性があります。

2. http://demo.testfire.net/search.aspx?txtSearch <iframe> http://google.com 幅 = 500 高さ 500>

上記のスクリプトを実行すると、ブラウザは以下を指す非表示のフレームを読み込みます。 http://google.com.

ブラウザ上で悪意のあるスクリプトを実行すると、攻撃が深刻になる可能性があります。

クライアントの声

1. ホワイトリスト入力フィールド
2. 入力出力エンコーディング

壊れた認証とセッション管理

説明

Web サイトは通常、有効なセッションごとにセッション Cookie とセッション ID を作成します。これらの Cookie にはユーザー名、パスワードなどの機密データが含まれています。ログアウトまたはブラウザが突然閉じられてセッションが終了した場合、これらの Cookie はセッションごとに無効化される必要があります。新しいクッキーがあるはずです。

Cookie が無効化されていない場合、機密データがシステム内に存在することになります。 たとえば、ユーザーが公共のコンピュータ (サイバー カフェ) を使用している場合、脆弱なサイトの Cookie がシステム上に存在し、攻撃者にさらされます。 攻撃者が同じ公共のコンピュータをしばらく使用すると、機密データが危険にさらされます。

同様に、公共のコンピュータを使用しているユーザーは、ログオフする代わりに、ブラウザを突然閉じます。 攻撃者が同じシステムを使用し、同じ脆弱なサイトを閲覧すると、被害者の以前のセッションが開かれます。 攻撃者はプロフィール情報やクレジットカード情報などを盗むなど、やりたい放題です。

認証とセッション管理の強度を確認するためにチェックを行う必要があります。 キー、セッション トークン、Cookie は、パスワードを損なうことなく適切に実装する必要があります。

脆弱なオブジェクト

• URL 上でセッション ID が公開されると、セッション固定攻撃が引き起こされる可能性があります。
• セッション ID はログアウトおよびログインの前後で同じです。
• セッション タイムアウトが正しく実装されていません。
• アプリケーションは、新しいセッションごとに同じセッション ID を割り当てています。
• アプリケーションの認証された部分は SSL を使用して保護され、パスワードはハッシュまたは暗号化された形式で保存されます。
• セッションは、権限の低いユーザーでも再利用できます。

含意

• この脆弱性を利用して、攻撃者はセッションをハイジャックし、システムへの不正アクセスを取得して、不正な情報の開示や変更を可能にする可能性があります。
• セッションは、盗まれた Cookie または XSS を使用したセッションを使用してハイジャックされる可能性があります。

例

1. 航空会社予約アプリケーションは、URL にセッション ID を含める URL 書き換えをサポートしています。http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (モルディブ行きのチケットの販売) サイトの認証済みユーザーが友人にセールについて知らせたいと思い、メールを送信します。友人はセッション ID を受け取り、不正な変更を行ったり、保存されたクレジットカードの詳細を悪用したりする可能性があります。
2. アプリケーションには XSS に対して脆弱があり、攻撃者がセッション ID にアクセスし、セッションをハイジャックするために使用される可能性があります。
3. アプリケーションのタイムアウトが適切に設定されていません。ユーザーは公共のコンピュータを使用し、ログオフせずにブラウザを閉じて立ち去ります。攻撃者はしばらくしてから同じブラウザを使用し、セッションが認証されます。

クライアントの声

1. すべての認証およびセッション管理要件は、OWASP アプリケーション セキュリティ検証標準に従って定義する必要があります。
2. URL やログ内の資格情報を決して公開しないでください。
3. セッション ID を盗むために使用される可能性のある XSS の欠陥を回避するためにも、強力な努力を行う必要があります。

安全でない直接オブジェクト参照

説明

これは、開発者がファイル、ディレクトリ、データベース キーなどの内部実装オブジェクトへの参照を URL または FORM パラメータとして公開するときに発生します。 攻撃者はこの情報を使用して他のオブジェクトにアクセスし、今後、不正なデータにアクセスする攻撃を作成する可能性があります。

含意

• この脆弱性を利用すると、攻撃者は未承認の内部オブジェクトにアクセスしたり、データを変更したり、アプリケーションを侵害したりする可能性があります。

脆弱なオブジェクト

• URL内。

例：

以下の URL の「userid」を変更すると、攻撃者が他のユーザーの情報を閲覧できるようになります。

http://www.vulnerablesite.com/userid=123 に変更されました http://www.vulnerablesite.com/userid=124

攻撃者はユーザー ID の値を変更することで他の情報を閲覧できます。

推奨事項：

1. アクセス制御チェックを実装します。
2. URL でオブジェクト参照を公開しないようにします。
3. すべての参照オブジェクトに対する権限を確認します。

クロスサイトリクエストフォージェリ

説明

クロスサイト リクエスト フォージェリは、クロスサイトから送信された偽造リクエストです。

CSRF 攻撃は、悪意のある Web サイト、電子メール、またはプログラムによって、ユーザーが現在認証されている信頼できるサイトでユーザーのブラウザが望ましくないアクションを実行する場合に発生する攻撃です。

CSRF 攻撃は、ログオンしている被害者のブラウザに、被害者のセッション Cookie やその他の自動的に含まれる認証情報を含む偽の HTTP リクエストを脆弱な Web アプリケーションに送信させます。

ユーザーが元の Web サイトにログインしているときにその URL をクリックすると、攻撃者から被害者にリンクが送信され、Web サイトからデータが盗まれます。

含意

• この脆弱性を攻撃者として利用すると、ユーザー プロファイル情報の変更、ステータスの変更、管理者に代わって新しいユーザーの作成などが行われる可能性があります。

脆弱なオブジェクト

• ユーザープロフィールページ
• ユーザーアカウントフォーム
• お取引ページ

例

被害者は有効な認証情報を使用して銀行の Web サイトにログインします。攻撃者から「ここをクリックして 1 ドルを寄付してください」というメールが届きます。

被害者がそれをクリックすると、特定のアカウントに 1 ドルを寄付するための有効なリクエストが作成されます。

http://www.vulnerablebank.com/transfer.do?account=cause&amount=1

攻撃者はこのリクエストをキャプチャし、以下のリクエストを作成し、「I Support Cause」というボタンを埋め込みます。

http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000

セッションは認証され、リクエストは銀行の Web サイト経由で送信されるため、サーバーは攻撃者に 1000 ドルを送金します。

おすすめ

1. 機密性の高いアクションを実行する際にユーザーの立ち会いを義務付けます。
2. CAのようなメカニズムを実装するPTCHA、再認証、および一意のリクエスト トークン。

セキュリティの構成ミス

説明

アプリケーション、フレームワーク、アプリケーション サーバー、Web サーバー、データベース サーバー、およびプラットフォームのセキュリティ構成を定義し、展開する必要があります。これらが適切に構成されている場合、攻撃者は機密データや機能に不正にアクセスできます。

場合によっては、このような欠陥によりシステムが完全に侵害されることがあります。 ソフトウェアを最新の状態に保つことは、セキュリティにも優れています。

含意

• この脆弱性を利用して、攻撃者は基盤となるテクノロジーとアプリケーション サーバーのバージョン情報、データベース情報を列挙し、アプリケーションに関する情報を取得して、さらにいくつかの攻撃を仕掛けることができます。

脆弱なオブジェクト

• URL
• Form Fields
• 入力フィールド

例

1. アプリケーション サーバー管理コンソールは自動的にインストールされ、削除されません。 デフォルトのアカウントは変更されません。 攻撃者はデフォルトのパスワードでログインし、不正アクセスを取得する可能性があります。
2. サーバーではディレクトリ一覧が無効になっていません。 攻撃者は任意のファイルを発見し、ディレクトリをリストするだけでファイルを見つけることができます。

クライアントの声

1. コンポーネント間の適切な分離とセキュリティを提供する強力なアプリケーション アーキテクチャ。
2. デフォルトのユーザー名とパスワードを変更します。
3. ディレクトリのリストを無効にし、アクセス制御チェックを実装します。

安全でない暗号化ストレージ

説明

安全でない暗号化ストレージは、機密データが安全に保存されていない場合に存在する一般的な脆弱性です。

ユーザーの資格情報、プロフィール情報、健康の詳細、クレジットカード情報などは、Web サイト上の機密データ情報に該当します。

このデータはアプリケーション データベースに保存されます。 このデータが暗号化やハッシュ* を使用せずに不適切に保存されると、攻撃者に対して脆弱になります。

(*ハッシュとは、文字列文字を固定長の短い文字列またはキーに変換することです。文字列を復号化するには、キーの形成に使用されるアルゴリズムが利用可能である必要があります)

含意

• この脆弱性を利用すると、攻撃者はそのような保護が弱いデータを盗んだり改ざんしたりして、個人情報の盗難、クレジット カード詐欺、その他の犯罪を実行する可能性があります。

脆弱なオブジェクト

• アプリケーションデータベース。

例

銀行アプリケーションの XNUMX つでは、パスワード データベースはソルトされていないハッシュ * を使用して全員のパスワードを保存しています。 SQL インジェクションの欠陥により、攻撃者はパスワード ファイルを取得できます。 ソルトなしのハッシュはすべてすぐに総当たり攻撃できるのに対し、ソルト付きパスワードは数千年かかります。

(*ソルトなしのハッシュ – ソルトは元のデータに追加されるランダムなデータです。ソルトはハッシュ化する前にパスワードに追加されます)

クライアントの声

1. 適切な強力な標準アルゴリズムを確保します。独自の暗号化アルゴリズムを作成しないでください。AES、RSA 公開キー暗号化、SHA-256 などの承認された公開アルゴリズムのみを使用します。
2. オフサイト バックアップが暗号化されていることを確認しますが、キーは個別に管理され、バックアップされます。

URL アクセスの制限に失敗する

説明

Web アプリケーションは、保護されたリンクやボタンを表示する前に、URL アクセス権をチェックします。 アプリケーションは、これらのページにアクセスするたびに、同様のアクセス制御チェックを実行する必要があります。

ほとんどのアプリケーションでは、特権ページ、場所、リソースは特権ユーザーに表示されません。

賢明な推測により、攻撃者は特権ページにアクセスできます。 攻撃者は機密ページにアクセスし、関数を呼び出し、機密情報を閲覧する可能性があります。

含意

• この脆弱性を悪用すると、攻撃者はアプリケーションにログインせずに不正な URL にアクセスし、脆弱性を悪用する可能性があります。 攻撃者は機密ページにアクセスし、関数を呼び出し、機密情報を閲覧する可能性があります。

脆弱なオブジェクト:

• URLは

例

1. 攻撃者は、URL が「/user/getaccounts」としてロールを示していることに気づきます。 「/admin/getaccounts」として変更します。
2. 攻撃者は URL にロールを追加できます。

http://www.vulnerablsite.com 次のように変更できます http://www.vulnerablesite.com/admin

クライアントの声

1. 強力なアクセス制御チェックを実装します。
2. 認証および認可ポリシーはロールベースである必要があります。
3. 不要な URL へのアクセスを制限します。

トランスポート層の保護が不十分

説明

ユーザー (クライアント) とサーバー (アプリケーション) 間の情報交換を処理します。アプリケーションは、認証の詳細、クレジットカード情報、セッション トークンなどの機密情報をネットワーク経由で頻繁に送信します。

弱いアルゴリズムを使用したり、期限切れまたは無効な証明書を使用したり、SSL を使用しなかったりすると、通信が信頼できないユーザーに公開され、Web アプリケーションが危険にさらされたり、機密情報が盗まれたりする可能性があります。

含意

• この Web セキュリティの脆弱性を利用して、攻撃者は正規のユーザーの資格情報を盗み出し、アプリケーションへのアクセスを取得する可能性があります。
• クレジットカード情報を盗む可能性があります。

脆弱なオブジェクト

• ネットワーク経由で送信されるデータ。

クライアントの声

1. セキュア HTTP を有効にし、HTTPS のみを介した認証情報の転送を強制します。
2. 証明書が有効で、有効期限が切れていないことを確認してください。

例：

1. SSL を使用しないアプリケーションでは、攻撃者は単にネットワーク トラフィックを監視し、認証された被害者のセッション Cookie を監視します。 攻撃者はその Cookie を盗み、中間者攻撃を実行する可能性があります。

未検証のリダイレクトと転送

説明

Web アプリケーションは、意図された目的のためにユーザーを他のページにリダイレクトおよび転送するためにいくつかの方法を使用します。

他のページへのリダイレクト中に適切な検証が行われない場合、攻撃者はこれを利用して被害者をフィッシング サイトやマルウェア サイトにリダイレクトしたり、転送を使用して未承認のページにアクセスしたりする可能性があります。

含意

• 攻撃者は、本物の URL にエンコードされた悪意のある URL が付加された URL をユーザーに送信する可能性があります。 ユーザーは、攻撃者が送信した URL の本物の部分を見ただけでそれを閲覧でき、被害に遭う可能性があります。

例

1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com

に変更されました

http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com

クライアントの声

1. アプリケーション内でのリダイレクトと転送の使用は避けてください。 使用する場合は、宛先の計算にユーザー パラメーターを使用しないでください。
2. 宛先パラメータを回避できない場合は、指定された値が有効であり、ユーザーに対して承認されていることを確認してください。