知っておくべき22の一般的なWebアプリケーションの脆弱性
公開: 2021-10-14企業は常に「左にシフト」しており、クラウド駆動型アプリケーションによって提供される革新的な顧客と従業員のエクスペリエンスを活用しています。 同時に、悪意のある加害者も、この変化に合わせて攻撃戦略を継続的に改訂しています。
データのプライバシーとセキュリティを維持するには、企業がこれらの22の一般的なWebアプリケーションの脆弱性に対する保護を求めることが不可欠です。
破損したアクセス制御
アクセス制御は、ユーザーがリソースやデータを操作する方法、およびユーザーが編集および/または読み取ることができるものに責任があります。 ユーザーが本当に不必要な方法でデータを利用できる場合、誤ったアクセス制御の脆弱性が発生する可能性があります。 たとえば、ユーザーが支払いの詳細を読み取ることしかできないが、実際にはそれらを編集することができる場合、そのような状況はアクセス制御が壊れていることを示しています。 悪意のある攻撃者はこの脆弱性を利用して、ソフトウェア、ネットワーク、およびシステムへの不正アクセスを取得します。 次に、状況を悪用し、ユーザーIDにインフラストラクチャ内でのより多くのアクセスを許可して、データの可用性、機密性、または整合性を危険にさらす可能性があります。
破損した認証
認証の破損または破損に関連するWebアプリケーションの脆弱性も、ユーザーアクセスに起因します。 ただし、この場合、悪意のある攻撃者は、セッショントークン、キー、またはパスワードの乗っ取りなどを通じて、ユーザーのIDを確認するデータに悪影響を及ぼします。 悪意のある攻撃者は、組織が適切なIDおよびアクセス管理制御を適切に設定できなかったため、ソフトウェア、システム、およびネットワークへの不正アクセスを取得します。
キャリッジリターンおよびラインフィード（CRLF）インジェクション
キャリッジリターンは、コード行の先頭を示すコマンドとして機能します。通常は/ rで示されます。 一方、改行はコード行の終わりを示すコマンドであり、通常は/ nとして示されます。 他のいくつかのソフトウェアと同様に、各オペレーティングシステムは、キャリッジリターンとラインフィードのさまざまな組み合わせを利用します。 悪意のある攻撃者がCRLFインジェクションに関与している場合、入力されたコードはWebアプリケーションがコマンドに反応する方法を変更します。 これは、機密データを開示したり、コードを実行したりするために使用できます。
安全でない暗号変換
「暗号化アルゴリズム」の標準用語である暗号は、実際には暗号化または復号化プロセスの背後にある数学です。 変換とは、期待される出力を提供するために入力に対して実行される操作の概要を指します。 したがって、暗号変換とは、読み取り不可能な暗号化データを読み取り可能で復号化されたデータに戻す操作の数を指します。 暗号変換の安全でない脆弱性は、暗号化アルゴリズムが簡単に破られ、最終的には最初に暗号化の本質を妨害する可能性があることを示しています。
明らかな脆弱性を持つコンポーネント
すべてのWebアプリケーションは、機能するために他のコンポーネントに依存しています。 たとえば、パッチが適用されていないWebサーバーまたはアプリケーションサーバーでアプリケーションを操作している場合、サーバーは明らかな脆弱性を備えた部分です。 Common Vulnerabilities and Exposures（CVE）リストには、すべての既知のセキュリティ脆弱性が含まれています。 悪意のある攻撃者はリストを知っているため、適切なセキュリティパッチの更新がないコンポーネントを頻繁に探します。 Webアプリケーションの1つのコンポーネントに侵入できるようになるとすぐに、アプリケーションのデータにもアクセスできるようになります。
クロスオリジンリソースシェアリング（CORS）ポリシー
すべてのWebベースのアプリケーションは、ユーザーのブラウザーをサーバーに接続するための媒体としてURLを使用します。 同一生成元ポリシーは、一般的な保護の1つです。 これに沿って、サーバーは同じプロトコル、パススキーマ、およびトップレベルドメイン名を持つURLにのみ応答します。 これは、http：//organization.com/page1とhttp://organization.com/page2の両方が以下を共有しているため、これらにアクセスできることを意味します。
- プロトコル：HTTP
- ドメイン：Company.com
- パススキーマ：/ page＃
安全ですが、サードパーティまたはサブドメインに接続するリソースへのアクセスを必要とするWebベースのアプリを処理する場合、同一生成元ポリシーは制限されます。
CORSポリシーは、「信頼できる」と見なされる許可されたHTTPヘッダーの数を確立することにより、これらの相互に関連するリソースを表示する許可をブラウザーに付与します。 たとえば、アプリケーションは、別々のWebサーバー上の2つのデータベースからデータを取得する必要がある場合があります。 追加のサーバーを含めると、特定の「許可された」リストを作成するのは過度の作業になります。 両方のサーバーがアプリケーションを「共有」しているため、会社はブラウザーが両方に接続できるようにするCORSポリシーを作成します。 ただし、CORSポリシーが適切に定義されていない場合、悪意のある攻撃者から要求されたときに、ポリシーによってサーバーがアクセスを許可される可能性があります。
クレデンシャル管理
ユーザー資格情報は、ユーザーIDとパスキーで構成されます。 ユーザーは、アプリケーションにアクセスする前に、両方の情報をログインページに入力する必要があります。 ただし、データベースは弱い暗号化を使用したり、情報をプレーンテキストで保持したりする傾向があります。 不十分な資格情報管理により、攻撃者は資格情報を簡単に盗み、それらを悪用してWebアプリケーションへのアクセスを取得できます。
クロスサイトリクエストフォージェリ（CSRF）
CSRF攻撃は、ソーシャルエンジニアリング手法を使用して、ユーザーがアプリケーション内のパスワードやユーザー名などの情報を変更するように誘導します。 CSRFは、クロスサイトスクリプティング（XXS）攻撃やマルウェアとは異なり、ユーザーの要求を検証したりセッションを追跡したりするためにセッションCookieのみを使用するアプリケーションにユーザーがログインしている必要があります。 ユーザーが予想されるアクションを実行した瞬間、悪意のあるアクターはブラウザーを使用して、ユーザーが何が起こったのかを知らずに、資金の移動など、攻撃の残りの部分を実行します。
クロスサイトスクリプティング（XXS）
ユーザーがアプリにログインして特定の情報を変更するようにだまされる必要があるCSRFとは異なり、XXS攻撃では、悪意のある攻撃者がWebページ（通常は画像などのページの一部のコンポーネント）にコードを入力する必要があります。 ユーザーがブラウザでWebページを起動すると、不正なコードがダウンロードされ、ブラウザで実行され始めます。 たとえば、悪意のあるコードは、ユーザーを信頼できるサイトから不正なサイトにリダイレクトする可能性があります。
ディレクトリのインデックス作成
通常、Webサーバーは、単一のディレクトリに保存されているすべてのファイルの概要を示します。 ユーザーがWebアプリケーションで特定のファイルを見つけたい場合、通常はリクエストにファイル名を追加します。 ファイルが利用できない場合、アプリケーションはすべてのインデックス付きファイルのリストをユーザーに提示するため、ユーザーは他のファイルを選択することができます。
ただし、ファイルはWebサーバーによって自動的にインデックスが作成されます。 アプリケーションが保存されているすべてのファイルのリストを表示すると、悪意のある攻撃者がディレクトリインデックスの脆弱性を利用して、システムに関する詳細情報を提供できるデータへのアクセスを取得する可能性があります。 たとえば、個人のユーザーアカウントや命名規則について知ることができます。 これらの2つのデータポイントは、資格情報の盗難攻撃を実行したり、機密情報を解明したりするために悪用される可能性があります。
ディレクトリトラバーサル
バックトラッキング攻撃、ドットドットスラッシュ、ディレクトリクライミングとも呼ばれるディレクトリトラバーサルの脆弱性は、アプリケーションがWebサーバーからデータを受信する方法を悪用します。 アクセス制御リスト（ACL）は通常、ルートディレクトリ内の特定のファイルへのユーザーアクセスを制限します。 ディレクトリトラバーサル脆弱性モードを使用する悪意のある攻撃者は、アプリケーションがファイルを要求する際に使用するURL形式を把握します。
カプセル化
リストにある他の一般的なWebアプリケーションの脆弱性とは異なり、カプセル化の脆弱性は、開発者がアプリケーションをコーディングする方法の欠陥を利用します。 カプセル化とは、データとそのデータに対して実行できるアクションを1つのユニットにバンドルすることを指すプログラミング用語です。 カプセル化は、コードの実行方法に関する情報を隠すことでデータを保護し、より優れたユーザーインターフェイスを提供します。 ユーザーは、アプリケーションがどのようにデータをユーザーに配信するかを知る必要はありません。 彼らが必要とするのはそれにアクセスすることだけです。
たとえば、アプリ開発者は、データを取得するアプリケーションの機能に、読み取りまたは書き込み権限などのアクセス制御を含めることができます。 ユーザーがアプリで情報を要求すると、アクセスが許可されたデータのみが配信されます。
ただし、開発者がデータとアプリケーションのさまざまな側面で実行されるアクションの間に明確に定義された境界を設定できない場合、アプリケーションにはカプセル化の脆弱性があります。 攻撃者は、このようなアクションがエラーメッセージにつながることを知って、アプリケーションにリクエストを送信することでこれを利用します。 このエラーメッセージは、アプリケーションの構造に関する情報を提供し、DOS（サービス拒否）などのより多くの攻撃戦略を支援します。
安全でない直接オブジェクト参照（IDOR）
WebアプリケーションのURLは、ユーザーをバックエンドの保存場所に誘導する際に使用されるパターンまたは形式を公開することができます。 たとえば、URLには、ファイルシステムやデータベースなどのストレージシステムのレコード識別子のパターン/形式が表示される場合があります。
IDORだけでもリスクの低い懸念事項である可能性があります。 ただし、IDORが失敗したアクセス制御チェックと組み合わされると、攻撃者は攻撃に成功するチャンスがあります。
知っておくべきその他の一般的なWebアプリケーションの脆弱性は次のとおりです。
HTTP応答分割
これは一種のCRLFインジェクション攻撃です。 HTTPは、ブラウザがクエリを送信し、サーバーが応答を送り返すプロセスです。 このWebアプリケーションの脆弱性では、悪意のある攻撃者がCRとLRの表記を利用して、ブラウザとサーバーが相互に通信する方法を操作し、要求を配信しますが、サーバーに応答をさまざまな部分に「分割」するように指示します。 応答を2つの異なる部分に分割すると、悪意のある攻撃者は、要求の他の部分に応答してサーバーが配信する情報を制御できるようになります。 そのような要求されたデータがユーザーIDデータまたは機密情報である場合、悪意のある攻撃者は攻撃を正常に実行しました。
注入の欠陥
インジェクションの欠陥により、さまざまな攻撃手法が可能になります。 ユーザーがシェルコマンド、オペレーティングシステムの呼び出し、またはデータベースを更新できるようにするアプリケーションは、インジェクションの欠陥が発生する可能性があります。 悪意のある攻撃者は、インジェクションの欠陥を利用して、アプリケーション内で新しい予期しないアクションに発展するコマンドを変更します。 これらの脆弱性を利用することにより、悪意のある攻撃者はデータを作成、更新、読み取り、さらには削除することができます。
安全でないメッセージダイジェストの脆弱性
これは暗号化の脆弱性であり、暗号化の有効性を制限します。 メッセージダイジェストは、暗号化ハッシュ関数を含む必要があります。 暗号化とは対照的に、ハッシュ関数では送信者とユーザーがキーを使用する必要はありません。
したがって、悪意のある攻撃者は、安全でないダイジェストの脆弱性を利用して、「ハッシュ衝突攻撃」を永続化します。 攻撃の目的は、入力の送信が重複ハッシュの生成につながるかどうかを確認することです。 悪意のあるアクションが共有ハッシュを強制的に生成する場合、彼らはこのハッシュを使用して、ダウンロード用の悪意のあるファイルを提示する可能性があります。 これにより、エンドユーザーはファイルが正当であると想定することになります。
不十分なトランスポート層保護
トランスポート層セキュリティ（TLS）とは、コンピューターアプリケーションがインターネット上で相互に安全に「通信」できるプロセスを指します。 多くのアプリケーションは、認証プロセス中にのみTLSを利用するため、ユーザーがアプリケーションを使用するときにデータとIDセッション情報が脆弱になります。
攻撃者はこの脆弱性を利用して、ユーザーのデバイスとアプリケーションサーバーの間でデータがインターネット上を移動するときにデータを迂回させることができます。
リモートコード実行（RCE）
リモートコード実行の脆弱性は、悪意のある攻撃者が地理的な場所に関係なくコードを挿入できるようにするWebアプリケーションのコーディングエラーです。 RCEは、攻撃者がユーザー入力を確認しない独自のコードをアプリケーションに入力し、サーバーにそれを本物のアプリケーションコードと見なさせる、Webアプリケーションインジェクションの脆弱性のより広いカテゴリに分類されます。 通常、悪意のある攻撃者は、パッチが適用されていない一般的に知られている脆弱性を利用して、アプリケーションにコードを挿入します。
リモートファイルインクルード（RFI）
共通ディレクトリをアプリケーションにリンクするために、開発者はコードに「include」ステートメントを追加します。 たとえば、アプリケーションはデータベースからデータを取得する必要がある場合があります。 「include」ステートメントは、各ファイルを取得するために手動でコーディングするのではなく、ソースディレクトリ全体をリンクして、そこに保存されているすべてのものを使用できるようにするのに役立ちます。
WebアプリケーションにRFIの脆弱性が存在する場合、攻撃者はアプリケーションを操作して、悪意のあるコードやマルウェアをデータベース、サーバー、またはWebサイトにアップロードできます。
セキュリティの設定ミス
セキュリティの設定ミスの可能性は、実際、今日最も一般的なWebアプリケーションの脆弱性の1つです。 この脆弱性は通常、組織がデフォルトのセキュリティ設定を変更できなかったために発生します。 一般的なセキュリティの設定ミスは次のとおりです。
- デフォルトのパスワードまたはアカウントを利用する
- パッチが適用されていないソフトウェア
- 暗号化なし
- 不十分なファイアウォールポリシー
- 未使用のリソース、機能、およびその他のコンポーネントを無視する
SQLインジェクション
構造化照会言語を意味するSQLは、データベースに使用されるプログラミング言語です。 これにより、リレーショナルデータベースのデータの取得と操作が可能になります。 SQLインジェクションの脆弱性は、未確認のユーザー入力のより大きなグループの下にあります。 悪意のあるアクターが故意に誤った要求を送信すると、Webアプリケーションは、データベースの構造と保護に関する情報を提供するエラーメッセージで応答します。
未検証の自動ライブラリアクティベーション
コーディングの時間を節約するために、開発者はサードパーティのライブラリを使用する傾向があります。 ほとんどの場合、これにより、アプリケーション開発プロセスを加速する事前テスト済みのコードを利用できるようになります。 ただし、公開されているオープンソースコードを利用すると、次のようなセキュリティリスクが高まります。
- 文書化された所有権がないため、悪意のあるコードが追加されるリスクが高まります
- もう更新されていない無視されたプロジェクト
いくつかのアプリケーションがサードパーティのライブラリに依存していることを考えると、この特定の脆弱性はますます蔓延しています。
このブログ投稿の内容が本当にお役に立てて、洞察に満ちていることを願っています。 ケースに当てはまるWebアプリケーションの脆弱性に対する解決策を確実に見つけることは、従業員と顧客のエクスペリエンスを大きく変えることになります。