迷茫2017-05-16 13:10:53
XSS (クロスサイト スクリプト) 攻撃は、クロスサイト スクリプティング攻撃とも呼ばれ、本質的には、さまざまな手段を使用して悪意のあるコードを Web ページに追加し、被害者にスクリプトを実行させることです。 。
xss 攻撃を防ぐ
つまり、信頼できないデータはいかなる場合でも DOM 内のいかなる場所にも直接挿入せず、必ずエスケープしてください。
一部の場所では、信頼できないデータをエスケープすることでセキュリティを確保できます
リンクされた URL の一部が動的に生成される場合は、エスケープする必要があります。
ブラウザに付属のxssフィルターを使用してください
xss-filter を無効にする必要がある場合は、通常、http ヘッダーに次のフィールドを追加することは、xss-filter を有効にすることを意味します。 リーリー
を 0 に設定します。
上で述べたように、最新のブラウザは、反射ドア: XSS テスト ページに対してある程度の防御機能を備えています。X-XSS-Protection
コンテンツセキュリティポリシー
コンテンツ セキュリティ ポリシー、つまり csp と呼ばれるコンテンツ セキュリティ ポリシー
潜在的なクロスサイト スクリプティングの問題の大部分を軽減するために、ブラウザ拡張システムには CSP が導入されており、CSP は Web サイトがロードできるコンテンツを管理し、ホワイトリスト メカニズムを使用して、Web サイトによってロードまたは実行されるリソースに作用します。 Web ページでは、このようなポリシーは HTTP ヘッダー情報またはメタ要素を通じて定義されます。
CSP は XSS 攻撃を防ぐために使用されるのではなく、XSS による被害を最小限に抑えるために使用されます。実際には、開発者自身が XSS を回避する以外に、CSP の発生を防ぐ最も手頃な方法はありません。 HTML5 が Web セキュリティにもたらすもの では、CSP を導入するにはどうすればよいでしょうか?
応答ヘッダー経由
ソースからの Content-Security-Policy のロードのみをスクリプトに許可します: script-src ‘self’
HTMLのMETAタグ経由
同上<meta http-equiv=”Content-Security-Policy” content=”script-src ‘self’”>
では、script-src を制限する以外に、CSP は他に何を制限できるのでしょうか?
base-uri: このドキュメントの URI を制限します
child-src: Frame-src を置き換えて、子ウィンドウ (iframe、ポップアップ ウィンドウなど) のソースを制限します
connect-src: スクリプトがアクセスできるソースを制限します
font-src : フォントソースを制限します
form-action: フォームを送信できるソースを制限します
frame-ancestors: 現在のページをロードできるページを iframe、frame、object などによって制限します。
frame-src: child-src で非推奨となり、現在のページがロードできるソースを制限し、frame-ancestors に対応します
img-src : 画像をロードできるソースを制限します
media-src:
からロードできるビデオ、オーディオ、ソース、トラックのソースを制限しますobject-src : プラグインをロードできるソースを制限します
サンドボックス: サンドボックスモードを強制的に開きます
CSP は、使用できるほぼすべてのリソースのソースを制限できる強力な戦略であることがわかります。CSP をうまく使用すると、XSS によって引き起こされるリスクを大幅に軽減できます。
さらに、CSP にはレポート ヘッダー フィールドも用意されています このヘッダー フィールドを使用して、ブラウザは CSP ステータスをサーバーにレポートします。
リーリー
Content-Security-Policy-Report-Only上記の設定を使用すると、ページにインライン js がある場合でも実行されますが、ブラウザーは次の情報を含む投稿リクエストを送信します。
CSP には現在、CSP1 と CSP2 の 2 つのバージョンがあります。これら 2 つのバージョンのサポート状況は、http://caniuse.com/#search=csp で確認できます。
CSP1のサポート
CSP2のサポート
CSP は強力なセキュリティ保護を提供しますが、次の問題も引き起こします: Eval および関連機能が無効になり、埋め込まれた JavaScript コードが実行されなくなり、リモート スクリプトはホワイトリストを通じてのみロードできます。
X-Frame-Options 応答ヘッダーは、frame, iframe 或者 object などのタグでページを表示できるかどうかをブラウザーに示すために使用されるタグです。Web サイトはこの機能を使用して、自分の Web サイトのコンテンツが他の人の Web サイトに埋め込まれないようにすることができます。これにより、クリックジャッキング攻撃も回避されますが、将来的には CSP フレーム祖先によって置き換えられる可能性があります。現在のサポート状態は、CSP フレーム祖先よりも優れています。
X-Frame-Options には 3 つの値があります:
DENY は、このページをフレームにロードすることが許可されていないことを意味します
SAMEORIGIN は、このページが同じソースからのページによってのみロードできることを意味します
ALLOW-FROM uri は、このページが特定のドメインによってのみロードできることを示します
サーバー構成
Javaコード:
リーリーNginx 構成:
リーリーApache 構成:
リーリーブラウザの互換性
| 特徴 | クロム | Firefox (Gecko) | Internet Explorer | オペラ | サファリ |
|---|---|---|---|---|---|
| 基本サポート | 4.1.249.1042 | 3.6.9 (1.9.2.9) | 8.0 | 10.5 | 4.0 |
| サポートからの許可 | サポートされていません | 18.0 | 8.0? | ? | サポートされていません |
http-only を使用した後は、js による Cookie の読み書きを禁止できるため、xss が発生した場合でもユーザーの Cookie は安全です。
HTML5 は iframe にセキュリティ属性サンドボックスを提供するため、iframe の機能が次のように制限されます。 リーリー
その他のセキュリティ関連の HTTP ヘッダーこのヘッダーは主に、IE9、Chrome、Safari での MIME タイプ混同攻撃を防ぐために使用されます。通常、ブラウザーは、応答内のコンテンツ タイプの値を調べるのではなく、コンテンツ自体をスニッフィングすることで、そのタイプを判断できます。 -Content-Type-Options: content-type が予期されるタイプと一致する場合、スニッフィングは必要なく、特定のタイプのリソースのみを外部からロードできます。たとえば、スタイルシートがロードされる場合、MIME タイプをロードできます。 IE のスクリプト リソースの場合は、次のコンテンツ タイプが有効です:
リーリー
Chrome の場合、次の MIME タイプがサポートされています:リーリー
正しい設定 リーリー
設定が間違っていることが多いリーリー
検出方法
IE と chrome で開発者ツールを開き、コンソールで nosniff が設定されている場合と nosniff が設定されていない場合の出力の違いを観察します。HPKP(公開鍵ピンニング)
信頼できる CA (認証局) が何百も存在し、Web サイトの ID 認証プロセス全体において大きな攻撃対象となっていることがわかっています。既存の証明書信頼チェーン メカニズムの最大の問題は、すべての CA が信頼できるということです。あらゆる Web サイトのサイト証明書を発行し、これらの証明書はブラウザーの目には合法です。
HPKP テクノロジーは、CA を信頼することを積極的に選択する権利を与えます。その動作原理は、応答ヘッダーまたは <meta> タグを通じて現在の Web サイトの証明書フィンガープリントをブラウザーに伝えることです。有効期限が切れると、ブラウザは再度この Web サイトにアクセスする際に、証明書チェーン内の証明書フィンガープリントを検証する必要があります。証明書自体が正当であっても、接続を切断する必要があります。
公式 HPKP ドキュメントは RFC7469 にあり、現在 Firefox 35 以降および Chrome 38 以降でサポートされています。その基本形式は次のとおりです。 リーリーHSTS (HTTP 厳密トランスポートセキュリティ)
HSTS は、国際インターネット技術機関 IETE によって推進されている新しい Web セキュリティ プロトコルであり、中間者攻撃に対抗するために使用できます。これは、ブラウザーに TSL をデータ チャネルとして使用することを強制します。 HTTPS を使用してサーバーとの接続を作成します。
たとえば、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 の攻撃と防御についての簡単な説明
PHP中文网2017-05-16 13:10:53
-.- これはバックエンドで処理する必要があり、jsで書くとフロントエンドのhtmlspecialcharsという関数になるようです。引用符で囲むのが最善です。 jsコードの実行を阻止します。
さらに、パラメータを渡すときは、フォールトトレラントであり、デフォルト値を指定する必要があります。
PHPz2017-05-16 13:10:53
xss の脆弱性は、実際にはバックエンドが挿入またはハイジャックされ、フロントエンドが悪意のあるコードを実行することです。
鍵となるのは依然としてバックエンドの問題です。フロントエンドが実行できる作業は限られています。
特にドメイン間で jsonp を使用する場合は、安易に評価しないでください。
ユーザー入力のタグをフィルタリングして調整する もちろん、このバックエンドは 2 回フィルタリングするのが最適です。
改ざんを防ぐために、要求されたデータを検証します。
https を使用できる場合は、それを使用してください。これにより、データが改ざんされないことが基本的に保証されます。