защитавашите приложения
В предишния брой говорих за важността на изграждането на сигурност в уеб приложенията и разгледах някои видове атаки, включително SQL инжектиране и модифициране на параметри, и обясних как да ги предотвратим (msdn.microsoft.com/magazine/hh580736). В тази статия ще обсъдим подробно две по-често срещани атаки: скриптове между сайтове (XSS) и фалшифициране на заявки между сайтове (CSRF).
Може би се чудите защо просто не използвате търговски скенер за ниво на сигурност? Скенерите са чудесен инструмент за разкриване на това, което е на повърхността, и са особено добри в анализирането на проблеми в конфигурациите на приложения и системи, но те не познават вашето приложение по начина, по който вие го знаете. Следователно е изключително важно да разберете потенциалните проблеми със сигурността, да отделите време за тестване на вашите приложения и да планирате работата по сигурността в жизнения цикъл на разработката на софтуер.
Междусайтови скриптове
Резултатът от XSS атака се използва по няколко начина, всички от които разчитат на изход без или невалидни екраниращи знаци.
Как се използва резултатът от тази атака? Резултатът от XSS атака се използва по няколко начина, всички от които разчитат на изход без или с невалидни екраниращи знаци. Да вземем случая на приложение, което трябва да покаже просто съобщение за състояние на потребителя. Обикновено това съобщение се изпраща в низ за заявка, както е показано нафиг. 1.
.png "защитавашите приложения")
Фиг. 1. Съобщение от низ на заявка
ТукОсновният експлойт е, че резултатите не са кодирани според стандарта HTML.
Нафиг. 1 можете да видите, че този URI приема параметър msg. Уеб страницата за този URI ще съдържа например следния код за просто записване на тази променлива в страницата без кодиране:
Ако заменим "Profile Saved" със скрипта, показан нафиг. 2, браузърът ще покаже функцията за предупреждение от скрипта, включен в низа на заявката. Основният експлойт тук е, че резултатите не са HTML-кодирани, така че "
HTML изходното кодиране убива тази атака в зародиш. В раздел. 1 изброява основните опции за кодиране на опасни данни.
Раздел. 1. Опции за кодиране в HTML
| ASP.NET (или MVC, или уеб формуляри) | |
| Уеб формуляри (синтаксис на ASP.NET 4) | |
| ASP.NET MVC 3 Razor | @съобщение |
| Обвързване на данни |
За съжаление синтаксисът за свързване на данни все още няма вграден синтаксис за кодиране; този синтаксис ще се появи в следващата версия на ASP.NET под формата на . За сега използвайте:
От библиотеката AntiXSS в пространството на имената на Microsoft.Security.Application:
Тези опции предотвратяват типа атака, показан в примера, и трябва да се използват във вашите приложения.
AntiXSS библиотеката е претърпяла много задълбочен редизайн.
Важно е да знаете вашите контроли. Кои кодират данни в HTML вместо вас и кои не? Например TextBox HTML кодира изобразения изход, но LiteralControl не. Това е важна разлика. Ако текстовото поле е зададено
след това изобразява текста правилно за страницата:
Когато използвате обвързване на данни в уеб формуляриотстраняването на уязвимостта е малко по-трудно. Вижте следния пример:
Той уязвим ли е? Не. Въпреки че изглежда, че кодът, заместен в низа, може да напише скрипт или да излезе извън границите на кавички, той всъщност е кодиран.
Какво ще кажете за това:
Той уязвим ли е? да Синтаксисът за обвързване на данни не предоставя HTML кодиране. Ето поправката:
Имайте предвид, че ако използвате Bind в този сценарий, няма да можете да го обвиете в Server.HtmlEncode поради факта, че зад кулисите Bind се компилира като две отделни извиквания. Този блок от код е грешен:
Подобна е ситуацията с обвързването на данни в ASP.NET MVC, където трябва да знаете дали HTML помощниците кодират текст. Такива методи за етикети и текстови полета изпълняват HTML кодиране. И така, следният код:
По-рано споменах AntiXSS. Текущата версия е 4.1 beta 1. AntiXSS библиотеката е претърпяла много цялостна ревизия и по отношение на сигурността предоставя по-ефективен HTML енкодер от този, който идва с ASP.NET. Не че нещо не е наред със Server.HtmlEncode, но основната му цел е да осигури съвместимост, а не сигурност. AntiXSS използва различен подход към кодирането. Научете повече на msdn.microsoft.com/security/aa973814.
За да активирате AntiXSS енкодера, просто изпълнете следното извикване:
ASP.NET MVC 4 добавя страхотна нова функция, която ви позволява да замените оригиналния ASP HTML кодер и да го замените с AntiXSS кодера. Към момента на писане на тази статия се нуждаете от версия 4.1; тъй като в момента е в бета версия, трябва да изтеглите кода, да го компилирате и да добавите библиотеката към вашето приложение като справка - всичко това отнема пет минути. След това добавете към вашитераздел web.config с този ред:
Сега всяко HTML-кодирано повикване, инициирано с помощта на някой от синтаксиса, посочен вTab. 1, включително синтаксиса на ASP.NET MVC 3 Razor, ще бъдат кодирани от библиотеката AntiXSS. Не е зле за свързана функционалност?
В резултат на това получавате следния изчистен ред, който след това се съхранява в базата данни:
ASP.NET MVC 4 добавя страхотна нова функционалност, която ви позволява да замените оригиналния ASP HTML енкодер.
Фалшифициране на заявка между сайтове
Какво е това? Фалшифицирането на междусайтови заявки (CSRF) (произнася се „морски сърф“) е атака, при която някой използва връзката на доверие между вашия браузър и уебсайт, за да изпълни команда в сесия на невинен потребител. Тази атака е малко по-трудна за разбиране, без да знаем подробностите, така че нека преминем направо към тях.
Как се използва резултатът от тази атака? Да кажем, че Джон се удостоверява като администратор на сайта PureShoppingHeaven. Този сайт има URL адрес само за администратор и към него може да бъде предадена информация за извършване на някаква операция, като например създаване на нов потребител, както е показано нафиг. 6.
.png "защитавашите приложения")
Ако нападател успее да накара Джон да поиска този URL чрез един от различни методи, неговият браузър ще поиска този URL от сървъра и ще му изпрати всяка информация за удостоверяване, която може да бъде кеширана или използвана от браузъра на Джон, като бисквитки за удостоверяване или други токени за удостоверяване, включително тези от Windows Authentication.
Това е прост пример, но CSRF атаките могат да бъдат много по-сложни и да включватформират POST команди в допълнение към GET заявките, както и други атаки като XSS едновременно.
По проект браузърът ще изпрати всички валидни бисквитки или информация за удостоверяване.
Всичко това се случва без знанието на Джон. Важно е да разберете, че браузърът е проектиран да изпраща всякакви валидни бисквитки или информация за удостоверяване. Забелязали ли сте някога, че вашият имейл клиент обикновено не изтегля изображения по подразбиране? Една от причините за това е да се предотврати CSRF. Ако получите HTML имейл с вграден етикет за изображение, както е показано по-долу, този URL ще бъде поискан и сървърът ще извърши подходящата операция, при условие че сте удостоверени на този уебсайт:
Ако случайно сте администратор на „вашия сайт“ и вече сте удостоверени в него, браузърът с радост ще му изпрати GET заявка с всички идентификационни данни. Сървърът вижда, че това е валидна заявка от удостоверен потребител и изпълнява тази заявка без ваше знание, тъй като клиентът за електронна поща не получава валиден отговор с изображение, което може да изобрази.
Как да предотвратите CSRF? За да предотвратите CSRF, започнете със следните правила.
Предотвратяването на атаки чрез уеб формуляри се прилага малко по-различно, отколкото за ASP.NET MVC. В случай на уеб формуляри е възможно да подпишете MAC атрибута за ViewState, който помага за защита срещу фалшификации, стига да не зададете EnableViewStateMac на false. Също така си струва да подпишете своето ViewState, като използвате текущата сесия и да предотвратите предаването на ViewState в низа на заявката, за да блокирате това, което някои наричат атака с едно щракване (Фигура 7 ).
Фиг. 7. Предотвратяване на атаки с едно кликване