web-dev-qa-db-ja.com

Chrome：ERR_BLOCKED_BY_XSS_AUDITORの詳細

投稿してから簡単なフォームを取得しようとすると、このchromeフラグが表示されます。

問題は、開発者コンソールにこれについて何も表示されず、自分で問題の原因を見つけることができないことです。

これを詳細に見るためのオプションはありますか？修正のためにエラーを引き起こすコードの一部を表示...

google-chromexss
47
rpfc

Chrome v58mightまたは問題を解決できない可能性があります...実際にPOSTを実行している内容によって異なります。たとえば、input/select/textarea要素内で生のHTML/XMLデータをPOSTしようとすると、リクエストが監査者からブロックされる可能性があります。

過去数日で、WYSIWYGclient-sideエディターと、ある種のコンテンツプレビューを備えたインタラクティブなアップロードフォームという2つの異なるシナリオでこの問題に遭遇しました。生のHTMLをbase64でエンコードしてからPOSTでPOSTし、受信PHPページでデコードすることで、それらを修正することができました。これにより問題が解決する可能性が高く、最も重要なことは、POSTリクエストからのデータに関する開発者の認識レベルを高め、効果的なデータエンコード/デコード戦略の採用を促し、XSSからWebアプリケーションを強化することです。タイプ攻撃。

クライアント側でコンテンツをbase64エンコードするには、現在ほとんどのブラウザでサポートされている ネイティブbtoa（）関数 を使用するか、 jQueryプラグインなどのサードパーティの代替手段（私は this を使用しましたが、これは正常に機能しました）。

POSTデータをbase64デコードするには、PHPのbase64_decode(str)関数、ASP.NETのConvert.FromBase64String(str)またはその他（サーバー側のシナリオに応じて）を使用できます。

詳細については、このトピックで書いた このブログ投稿 をご覧ください。

26
Darkseal

開発中にこのエラーを回避する簡単な方法は、ヘッダーをブラウザに送信することです

ブラウザにデータを送信する前にヘッダーを配置します。

phpでは、このエラーをバイパスするためにこのヘッダーを送信できます、 ヘッダー参照を送信 ：

header('X-XSS-Protection:0');

ASP.netでは、このヘッダーと ヘッダー参照の送信 を送信できます。

HttpContext.Response.AddHeader("X-XSS-Protection","0");
or 
HttpContext.Current.Response.AddHeader("X-XSS-Protection","0");

nodejs送信ヘッダーで、 ヘッダー参照を送信 ：

res.writeHead(200, {'X-XSS-Protection':0 });
// or express js
res.set('X-XSS-Protection', 0);
72
A1Gard

この場合、 Creative forums 、（何らかの種類の vBulletin 構文）で初めて貢献し、PMを投稿することになりますフォーラムにアクセスする前のモデレーターは、上記のより一般的な回答から問題の性質を簡単にカプセル化できます。コマンドは

http://forums.creative.com/private.php?do=insertpm&pmid=

また、上記のように、実際のデータは「input/select/textarea要素内の生のHTML/XMLデータ」でした。

ユーザーエンドでこのようなバグ（または機能）を処理するための一般的な要件は、ある種の迅速な修正Tweakまたはtwiddleです。 この投稿 キャッシュのクリア、Chrome設定のリセット、new_userの作成、または新しいベータリリースでの操作の再試行のオプションについて説明しています。また、次のように新しいインスタンスを起動することも提案されました。

google-chrome-stable --disable-xss-auditor

この修正は、このW101703Chrome061エディションで実際に起動しましたバージョン：

chrome --disable-xss-auditor

ただし、サイトに再度ログインして投稿を再試行すると、同じエラーが生成されました。おそらく、構文が洗練されていることを望んでいるか、何か他のものが間違っています。

その後、Edgeを起動してそこから再投稿するのが妥当と思われましたが、まったく問題はありませんでした。

5
Laurie Stearn

これはmay状況によっては役立ちます。 Apache httpd.confファイルを変更して追加します

ResponseHeader set X-XSS-Protection 0

それmayはVersion 58.0.3029.110 (64-bit)で修正されました。

3
Chloe

テキストにアポストロフィ'が含まれていると、Chromeがそれをブロックすることに気付きました。

2
Stephen

問題を解決しました！

私の場合、submmitを作成するとき、アクションにHTMLを送信し、モデルには「AllowHTML」でHTMLを受け入れるプロパティがありました。

解決策は、この「AllowHTML」プロパティを削除することで構成され、すべてがOKになります！

私の場合は必要ないので、明らかに私はもはやアクションにHTMLを送信しません

0
Frana

これはChromeのバグです。唯一の解決策は、このChromeのバグを修正するまでFireFoxを使用することです。 XSS監査員が20年間問題なく動作していたページを破棄することは、原因ではなく症状のようです。

0
user236939

POSTリクエストのページでhrefをjavascript:void(0)から#に更新すると、動作します。

例えば：

<a href="javascript:void(0)" id="loginlink">login</a>

への変更：

<a href="#" id="loginlink">login</a>
0
Green Lei