2

クライアントは、任意の数の攻撃を防ぐために、Webサイトの周りにカスタムファイアウォールルールを持っています。カスタムルールの1つは、SQLインジェクションを防ぐために、ダブルハイフンを含むすべての要求(GETまたはPOSTのいずれか)をブロックします。昨夜彼らのウェブサイトを更新しているときに、すべてのページで、ScriptResource.axdへの呼び出しの1つに二重ハイフン(-)が含まれ、スクリプトへのアクセスが拒否されるという問題がありました。

以前にこの問題を確認し、ScriptReferenceProfilerを使用して、非常に多くのスクリプト参照を削除するために組み合わせる必要のあるスクリプトのリストを生成することで、この問題を回避したと考えました。これは、問題が再発した昨夜の更新まで機能していました。(興味深いことに、ScriptReferenceProfilerを再実行したところ、識別されたすべてのスクリプトがすでにCompositeScriptリストに含まれていたため、このファイルがどこから来たのかわかりません。)

以前の仮想ディレクトリと同じディレクトリとコードベースを指しているにもかかわらず、二重ダッシュの問題が発生しない新しいIIS仮想ディレクトリを最終的に作成しました。(最初の仮想ディレクトリを新しい仮想ディレクトリへのリダイレクトとして機能するように設定したので、ユーザーはリンクやブックマークの更新について心配する必要がありません。)この投稿から、最初のパラメーターはアセンブリ名と2つの仮想ディレクトリ間の値の違いを説明するresourcename。

しかし、明らかに、私は将来この状況を避けたいと思います。ScriptResourceリクエストに二重ダッシュが表示されないようにする方法について誰かが考えていますか?

参考までに、これはIIS 6 / Windows Server2003上の.NET4.0で実行されているVB.NetWebサイトで発生しました。さらに、拒否されたスクリプトファイルは、ある種のInfragisticsコントロール用でした。(ファイルを取得してから再度有効にするために、ファイアウォールルールを一時的にオフにしました。ただし、スクリプトからは、インフラストラクチャでどのような役割を果たしているかを判断できませんでした。)

ありがとう。

4

1 に答える 1

4

最初のパラメーター(d)は、アセンブリとリソースです。アセンブリの場合、これには名前とバージョン、およびアセンブリに厳密な名前が付けられている場合は公開鍵トークンが含まれます。これらのいずれかが変更されると、リソースの文字列も変更されます。

2番目のパラメーター(t)はタイムスタンプ専用であり、これにより、サイトでキャッシュが有効になっている場合でも、アセンブリ名やバージョンを変更せずに、埋め込みリソースを含むアセンブリを更新すると、リソースを変更できます。

最初のパラメーターの暗号化はMachineKeyに基づいているため、MachineKeyを変更して、暗号化の結果の文字列を変更できます。これにより、使用するすべてのアセンブリの名前とバージョンを制御していなくても、問題が発生したときに簡単な回避策を講じることができます。

あなたが興味を持つかもしれない関連読書:

于 2013-01-03T19:47:51.397 に答える