追記追加
SurferOnWww
1183
不正な ViewState を POST するということは想像が入ってますが、結果からみると間違いなさそうです。その想像が正しければ今回の問題は気にしなくていいと思われます。
想像が正しいかどうか、ViewState の検証を無効にしてみる等で確認してはいかがですか？
+
+
+**【追記】**
+
+以下は質問者さんが回答欄に書いたことへのレスです。
+
+> (ただ一般的には500エラーは脆弱性扱いとなっていますが。。。)
+
+「HTTP 500 エラー」＝「脆弱性」では決してないです。
+
+不正な ViewState を送られたらサーバーエラーとして処置を中断するのは「偽造・改ざん」対策です。それ自体は決して脆弱性ではなく、逆にセキュリティ対策です。詳しくは以下の記事を見てください。
+
+2.5 ViewStateのセキュリティ
+http://www.atmarkit.co.jp/fdotnet/entwebapp/entwebapp03/entwebapp03_04.html
+
+問題は、もしクライアントに HTTP 500 エラーが返ってくるとすると、クライアント側でサーバーエラーになったことが分かるということです。それは脆弱性と言えるかもしれません。
+
+でも、そこはカスタムエラーページを実装するなどして HTTP 500 エラーという情報は返さないようにすれば良いのではないですか？ 具体的には以下の記事を見てください。それができれば脆弱性にはならないです。
+
+ASP.NETでのWebアプリケーションのエラー処理
+https://codezine.jp/article/detail/81
+
+> htmlソースを見る限り、ViewStateを無効にしても、レスポンスには必ず"__VIEWSTATE"が含まれてしまう様です。
+
+ASP.NET 2.0 以降では、ViewState とは別に、ControlState と呼ばれる別個のオブジェクトにサーバーコントロールが機能するために必要な状態情報が格納されます。開発者が ViewState を無効にしても ControlState は影響を受けません。たぶん、そのせいではないかと思います。
+
+ただ、enableViewStateMAC を false にすると、【追記】の一番上に紹介した記事に書いてあるように「改ざん検知」は無効になるはずなのですが・・・
脆弱性診断ツール(OWASP ZAP) というのが何をしているか分からないので想像が入ってますが・・・
内容としては、以下のURL(カスタムエラーページ)に対してPOSTをした場合 HTTP 500エラー(Internal Server Error)が出るというものでした。
これは POST 要求した際に送信した ViewState が不正のためサーバーエラーとなったということだと思います。
ViewState の検証については、ご存知かもしれませんが、以下の記事の「ビューステートのセキュリティ保護」のセクションを見てください。
ASP.NET ビューステートの概要
https://msdn.microsoft.com/ja-jp/library/bb386448.aspx
疑問点は、これでなぜランタイムエラーが発生しなくなるのか分かりません。(リダイレクトさせることで送られた無効なViewStateを読まないから？)
これも想像が入ってますが、
ViewState の検証がかかる前に Response.Redirect(requestPath) で処理が中断され直ちに HTTP 302 応答と応答ヘッダの Location に requestPath を設定してブラウザに返す ⇒ ブラウザは Location の requestPath を GET 要求に行く ⇒ GET 要求なので ViewState の問題はない
・・・ということだと思います。
あとはここまでする必要があるのか謎です。。。(ランタイムエラーページは内部情報が分かるような内容は含まれていませんし、aspxerrorpathクエリを削除してしまうと、エラー元のページ名が分からなくなる。)
問題はクエリ文字列 aspxerrorpath ではなく、脆弱性診断ツール(OWASP ZAP) が不正な ViewState を POST するということにありそうです。
不正な ViewState を POST するということは想像が入ってますが、結果からみると間違いなさそうです。その想像が正しければ今回の問題は気にしなくていいと思われます。
想像が正しいかどうか、ViewState の検証を無効にしてみる等で確認してはいかがですか？
【追記】
以下は質問者さんが回答欄に書いたことへのレスです。
(ただ一般的には500エラーは脆弱性扱いとなっていますが。。。)
「HTTP 500 エラー」＝「脆弱性」では決してないです。
不正な ViewState を送られたらサーバーエラーとして処置を中断するのは「偽造・改ざん」対策です。それ自体は決して脆弱性ではなく、逆にセキュリティ対策です。詳しくは以下の記事を見てください。
2.5 ViewStateのセキュリティ
http://www.atmarkit.co.jp/fdotnet/entwebapp/entwebapp03/entwebapp03_04.html
問題は、もしクライアントに HTTP 500 エラーが返ってくるとすると、クライアント側でサーバーエラーになったことが分かるということです。それは脆弱性と言えるかもしれません。
でも、そこはカスタムエラーページを実装するなどして HTTP 500 エラーという情報は返さないようにすれば良いのではないですか？ 具体的には以下の記事を見てください。それができれば脆弱性にはならないです。
ASP.NETでのWebアプリケーションのエラー処理
https://codezine.jp/article/detail/81
htmlソースを見る限り、ViewStateを無効にしても、レスポンスには必ず"__VIEWSTATE"が含まれてしまう様です。
ASP.NET 2.0 以降では、ViewState とは別に、ControlState と呼ばれる別個のオブジェクトにサーバーコントロールが機能するために必要な状態情報が格納されます。開発者が ViewState を無効にしても ControlState は影響を受けません。たぶん、そのせいではないかと思います。
ただ、enableViewStateMAC を false にすると、【追記】の一番上に紹介した記事に書いてあるように「改ざん検知」は無効になるはずなのですが・・・
脆弱性診断ツール(OWASP ZAP) というのが何をしているか分からないので想像が入ってますが・・・ > 内容としては、以下のURL(カスタムエラーページ)に対してPOSTをした場合 HTTP 500エラー(Internal Server Error)が出るというものでした。 これは POST 要求した際に送信した ViewState が不正のためサーバーエラーとなったということだと思います。 ViewState の検証については、ご存知かもしれませんが、以下の記事の「ビューステートのセキュリティ保護」のセクションを見てください。 ASP.NET ビューステートの概要 https://msdn.microsoft.com/ja-jp/library/bb386448.aspx > 疑問点は、これでなぜランタイムエラーが発生しなくなるのか分かりません。(リダイレクトさせることで送られた無効なViewStateを読まないから？) これも想像が入ってますが、 ViewState の検証がかかる前に Response.Redirect(requestPath) で処理が中断され直ちに HTTP 302 応答と応答ヘッダの Location に requestPath を設定してブラウザに返す ⇒ ブラウザは Location の requestPath を GET 要求に行く ⇒ GET 要求なので ViewState の問題はない ・・・ということだと思います。 > あとはここまでする必要があるのか謎です。。。(ランタイムエラーページは内部情報が分かるような内容は含まれていませんし、aspxerrorpathクエリを削除してしまうと、エラー元のページ名が分からなくなる。) 問題はクエリ文字列 aspxerrorpath ではなく、脆弱性診断ツール(OWASP ZAP) が不正な ViewState を POST するということにありそうです。 不正な ViewState を POST するということは想像が入ってますが、結果からみると間違いなさそうです。その想像が正しければ今回の問題は気にしなくていいと思われます。 想像が正しいかどうか、ViewState の検証を無効にしてみる等で確認してはいかがですか？ **【追記】** 以下は質問者さんが回答欄に書いたことへのレスです。 > (ただ一般的には500エラーは脆弱性扱いとなっていますが。。。) 「HTTP 500 エラー」＝「脆弱性」では決してないです。 不正な ViewState を送られたらサーバーエラーとして処置を中断するのは「偽造・改ざん」対策です。それ自体は決して脆弱性ではなく、逆にセキュリティ対策です。詳しくは以下の記事を見てください。 2.5 ViewStateのセキュリティ http://www.atmarkit.co.jp/fdotnet/entwebapp/entwebapp03/entwebapp03_04.html 問題は、もしクライアントに HTTP 500 エラーが返ってくるとすると、クライアント側でサーバーエラーになったことが分かるということです。それは脆弱性と言えるかもしれません。 でも、そこはカスタムエラーページを実装するなどして HTTP 500 エラーという情報は返さないようにすれば良いのではないですか？ 具体的には以下の記事を見てください。それができれば脆弱性にはならないです。 ASP.NETでのWebアプリケーションのエラー処理 https://codezine.jp/article/detail/81 > htmlソースを見る限り、ViewStateを無効にしても、レスポンスには必ず"__VIEWSTATE"が含まれてしまう様です。 ASP.NET 2.0 以降では、ViewState とは別に、ControlState と呼ばれる別個のオブジェクトにサーバーコントロールが機能するために必要な状態情報が格納されます。開発者が ViewState を無効にしても ControlState は影響を受けません。たぶん、そのせいではないかと思います。 ただ、enableViewStateMAC を false にすると、【追記】の一番上に紹介した記事に書いてあるように「改ざん検知」は無効になるはずなのですが・・・