ASP.NETで正常にハンドルするURIを正しく処理する

Question

ほとんどの例外を正常に処理するアプリケーションを作成しました。ページのデザインはそのままで、かなりのエラーメッセージが表示されます。私のアプリケーションはPage_Errorイベントでそれらをすべてキャッチし、HttpContext.Curent.Context.Itemsに例外を追加し、次にServer.TransferをError.aspxページに追加します。私はこれがASP.NETの唯一の実行可能な解決策であると考えています。集中した一般的な方法でそれを行う方法は他にないようです。

私はApplication_Errorも処理していますが、正常に処理できるかどうかを調べるために発生した例外については、いくつか点検を行います。私が優雅に扱えることがわかった例外は、誰かがURIをハックして.NETフレームワークがファイルシステムレベルで危険または基本的に違法であると考える文字の後にスローされたものです。

このようなURIは、例えばのようになります。：

• http://exmample.com/"illegal"
• http://example.com/illegal"/
• http://example.com/illegal /

（最後のURIの末尾にスラッシュの前のスペースに注意してください）。

私は、これらのURIが "404 Not Found"とフレンドリーなメッセージで応答し、DDoS攻撃のベクターなどを避けるためにエラーレポートを送信しないようにしたいと思います。私は、しかし、これらのタイプのエラーをキャッチするエレガントな方法が見つかりませんでした。私が今やっていることはexception.TargetSite.Nameプロパティを検査し、それがCheckInvalidPathChars、ValidatePathかCheckSuspiciousPhysicalPathに等しいだ場合、私はそれを「パス検証の例外」を検討し、これはしかし、ハックのように思える404

で応答です。まず、メソッド名のリストはおそらく完全ではないでしょうし、第2に、これらのメソッド名が改行されたり、名前が改行されてコードが破損する可能性があります。

誰も私がこのハードコードされていない、はるかに将来的に耐えられる方法をどのように処理できるか考えていますか？

PS：私のアプリケーションでは、任意の解決策にとって重要であれば、きれいで分かりやすいURIを使用するためにSystem.Web.Routingを使用しています。

Answer 1

System.Web.Routingが何らかの種類のURLフィルタリングをサポートしている可能性がありますが、独自の実装が非常に簡単です。

System.Web.IHttpModuleインターフェイスを見て、implementing custom HTTP Modulesについて読んでください。 HTTPモジュールはそのAsp.Netパイプラインに入り、ページが実行される前に実行されます。リクエストのロギング、リクエストの変更、およびリクエストのフィルタリングにこれを使用できます。 Asp.Netルーティングモジュールは、カスタムHTTPモジュールとしても実装されています。

あなたができることは、リクエストされたURLを見て、それが有効かどうかをチェックするHttpモジュールを実装することです。 urlが無効な場合は、必要な処理を行うことができます。たとえば、404 - not foundページにリダイレクトするなど、リクエストを停止することができます。

Answer 2

私はSystem.Web.IHttpModuleを使用してIIS7 +の正解であるとは思わない。パスを検証するためにIHttpModuleを実装しようとしていますが、HttpModuleが実行される前に例外がスローされています。

は、これが私の例外スタックです：

[ArgumentException: Illegal characters in path.] 
    System.IO.Path.CheckInvalidPathChars(String path) +7493413 
    System.IO.Path.Combine(String path1, String path2) +40 
    System.Web.Configuration.UserMapPath.GetPhysicalPathForPath(String path, VirtualDirectoryMapping mapping) +114 
    System.Web.Configuration.UserMapPath.GetPathConfigFilename(String siteID, VirtualPath path, String& directory, String& baseName) +72 
    System.Web.Configuration.UserMapPath.MapPath(String siteID, VirtualPath path) +30 
    System.Web.Configuration.UserMapPath.MapPath(String siteID, String path) +31 
    System.Web.Hosting.HostingEnvironment.MapPathActual(VirtualPath virtualPath, Boolean permitNull) +297 
    System.Web.Hosting.HostingEnvironment.MapPathInternal(VirtualPath virtualPath, Boolean permitNull) +51 
    System.Web.CachedPathData.GetConfigPathData(String configPath) +341 
    System.Web.CachedPathData.GetVirtualPathData(VirtualPath virtualPath, Boolean permitPathsOutsideApp) +110 
    System.Web.HttpContext.GetFilePathData() +36 
    System.Web.HttpContext.GetConfigurationPathData() +26 
    System.Web.Configuration.RuntimeConfig.GetConfig(HttpContext context) +43 
    System.Web.Configuration.CustomErrorsSection.GetSettings(HttpContext context, Boolean canThrow) +41 
    System.Web.HttpResponse.ReportRuntimeError(Exception e, Boolean canThrow, Boolean localExecute) +101 
    System.Web.HttpRuntime.FinishRequest(HttpWorkerRequest wr, HttpContext context, Exception e) +383 

、これは私が推測していIIS 7.0のアプリケーションライフサイクルへのリンク（http://msdn.microsoft.com/en-us/library/bb470252.aspx）

である「RESOLVEのCACHE」によって引き起こされた例外のステップ

Answer 3

ライティングカスタムHttpModuleを私のために動作しませんでした - 私はまだ問題が解決し、「パスに無効な文字」エラーを得たが、this questionに答える：

を

web.ConfigのrequestFilteringに対してallowDoubleEscaping = "false"を設定すると、これを回避できます。すなわち：

<configuration> 
    <system.webServer> 
    <security> 
     <requestFiltering allowDoubleEscaping="false" /> 
    </security> 
    </system.webServer> 
</configuration> 

おそらくない完璧なソリューション（良い方のための任意の提案は非常に高く評価され）、それは問題を解決します。