Заобикалянето на криптографската уязвимост на ASP.NET ГОЛЯМА ЛЪЖА ли е?

re:

Как това има отношение към това дали са пренасочени към 200, 404 или 500? Никой не може да отговори на това, това е основният въпрос. Ето защо аз наричам глупости да се налага да правите това като глупост с персонализираните грешки, които връщат 200. Просто трябва да върне едни и същи 500 страници и за двете грешки.

Не мисля, че това беше ясно от първоначалния въпрос, ще го разгледам:

кой каза, че грешките трябва да връщат 200? това не е наред, просто се нуждаете от всички грешки, за да върнете един и същ код, като накарате всички грешки да връщат 500 също ще работи. Конфигурацията, предложена като решение, току-що използва 200.

Ако не направите заобиколното решение (дори ако това е ваша собствена версия, която винаги връща 500), ще видите 404 срещу 500 разлики. Това е особено вярно в webresource.axd и scriptresource.axd, тъй като декриптираните невалидни данни са липсващ ресурс / 404.

Само защото не знаете коя функция е имала проблема, не означава, че няма функции в asp.net, които дават различни кодове на отговор в различни сценарии, които се отнасят до подпълване спрямо невалидни данни. Лично аз не мога да съм сигурен дали има друга функция, която също дава различен код на отговор, просто мога да ви кажа, че тези 2 го правят.

Може ли някой да обясни защо връщането на същата страница за грешка и същия код на състояние за персонализирани грешки има значение? Намирам това за несъществено, особено ако това се препоръчва като част от работата по него.

Шри вече отговори много ясно на това във въпроса, към който поставихте връзка.

Не става въпрос за скриване на възникнала грешка, а за гарантиране, че нападателят не може да различи грешките. По-конкретно става дума за гарантиране, че атакуващият не може да определи дали заявката е неуспешна, защото не може да декриптира /padding е невалиден, или защото декриптираните данни са боклук.

Можете да спорите: добре, но мога да се уверя, че това не е боклук за приложението. Разбира се, но ще трябва да намерите механизъм в приложението, който ви позволява да направите това, и начинът, по който работи атаката, вие Винаги се нуждаете от поне малко боклук във входящото съобщение. Помислете за тези:

• ScriptResource и WebResource хвърлят, така че персонализираната грешка я скрива.
• Състоянието на изглед по подразбиране е Нешифровано, така че по подразбиране не включва вектора на атака. Ако имате проблеми с включването на криптирането, тогава много вероятно сте го настроили да го подпише/валидира. Когато случаят е такъв, неуспехът при дешифриране и неуспехът при валидиране е един и същ, така че атакуващият отново не може да знае.
• Билетът за удостоверяване също се подписва, така че е като сценария за състояние на преглед
• Сесийните бисквитки не са криптирани, така че са без значение

Публикувах в моя блог как атаката стига толкова далеч, че може да фалшифицира бисквитки за удостоверяване.

Не е ли също толкова лесно за скрипта/приложението да изпълни тази атака и да не се интересува дали ще получи или не http статус код и повече за резултата? Т.е. правейки това 4000 пъти, вие ще бъдете пренасочени към страница за грешка, където на 4001 оставате на същата страница, защото не е обезсилила подложката?

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

Или Fail, те са на страница и viewstate не съдържа техните данни. Без значение какво правите тук, няма начин да премахнете случая на неуспех, защото страницата просто никога няма да съдържа техните вмъкнати данни, освен ако те успешно не са разбили ключа. Ето защо не мога да обоснова, че използването на персонализирани грешки има ИЗОБЩО НИКАКЪВ ЕФЕКТ.

Или Pass, те са на страница и viewstate съдържа техните вмъкнати данни.

Прочетете какво споменах за състоянието на изгледа по-горе. Също така имайте предвид, че способността за по-точно повторно криптиране се придобива, след като те придобият способността да декриптират. Въпреки това, както бе споменато по-горе, по подразбиране състоянието на изглед не е по този начин и когато е включено, обикновено се придружава от подпис/потвърждение.

Ще обясня подробно моят отговор в нишката, която споменахте.

За да издържи атаката, приложението трябва да отговори по три различни начина. Тези три различни начина могат да бъдат всякакви - кодове на състоянието, различно html съдържание, различно време за реакция, пренасочвания или какъвто и да е творчески начин, за който се сетите.

Ще повторя отново - нападателят трябва да може да идентифицира три различни отговора, без да направи грешка, в противен случай атаката няма да работи.

Сега стигаме до предложеното решение. Работи, защото намалява трите резултата само до два. Как става това? Страницата за всички грешки прави всички кодове на състоянието/html/пренасочване да изглеждат идентични. Случайното забавяне прави невъзможно разграничаването между едното или другото само въз основа на времето.

Така че не е лъжа, работи както се рекламира.

Атаката, която се обсъжда, позволява на атакуващия да намали тези милиарди заявки до няколко хиляди. Това е възможно поради 3-те различни състояния на отговор. Предлаганото заобиколно решение намалява това обратно до атака с груба сила, която е малко вероятно да успее.

Заобиколното решение работи, защото:

• Не давате никаква индикация за това „докъде“ ви е отнело леко коригираното. Ако получите друго съобщение за грешка, това е информация, от която можете да се поучите.
• Със закъснението криете колко време е отнело действителното изчисление. Така че не получавате информация, която показва дали сте навлезли по-дълбоко в системата, от която можете да се поучите.

Не, не е голяма лъжа. Вижте този отговор във въпроса, който посочихте за добро обяснение.