QA@IT
«回答へ戻る

回答を投稿

SurferOnWww様

再度回答ありがとうございます。大変助かります。
 

不正な ViewState を送られたらサーバーエラーとして処置を中断するのは「偽造・改ざん」対策です。それ自体は決して脆弱性ではなく、
問題は、もしクライアントに HTTP 500 エラーが返ってくるとすると、クライアント側でサーバーエラーになったことが分かるということです。それは脆弱性と言えるかもしれません。

はい。その辺は理解しています。
 

でも、そこはカスタムエラーページを実装するなどして HTTP 500 エラーという情報は返さないようにすれば良いのではないですか? 具体的には以下の記事を見てください。それができれば脆弱性にはならないです。

はい。今回のケースで、カスタムエラーページにてエラーが出た場合は、ランタイムエラー(500エラー)となることが分かりました。
最初の対応としては、Global.asaxでリダイレクトさせて不正なViewStateがない状態にしましたが、その他の例外もあり得るので、一番良いのはカスタムエラーページ内でも例外を捕捉し、500エラーを出さない様にする様にした方が良いと思いました。
 

ASP.NET 2.0 以降では、ViewState とは別に、ControlState と呼ばれる別個のオブジェクトにサーバーコントロールが機能するために必要な状態情報が格納されます。開発者が ViewState を無効にしても ControlState は影響を受けません。たぶん、そのせいではないかと思います。

なるほどですね。この辺は中々調べても出てこなかったので勉強になります。
 

ただ、enableViewStateMAC を false にすると、【追記】の一番上に紹介した記事に書いてあるように「改ざん検知」は無効になるはずなのですが・・・

何度か試しましたが、やはりどうしても不正なViewStateとして検知されました。
ControlState だけは enableViewStateMAC の影響を受けないのかもしれないですね。

SurferOnWww様

再度回答ありがとうございます。大変助かります。
  
> 不正な ViewState を送られたらサーバーエラーとして処置を中断するのは「偽造・改ざん」対策です。それ自体は決して脆弱性ではなく、
> 問題は、もしクライアントに HTTP 500 エラーが返ってくるとすると、クライアント側でサーバーエラーになったことが分かるということです。それは脆弱性と言えるかもしれません。

はい。その辺は理解しています。
 
> でも、そこはカスタムエラーページを実装するなどして HTTP 500 エラーという情報は返さないようにすれば良いのではないですか? 具体的には以下の記事を見てください。それができれば脆弱性にはならないです。

はい。今回のケースで、カスタムエラーページにてエラーが出た場合は、ランタイムエラー(500エラー)となることが分かりました。
最初の対応としては、Global.asaxでリダイレクトさせて不正なViewStateがない状態にしましたが、その他の例外もあり得るので、一番良いのはカスタムエラーページ内でも例外を捕捉し、500エラーを出さない様にする様にした方が良いと思いました。
  
> ASP.NET 2.0 以降では、ViewState とは別に、ControlState と呼ばれる別個のオブジェクトにサーバーコントロールが機能するために必要な状態情報が格納されます。開発者が ViewState を無効にしても ControlState は影響を受けません。たぶん、そのせいではないかと思います。

なるほどですね。この辺は中々調べても出てこなかったので勉強になります。
 
> ただ、enableViewStateMAC を false にすると、【追記】の一番上に紹介した記事に書いてあるように「改ざん検知」は無効になるはずなのですが・・・

何度か試しましたが、やはりどうしても不正なViewStateとして検知されました。
ControlState だけは enableViewStateMAC の影響を受けないのかもしれないですね。