CryptographicException：パディングは無効であり、削除できず、ビューステートMACの検証に失敗しました

StackOverflow https://stackoverflow.com/questions/1821243

質問

グローバル例外ログを監視すると、このエラーは私が何をしても削除することは不可能であるように思われます。 同様の投稿はこちら。

環境に関する注意：

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で生成されたすべての非表示フィールドがページの上部に正しく表示されていることがわかります。

役に立ちましたか？

解決

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

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

だから誰かがアクションを行う、男をエーテルにする、ページを「クリックする」ことで他の検索マシンをエーテルする、またはハッカーがシステムの問題をチェックしようとする...

私は同様の問題を抱えています（まれですが、既存のもの）。そして、最終的に、人々が私のページをハックテストしようとすることに気付きました。 （私が持っているのと同じ攻撃からの攻撃）

私はビューステートを変換する関数 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;
    }    
}

第2の理由

今、これが発生する理由がもう1つあります。その理由は、__ EVENTVALIDATIONがロードされる前にページをクリックするからです。

この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つの理由があり、パディングが無効で削除できないなどのメッセージをスローします。

これがあなたのお役に立てば幸いです。

他のヒント

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

多くの類似したまだ異なる状況の存在は、おそらく非常に多くの異なるアーキテクチャと基本的な構成に結びついており、何らかの理由で暗号化層がMACの真正性を主張することができなくなる可能性があります（メッセージ認証コード）リクエストページ：

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

1つの比較的頻繁な「マーカー」これらのバグレポートの周りには、リソースリクエストの言及があります（例： WebResource.axd ）。
このようなリクエストは、多くの場合ログに記録されないことに注意してください（ログファイルのサイズが比較的興味のないイベントで膨らまないように）。ログファイルが存在しないことと、ログファイルが頻繁にキャッシュされるという事実（したがって、バグが比較的ランダムで頻繁に発生しないこと）により、このバグの原因が「レーダーの下」にあることがわかります。これは、バグを再現しようとする場合（ログの追跡中、リアルタイムなど）に、Webブラウザーがキャッシュしないようにすること（または少なくとも最初にキャッシュをクリアすること）が役立つことを示唆しています。

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

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

これが役立つことを願って;-）

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

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top