Криптографическое исключение:Заполнение недопустимо и не может быть удалено, а проверка viewstate MAC завершилась неудачей

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

Вопрос

Мониторинг моих глобальных журналов исключений эту ошибку, похоже, невозможно удалить, что бы я ни делал, я думал, что наконец-то избавился от нее, но она вернулась снова.Вы можете увидеть трассировку ошибки на похожий пост здесь.

Заметки об окружающей среде:

IIS 6.0, .NET 3.5 с пакетом обновления 1 единый сервер 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 .

Также я должен сказать , что я сделал все, что каждый из них предлагает , чтобы избежать этой проблемы. И у меня есть одна машина, но 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;
    }    
}

Вторая причина

Теперь есть еще одна причина, по которой это может произойти, и причина в том, что кто-то одним щелчком мыши на вашей странице загружает __EVENTVALIDATION.

Это событие EventValidation помещается на последнюю кнопку, даже найденную asp.net, и если у вас есть некоторые из них на многих местах на странице или рядом с кнопкой, то это происходит в конце страницы.

Таким образом, даже если вы видите состояние просмотра в верхней части страницы, где находится проверка ??? может быть, это никогда не загружалось - страница повреждена?, слишком быстрый пользователь нажимает на страницу? 

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

Чтобы избежать подобных проблем, я сделал простой javascript, который не позволяет нажимать кнопку, если этот вход не был загружен !!!.

Еще один комментарий, __EVENTVALIDATION не всегда представляет! поэтому, может быть, безопаснее не искать это поле, если вы принимаете общее решение, но сделать трюк JavaScript, чтобы просто проверить, загружена ли полная страница, или что-то еще, что вы думаете.

Вот мое окончательное решение с помощью jQuery: (обратите внимание, что я проверяю на PageLoad, существует ли проверка событий!). Я разместил это на своих мастер-страницах. 

<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); %>

Update

Сегодня я снова вижу в журнале это сообщение для WebResource, и я обнаружил, что бот получает страницы и делает все символы в ссылках в нижнем регистре , включая параметры, так что это было еще одна причина, по которой вы не можете получить правильную закодированную строку, а сообщение типа Padding недопустимо и не может быть удалено.

Надеюсь, это поможет вам больше.

Другие советы

Обзор веб-страниц, найденных с несколькими ключевыми словами из сообщения об ошибке, показывает, что это Тип ошибки относительно распространены, обычно случайны (по крайней мере, на первый взгляд) и, к сожалению, редко содержат явный обходной маневр или объяснение...

Существование многих похожих, но разных ситуаций, вероятно, связано с очень многими различными архитектурами и базовыми конфигурациями, которые могут каким-то образом привести к неспособности криптоуровня утверждать подлинность MAC (кодов аутентификации сообщений) на страницах запросов:

  • Настройка фермы серверов
  • Междоменные / синдицированные страницы
  • сторонние библиотеки виджетов и тому подобное
  • Фактическая логика программы ASP (конечно)

Одним из относительно частых "маркеров" в этих отчетах об ошибках является упоминание запросов на ресурсы (например. Вебресурс.axd).
Обратите внимание, что такие запросы часто не зарегистрирован (чтобы они не увеличивали размер файлов журнала из-за события, представляющего относительно небольшой интерес).Это отсутствие в файле журнала и тот факт, что они часто кэшируются (и, следовательно, относительно случайное и нечастое возникновение ошибки), могут объяснить, почему это возможное происхождение ошибки остается "незамеченным".Это также говорит о том, что при попытке воссоздать ошибку (при отслеживании в журналах, в режиме реального времени и т.д.) Может быть полезно запретить веб-браузеру кэширование (или, по крайней мере, изначально очистить его кеш).

Короче говоря, вот несколько идей и вещей, на которые стоит обратить внимание:

  • начните регистрировать запросы *.axd
  • попробуйте связать такие запросы axd с событиями ошибок в журнале исключений
  • ищите страницы со ссылками на ресурсы
  • если в настройках фермы, убедитесь, что все экземпляры используют один и тот же ключ (очевидно, фрагмент, приведенный в вопросе, указывает на несколько серверов IIS)
  • С подозрением относитесь к страницам со сторонними ссылками (поисковые сервисы, партнерские программы ...)

Надеюсь, это поможет ;-)

Вы уверены, что ваша проблема связана с криптографией, а не вызвана слишком большим ViewState? Если проблема с ViewState, вы можете разделить ее на части - измените значение pages / MaxPageStateFieldLength в web.config

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top