Риск от използване на постоянна бисквитка XSRF-TOKEN в Angular

Това е свързано с този въпрос CSRF защита за Refresh Token Cookie в SPA

Искам да използвам препоръчания механизъм за бисквитки XSRF-TOKEN, за да защитя друга бисквитка HttpOnly. За този сценарий трябва да направя бисквитката XSRF-TOKEN постоянна, защото тя трябва да е достъпна при стартиране на приложението след презареждане. Реализацията по подразбиране в Angular $http търси само в сесийни бисквитки.

Какви са рисковете, ако направя бисквитката постоянна и ръчно задам HTTP заглавката X-XSRF-TOKEN?


javascript security angularjs csrf
person hansmaad    schedule 05.06.2015    source източник

Отговори (3)


arrow_upward
3
arrow_downward

Какви са рисковете, ако направя бисквитката постоянна и ръчно задам HTTP хедъра X-XSRF-TOKEN?

Рискът е, че нападателят може в крайна сметка да принуди стойността на токена.

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

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

Можете също така да вградите някаква защита от груба сила. Например, след 10 заявки, направени с невалиден CSRF токен, можете да прекъснете сесията и след това да информирате потребителя, че е излязъл. Това ще смекчи атаката с груба сила, но преобразува атаката в атака за отказ на услуга, тъй като злонамереният уебсайт ще успее да излезе от потребителя. Следователно трябва да проследите това, като се свържете с потребителя и го информирате, че сайт, който посещават, се опитва да го компрометира (можете да проверите регистрационните файлове на вашия сървър, за да определите заглавките referer и origin).

person SilverlightFox    schedule 08.06.2015
comment
Ще генерирам нов токен за нова сесия, но бисквитката ще остане до следващото стартиране на приложението. Така че сте прав, една и съща бисквитка е валидна за по-дълго време и дава повече време за груба сила на токена. Благодаря ви за оценката - person hansmaad; 08.06.2015

arrow_upward
0
arrow_downward

Ако изберете да използвате постоянни бисквитки, все още ще бъдете уязвими за CSRF атаки, тъй като браузърът ще изпраща тези бисквитки със заявките

За angularjs, следното е това, което използвам в моето SPA приложение; CSRF токен се генерира от бекенд сървъра и се предава като заглавка само в заявката за файла index.html. от тази точка angular е конфигуриран да добавя токена в заглавката + в бисквитка на сесия - за всяка вътрешна $http.post/delete/put/... заявка

app.config(['$httpProvider', function ($httpProvider)
{
    $httpProvider.defaults.xsrfCookieName = 'csrftoken';
    $httpProvider.defaults.xsrfHeaderName = 'X-CSRFToken';
}]);

Тествайте го

използвайте този малък фрагмент, за да тествате ръчно своя API:

<!DOCTYPE html>
<html>
   <head>
        <script>
            function csrf(id)
            {
                document.getElementById("csrf-form-" + id).submit();
            }
        </script>
   </head>
   <body>
        <form method="POST" action="http://127.0.0.1:8080/api/test" enctype="text/plain" target="_blank" id="csrf-form-1">
           <input name='{"protected":false, "ignore_me":"' value='test"}'type='hidden'>  
        </form>

        <button onclick="csrf(1)"}>CSRF!</button>
   </body>
</html>
person Jossef Harush    schedule 05.06.2015
comment
Приложението ми се зарежда от AppCache, така че това няма да работи. Искам бисквитката да е налична при първа заявка. Не разбирам аргумента ви срещу постоянната бисквитка. Каква е разликата между постоянен XSRF-TOKEN и само една сесия? Това е моят въпрос. - person hansmaad; 05.06.2015
comment
Йосеф е прав, постоянната бисквитка все още ви оставя отворени за CSRF - person Juxhin; 05.06.2015
comment
Как този тест ще зададе изискваната X-XSRF-TOKEN HTTP заглавка, съдържаща CSRF токена? - person hansmaad; 08.06.2015

arrow_upward
0
arrow_downward

CSRF атака работи на незащитен сайт, в който потребителят е влязъл. Помислете за сайт S, който използва бисквитка за сесия C (и нищо друго), за да идентифицира сесията на потребителя. Това означава, че браузърът ще изпрати C при всяка заявка до S. Тъй като наличието на сесийната бисквитка е всичко, което е необходимо за потвърждаване на сесия, потребителят ще бъде влязъл, когато получи достъп до S. Това е страхотно. Точно това, което искаме.

С изключение...

Да приемем, че S can е уебсайт, който може да изпраща пари в брой чрез URL като https://S/email-cash?email=recipient@examplecom. Зъл уебсайт E може да е вградил връзката https://S/email-cash?email=ATTACKER@examplecom в една от страниците си. Сега, когато потребителят разглежда сайт E, докато е влязъл в сайт S и щракне върху тази връзка, в крайна сметка ще изпрати пари на нападателя по имейл. Дори по-лошо, тази връзка може да бъде изпълнена в JavaScript зад кулисите, така че потребителят трябва само да посети сайт E. Много лошо.

Проблемът възниква, защото всяка заявка, придружена от валидна бисквитка C за идентификатор на сесия, се третира като валидна заявка. Решението е да се изиска от браузъра да изпрати част от идентификатора, който е могъл да получи съвсем наскоро от сайт S. Това е CSRF токенът. Няма начин браузърът да го получи, освен ако не му е дадено от S и S ще го даде само когато обслужва страница, а не за атака между сайтове.

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

person Neil Smithline    schedule 05.06.2015
comment
Благодаря за въведението в основите на csrf:) Но действителният въпрос беше за разликата между сесийната бисквитка и постоянната бисквитка за съхраняване на CSRF токена. Последното ви изречение не е ли вярно за токен в сесийна бисквитка, използвана в приложения на AngularJs? - person hansmaad; 08.06.2015