OWASP（Open Web Security Project）は、ソフトウェアやWebアプリケーションのセキュリティを向上させることを目的とした非営利の慈善団体です。
この団体は、さまざまなセキュリティ団体のデータに基づいて、Webセキュリティのトップレベルの脆弱性のリストを発表しています。
Webセキュリティの脆弱性は、悪用可能性、検出可能性、ソフトウェアへの影響に応じて優先順位が付けられています。
- Exploitability –
セキュリティの脆弱性を悪用するためには何が必要か？ 攻撃に必要なものが Web ブラウザーだけの場合、最も高い Exploitability となり、高度なプログラミングやツールが必要な場合は最も低いものとなります。 最も高いのは、URL、フォーム、またはエラー メッセージに表示される情報で、最も低いのはソース コードです。
- Impact or Damage –
セキュリティの脆弱性が公開されたり攻撃されたりした場合、どのくらいの損害が発生するか。
OWASP Top 10 の主な目的は、最も重要なセキュリティの脆弱性について、開発者、設計者、管理者、建築家、および組織を教育することです。
- SQLインジェクション
- クロスサイトスクリプティング
- 認証とセッション管理の破壊
- 安全でない直接オブジェクト参照
- クロスサイトリクエストフォージェリ
- セキュリティの誤設定
- 安全でない暗号化ストレージ
- URLアクセス制限の失敗
- 不十分な Transport Layer Protection
- Unvalidated Redirects and Forwards
SQL インジェクション
説明
インジェクションはセキュリティ上の脆弱性であり、攻撃者はユーザーが入力したデータを操作することで、バックエンドの SQL 文を変更することができます。
インジェクションは、ユーザーの入力がコマンドやクエリの一部としてインタープリターに送られ、インタープリターを騙して意図しないコマンドを実行させたり、許可されていないデータにアクセスさせたりすることで発生します。
Webアプリケーションで実行されるSQLコマンドは、バックエンドのデータベースを公開することにもなります。
Implication
- 攻撃者は脆弱なフィールドに悪意のあるコンテンツを注入することができます。
- ユーザー名やパスワードなどの機密データをデータベースから読み取ることができます。
- データベース上で管理操作が実行できる。
脆弱性のあるオブジェクト
- 入力フィールド
- データベースと対話する URL。
例。
- ログイン ページでの SQL インジェクション
有効な認証情報を持たないアプリケーションにログインします。
有効なuserNameはありますが、passwordはありません。
テスト用のURLです。 http://demo.testfire.net/default.aspx
ユーザー名: sjones
パスワード: 1=1’またはpass123
SQLクエリが作成され、以下のようにインタプリタに送信されました。
SELECT * FROM Users WHERE User_Name = sjones AND Password = 1=1’またはpass123;
推奨事項
- 入力フィールドをホワイトリスト化する
- 攻撃者にとって有益な詳細なエラーメッセージを表示しないようにする。
Cross Site Scripting
説明
Cross Site Scriptingは、正確にはXSSとして知られています。
XSS の脆弱性は、ページに埋め込まれたスクリプトが、サーバー側ではなく、クライアント側 (ユーザーのブラウザ) で実行されることを狙ったものです。 これらの欠陥は、アプリケーションが信頼できないデータを受け取り、適切な検証を行わずにWebブラウザに送信したときに発生します。
攻撃者はXSSを利用して、ユーザー（ここでは被害者のブラウザ）に対して悪意のあるスクリプトを実行することができます。 ブラウザはスクリプトが信頼できるものかどうかを知ることができないため、スクリプトが実行され、攻撃者はセッション クッキーを乗っ取ったり、ウェブサイトを改ざんしたり、ユーザーを不要な悪意のあるウェブサイトにリダイレクトしたりすることができます。
XSSは、攻撃者が被害者のブラウザ上でスクリプトを実行することができる攻撃です。
インプリメンテーションです。
- このセキュリティの脆弱性を利用して、攻撃者はアプリケーションにスクリプトを注入したり、セッション Cookie を盗んだり、ウェブサイトを改ざんしたり、被害者のマシン上でマルウェアを実行したりすることができます。
脆弱性のあるオブジェクト
- 入力フィールド
- URL
例
1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script>
上記のスクリプトをブラウザで実行すると、そのサイトがXSSに対して脆弱である場合、メッセージボックスが表示されます。
より深刻な攻撃は、セッションクッキーを表示または保存しようとする場合に行われます。 http://demo.testfire.net/search.aspx?txtSearch<iframe><src = http://google.com。 width = 500 height 500></iframe>
上記のスクリプトを実行すると。 ブラウザは、http://google.comを指す不可視のフレームをロードします。
この攻撃は、ブラウザ上で悪意のあるスクリプトを実行することで深刻化します。
Recommendations
- 入力フィールドのホワイトリスト化
- 入力出力のエンコーディング
認証およびセッション管理の破損
Description
Webサイトは通常、有効なセッションごとにセッションクッキーとセッションIDを作成します。 これらのクッキーには、ユーザー名やパスワードなどの機密データが含まれています。 ログアウトやブラウザの突然の終了によってセッションが終了すると、これらのクッキーは無効になるはずです。
クッキーが無効化されないと、機密データはシステム内に存在することになります。 例えば、ユーザーが公共のコンピューター(サイバーカフェ)を使用すると、脆弱なサイトのクッキーがシステム上に存在し、攻撃者にさらされます。 攻撃者がしばらくして同じ公共のコンピューターを使用すると、機密データが漏洩します。
同じように、公共のコンピューターを使用しているユーザーは、ログオフする代わりに、突然ブラウザを閉じます。 攻撃者が同じシステムを使い、同じ脆弱なサイトを閲覧すると、被害者の以前のセッションが開かれます。 攻撃者は、プロファイル情報やクレジットカード情報など、やりたいことが何でもできてしまいます。
認証とセッション管理の強さを確認するために、チェックを行う必要があります。 キー、セッショントークン、クッキーは、パスワードを損なうことなく適切に実装されるべきです。
脆弱なオブジェクト
- URL上で公開されているセッションIDは、セッション固定化攻撃につながる可能性があります。
- アプリケーションは新しいセッションごとに同じセッション ID を割り当てている。
- アプリケーションの認証された部分は SSL を使用して保護されており、パスワードはハッシュ化または暗号化された形式で保存されている。
- セッションは低い権限のユーザーによって再利用されることがある。
implication
- この脆弱性を利用して、攻撃者はセッションをハイジャックし、システムへの不正なアクセスを得て、不正な情報の開示や変更を可能にします。
例
- 航空会社の予約アプリケーションは、URLの書き換えをサポートしており、セッションIDをURLに入れることができます:
http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (モルディブ行きのチケットの販売)
サイトの認証されたユーザーが、この販売を友人に知らせたいと思い、メールを送信します。 友人はセッションIDを受け取り、不正な変更や保存されたクレジットカード情報の悪用に利用されます。
- アプリケーションには XSS の脆弱性があり、攻撃者はセッション ID にアクセスしてセッションを乗っ取ることができます。
- アプリケーションのタイムアウトが適切に設定されていません。 ユーザーが公共のコンピューターを使用し、ログオフせずにブラウザを閉じて立ち去る。
Recommendations
- すべての認証およびセッション管理の要件は、OWASP Application Security Verification Standardに従って定義されるべきです。
- セッション ID を盗むために使用できる XSS の欠陥を避けるためにも、強い努力が必要です。
Insecure Direct Object References
説明
開発者が、ファイル、ディレクトリ、データベース キーなどの内部実装オブジェクトへの参照を、URL や FORM のパラメーターとして公開した場合に発生します。 攻撃者はこの情報を使って他のオブジェクトにアクセスしたり、将来的に不正なデータにアクセスするための攻撃を行うことができます。
Implication
- この脆弱性を利用すると、攻撃者は許可されていない内部オブジェクトにアクセスし、データを変更したり、アプリケーションを危険にさらすことができます。
脆弱なオブジェクト
- URLの中
例を挙げます。
以下のURLで「userid」を変更すると、攻撃者が他のユーザーの情報を閲覧できるようになります。
http://www.vulnerablesite.com/userid=123http://www.vulnerablesite.com/userid=124
攻撃者はuseridの値を変更することで、他のユーザーの情報を閲覧することができます。
お勧めします。
- アクセスコントロールチェックを実装する
- URLでオブジェクトの参照を公開しない
- すべての参照オブジェクトに対する権限を検証する
Cross Site Request Forgery
Description
Cross Site Request Forgeryとは、クロスサイトからの偽造されたリクエストのことです。
CSRF 攻撃とは、悪意のある Web サイト、電子メール、またはプログラムが、ユーザーのブラウザに、ユーザーが現在認証されている信頼できるサイト上で、望ましくない動作を実行させることで発生する攻撃です。
CSRF攻撃は、ログオンしている被害者のブラウザに、被害者のセッション・クッキーやその他の自動的に含まれる認証情報を含む、偽造されたHTTPリクエストを脆弱なウェブ・アプリケーションに送信させます。
元のWebサイトにログインしたユーザーがそのURLをクリックすると、攻撃者から被害者にリンクが送られ、Webサイトからデータが盗まれます。
Implication
- この脆弱性を利用して、攻撃者はユーザーのプロファイル情報を変更したり、ステータスを変更したり、管理者の代わりに新しいユーザーを作成したりすることができます。
脆弱性のあるオブジェクト
- ユーザー プロファイル ページ
- ユーザー アカウント フォーム
- ビジネス トランザクション ページ
例
被害者は有効な認証情報を使用して銀行のウェブサイトにログインしています。 彼は、”Please click here to donate $1 to the cause. “というメールを攻撃者から受け取りました。
被害者がこのメールをクリックすると、特定の口座に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ドルを攻撃者に送金します。
推奨事項
- 機密性の高い操作を行う際には、ユーザーの立会いを義務付ける。
- 再認証やユニーク リクエスト トークンなどのメカニズムを導入する。
セキュリティの誤設定
説明
セキュリティの設定は、アプリケーション、フレームワーク、アプリケーションサーバー、ウェブサーバー、データベースサーバー、プラットフォームに対して定義され、展開されなければなりません。 これらが適切に設定されていれば、攻撃者は機密データや機能に不正にアクセスすることができます。
そのような欠陥により、システムが完全に危険にさらされることもあります。 ソフトウェアを常に最新の状態にしておくことも良いセキュリティになります。
Implication
- この脆弱性を利用することで、攻撃者は基盤となる技術やアプリケーションサーバーのバージョン情報、データベース情報を列挙し、アプリケーションに関する情報を得て、さらにいくつかの攻撃を行うことができます。
脆弱性のあるオブジェクト
- URL
- フォームフィールド
- 入力フィールド
例
- アプリケーションサーバーの管理コンソールは自動的にインストールされ、削除されません。 デフォルトのアカウントは変更されません。 攻撃者はデフォルトのパスワードでログインすることができ、不正なアクセスが可能になります。
- Directory Listingがサーバー上で無効になっていません。
Recommendations
- コンポーネント間の良好な分離とセキュリティを提供する強力なアプリケーション アーキテクチャ
- デフォルトのユーザー名とパスワードの変更。
- ディレクトリリストを無効にし、アクセスコントロールチェックを実装する。
Insecure Cryptographic Storage
説明
Insecure Cryptographic Storageは、機密データが安全に保存されていない場合に存在する一般的な脆弱性です。
ユーザーの認証情報、プロフィール情報、健康情報、クレジットカード情報などは、ウェブサイト上のセンシティブなデータ情報に該当します。
これらのデータは、アプリケーションのデータベースに保存されます。
これらのデータはアプリケーションのデータベースに保存されますが、暗号化やハッシュ化*を行わずに不適切に保存されると、攻撃者の攻撃を受けやすくなります。
（※ハッシュ化とは、文字列を一定の長さの短い文字列や鍵に変換することです。
Implication
- この脆弱性を利用することで、攻撃者はこのような保護の弱いデータを盗み、変更して、個人情報の窃盗やクレジットカードの不正使用などの犯罪を行うことができます。
脆弱性のあるオブジェクト
- アプリケーションのデータベース
事例
ある銀行アプリケーションでは、パスワードデータベースが全員のパスワードを保存するために無塩ハッシュ * を使用しています。 SQLインジェクションの欠陥により、攻撃者はパスワードファイルを取得することができます。 塩漬けされていないハッシュはすぐにブルートフォースできますが、塩漬けされたパスワードは何千年もかかってしまいます。
(*Unsalted Hashes – Saltは、元のデータに付加されたランダムなデータです。
推奨事項
- 適切で強力な標準アルゴリズムを確保すること。 独自の暗号アルゴリズムを作らないこと。
URL アクセス制限の失敗
説明
Web アプリケーションは、保護されたリンクやボタンを表示する前に URL のアクセス権をチェックします。 アプリケーションは、これらのページがアクセスされるたびに、同様のアクセス制御チェックを行う必要があります。
ほとんどのアプリケーションでは、特権的なページ、場所、およびリソースは、特権的なユーザーには表示されません。
インテリジェントな推測によって、攻撃者は特権ページにアクセスすることができます。 攻撃者は特権ページにアクセスし、関数を呼び出し、機密情報を閲覧することができます。
Implication
- この脆弱性を利用すると、攻撃者はアプリケーションにログインすることなく、不正なURLにアクセスし、脆弱性を悪用することができます。 攻撃者は、機密性の高いページにアクセスしたり、関数を呼び出したり、機密情報を閲覧したりすることができます。
脆弱性のあるオブジェクト。
- URL
例
- 攻撃者は、URL が「/user/getaccounts」という役割を示していることに気付きます。
- 攻撃者は URL にロールを追加することができます。
http://www.vulnerablsite.comhttp://www.vulnerablesite.com/admin
Recommendations
- 強力なアクセスコントロールチェックを導入します。
- 認証と認可のポリシーはロールベースであるべきです。
- 不要なURLへのアクセスを制限します。
Insufficient Transport Layer Protection
説明
ユーザー（クライアント）とサーバー（アプリケーション）間の情報交換を扱います。 アプリケーションは、認証情報、クレジットカード情報、セッショントークンなどの機密情報をネットワーク上で頻繁に送信します。
脆弱なアルゴリズムを使用したり、期限切れの証明書や無効な証明書を使用したり、SSLを使用しなかったりすると、信頼できないユーザーに通信が公開されてしまい、Webアプリケーションが危険にさらされたり、機密情報が盗まれたりする可能性があります。
Implication
- このWebセキュリティの脆弱性を利用して、攻撃者は正当なユーザーの認証情報を盗み、アプリケーションへのアクセスを得ることができます。
脆弱なオブジェクト
- ネットワーク上で送信されるデータ。
Recommendations
- セキュアなHTTPを有効にし、HTTPSのみでのクレデンシャル転送を強制する。
- 証明書が有効であり、期限切れでないことを確認する。
例。
1. SSLを使用していないアプリケーションでは、攻撃者は単にネットワーク・トラフィックを監視し、認証された犠牲者のセッション・クッキーを観察します。 攻撃者はそのクッキーを盗み、マンインザミドル攻撃を行うことができます。
無効なリダイレクトとフォワード
説明
Webアプリケーションは、意図した目的のためにユーザーを他のページにリダイレクトしたりフォワードしたりするために、いくつかの方法を使用しています。
他のページにリダイレクトする際に適切な検証が行われていない場合、攻撃者はこれを利用して、被害者をフィッシングやマルウェアのサイトにリダイレクトしたり、フォワードを使って不正なページにアクセスしたりすることができます。
Implication
- 攻撃者は、正規のURLにエンコードされた悪意のあるURLを付加したURLをユーザーに送信することができます。
例
1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com
Modified to
http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com
Recommendations
- アプリケーションでリダイレクトやフォワードを使用しないようにするだけです。
この記事はPrasanthi Eatiが寄稿しています。