Обходит ли криптографическая уязвимость ASP.NET БОЛЬШАЯ ЛОЖЬ?

re:

Как это имеет отношение к тому, перенаправляются ли они на 200, 404 или 500? Никто не может ответить на этот вопрос, это принципиальный вопрос. Вот почему я вызываю махинации с необходимостью проделать эту дурацкую шутку с пользовательскими ошибками, возвращающими 200. Просто нужно вернуть одну и ту же страницу 500 для обеих ошибок.

Я не думаю, что это было ясно из исходного вопроса, я отвечу на него:

кто сказал ошибок нужно возвращать 200? это неправильно, вам просто нужно, чтобы все ошибки возвращали один и тот же код, и все ошибки, возвращающие 500, также будут работать. Конфигурация, предложенная в качестве обходного решения, просто использует 200.

Если вы не сделаете обходной путь (даже если ваша собственная версия всегда возвращает 500), вы увидите различия 404 и 500. Это особенно верно для webresource.axd и scriptresource.axd, поскольку дешифрованные недопустимые данные - это отсутствующий ресурс / 404.

Тот факт, что вы не знаете, в какой функции возникла проблема, не означает, что в asp.net нет функций, которые дают разные коды ответов в разных сценариях, которые относятся к заполнению или недопустимым данным. Лично я не могу быть уверен, есть ли какая-либо другая функция, которая также дает другой код ответа, я просто могу сказать вам, что эти 2 имеют.

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

Шри уже очень четко ответил на этот вопрос в вопросе, который вы связали.

Дело не в том, чтобы скрыть произошедшую ошибку, а в том, чтобы убедиться, что злоумышленник не может различить ошибки. В частности, необходимо убедиться, что злоумышленник не может определить, не удалось ли выполнить запрос, потому что он не может расшифровать / заполнение было недопустимым, или потому что расшифрованные данные были мусором.

Вы можете возразить: хорошо, но я могу убедиться, что это не мусор для приложения. Конечно, но вам нужно будет найти в приложении механизм, который позволит вам это сделать, и способ работы атаки. Всегда нужен хотя бы крошечный кусочек мусора во входящем сообщении. Обратите внимание на это:

• И ScriptResource, и WebResource выбрасывают, поэтому настраиваемая ошибка скрывает это.
• Состояние просмотра по умолчанию не зашифровано, поэтому по умолчанию его вектор атаки не задействован. Если у вас возникнут проблемы с включением шифрования, вы, скорее всего, настроите его для подписи / проверки. В этом случае отказ от дешифрования и отказ от проверки одинаковы, поэтому злоумышленник снова не может знать.
• Аутентификационный билет также подписывается, так что это похоже на сценарий состояния просмотра
• Сессионные файлы cookie не зашифрованы, поэтому это не имеет значения.

Я разместил в своем блоге насколько далеко заходит атака, например, возможность подделать файлы cookie аутентификации.

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

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

Либо Fail, они находятся на странице, и состояние просмотра не содержит их данных. Независимо от того, что вы здесь делаете, невозможно удалить случай сбоя, потому что страница просто никогда не будет содержать их вставленные данные, если они не взломали ключ. Вот почему я не могу оправдать использование пользовательских ошибок, имеющих КАКОЙ-ЛИБО ВЛИЯНИЕ.

Или Pass, они находятся на странице, а состояние просмотра содержит их вставленные данные.

Прочтите, что я упомянул о состоянии просмотра выше. Также обратите внимание, что возможность более точного повторного шифрования появляется после того, как они получили возможность дешифровать. Тем не менее, как упоминалось выше, по умолчанию состояние просмотра не такое, и когда оно обычно сопровождается подписью / проверкой.

Я собираюсь подробнее рассказать о мой ответ в теме, на которую вы ссылались.

Чтобы отразить атаку, приложение должно отреагировать тремя разными способами. Эти три различных способа могут быть любыми - кодами состояния, разным HTML-контентом, разным временем отклика, перенаправлениями или любым другим творческим способом, который вы можете придумать.

Повторюсь еще раз - злоумышленник должен уметь безошибочно идентифицировать три различных ответа, иначе атака не сработает.

Теперь переходим к предлагаемому решению. Это работает, потому что сокращает три результата до двух. Как оно это делает? На странице общих ошибок все коды состояния / html / redirect выглядят одинаково. Случайная задержка не позволяет отличить одно от другого только по времени.

Так что это не ложь, это работает так, как рекламируется.

Обсуждаемая атака позволяет злоумышленнику сократить эти миллиарды запросов до нескольких тысяч. Это возможно благодаря 3 различным состояниям ответа. Предлагаемый обходной путь сводит это обратно к атаке методом перебора, который вряд ли увенчается успехом.

Обходной путь работает, потому что:

• Вы не даете никаких указаний на то, "как далеко" вас занесло немного скорректированное. Если вы получите другое сообщение об ошибке, это информация, из которой вы можете извлечь пользу.
• С задержкой вы скрываете, сколько времени занял фактический расчет. Таким образом, вы не получаете информации, которая показывает, если вы углубились в систему, из которой вы можете извлечь уроки.

Нет, это не большая ложь. См. этот ответ в вопросе, на который вы указали хорошее объяснение.