3.5 Testing for Cross Site Request Forgery
Суть вразливості:
Підробка міжсайтових запитів (CSRF) - це атака, яка змушує користувача виконувати дії в мережі, нав'язані хацкером. З невеликою допомогою соціальної інженерії (наприклад, відправивши посилання електронною поштою або в чати), зловмисник може змусити користувачів веб-програми виконувати дії на його вибір. Успішний Експлойт CSRF може поставити під загрозу дані та роботу користувача. Якщо користувач має права адміністратора, CSRF-атака може поставити під загрозу всю програму.
CSRF покладається на:
1. Поводження браузера щодо обробки, пов'язаної з сеансом інформації, такої як cookie та інформації про автентифікацію HTTP.
2. Знання зловмисником дійсних URL-адрес веб-додатків, запитів або функцій.
3. Управління сеансом програми, що базується на інформації відомої браузеру.
4. Наявність тегів HTML, наявність яких викликає негайний доступом до ресурсу HTTP [S]; наприклад, зображення тега img.
Пункти 1, 2 та 3 важливі для наявності вразливості, а пункт 4 полегшує фактичну експлуатацію.
Для простоти розглянемо URL-адресу через GET запит (хоча обговорення вище, відноситься також і до запитів POST). Якщо жертва вже пройшла автентифікацію, надсилання іншого запиту призводить до автоматичного відправлення cookie разом з ним. На малюнку нижче показано, як користувач звертається до www.example.com.
Запит GET може бути надісланий користувачем кількома способами:
- Через веб-додатки
- Через введення URL-адреси прямо у браузері
- Через перехід за зовнішнім посиланням
Зокрема, небезпечним може бути третій варіант. Існують різні прийоми, які можуть приховати реальні властивості посилання. Посилання можна вставити в повідомлення електронної пошти, вивести на шкідливий веб-сайт, на який залучається користувач. Якщо користувач натискає на посилання, оскільки вони вже автентифіковані на веб-додаток, браузер надішле запит GET в Інтернет на програму, що супроводжується даними автентифікації (cookie ідентифікатора сеансу). Це призводить до того, що виконуються дії від імені користувача, на які не очікує сам користувач; наприклад, переказ коштів через інтернет-банкінг.
Використовуючи такий тег, як img, як зазначено у пункті 4, навіть не обов'язково, щоб користувач перейшов за конкретним посиланням. Припустимо, зловмисник відправляє користувачеві електронного листа, який спонукає його відвідати URL-адресу, що посилається на сторінку, що містить наступний (спрощений) HTML.
«html»
«body»
«img src=”https://www.company.example/action” width=”0” height=”0”»
«/body»
«/html»
Коли браузер відобразить цю сторінку, він спробує відобразити вказане зображення нульового розміру (таким чином, воно буде ніби невидиме) на сайт https://www.company.example. Це призводить до автоматичного надсилання запиту на веб-додаток. Не важливо, що URL-адреса зображення не відноситься до правильного зображення, оскільки його присутність викличе у будь-якому випадку запит на дію, вказану в полі src. Це станеться за умови, що завантаження зображення не відключено у браузері. У більшості браузерів завантаження зображень не вимкнено, оскільки це призведе до виходу з ладу більшості веб-застосунків.
Проблема тут є наслідком:
- HTML-теги на сторінці, що призводять до автоматичного виконання HTTP-запиту (img є одним із них).
- Браузер не може сказати, що ресурс, на який посилається img, не є законним зображенням.
В інтегрованих середовищах, простий показ електронної пошти, що містить посилання на зображення, призводить до виконання запиту до веб-додатку зі зв'язаним файлом cookie браузера. Електронні повідомлення можуть посилатися на допустимі URL-адреси зображень, такі як:
«img src=”https://[attacker]/picture.gif” width=”0” height=”0”»
У цьому прикладі [attacker] – це сайт, контрольований зловмисником. Використовуючи механізм перенаправлення, шкідливий сайт може використовувати http://[attacker]/picture.gif, щоб направити жертву на http://[thirdparty]/action/ та викликати action.
Файли cookie – не єдине вразливе місце. У Веб-додатках також може бути вразлива інформація про сеанс, який повністю надано браузеру. Сюди входять додатки, які використовують автентифікацію HTTP, оскільки інформація про аутентифікацію відома браузеру і відправляється автоматично при кожному запиті.
Припустимо, що жертва увійшла до консолі управління брандмауером. Для входу користувач повинен пройти аутентифікацію, інформація про сеанс збережеться у файлі cookie. Припустимо, в консолі управління брандмауером є функція, яка дозволяє автентифікованому користувачеві видаляти якесь правило. Далі з'явиться сторінка видалення. Припустимо, що форма видає GET-запит. Щоб видалити 1 правило:
https://[target]/fwmgt/delete?rule=1
А для того, щоб видалити всі правила ось такий запит:
https://[target]/fwmgt/delete?rule=*
Цей приклад свідчить про небезпеку CSRF.
Використовуючи форму, зображену на малюнку вище, введіть і натисніть кнопку Видалити, щоб надіслати наступний запит GET:
https://www.company.example/fwmgt/delete?rule=
Це видалить усі правила брандмауера
Користувач міг також отримати ті ж результати, надіславши URL-адресу вручну:
https://[target]/fwmgt/delete?rule=*
Або перейшовши за посиланням, на пряму або через перенаправлення на вказану вище URL-адресу. Або, знову ж таки, відкривши HTML-сторінку з вбудованим тегом img, що вказує на ту саму URL-адресу.
У всіх цих випадках, якщо користувач увійшов до програми для керування брандмауером, запит буде успішним і змінить конфігурацію брандмауера. Можна уявити атаки, націлені на чутливі програми такі як: автоматичні аукціони, грошові перекази, замовлення, зміна конфігурації важливих програмних компонентів і т.д.
Як тестувати
Проведіть аудит програми, щоб переконатися, що керування сеансом уразливе. Якщо керування сеансом покладається тільки на клієнт (інформація, доступна браузеру), то програма вразлива. «Значення на стороні клієнта» відносяться до файлів cookie та облікових даних, спрямованих через HTTP-автентифікацію.
Ресурси, доступні через запити HTTP GET вразливі, хоча запити POST можна автоматизувати за допомогою JavaScript і вони також стануть вразливими; тому використання лише POST недостатньо, щоб виправити виникнення CSRF-уразливості.
У випадку POST можна використовувати наступний кейс:
1. Створіть HTML-сторінку, подібну до наведеної нижче.
2. Розмістіть HTML-код на шкідливому або сторонньому сайті.
3. Надішліть посилання на сторінку жертві (ам) і змусіть їх клацнути по ній.
«html»
«body onload='document.CSRF.submit()'»
«form action='http://tagetWebsite/Authenticate.jsp' method='POST' name='CSRF'»
<input type='hidden' name='name' value='Hacked'>
<input type='hidden' name='password' value='Hacked'>
«/form»
«/body»
«/html»
У випадку веб-застосунків, у яких розробники використовують JSON для зв'язку браузера з сервером, проблема може виникнути через відсутність параметрів запиту з форматом JSON, які необхідні при самостійному надсиланні форми. Щоб уникнути цього випадку, ми можемо використовувати форму самовідправлення з корисними даними JSON, включаючи приховане введення для використання CSRF. Нам потрібно буде змінити тип кодування (enctype) на text/plain, щоб забезпечити доставку payload як є. Код експлойту буде виглядати так:
«html»
«body»
«script»history.pushState('', '', '/')«/script»
«form action='http://victimsite.com' method='POST' enctype='text/plain'»
<input type='hidden' name='{"name":"hacked","password":"hacked","padding":"'value='something"}'/>
<input type='submit' value='Submit request' />
«/form»
«/body»
«/html»
POST запит буде таким:
POST / HTTP/1.1
Host: victimsite.com
Content-Type: text/plain
{"name":"hacked","password":"hacked","padding":"=something"}
Коли ці дані надсилаються у вигляді запиту POST, сервер з радістю приймає поля імені та пароля та ігнорує один із доповненням імені, оскільки він не потрібен.
Tools
