Криптографическое исключение:Заполнение недопустимо и не может быть удалено, а проверка viewstate MAC завершилась неудачей
-
10-07-2019 - |
Вопрос
Мониторинг моих глобальных журналов исключений эту ошибку, похоже, невозможно удалить, что бы я ни делал, я думал, что наконец-то избавился от нее, но она вернулась снова.Вы можете увидеть трассировку ошибки на похожий пост здесь.
Заметки об окружающей среде:
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