http-header“ X-XSS-Protection”とは何ですか?


194

だから私は今Telnetで楽しみのためにHTTPをいじくり回しています(つまりtelnet google.com 80、さまざまなヘッダーなどでランダムなGETとPOSTを入力して入力するだけです)が、google.comがヘッダーで送信するものに遭遇しました分からない。

私はhttp://www.w3.org/Protocols/rfc2616/rfc2616.htmlを調べていましたが、Googleが噴出しているように見えるこの特定のhttp-headerの定義が見つかりませんでした。

GET / HTTP/1.1

HTTP/1.1 200 OK
Date: Wed, 01 Feb 2012 03:42:24 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=6ddbc0a0342e7e63:FF=0:TM=1328067744:LM=1328067744:S=4d4farvCGl5Ww0C3; expires=Fri, 31-Jan-2014 03:42:24 GMT; path=/; domain=.google.com
Set-Cookie: NID=56=PgRwCKa8EltKnHS5clbFuhwyWsd3cPXiV1-iXzgyKsiy5RKXEKbg89gWWpjzYZjLPWTKrCWhOUhdInOlYU56LOb2W7XpC7uBnKAjMbxQSBw1UIprzw2BFK5dnaY7PRji; expires=Thu, 02-Aug-2012 03:42:24 GMT; path=/; domain=.google.com; HttpOnly
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Transfer-Encoding: chunked

1000

誰か知ってるX-XSS-Protection


6
FWIW、ヘッダーフィールドの仕様を検索するための「正しい」場所はHTTP仕様(現在はRFC 2616)ではありませんが、IANAメッセージヘッダーフィールドレジストリ(つまり、そこにはリストされていません)
Julian Reschke

1
@JulianReschke、なぜそうなのですか?HTTP仕様はHTTPに対して信頼すべきではありませんか?
Pacerier 2015年

1
HTTP仕様では、ヘッダーレジストリをIANAに委任しています。
Julian Reschke、2015

回答:


107

X-XSS-Protectionは、Internet Explorer 8(およびそれ以降のバージョン)で認識されるHTTPヘッダーです。このヘッダーを使用すると、ドメインでIE8の「XSSフィルター」のオンとオフを切り替えることができます。これにより、一部のカテゴリのXSS攻撃を防ぐことができます。IE8のフィルターはデフォルトで有効になっていますが、サーバーをオフにすると、

   X-XSS-Protection: 0

http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-headerも参照してください。 aspx


107
これは非常にあいまいです。正確にどのようにこのヘッダは、XSSを防ぐのですか?では、IEはX-XSS-Protection:1それを見て、XSSを防ぐためにどのアルゴリズムを使用するのでしょうか。
パセリエ2012

11
独自技術のため詳細はわかりにくい。基本的に、IEは、ブラウザーがWebサイトに送信した疑わしい外観のパラメーターが、デコードされた応答で返されるかどうかを監視します。たとえば、ユーザーがattack-me.com/…( "> <script> alert( 'XSS')</ script>)をクリックして、結果としてそのスクリプトを含むページを受け取った場合、IEはそれを防止します。
Luca Invernizzi

11
そのため、保存されたXSS(永続的なXSSとも呼ばれます)を検出する手段がないため、反射されたXSS(infosecisland.com/blogview/…)に対してのみ保護するように思えます(証明を見つけるのは難しい)。
Luca Invernizzi

11
うーん、IEの見栄えを良くするために、マイクロソフトがマーケティングを練り上げているように見えます...
Matej

5
まあ、それはマーケティングの綿毛で提示されていますが、コードは動作するようです。あなたはここでそれをテストすることができますenhanceie.com/test/xss/BlockMode.asp(MSDNブログ投稿にもリンクされています)。
Luca Invernizzi 2013

61
  • X-XSS-Protection: 1 :XSS保護を強制します(ユーザーがXSS保護を無効にした場合に役立ちます)

  • X-XSS-Protection: 0 :XSS保護を無効にする

  • トークンmode=blockは、潜在的なXSSリフレクション(=非永続的)攻撃が検出された場合、ブラウザー(IE8 +およびWebkitブラウザー)が(サニタイズではなく)ページをレンダリングするのを防ぎます。

/!\警告、mode=blockIE8に脆弱性を作成します(詳細)。

詳細:http : //blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspxおよびhttp://blog.veracode.com / 2014/03 / guidelines-for-setting-security-headers /


6
参考までに、IE8のバグは修正されました(CVE-2009-4074)
yakatz

developer.mozilla.org/es/docs/Web/HTTP/Headers/X-XSS-Protectionこのリンクでは、X-XSS-Protectionの説明を見つけることができます
Maria Montenegro

1
0これがこのヘッダーの唯一の安全な値であることに注意してください。詳細については、stackoverflow.com / a / 57802070/334451をご覧ください。
ミッコランタライネン、

48

この応答ヘッダーを使用して、ユーザーエージェントの組み込み反射XSS保護を構成できます。現在、MicrosoftのInternet Explorer、Google Chrome、Safari(WebKit)のみがこのヘッダーをサポートしています。

Internet Explorer 8には、XSSフィルターと呼ばれる、クロスサイトスクリプティング攻撃の反射を防止するのに役立つ新機能が含まれていました。このフィルターは、インターネット、信頼済み、および制限付きのセキュリティゾーンでデフォルトで実行されます。ローカルイントラネットゾーンページは、同じヘッダーを使用して保護をオプトインできます。

質問に投稿したヘッダーについて、

ヘッダーX-XSS-Protection: 1; mode=blockはXSSフィルターを有効にします。ページをサニタイズするのではなく、XSS攻撃が検出されると、ブラウザーはページのレンダリングを防止します。

2010年3月に、X-XSS-Protectionヘッダーの新しいトークンmode = blockのIE8サポートを追加しました。

X-XSS-Protection: 1; mode=block

このトークンが存在する場合、潜在的なXSSリフレクション攻撃が検出されると、Internet Explorerはページのレンダリングを防止します。XSS攻撃を外科的に削除するためにページをサニタイズしようとする代わりに、IEは「#」のみをレンダリングします。

Internet Explorerは、起こり得るクロスサイトスクリプティング攻撃を認識します。イベントをログに記録し、適切なメッセージをユーザーに表示します。MSDNの記事では、このヘッダーの仕組みについて説明しています。

このフィルターがIEどのように機能するか

この記事の詳細は、https://blogs.msdn.microsoft.com/ie/2008/07/02/ie8-security-part-iv-the-xss-filter/

XSSフィルターはIE8コンポーネントとして動作し、ブラウザーを通過するすべての要求/応答を可視化します。フィルターがクロスサイトリクエストでXSSの可能性を発見すると、サーバーの応答で攻撃が再生された場合、攻撃を識別して阻止します。ユーザーには答えられない質問は表示されません。IEは悪意のあるスクリプトの実行をブロックするだけです。

新しいXSSフィルターにより、タイプ1のXSS攻撃に遭遇したIE8 Beta 2ユーザーには、次のような通知が表示されます。

IE8 XSS攻撃通知

ページが変更され、XSS攻撃がブロックされています。

この場合、XSSフィルターはURLのクロスサイトスクリプティング攻撃を識別しました。特定されたスクリプトが応答ページに再生されたため、この攻撃を無効にしました。このようにして、サーバーへの最初の要求を変更したり、応答全体をブロックしたりせずに、フィルターは効果的です。

Windows Internet Explorer 8がクロスサイトスクリプティング(XSS)攻撃を検出して軽減すると、クロスサイトスクリプティングフィルターイベントがログに記録されます。クロスサイトスクリプティング攻撃は、ある悪意のあるWebサイトがJavaScriptコードを別のWebサイトへの正当な要求に挿入(追加)すると発生します。別のページへのリンクや、共通サービス(ゲストブックなど)を提供するCommon Gateway Interface(CGI)スクリプトなど、元の要求は通常は無害です。挿入されたスクリプトは通常、2番目のWebサイトが許可する予定のない特権情報またはサービスにアクセスしようとします。応答または要求は通常、結果を悪意のあるWebサイトに反映します。Internet Explorer 8の新機能であるXSSフィルターは、URLおよびHTTP POST要求でJavaScriptを検出します。JavaScriptが検出された場合、XSSフィルターは反射の証拠を検索します。この情報は、攻撃要求が変更されずに送信された場合に攻撃Webサイトに返されます。リフレクションが検出されると、XSSフィルターは元の要求をサニタイズして、追加のJavaScriptを実行できないようにします。XSSフィルターは、そのアクションをクロスサイトスクリプトフィルターイベントとしてログに記録します。次の画像は、クロスサイトスクリプティング攻撃を防ぐために変更されたサイトの例を示しています。

ソース:https : //msdn.microsoft.com/en-us/library/dd565647(v=vs.85).aspx

Web開発者は、自分のコンテンツのフィルターを無効にすることができます。HTTPヘッダーを設定することで、これを行うことができます。

X-XSS-Protection: 0

セキュリティヘッダーの詳細


1
これX-XSS-Protection: 0は、この機能の唯一の安全なヘッダーです。詳細については、stackoverflow.com
a / 57802070/334451

10

この便利なHTTPヘッダーのリストで確認できます。

X-XSS-Protection:このヘッダーは、最新のWebブラウザーに組み込まれているクロスサイトスクリプティング(XSS)フィルターを有効にします。いずれにしても、通常はデフォルトで有効になっているため、このヘッダーの役割は、ユーザーによって無効にされた場合に、この特定のWebサイトのフィルターを再度有効にすることです。このヘッダーはIE 8以降とChromeでサポートされています(バージョンは不明)。アンチXSSフィルターはChrome 4で追加されました。そのバージョンがこのヘッダーを受け入れたかどうかは不明です。


残念ながら、この機能セキュリティの問題を引き起こし、唯一の安全な値はX-XSS-Protection: 0です。詳細については、stackoverflow.com
a / 57802070/334451

8

TL; DR:すべての適切に記述されたWebサイト(/ apps)はヘッダーX-XSS-Protection: 0を発行し、この機能を忘れる必要があります。より優れたユーザーエージェントが提供できる追加のセキュリティが必要な場合は、厳格なContent-Security-Policyヘッダーをます。

長い答え:

HTTPヘッダー X-XSS-Protectionは、MicrosoftがInternet Explorer 8.0(MSIE 8)で導入したものの1つであり、誤って記述されたWebサイトのセキュリティを向上させることになっています。

アイデアは、ある種のヒューリスティックを適用して、リフレクションXSS攻撃を検出し、自動的に攻撃を無効にすることです。

これの問題のある部分は、「ヒューリスティック」と「中和」です。ヒューリスティックは誤検出を引き起こし、実装に使用できる副作用を引き起こすため、安全に除去することはできません、完全に安全なWebサイトにXSS攻撃およびDoS攻撃。

悪い点は、WebサイトがヘッダーX-XSS-Protectionを発行しない場合、ブラウザーはヘッダーのように動作することです。X-XSS-Protection: 1です。悪い点は、この値がこのヘッダーのすべての可能な値の中で最も安全でない値であることです。

所定の安全なWebサイト(つまり、サイトにリフレクションXSS脆弱性がない)の場合、この「XSS保護」機能により、次の攻撃ます。

X-XSS-Protection: 1攻撃者がJavaScriptの一部を選択的にブロックし、残りのスクリプトを実行し続けることを可能にします。これが可能なのは、この機能のヒューリスティックが単に「ページソースのスクリプト部分にGETパラメータの値が見つかった場合、スクリプトはユーザーエージェントに依存する方法で自動的に変更される」ためです。実際には、攻撃者はたとえば、パラメータを追加して、プレーンテキストデータを実行可能なJavaScriptコードに誤って変換する可能性がありますdisablexss=<script src="framebuster.js"を、ブラウザは<script src="framebuster.js"実際のページソースから文字列を自動的に削除します。ページの残りの部分は引き続き実行され、攻撃者はページセキュリティのこの部分を削除したことに注意してください。実際には、ページソースのJSは変更できます。場合によっては、コンテンツが反映されたXSS脆弱性のないページを使用して、選択されたJavaScriptをページ上で実行できます

X-XSS-Protection: 1; mode=block攻撃者は、ページの動作をサイドチャネルとして使用することにより、ページソースからデータをリークすることができます。たとえば、ページにの行に沿ってJavaScriptコードが含まれている場合、var csrf_secret="521231347843"攻撃者はパラメータを追加するだけです。たとえばleak=var%20csrf_secret="3、ページがブロックされていない場合、3最初の桁は正しくありませんでした。攻撃者は再試行しますが、今回leak=var%20csrf_secret="5はページの読み込みが中止されます。これにより、攻撃者はシークレットの最初の桁がであることを知ることができます5。その後、攻撃者は次の数字を推測し続けます。

最後に、サイトがXSSリフレクション攻撃でいっぱいの場合、デフォルト値の1を使用すると、攻撃対象領域が少し減少します。ただし、サイトがセキュリティで保護されていない場合、サイトはX-XSS-Protection: 0この機能をサポートするブラウザで脆弱になります。サイトでの未知のXSS脆弱性に対するブラウザーからの多層防御サポートが必要な場合は、厳密なContent-Security-Policyヘッダーを使用してください。それはあなたのサイトを既知の脆弱性にさらしません。

現在、この機能はMSIE、Safari、Google Chromeでデフォルトで有効になっています。これは以前Edgeで有効にされていましたが、Microsoftはすでにこの誤った機能をEdgeから削除してます。Mozilla Firefoxはこれを実装していません。

以下も参照してください。

https://homakov.blogspot.com/2013/02/hacking-facebook-with-oauth2-and-chrome.html https://blog.innerht.ml/the-misunderstood-x-xss-protection/ http:/ /p42.us/ie8xss/Abusing_IE8s_XSS_Filters.pdf https://www.slideshare.net/masatokinugawa/xxn-en https://bugs.chromium.org/p/chromium/issues/detail?id=396544 https:// bugs.chromium.org/p/chromium/issues/detail?id=498982

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.