9

グローバル例外ログを監視すると、このエラーは何をしても削除できないようです。最終的に削除したと思っていましたが、再び戻ってきました。同様の投稿で、エラーのストラック トレースを確認できます。

環境に関する注意事項:

IIS 6.0、.NET 3.5 SP1単一サーバー ASP.NET アプリケーション

すでに実行されている手順:

  <system.web>
    <machineKey validationKey="big encryption key"
      decryptionKey="big decryption key"
      validation="SHA1" decryption="AES" />

すべてのページのページ ベース内

  protected override void OnInit(EventArgs e)
  {
    const string viewStateKey = "big key value";

    Page.ViewStateUserKey = viewStateKey;
  }

また、ページのソースでは、ASP.NET によって生成されたすべての非表示フィールドがページの上部に正しく表示されていることがわかります。

4

3 に答える 3

23

まず、ビューステートのこのエラーが PostBack で発生するという事実から始めましょう。

また、この問題を回避するために誰もが提案するすべてのことを行ったと言わなければなりません。また、マシンは 1 台ですが、同じページを実行する 2 つのプールがあります。

つまり、誰かがアクションを実行したり、人を操作したり、ページを「クリック」して他の検索マシンを操作したり、ハッカーがシステムに問題がないかチェックしようとしたりします...

私も似たような問題を抱えています (まれではありますが、既存の問題です)。最終的に、人々が私のページをハックテストしようとしていることがわかりました。(私が持っている同じIPから攻撃を行います)

ビューステートを変換する関数LoadPageStateFromPersistenceMedium()を変更し、正確に入力されたものと、どの IP からのものかをログに記録して確認します。次に、これらの結果の監視を開始し、ビューステートが手動で変更されたか、または完全に空であったことを確認しました。 .

エラーが発生した場合、私は彼を同じページにリダイレクトします...

これが私がしたことです...

public abstract class BasePage : System.Web.UI.Page
{
    protected override object LoadPageStateFromPersistenceMedium()
    {
        try
        {
            .. return the base, or make here your decompress, or what ever...
            return base.LoadPageStateFromPersistenceMedium();            
        }
        catch (Exception x)
        {
            string vsString = Request.Form[__VIEWSTATE];
            string cThePage = Request.RawUrl;

            ...log the x.ToString() error...
            ...log the vsString...
            ...log the ip coming from...
            ...log the cThePage...

        // check by your self for local errors
            Debug.Fail("Fail to load view state ! Reason:" + x.ToString());
        }

        // if reach here, then have fail, so I reload the page - maybe here you
        // can place somthing like ?rnd=RandomNumber&ErrorId=1 and show a message
        Responce.Redirect(Request.RawUrl, true);        

        // the return is not used after the redirect
        return string.Empty;
    }    
}

第二の理由

これが発生する理由はもう 1 つあります。その理由は、__EVENTVALIDATION が読み込まれる前にページが 1 回クリックされたためです。

この eventValidation は、asp.net が見つけた最後のボタンにも配置されます。ページの多くの場所またはボタンの近くにそれらのいくつかがある場合、これはページの最後に移動します。

したがって、ページの上部にビューステートが表示されていても、検証はどこにありますか??? おそらくこれはロードされていません - ページが壊れていますか? ユーザーがページをクリックするのが速すぎますか?

<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" ... >

この種の問題を回避するために、この入力がロードされていない限りボタンを押さないようにする単純な JavaScript を作成しました!!!.

もう1つのコメント、__EVENTVALIDATIONは常に存在するとは限りません! したがって、一般的な解決策を作成する場合は、このフィールドを検索しない方が安全かもしれませんが、ページ全体が読み込まれているかどうかを確認するための JavaScript トリックを作成するか、他の何かを考えてください。

jQuery を使用した最終的な解決策は次のとおりです (eventvalidation が存在する場合は PageLoad をチェックすることに注意してください!)。これをMasterPagesに配置しました。

<script language="javascript" type="text/javascript">
    function AllowFormToRun()
    {
        var MyEventValidation = $("#__EVENTVALIDATION");

        if(MyEventValidation.length == 0 || MyEventValidation.val() == ""){
            alert("Please wait for the page to fully loaded.");
            return false;
        }

        return true; 
    }       
</script>

protected void Page_Load(object sender, EventArgs e)
{
    // I do not know if Page can be null - just in case I place it.
    if (Page != null && Page.EnableEventValidation)
    {
        Form.Attributes["onsubmit"] = "return AllowFormToRun();";
    }
}

ページのボタンの近くに遅延を配置してテストできます。

<% System.Threading.Thread.Sleep(5000); %>

アップデート

今日、WebResource のログにこのメッセージが再び表示されます。ボットがページを取得し、リンク上のすべての文字をパラメーターを含めて小文字にすることを発見したため、これが正しいエンコードされた文字列を取得できないもう 1 つの理由でした。 、およびPadding is invalid and cannot be removedのようなメッセージをスローします。

これがさらに役立つことを願っています。

于 2010-03-31T09:38:20.650 に答える
4

エラー メッセージのいくつかのキーワードで見つかった Web ページを調査したところ、このタイプのエラーは比較的一般的であり、通常は (少なくとも外観上) ランダムであり、残念ながら明示的な回避策や説明が含まれていることはめったにありません...

類似しているが異なる状況が多数存在することは、おそらく非常に多くの異なるアーキテクチャと基本的な構成に関連しており、暗号層が要求ページで MAC (メッセージ認証コード) の信頼性を主張できなくなる可能性があります。

  • サーバー ファームのセットアップ
  • クロスドメイン / シンジケート ページ
  • サードパーティのウィジェット ライブラリなど
  • 実際の ASP プログラム ロジック (もちろん)

これらのバグ レポートに関する比較的頻繁な「マーカー」の 1 つは、リソース リクエストに関する言及です (例: WebResource.axd )。このようなリクエストはログに記録され
ない ことが多いことに注意してください(あまり関心のないイベントでログ ファイルのサイズが大きくならないように)。このログ ファイルの不在と、ログ ファイルが頻繁にキャッシュされるという事実 (したがって、バグの比較的ランダムでまれな発生) は、バグのこの考えられる原因が「レーダーの下」にあることを説明する可能性があります。これはまた、バグを再現しようとする際に (ログで追跡中、リアルタイムなどで)、Web ブラウザーがキャッシュしないようにする (または少なくとも最初にキャッシュをクリアする) ことが役立つ可能性があることを示唆しています。

要するに、ここにいくつかのアイデアと探すべきものがあります:

  • *.axd リクエストのログ記録を開始します
  • そのような axd リクエストを、例外ログのエラー イベントと関連付けてみてください。
  • リソース参照のあるページを探す
  • ファーム設定の場合は、すべてのインスタンスが同じキーを使用していることを確認してください (明らかに、複数の IIS サーバーの質問のヒントで提供されているスニペット)。
  • サードパーティと提携しているページ (検索サービス、アフィリエイト プログラムなど) を疑ってください。

お役に立てれば ;-)

于 2010-03-31T04:22:50.900 に答える
2

問題が暗号化に関連していて、ViewState が大きすぎることが原因ではないことを確認してください。ViewState が問題の場合は、チャンクできます - web.config の pages / MaxPageStateFieldLength の値を変更します

于 2010-03-25T21:36:06.940 に答える