ASP.NET 1.1の後、フォームを送信するためにXSS（クロスサイトスクリプト攻撃）があるかどうかを自動的に確認する機能が導入されます。ユーザーがそのような入力を使用してページに影響を与えて結果を返すと、ASP.NETエンジンはHTTPRequestValidationExceptininをトリガーします。デフォルトでは、次のテキストがあるページが返されます。
これは、ASP.NETが提供する非常に重要なセキュリティ機能です。多くのプログラマーはセキュリティについて知らないため、XSSのような攻撃の存在さえ知らないため、それらを保護するためのイニシアチブをとることを知っている人は少なくなります。この時点では、デフォルトでASP.NETが安全です。これにより、セキュリティについてあまり知らないプログラマーは、特定のセキュリティ保護機能を備えたWebサイトを作成することができます。
ただし、 httprequestvalidationexceptionまたは潜在的に危険な要求を検索したとき、クライアントからフォーム値が検出されたとき、ほとんどの人から与えられた解決策がASP.NETページの説明でvalidAterequest = falsを設定することでそれを無効にすることであることに驚きました。この機能は、プログラマーのウェブサイトが本当にこの機能を必要としないかどうかを気にすることではありません。私はその光景にとても怖がっていました。セキュリティ認識は、常にすべてのプログラマーの心にあるはずです。
なぜ多くのプログラマーがvalidAterequestを禁止したいのですか？これを言う必要はありません。別の部分は、実際には、ユーザーがXSSを簡単に引き起こす文字の入力を許可することではなく、この形式のエラーレポートを嫌っています。ユーザーではありませんが、違法なキャラクターを入力しましたが、エラーの報告を防ぐ方法がわかりませんでした。
デフォルトのASP.NET例外エラーメッセージを使用せずにこのエラーメッセージを適切に処理したいプログラマーについては、validaterequest = falseを無効にしないでください。
正しい方法は、Page_Error（）関数を現在のページに追加して、処理せずにページ処理中に発生するすべての例外をキャッチすることです。次に、ユーザーに法的エラーメッセージを提供します。現在のページにpage_error（）がない場合、この例外は処理のためにglobal.asaxのapplication_error（）に送信され、一般的な例外エラー処理機能を記述することもできます。両方の場所で例外処理機能が記述されていない場合、このデフォルトのエラーレポートページが表示されます。
たとえば、この例外を扱うために非常に短いコードのみが必要です。このコードをページのコードビハインドページに追加します。
| 以下は引用されたスニペットです： protectedVoidPage_Error（objectsender、eventargse） { ExceptionEx = server.getLasterRor（）; if（exishttprequestValidationException） { Response.Write（法的文字列を入力してください。）; server.ClearError（）; // clearError（）がClearError（）でない場合、この例外は引き続きApplication_Error（）に渡されます。 } } |
このように、このプログラムはHTTPRequestValidationException例外を傍受することができ、プログラマーの希望に応じて合理的なエラーメッセージを返すことができます。
このコードは非常にシンプルなので、ユーザーなどの文字を実際に入力することを許可されていないすべての友人が、このセキュリティ機能のみが必要な場合は、上記のコードを使用してそれを処理してください。 。 できる。
この機能を明示的に禁止するプログラマーの場合、彼らは自分が何をしているのかを理解し、フィルタリングする必要がある文字列を手動でチェックする必要があります。そうしないと、サイトは簡単にクロスサイトスクリプト攻撃をトリガーします。
リッチテキストエディターのページをどのように処理する必要がありますか？
ページに豊富なテキストエディターを使用したコントロールがある場合、クラスのHTMLタグの提出に必然的につながります。この場合、hibalaterequest = falseする必要があります。では、この状況では、セキュリティに対処する方法を最大限に防ぐ方法は？
Microsoftのアドバイスによると、セキュリティベースの明示的に許可されたポリシーと呼ばれるポリシーを採用する必要があります。
最初に、httputility.htmlencode（）で入力文字列をエンコードし、HTMLタグを完全に禁止します。
次に、関心のあるセキュリティタグを置き換え、置換（）に置き換えられます。たとえば、ラベルが必要な場合は、明示的に置き換えます。
サンプルコードは次のとおりです。
| 以下は引用されたスニペットです： voidsubmitbtn_click（objectsender、eventargse） ... { //入力文字列をエンコードして、すべてのHTMLタグが無効になるようにします。 StringBuildersB = NewStringBuilder（ httputility.htmlencode（htmlinputtxt.text））; //次に、<b>および<i>を選択的に許可します sb.Replace（＆lt; b＆gt;、<b>）; sb.Replace（＆lt;/b＆gt;、）; sb.replace（＆lt; i＆gt;、<i>）; sb.Replace（＆lt;/i＆gt;、）; Response.write（sb.toString（））; } |
このようにして、いくつかのHTMLタグを許可し、危険なタグを禁止します。
Microsoftが提供するアドバイスによると、これらのHTMLタグはクロスサイトのスクリプト攻撃につながる可能性があるため、次のHTMLタグを慎重に許可する必要があります。
以下は引用されたスニペットです：
|
おそらく、ここで最も理解できないことは<img>です。ただし、次のコードを読んだ後、その危険を理解する必要があります。
| 以下は引用されたスニペットです： <imgsrc = javascript：alert（ 'hello'）;> <imgsrc = java＆＃010; script：alert（ 'hello'）;> <imgsrc = java＆＃x0a; script：alert（ 'hello'）;> |
攻撃者が変装したいことを何でもできるように、<IMG>タグを介してJavaScriptの実行を引き起こすことができます。
<style>にも同じことが言えます：
| 以下は引用されたスニペットです： <styletype = text/javascript> ... アラート（ 'hello'）; </style> |
| 以下は引用されたスニペットです： 「/YourApplicationPath」アプリケーションのサーバーエラー 潜在的に危険なリクエスト。クライアントからフォーム値が検出されました （txtname = <b>）。 説明：リクエストは、潜在的に危険なクライアント入力値を検出し、リクエストの処理は、クロスサイトスクリプト攻撃など、アプリケーションのセキュリティを補正する試みを示していますただし、ページディレクティブまたは構成セクションでfalse = falseを設定することにより、この場合のすべての入力を明示的に確認することを強くお勧めします。 例外の詳細：System.Web.httpRequestValidationException：潜在的に危険な要求。クライアント（txtname = <b>）からフォーム値が検出されました。 ... |