Логнали сте се в дадено приложение. Но тъй като създателят му не се е погрижил да ви защити, някой злонамерен хакер може да използва своя сайт, за да управлява вашето поведение. Така например би могъл да си прехвърли пари, да ви смени имейла и какви ли още не пакости.
Ето че след като в блога на ZETTAHOST.bg вече демистифицирахме страшно звучащите заплахи за онлайн сигурността DDoS, SQL Injection и XSS, дойде време същото да се случи и с CSRF.
Парола назаем
Понякога можете да я намерите и като XSRF, „кражба на сесия“ или „атака с един клик“. Cross-Site Request Forgery, откъдето идва съкращението, най-грубо би могло да се преведе като „междусайтово фалшифициране на заявки“. Разбира се, в онлайн света и конкретно стане ли дума за сигурността в мрежата, почти винаги терминологията стига до английския, така че сред всички специалисти тази заплаха си остава по-известна просто като CSRF. А много по-важно от точния ѝ превод е това, което стои зад нея.
Обикновено този тип атака включва и някакъв елемент на социално инженерство. Чрез имейл или чат хакерът ни изпраща съобщение, с което по някакъв начин ни убеждава да кликнем на даден линк, който пък да използва факта, че в момента имаме отворен друг таб, където сме логнати например на сайта на банката ни. В други случаи пък линкът се намира на сайт, на който хакерът по някакъв начин е отвел потребителя.
Още по-„дебела“ става работата, ако по този начин е таргетиран администраторът на даден сайт. Обикновено достъпът до по-чувствителни страници, като например банковите, е с кратко време. За всяко плащане се изисква 2-факторна автентикация например с есемес. Докато администраторите на сайтове рядко имат подобни защити, тъй като те доста биха ги забавяли в работата им. Ето защо особено внимателни за подобна атака трябва да бъдете, ако сте собственик или администратор на сайт.
Има токен, няма токен
На български си има дума, която е точен превод на английското token. „Жетон“ – идеята е, че когато например сте на театър и излезете за малко, ви го дават, така че връщайки се, да удостоверите, че вече сте минали веднъж процеса по проверка на билета. Е, точно за същото служат и token-ите на уебсайтовете. Само че, за добро или лошо, на български почти няма да чуете някой да ги нарича „жетони“, а не „токени“.
Така или иначе, функцията им е същата – след като веднъж сте влезли с потребителското име и паролата си, сайтът ви връща този обикновено доста дълъг хаширан стринг (или „низ“, след като вече се заиграхме с преводите). После вие го използвате във всяка заявка, за да се знае, че сте същият логнат потребител, който има определени права на сайта. Без да се налага за всяка заявка към бекенда да изпращате отново потребителско име и парола. Разбира се, не се очаква от вас да го правите ръчно – браузерът ви знае добре как да се погрижи.
Именно към тези токени е насочена CSRF атаката. Когато сайтът получи заявка, включваща вашия токен, той няма как да знае, ако хакерът по някакъв начин е стигнал до него и се представя за вас. Заявките най-често са за промяна на някакви данни, а не такива, които връщат важна информация – защото тя отново би се появила в браузъра на жертвата, а не на хакера.
Има и малко по-усъвършенстван вариант, при който атакуващият успява да „запази“ резултата от атаката за себе си – това се получава, ако намери вариант да съхрани външен код, обикновено в тага iframe, който приема html.
Пари при пари отиват
Нека разгледаме нещата и в малко повече конкретика, включително и с примери. Ето един вариант как точно изглежда подобна атака.
Първо хакерът трябва да разбере как да генерира валидна зловредна заявка, която жертвата да изпълни. За целта се започва с внимателно проучване на сайта, който ще бъде използван. Ако например жертвата иска да преведе пари онлайн, хакерът трябва да разбере как точно изглежда изпращаната заявка, така че единствено да смени в нея полето за банковата сметка на получателя с това, което иска. Или пък да го допълни с увеличаване на сумата.
Ако например оригиналната заявка изглежда така:
GET http://bank.bg/transfer.do?acct=IVAN&amount=100
То заявката, която ще я подмени, би могла да бъде:
GET http://bank.bg/transfer.do?acct=HACKER&amount=100000
И в този момент идва ред на социалното инженерство – как едната заявка да бъде подменена с другата. Например, ако човек не провери какво се крие зад линка в имейл, който убедително наподобява такъв от приятел:
<a href=“http://bank.bg/transfer.do?acct=HACKER&amount=100000″>Виж какви яки снимки направих!</a>
Или пък в скрит таг за снимка:
<img src=“http://bank.bg/transfer.do?acct=HACKER&amount=100000″ width=“0″ height=“0″ border=“0″>
Както вече стана дума, друг вариант е в страница на атакуващия да бъде скрит скрипт, който „отприщва“ този тип заявка, например:
<script>
function put() {
var x = new XMLHttpRequest();
x.open(„PUT“,“http://bank.com/transfer.do“,true);
x.setRequestHeader(„Content-Type“, „application/json“);
x.send(JSON.stringify({„acct“:“HACKER“, „amount“:100000}));
}()
</script>
<body onload=“put()“>
През ръцете
Преди време се смяташе за възможна стратегия срещу проблема създаването на сайтове, които приемат само POST заявки. Това обаче се оказа, че не работи, защото атакуващите има как да използват и тях за CSRF удара си. Например като накарат жертвата да попълни форма на техния сайт, която да задвижи атаката.
За щастие, браузърите също вече са доста по-готови за такъв тип атаки и в повечето случаи биха ги „уловили“. И все пак, винаги е добре да имаме едно наум. Правилото, което ни помага в този случай, се нарича same-origin policy restrictions – ограничение за заявки от един и същи произход. С други думи – заявките от един сайт да не могат да се пренасочват към друг със същите токени.
От една страна, за да избегнем всички рискове, достатъчно е да сме внимателни, когато се стигне до опит за социално инженерство. Онлайн човек винаги трябва да има едно наум в комуникацията си, защото атакуващите наистина могат да проявят доста изобретателност. Да са впечатляващо убедителни. (Още много по темата – четете тук).
Код като слънце
На второ място идва сигурният компютърен код на уеб приложението. За щастие, повечето днешни фреймуърци, на които се създават сайтовете, имат вградена защита срещу CSRF атаки. Като се започне от трите водещи JavaScript решения – Angular, React и Vue, и се стигне до Spring, Ruby on Rails и .NET. Опасност може да има обаче, ако например решите да създадете част от проекта си, без да използвате фреймуърк. Или ако, разбира се, в тази вградена защита има пропуски. А също и – ако нарочно или без да искате, свалите защитата за заявки от същия сайт – тъй като понякога наистина се налага, всички фреймуърци имат варианти за временно изключване.
Извън тези изключения обаче, атаката трудно би могла да се случи, ако се спрете на достатъчно популярно софтуерно решение като например тези, споменати по-горе. Те блокират заявките между различни сайтове, така че не е възможно атакуващият да използва жетончето ви, за да се представи за вас.
Стой на сухо
И все пак, важно е да знаем какви са рисковете. А в блога на ZETTAHOST.bg, както може би сте забелязали, обръщаме сериозно внимание на сигурността.
Вече ви разказахме за социалното инженерство и за друга от „човешките“ страни на темата – „белите хакери“. Спряхме се на технологии като VPN и IoT и опасностите, които идват от това, че ги използваме.
Както и този път, минаваме една по една през най-честите атаки на технологично ниво – до момента в списъка ни попаднаха DoS и DDoS, SQL Injection, Cross-site Scripting, преди сега да стигнем до CSRF.
Това, което ние ви обещаваме, е сигурен хостинг, където са взети всички възможни мерки за вашата сигурност. Опитайте го напълно безплатно тук!
