Хакване на CSRF токени с помощта на CSS History Hack

Актуализация: Изследователите по сигурността Sirdarckcat и Gareth бяха достатъчно любезни да споделят кода за чист CSSF търсач, базиран тук. Това е по-скрито от моето PoC по-долу, което използва комбинация от JS и CSS. Така че, той ще работи, дори да деактивирате JavaScript и вече не сте в безопасност :(:( . За да направите този PoC по-отзивчив към клиента, трябва да използвате няколко CSS таблици стилове, използвайки командата import. Единственият проблем, който виждам при този чист CSS подход, е, че ще има мрежова латентност, свързана с големи ключови пространства, защото големият ви CSS таблица стилове ще трябва да бъде изтеглен от вашия браузър.


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

До сега, бе счетено, че е невъзможно нападателят да открие вашия CSRF токен, използвайки Brute Force Attacks на сървъра.

Причините са:

  1. Той генерира много шум в мрежата и е бавен. Така че най-вероятно защитната стена на IDS или Web App ще вземе злонамерено поведение и ще блокира вашия ip. Например, Base16 CSRF токен с дължина 5 знака (започващ със знак) ще генерира приблизително 393 216 заявки.
  2. Много приложения са програмирани да обезсили сесията си след като открие повече от определен брой заявки с невалидни стойности на маркера. Например 30.

Ще променя това убеждение, като ви покажа техника за бързо намиране на маркери csrf, без да генерирам сигнали. Тази техника е а клиентска атака, така че почти няма генериран мрежов трафик и следователно вашият сървър и защитни стени на IDS / Web App спечелиха’изобщо не го забелязвам. Тази атака се основава на популярния CSS History Hack, намерен от Jeremiah Grossman преди 3 години.

В този експлоатация откриваме токена csrf чрез груба принуждаване на различни набори URL адреси в историята на браузъра. Ще се опитаме да вградим различни стойности за токени csrf като част от url и да проверим дали потребителят е посетил този URL адрес. Ако отговорът е „да“, има голям шанс, че потребителят или използва същия CSRF маркер в текущата активна сесия или може да е използвал този знак в предишна сесия. След като имаме списък с всички такива маркери, можем просто да опитаме нашата атака csrf на сървъра, използвайки този малък списък. В момента тази атака е възможна за символи с дължина от 5 знака или по-малка. Опитах го на base16 низ с дължина 5 и успях да изтрия насилствено цялото клавишно пространство за по-малко от 2 минути.

Някои от предпоставките за тази атака да работи са

  1. CSRF маркерът остава същият за конкретна сесия на потребителя. например csrf token = хеш (session_id) ИЛИ
  2. CSRF маркер, изпратен в по-стари форми за една и съща сесия, се приема. Много пъти това е така, тъй като подобрява потребителското изживяване и позволява използването на бутони за браузър напред и назад.

Доказване на концепцията е достъпен тук.
Преди да стартирате PoC, трябва да промените стойностите на параметрите на url и csrftoken.

За тестване с използване на настройките по подразбиране е необходимо първо да посетите един от следните URL адреси, напр.

  1. https://securethoughts.com/?param1=val1&csrftoken = b59fe [променете b59fe на всеки 5-цифрен основен 16 низ, започващ с знак, т.е. по-голям от a0000]
  2. http://tinyurl.com/l2lwgd [което е пренасочване 301 към предишния URL адрес].

Забележка: http://www.secureoughts.com и https://secureoughts.com се третират различно, докато се съхраняват в историята на браузъра.

Примерен цикъл ще изглежда така -

хакерство csrf токени с помощта на css история хакхакерство csrf токени с помощта на css история хак

За да направи тази атака невъзможна,

Сървърно решение (за разработчици):

  • Направете токените си CSRF достатъчно дълги (8 или повече знака), за да бъдат невъзможни за атака на КЛИЕНТНА СТРАНА. Непрекъснато нарастващата мощност на обработка ще направи тази атака възможна и за по-дълги маркери.
  • Съхранявайте маркера си CSRF като част от полето на скритата форма, вместо да въвеждате URL адрес.
  • Използвайте различен случаен маркер за всяко подаване на формуляр и не приемайте остарял маркер, дори и за една и съща сесия.

Клиентско решение (за вашите клиенти / потребители):

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

И не на последно място, XSS премахва всички възможни защити на CSRF. Така че, първо се отървете от XSS.

Бих искал да благодаря на Йеремия за предоставената му проницателна обратна връзка по този пост.

Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me