信頼できる CA (認証局) が何百も存在し、Web サイトの ID 認証プロセス全体において大きな攻撃対象となっていることがわかっています。既存の証明書信頼チェーン メカニズムの最大の問題は、すべての CA が信頼できるということです。あらゆる Web サイトのサイト証明書を発行し、これらの証明書はブラウザーの目には合法です。
HPKP テクノロジーは、CA を信頼することを積極的に選択する権利を与えます。その動作原理は、応答ヘッダーまたは <meta> タグを通じて現在の Web サイトの証明書フィンガープリントをブラウザーに伝えることです。有効期限が切れると、ブラウザは再度この Web サイトにアクセスする際に、証明書チェーン内の証明書フィンガープリントを検証する必要があります。証明書自体が正当であっても、接続を切断する必要があります。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
xss攻撃方法XSS(クロスサイト スクリプト) 攻撃は、クロスサイト スクリプティング攻撃とも呼ばれ、本質的には、さまざまな手段を使用して悪意のあるコードを Web ページに追加し、被害者にスクリプトを実行させることです。 。
攻撃方法により大きく分けて- 反射タイプ
- ストレージタイプ
- ドキュメントタイプ
この分類方法はやや時代遅れですが、XSS 分類には 3 つのタイプがあると考えられてきましたが、実際には区別できないことが多いため、より明確な分類方法は次の 2 つのカテゴリに分類されます。 :- client(クライアントタイプ)
- server(サーバータイプ)
一方の XSS コードがサーバー側に挿入される場合、これはサーバー側 XSS であり、同様に、コードがクライアント側に挿入される場合、それはクライアント側 XSS です。xss 攻撃を防ぐ
逃げる
サーバー側 XSS であってもクライアント側 XSS であっても、攻撃を達成するには 2 つの条件が必要です
コードが挿入されます
-
実際、どのような状況でもコードが実行されないように適切に対処する限り、xss 攻撃を完全に排除することができます。
つまり、信頼できないデータはいかなる場合でも DOM 内のいかなる場所にも直接挿入せず、必ずエスケープしてください。
一部の場所では、信頼できないデータをエスケープすることでセキュリティを確保できます一般的なタグ属性値
-
一部のポジションでは、たとえ逃げられても安全ではありませんスクリプトタグ
-
eval の代わりに JSON.parse を使用します。リクエストのコンテンツ タイプは Content-Type: application/json; として指定する必要があります。
リンクされた URL の一部が動的に生成される場合は、エスケープする必要があります。
ブラウザに付属のxssフィルターを使用してください
httpヘッダーを通じてxss-filterを開くかどうかを制御できます。デフォルトはオープンです。xss-filter を無効にする必要がある場合は、を 0 に設定します。
上で述べたように、最新のブラウザは、反射ドア: XSS テスト ページに対してある程度の防御機能を備えています。
さらに、ブラウザは保存されたデータに耐性がありませんX-XSS-Protectionコンテンツセキュリティポリシー
コンテンツ セキュリティ ポリシー、つまり csp と呼ばれるコンテンツ セキュリティ ポリシー
潜在的なクロスサイト スクリプティングの問題の大部分を軽減するために、ブラウザ拡張システムには CSP が導入されており、CSP は Web サイトがロードできるコンテンツを管理し、ホワイトリスト メカニズムを使用して、Web サイトによってロードまたは実行されるリソースに作用します。 Web ページでは、このようなポリシーは HTTP ヘッダー情報またはメタ要素を通じて定義されます。
CSP は XSS 攻撃を防ぐために使用されるのではなく、XSS による被害を最小限に抑えるために使用されます。実際には、開発者自身が XSS を回避する以外に、CSP の発生を防ぐ最も手頃な方法はありません。 HTML5 が Web セキュリティにもたらすもの では、CSP を導入するにはどうすればよいでしょうか?
応答ヘッダー経由
HTMLのMETAタグ経由
では、script-src を制限する以外に、CSP は他に何を制限できるのでしょうか?
CSP は、使用できるほぼすべてのリソースのソースを制限できる強力な戦略であることがわかります。CSP をうまく使用すると、XSS によって引き起こされるリスクを大幅に軽減できます。
さらに、CSP にはレポート ヘッダー フィールドも用意されていますこのヘッダー フィールドを使用して、ブラウザは CSP ステータスをサーバーにレポートします。 リーリー
リーリーContent-Security-Policy-Report-Only上記の設定を使用すると、ページにインライン js がある場合でも実行されますが、ブラウザーは次の情報を含む投稿リクエストを送信します。CSP には現在、CSP1 と CSP2 の 2 つのバージョンがあります。これら 2 つのバージョンのサポート状況は、http://caniuse.com/#search=csp で確認できます。
CSP1のサポート
Xフレームオプション
X-Frame-Options 応答ヘッダーは、
frame,iframe或者objectなどのタグでページを表示できるかどうかをブラウザーに示すために使用されるタグです。Web サイトはこの機能を使用して、自分の Web サイトのコンテンツが他の人の Web サイトに埋め込まれないようにすることができます。これにより、クリックジャッキング攻撃も回避されますが、将来的には CSP フレーム祖先によって置き換えられる可能性があります。現在のサポート状態は、CSP フレーム祖先よりも優れています。X-Frame-Options には 3 つの値があります:
DENY は、このページをフレームにロードすることが許可されていないことを意味します
SAMEORIGIN は、このページが同じソースからのページによってのみロードできることを意味します
ALLOW-FROM uri は、このページが特定のドメインによってのみロードできることを示します
サーバー構成
Javaコード:
リーリーNginx 構成:
リーリーApache 構成:
リーリーブラウザの互換性
HTTP のみ
http-only を使用した後は、js による Cookie の読み書きを禁止できるため、xss が発生した場合でもユーザーの Cookie は安全です。
iframeサンドボックス環境
HTML5 は iframe にセキュリティ属性サンドボックスを提供するため、iframe の機能が次のように制限されます。 リーリー
その他のセキュリティ関連の HTTP ヘッダー
X-コンテンツタイプ-オプション
X-Content-Type-Options は、ブラウザによるコンテンツ タイプ スニッフィングを防止し、タイプ スニッフィング攻撃を防ぐことができます。
このヘッダーは主に、IE9、Chrome、Safari での MIME タイプ混同攻撃を防ぐために使用されます。通常、ブラウザーは、応答内のコンテンツ タイプの値を調べるのではなく、コンテンツ自体をスニッフィングすることで、そのタイプを判断できます。 -Content-Type-Options: content-type が予期されるタイプと一致する場合、スニッフィングは必要なく、特定のタイプのリソースのみを外部からロードできます。たとえば、スタイルシートがロードされる場合、MIME タイプをロードできます。 IE のスクリプト リソースの場合は、次のコンテンツ タイプが有効です:リーリー
Chrome の場合、次の MIME タイプがサポートされています:リーリー
正しい設定 リーリー
設定が間違っていることが多いリーリー
検出方法
IE と chrome で開発者ツールを開き、コンソールで nosniff が設定されている場合と nosniff が設定されていない場合の出力の違いを観察します。HPKP(公開鍵ピンニング)
HPKP は応答ヘッダーであり、中間者攻撃を防ぐために証明書の公開キーが変更されたかどうかを検出するために使用されます。
信頼できる CA (認証局) が何百も存在し、Web サイトの ID 認証プロセス全体において大きな攻撃対象となっていることがわかっています。既存の証明書信頼チェーン メカニズムの最大の問題は、すべての CA が信頼できるということです。あらゆる Web サイトのサイト証明書を発行し、これらの証明書はブラウザーの目には合法です。
HPKP テクノロジーは、CA を信頼することを積極的に選択する権利を与えます。その動作原理は、応答ヘッダーまたは <meta> タグを通じて現在の Web サイトの証明書フィンガープリントをブラウザーに伝えることです。有効期限が切れると、ブラウザは再度この Web サイトにアクセスする際に、証明書チェーン内の証明書フィンガープリントを検証する必要があります。証明書自体が正当であっても、接続を切断する必要があります。
公式 HPKP ドキュメントは RFC7469 にあり、現在 Firefox 35 以降および Chrome 38 以降でサポートされています。その基本形式は次のとおりです。 リーリーHSTS (HTTP 厳密トランスポートセキュリティ)
HSTS は、国際インターネット技術機関 IETE によって推進されている新しい Web セキュリティ プロトコルであり、中間者攻撃に対抗するために使用できます。これは、ブラウザーに TSL をデータ チャネルとして使用することを強制します。 HTTPS を使用してサーバーとの接続を作成します。
サーバーが HSTS をオンにする方法は、クライアントが HTTPS 経由でリクエストを行うときに、サーバーから返されるハイパーテキスト転送プロトコルの応答ヘッダーに Strict-Transport-Security フィールドが含まれることです。暗号化されていない送信中に設定された HSTS フィールドは無効です。
たとえば、https://xxx の応答ヘッダーには Strict-Transport-Security: max-age=31536000; が含まれています。これは 2 つのことを意味します。
今後 1 年間 (つまり 31536000 秒)、ブラウザは HTTP リクエストを xxx またはそのサブドメイン名に送信するたびに、HTTPS を使用して接続を開始する必要があります。たとえば、ユーザーがハイパーリンクをクリックするか http:// と入力する必要があります。アドレス バーに xxx/ を入力すると、ブラウザは http を https に自動的に変換し、リクエストを https://xxx/ に直接送信します。
来年、xxx サーバーによって送信された TLS 証明書が無効な場合、ユーザーはブラウザーの警告を無視して Web サイトにアクセスし続けることができなくなります。
欠点は、ユーザーの Web サイトへの最初のアクセスが HSTS によって保護されていないことです。これは、HSTS が初めて受信されていないためです。1 つは、ブラウザーに HSTS ドメイン名リストを設定することです。これは、Google Chrome、Firefox、Internet Explorer によって実装されます。この解決策の 2 つ目は、HSTS 情報をドメイン名システム レコードに追加することです。フロントエンド xss フィルタリング
最後に、フロントエンドの xss フィルタリング方法を提供します
リーリーより良い体験を得るために、私のブログの原文を直接読むことができます。 XSS の攻撃と防御についての簡単な説明
サーバー側の実装にはどのような言語が使用されますか? フォームのコンテンツ内の <script> に関連する文字列を置き換えることです。
-.- これはバックエンドで処理する必要があり、jsで書くとフロントエンドのhtmlspecialcharsという関数になるようです。引用符で囲むのが最善です。 jsコードの実行を阻止します。
さらに、パラメータを渡すときは、フォールトトレラントであり、デフォルト値を指定する必要があります。
xss の脆弱性は、実際にはバックエンドが挿入またはハイジャックされ、フロントエンドが悪意のあるコードを実行することです。
鍵となるのは依然としてバックエンドの問題です。フロントエンドが実行できる作業は限られています。
特にドメイン間で jsonp を使用する場合は、安易に評価しないでください。
ユーザー入力のタグをフィルタリングして調整する もちろん、このバックエンドは 2 回フィルタリングするのが最適です。
改ざんを防ぐために、要求されたデータを検証します。
https を使用できる場合は、それを使用してください。これにより、データが改ざんされないことが基本的に保証されます。
この文を覚えておいてください。セキュリティの問題はフロントエンドで決して行われるべきではありません。 ！ ！