Подправяне на заявка между сайтове

Подправяне на заявки между сайтове (XSRF) е атака, при която сайтът на нападателя представя на потребителя формуляр, който при подаване изпраща заявка до уязвимо приложение. Уязвимото приложение обработва заявката нормално, тъй като най-често измаменият потребител остава удостоверен за уязвимия сайт.

В тази ситуация уязвимият сайт няма начин да разбере дали подадената заявка е дошла от самия него, което е нормално поведение, или от сайт на трета страна. Проблемът с ASP.NET MVC е как да предоставите етикет за защитен сайт, който той може да използва, за да гарантира, че заявките се генерират само от страниците, които той контролира.

XSRF в действие

Включихме работеща демонстрация на XSRF в примерния код за тази глава. Отново в решението има два сайта: уязвимия и нападателя. Уязвимият сайт приема просто подаване на формуляри.

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

Нашият атакуващ сайт е показан на Фигура 8-7. Този бутон просто моли за щракване.

Зад кулисите, в недрата на HTML източника, се разказва съвсем различна история, както е показано в Листинг 8-1.

Линия един: Изпращане на формуляра на друг сайт

Когато потребителят щракне върху бутона, формулярът се изпраща. Сега дори AuthorizeAttribute не може да ни спаси, вече сме влезли в системата! Резултатът е показан на Фигура 8-8.

Предотвратяване на XSRF

Прилагането на ValidateAntiForgeryTokenAttribute към действие изисква входът да бъде придружен от специален маркер, който гарантира, че той идва само от отговарящото приложение. Атрибутът трябва да бъде последван от специален HTML помощен метод, който извежда маркера във формата във HTML източника.

Следният код показва атрибут, приложен към нашето уязвимо действие:

Според нас можем да използваме помощния метод AntiForgeryToken:

Когато маркерът и атрибутът са зададени, данните, изпратени от сайта, който има както маркера, така и атрибута, ще бъдат приети, но нападателите няма да могат да формулират XSRF атаки. Ако се опитат, ще бъде хвърлено изключение, както е показано на фигура 8-9.

Сега е подходящият момент да приложите ValidateAntiForgeryTokenAttribute към действия, които приемат данни от формуляри. Както публичните, така и интранет сайтовете са уязвими към XSRF, така че това е от съществено значение за разработването на защитени приложения.

В следващия раздел ще разгледаме атаката за отвличане на JSON, която също изисква разработчиците да използват ASP.NET MVC за определени предпазни мерки.

Атака за отвличане на JSON

Атаката за отвличане на JSON е подобна на XSRF в много отношения, с изключение на това, че е фокусирана върху искането на защитени JSON данни от уязвими приложения, достъпни от по-стари браузъри. Атаката за отвличане на JSON включва няколко етапа:

Забележка

Съвременните браузъри (като Firefox 4, Chrome 12 и Internet Explorer 9) не са уязвими към тези видове атаки, но потребителите, използващи по-стари версии на Firefox и Chrome, са потенциално уязвими към такива атаки.

За да предотвратите подобна атака от злонамерен сайт, трябва да се уверите, че крайните точки на JSON, които връщат чувствителни данни, не отговарят на GET заявки .

Разрешете достъп до JSON само чрез POST

Решението ASP.NET MVC за тази уязвимост е да приема само HTTP POST, а не GET заявки за JSON данни. Това решение е затворено и внедрено в стандартния JsonResult, който се доставя с рамката. Ако трябваше да поискате данните да бъдат върнати в JsonResult чрез GET заявка, нямаше да получите JSON данни.

Струни 2-4: Помощна функция за JSON POST

Струни 6-14: Скрипт, който попълва опциите за извличане

Линия 20.: Целева проба

Заменете настройките по подразбиране за GET достъп

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

Ако причинява проблеми, имате допълнителни опции. Първо, можете изрично да включите JSON заявки от GET методи със следния код:

Това ще позволи на вашето действие да отговаря на редовни заявки за JSON GET .

Второ, можете да фрагментирате самия JsonResult, като използвате резултата от действието, за да върнете само неуязвими JSON данни, които не са масив.

Модификация на JSON отговор

Кодът в Листинг 8-3 показва специален резултат от действието, който обгръща уязвимите JSON данни в d променливата. .

Струни 13-24: Задайте правилното кодиране

Линия тридесет: Обгръща уязвимите JSON данни в променлива

Линия 7: Използва променлива d

С това решение можем да използваме GET за извличане на JSON данните, но сега те са в безопасност, защото никога не са просто масив - всеки масив е обвит в променливата d. Просто трябва да получим стойностите чрез променливата d .