フロントエンド開発における一般的なセキュリティ問題の概要

よくある質問:

(学習ビデオの共有: プログラミング ビデオ)

1. クロスサイト スクリプティング攻撃 ( XSS 攻撃)

XSS (クロスサイト スクリプティング)、クロスサイト スクリプティング攻撃。 XSS は一般的な Web 攻撃技術の 1 つです。いわゆるクロスサイト スクリプティング攻撃とは、悪意のある攻撃者が Web ページに悪意のあるスクリプト コードを挿入することを指します。ユーザーがこれらの Web ページを閲覧すると、悪意のあるコードが実行され、 Cookie情報の窃取やセッションハイジャックなど様々な攻撃

#解決策:

(1) 入力フィルタリング。ユーザー入力を決して信頼せず、ユーザー入力データに対して特定のフィルタリングを実行します。たとえば、入力データが日付形式、電子メール形式、電話番号

コード形式などの予期された形式に準拠しているかどうか。これにより、XSS 脆弱性に対する予備的な防御を提供できます。上記の対策は Web 側のみを制限しますが、攻撃者は Fiddler などのパケット キャプチャ ツールを使用してフロントエンドの入力制限を回避し、攻撃スクリプトを挿入するリクエストを変更することができます。

したがって、バックエンド サーバーは、ユーザーが入力したデータを受信した後、特殊な危険な文字をフィルタリングまたはエスケープして、データベースに保存する必要があります。 (2) 出力エンコード。サーバーからブラウザに出力されるデータは、システムのセキュリティ機能を使用してエンコードまたはエスケープすることで、XSS 攻撃を防ぐことができます。 PHP には、セキュリティ要件を満たすことができる 2 つの関数 htmlentities() と htmlspecialchars() があります。対応する JavaScript エンコード方式では JavascriptEncode を使用できます。 (3) セキュリティコーディング。開発では、Web クライアント ドキュメントの書き換え、リダイレクト、またはその他の機密性の高い操作を避け、クライアント データの使用を避けるように努める必要があり、これらの操作は可能な限り動的ページを使用してサーバー側で実装する必要があります。 (4) HttpOnly Cookie。 XSS 攻撃によるユーザーの Cookie の盗用を防ぐ最も効果的な防御方法。 Web アプリケーションが Cookie を設定する場合、その属性を HttpOnly に設定することで、クライアント側の悪意のある JavaScript によって Web ページの Cookie が盗まれるのを防ぎ、ユーザーの Cookie 情報を保護します。 (5) WAF (Web Application Firewall)、Web アプリケーション ファイアウォール。その主な機能は、Web トロイの木馬、

XSS、CSRF などの一般的な Web 脆弱性攻撃を防ぐことです。サードパーティ企業によって開発され、企業環境で人気があります。

2. クロスサイト リクエスト フォージェリ (CSRF 攻撃)

CSRF (クロスサイト リクエスト フォージェリ)、つまりクロスサイト リクエスト フォージェリは一般的な Web 攻撃ですが、多くの開発者がそれに気づいていない とても不思議です。 Web サイト攻撃

CSRF 攻撃の原理: CSRF 攻撃プロセスの被害者ユーザーは、Web サイト A にログインし、個人情報を入力し、Web サイトによって生成された Cookie を保存します。ローカルにサーバーを作成します。次に、Web サイト A 上で攻撃者によって構築された悪意のあるリンクをクリックして Web サイト

にジャンプします。その後、Web サイト B はユーザーの Cookie 情報を運び、Web サイト B にアクセスします。これにより、Web サイト A がユーザー自身の訪問であるかのように見えます。

解決策:

(1) 検証コード。アプリケーションとユーザー間の対話中、特にアカウント取引などのコアステップでは、ユーザーは最終リクエストを完了するために確認コードの入力を強制されます。通常の状況では、検証コードは

CSRF 攻撃を阻止するのに十分です。ただし、確認コードを追加するとユーザー エクスペリエンスが低下し、Web サイトがすべての操作に確認コードを追加できるわけではありません。したがって、検証コードは、重要なビジネス ポイントに検証コードを設定するための補助的な手段としてのみ使用できます。 (2) リファラーチェック。

HTTP リファラーはヘッダーの一部です。ブラウザが Web サーバーにリクエストを送信すると、通常、どのページからリンクされているかをサーバーに伝えるためにリファラー情報がもたらされます。サーバーはこれを使用して情報を取得できます。

理由を処理するための情報。 CSRF 攻撃は、リクエストの送信元を確認することで防御できます。通常のリクエストのリファラーには特定のルールがあり、たとえば、フォーム送信のリファラーは、そのページで開始されたリクエストである必要があります。したがって、http ヘッダー リファラーの値

がこのページであるかどうかを確認することで、CSRF 攻撃であるかどうかを判断できます。ただし、https から http にジャンプする場合など、セキュリティ上の理由からブラウザがリファラーを送信せず、サーバーがチェックできない場合があります。この Web サイトと同じドメイン内の他の Web サイトに XSS 脆弱性がある場合、攻撃者は他の Web サイトに悪意のあるスクリプトを挿入する可能性があり、被害者が同じドメイン内のそのような URL を入力すると、被害者も攻撃を受ける可能性があります。上記の理由により、リファラー チェックは CSRF

に対する防御の主な手段として完全に信頼することはできません。ただし、CSRF 攻撃の発生はリファラー チェックを通じて監視できます。 (3) アンチ CSRF トークン。現在の比較的完全な解決策は、Anti-CSRF-Token を追加することです。つまり、リクエストの送信時に HTTP リクエストにパラメータの形式でランダムに生成されたトークンを追加し、このトークンを検証するためにサーバー上にインターセプタを確立します。サーバーは、ブラウザの現在のドメイン Cookie のトークン値を読み取り、リクエストのトークン

と Cookie のトークン値が存在し、等しいかどうかを確認して、これが正当なリクエストであると判断します。そうでない場合、リクエストは違法とみなされ、サービスは拒否されます。この方法はリファラー チェックよりもはるかに安全です。ユーザー

がログインした後にトークンを生成し、セッションまたは Cookie に配置できます。その後、サーバーはリクエストごとにセッションまたは Cookie からトークンを取り出します。このリクエストのトークンが比較されます。トークンが存在するため、攻撃者は

を構築できなくなります。

CSRF 攻撃を実装するための完全な URL を出力します。ただし、複数ページの共存問題に対処する場合、あるページがトークンを消費すると、他のページのフォームは消費したトークンを保存したままとなり、他のページのフォームを送信するとトークンエラーが発生します。

3. SQL インジェクション攻撃

SQL インジェクション (SQL インジェクション) は、アプリケーションが SQL (構造化照会言語、構造化照会言語) をバックエンド データベースに渡すときに、攻撃者がWeb フォームの送信に SQL コマンドを入力したり、ページ リクエストのドメイン名やクエリ文字列を入力したりして、最終的にはサーバーをだまして悪意のある SQL コマンドを実行させます。情報が漏洩している。 php.ini オプションの display_errors=off を設定すると、php スクリプトでエラーが発生した後に機密情報エラーが Web ページに出力され、攻撃者が悪用する機会が与えられるのを防ぎます。 (2) データエスケープ。 php.ini オプションの magic_quotes_gpc=on を設定すると、送信された変数内のすべての '(一重引用符)、"(二重引用符)、\(バックスラッシュ)、空白文字などの前に \ が自動的に追加されます。または、mysql_real_escape を使用します。 () 関数または addslashes() 関数は入力パラメータをエスケープします (3) ブラックリストまたはホワイトリスト検証を追加します。ホワイトリスト検証は通常、ユーザー入力が期待されるタイプ、長さ、値の範囲、またはその他の形式に準拠しているかどうかをチェックすることを指します。ユーザー入力に明らかな悪意のあるコンテンツが含まれている場合、ユーザー リクエストは拒否されます。ホワイトリスト検証が使用される場合、通常はブラックリスト検証が使用されます。

4. ファイル アップロードの脆弱性

アップロードの脆弱性が最も蔓延していました。 DVBBS6.0 時代にハッカーによって悪用されました。アップロードの脆弱性は、WEBSHELL を直接入手するために使用できます。危害レベルは非常に高いです。アップロードの脆弱性は、現在の侵入でも一般的な脆弱性です。この脆弱性により、ユーザーは任意のファイルをアップロードすることで許可される可能性がありますファイルアップロード脆弱性の原理: ファイルアップロード機能の実装コードは、ユーザーがアップロードするファイルのサフィックスやファイルタイプを厳密に制限していないため、攻撃者は任意のファイルをアップロードすることで、 PHP ファイルを Web アクセス可能なディレクトリに保存し、これらのファイルを PHP インタープリタに渡すことができるため、リモート サーバー上で任意の PHP スクリプトを実行できます。サーバーはアップロードされたファイルのタイプとサフィックスを決定しています (2) アップロードされたファイル タイプのホワイトリストを定義します。つまり、ホワイトリスト内のファイル タイプのみがアップロードを許可されます (3) ファイル アップロード ディレクトリではスクリプトが禁止されています攻撃者を回避するための解析 二次攻撃 情報脆弱性 情報脆弱性は、CGI が入力パラメータをそのままページに出力し、攻撃者は入力パラメータを改変することでユーザーを騙す目的を達成します。はじめに:

ウェブサイトのセキュリティ

以上がフロントエンド開発における一般的なセキュリティ問題の概要の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。