localhostで実行中にJSONPコールバックが実行されない
https://stackoverflow.com/questions/1217926
-
10-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
これは奇妙なことです。なぜこれが起こったのか、誰かが光を当てられるかどうか疑問に思っていました。
基本的に、私は他のサイトが使用できるJSON Webサービスを実装できるように、JSONPをテストしようとして髪を引っ張ってきました。 localhost、具体的にはVisual Studio 2008およびVisual Studio 2008の組み込みWebサーバーで開発を行っています。
jQueryを使用したJSONPテストの実行として、以下を実装しました。
$().ready(function() {
debugger;
try {
$.getJSON("<%= new Uri(Request.Url, "/").ToString() %>XssTest?callback=?", function(data) {
alert(data.abc);
});
} catch (err) {
alert(err);
}
});
サーバー上..
<%= Request["callback"] %>({abc : 'def'})
そのため、最終的にサーバーにブレークポイントを設定し、最初の<！> quot; debugger; <！> quot;の両方にブレークポイントを取得します。クライアント側のスクリプトとサーバーにある文。 JSONP URLは、ページのロード後に実際に呼び出されています。それはうまく機能しています。
私が抱えていた問題は、コールバックが実行されないことでした。 IE8とFirefox 3.5の両方でこれをテストしました。どちらもコールバックを呼び出しません。 catch（err）にも到達しませんでした。何も起こりませんでした！
1週間これに固執し、指定されたポートのTelnetで手動でキー入力されたHTTP要求でテストして、サーバーが形式を返していることを確認しました...
callbackfn({abc : 'def'})
..そしてそれです。
それから、グローバライザー（ '。'）を使用してホスト名をlocalhostからlocalhostに変更するとどうなりますか、つまり http：// localhost：41559 / ではなくhttp://localhost.:41559/ （はい、ホスト名にドットを追加することは正当であり、DNSにとってはglobal::がC＃名前空間に対して何であるかです）。そしてそれはうまくいきました！ Internet ExplorerとFirefox 3.5では、ドットを追加したときに警告メッセージが表示されました。
それで、ここで何が起こっているのだろうと思いますか？なぜスクリプトタグの生成が遅くなるのは、普通のローカルホストではなくインターネットホスト名で機能するのですか？それとも正しい質問ですか？
これは明らかにセキュリティ上の理由で実装されていますが、何を保護しようとしていますか？そして、ドットで動作させることで、このセキュリティ機能にセキュリティホールを公開しただけですか？
ところで、私のhostsファイルは、他のホスト用に変更されていますが、localhostでは特別な処理は行われていません。デフォルトの127.0.0.1 / :: 1はそのままで、以下のオーバーライドはありません。
フォローアップ：以下を追加することで、ローカル開発の目的でこれを乗り越えました：
127.0.0.1 local.mysite.com
..ホストファイルに追加し、次にglobal.asaxに次のコードを追加します：
protected void Application_BeginRequest(object sender, EventArgs e)
{
if (Request.Headers["Host"].Split(':')[0] == "localhost")
{
Response.Redirect(
Request.Url.Scheme
+ "://"
+ "local.mysite.com"
+ ":" + Request.Url.Port.ToString()
+ Request.Url.PathAndQuery
, true);
}
}
解決
そこに答えを投げます。いくつか考えた後、私は自分の結論に達しました。
これは、クライアントマシンで実行されているJSONPサービスの呼び出しからインターネットWebサイトを妨害しようとするために実装されたセキュリティ機能である可能性があります。
Webサイトは、ポートのリストをたどって、さまざまなポートとパスでlocalhostを呼び出し続けることができます。 「Localhost」は、照会のタイミングと場所に応じて意味が動的になる数少ないDNSホスト名の1つであり、潜在的なターゲットを脆弱にします。そして、「localhost」（「localhost。」）にドット（。）を追加すると、回避策が作成されるという事実はセキュリティの脆弱性を明らかにしますが、開発の目的のための[仮の]回避策を提供します。
より良いアプローチは、ループバックIPをhostsファイル内の新しいホスト名エントリにマップして、ローカルで機能するようにすることです。<！> quot; fixed <！> quot;ブラウザの更新によるものであり、開発ワークステーション以外では機能しません。
他のヒント
同様の問題が発生しています。私が試したほとんどのソリューションはIE（7）で動作しますが、Firefox（3.5.2）でボールをプレーするのに苦労しています。
クライアントでサーバーの応答がどのように解釈されるかを確認するためにHttpFoxをインストールしましたが、NS_ERROR_DOM_BAD_URIを取得しています。私の状況はあなたとは少し異なります。ホスティングページが来た同じサイトにJSONPコールを呼び出そうとしているので、このコールは別のサイトへの302リダイレクトで応答しています。 （ブラウザーに返される両方のドメインからCookieを取得する便利な方法としてリダイレクトを使用しています。）
jQueryを使用していますが、元々は$ .ajax（）経由で標準のAJAX呼び出しを実行しようとしました。最初のリクエストはホスティングページと同じサイトに対するものであるため、Firefoxは別のドメインへの302レスポンスに従うだけであると考えました。しかし、いや、それはXSSの防御のファウルに落ちるように見えました。 （ XHRリクエストへの応答としてリダイレクトを返すの意味に反することに注意してください、jQueryは標準のdataType = <！> quot; json <！> quotの302リダイレクトに従います。同じドメインへのリダイレクトは正常に機能します。別のドメインへのリダイレクトはブラウザでNS_ERROR_DOM_BAD_URIを生成します。同じドメインの302リダイレクトが他のドメインにリダイレクトできない理由がわかりません。結局、リダイレクトを発行しているのはホスティングページのドメインなので、なぜ信頼できないのでしょうか。スクリプティングインジェクション攻撃が心配な場合は、とにかくJSONPルートが悪用される可能性があります...
jcallの$ .getJSON（）と？callback =？また、接尾辞はFirefoxで同じエラーで失敗します。 $ .getScript（）を使用して独自のJSONP <！> lt; script <！> gt;をロールするのと同様にタグ。
動作しているように見えるのは、既存の<！> lt; script id = <！> quot; jsonp <！> quot; type = <！> quot; text / javascript <！> quot; <！> gt; <！> lt; / script <！> gt; HTMLで、$（<！> quot; jsonp <！> quot;）。attr（<！> quot; src <！> quot ;, url + <！> quot;？callback = myCallback <！> quotを使用;）JSONP呼び出しを呼び出します。それを行うと、クロスドメイン302リダイレクトが追跡され、JSON応答がmyCallbackに渡されます（<！> lt; script / <！> gt;タグと同時に定義しました）。
そして、はい、これらすべてをlocalhost： port URLでCassiniを使用して開発しています。 Cassiniは非ローカルホストURLに応答しないため、local.mysite.comを簡単に試して、上記で試したソリューションに影響があるかどうかを確認することはできません。ただし、localhostの末尾にドットを付けると、すべての問題が修正されたようです！
これで、localhost __.__： port quot; jsonp <！> quot; ...}）呼び出しに戻ることができます> localhost： port の代わりに、すべて順調です。ページのHTMLに既に存在するスクリプトタグのsrc属性を変更すると、通常のlocalhost URLを呼び出すことができることは興味深いと思います-あなたの思考プロセスに従って、これは別のセキュリティ脆弱性である可能性があります。
