1 Востаннє редагувалося ktretyak (12.05.2015 08:54:42)

Тема: Збираємо інформацію стосовно XSRF-атак

Хоча про XSRF-атаки багато років вже чув і знав що це таке, але поверхово.

Зараз прийшов час краще зрозуміти їх. Що нам каже віка? Мені здається з прочитаного можна зробити наступний висновок, хто володіє докладнішою інфою, прохання доповнити мій опис.

Дійові особи
1. браузер користувача, в якому зберігаються всі сесії;
2. в браузері повинна бути актуальна сесія користувача, яка дозволяє заходити на залогінений сайт без додаткового введення паролю; припустимо це буде сайт http://nash-bank.com.ua
3. сайт зловмисника, на який користувач заходить, припустимо це сайт http://goli-divky.com.ua;
4. лінк або картинка на сайті зловмисника, в якому приховано запит на сайт, про який йдеться в другому пункті; припустимо це буде лінк http://nash-bank.com.ua?clien=vasya & perekaz=100000 & komu=zlovmysnyku

Як це працює
1. оскільки користувач, нічого не підозрюючи, просто заходить на сайт http://goli-divky.com.ua і клікає на ціцьки лінк зазначений у нашому четвертому пункті, то відбувається запит на сайт http://nash-bank.com.ua причому цей запит відбувається від імені користувача, з чийого браузера відбувся перехід;
2. також, оскільки сесія на сайті http://nash-bank.com.ua є активною, то відбувається те, що просить наш користувач, тобто clien=vasya perekaz=100000 komu=zlovmysnyku

Як цього уникають
1. найпростіший, але ненадійний спосіб - перевірка referer'а (тобто з якого домена робиться запит); цей спосіб ненадійний, бо реферер легко підробити (так кажуть в інтернеті);
2. оскільки зловмисник може робити лише GET або POST запити, описаним вище способом, і не може читати куки, то генерують додаткові куки і вставляють їх і у форму, яку користувач надсилає, і у куки. Коли сервер отримує запит, то він звіряє чи дійсні куки та чи їхнє значення таке ж як у формі, що надсилається.
3. AngularJS відправляє додаткові заголовки на сервер (замість куків)

Ось десь приблизно так. Але я поки що не знайшов інформації чому AngularJS відправляє свої токени саме через заголовки. З чим куки не справляються?...

Оновлено:
Здається знайшов відповідь на своє питання (стосовно заголовків)

2

Re: Збираємо інформацію стосовно XSRF-атак

Post можна відправляти через форму а форму сабмітити через javascript

3

Re: Збираємо інформацію стосовно XSRF-атак

http://replace.org.ua/topic/4029/

4

Re: Збираємо інформацію стосовно XSRF-атак

Приват24 для заходу на сторінку вимагає в адресі після "?" поля із значенням (схоже id активної сесії), яке надсилає сервер. Без нього перекидає на сторінку логіна.
Якщо зловмисник не зможе дізнатися цього значення, то простий "шкідливий" лінк на сайт банку нічого не дасть.

5

Re: Збираємо інформацію стосовно XSRF-атак

funivan написав:

Post можна відправляти через форму а форму сабмітити через javascript

Ідеальний захист — заборонити в браузері виконання JS взагалі. Щоправда, перед цим треба буде забрати комп'ютери в JS-євангелістів, які наклепали сучасних сайтів, непридатних для роботи без JS...

6

Re: Збираємо інформацію стосовно XSRF-атак

P.Y. написав:
funivan написав:

Post можна відправляти через форму а форму сабмітити через javascript

Ідеальний захист — заборонити в браузері виконання JS взагалі. Щоправда, перед цим треба буде забрати комп'ютери в JS-євангелістів, які наклепали сучасних сайтів, непридатних для роботи без JS...

Зараз - сайт без JS - "не сайт".

7

Re: Збираємо інформацію стосовно XSRF-атак

P.Y. написав:
funivan написав:

Post можна відправляти через форму а форму сабмітити через javascript

Ідеальний захист — заборонити в браузері виконання JS взагалі. Щоправда, перед цим треба буде забрати комп'ютери в JS-євангелістів, які наклепали сучасних сайтів, непридатних для роботи без JS...

Дійсно, а ідеальний спосіб захиститись від ДТП - не виходити з дому.

8

Re: Збираємо інформацію стосовно XSRF-атак

Не допоможе. Скільки вже було роликів, як влітають в будинок на тачці.

9

Re: Збираємо інформацію стосовно XSRF-атак

Ідеальний захист — заборонити в браузері виконання JS взагалі.

лол)) це я сприймаю як жарт )))

10

Re: Збираємо інформацію стосовно XSRF-атак

VTrim написав:
P.Y. написав:
funivan написав:

Post можна відправляти через форму а форму сабмітити через javascript

Ідеальний захист — заборонити в браузері виконання JS взагалі. Щоправда, перед цим треба буде забрати комп'ютери в JS-євангелістів, які наклепали сучасних сайтів, непридатних для роботи без JS...

Зараз - сайт без JS - "не сайт".

ІМНО, ЈЅ потрібен для додаткового функціоналу (без якого сайт, в принципі, має лишатись роботоздатним). Якщо користувач не готовий ризикувати своїм банківським рахунком заради якихось свистілок — його право. Ну або два браузери завести собі (бажано на різних компах чи віртуальних машинах): один — для банківських операцій (з відключеними JS, cookies і т.д.), інший — для розважальних сайтів зі свистілками (відповідно, ніяких обмежень на потенційні експлойти). Гірше, якщо банківський веб-сервіс розроблявся JS-євангелістами (обрати інший банк?..).

11

Re: Збираємо інформацію стосовно XSRF-атак

ІМНО, ЈЅ потрібен для додаткового функціоналу

це помилкова думка. js це і є функціонал і не додатковий. Хочеш безпеки пиши безпечні сайти і юзай ssl а не відключай js

12

Re: Збираємо інформацію стосовно XSRF-атак

Якщо використання SSL може захистити сайт від нелегальної автоматичної відправки форми з іншого сайту, то як саме? SSL захищає дані від перехоплення їх при передачі по мережі, а те, що відбувається в браузері, його не стосується. З таким же успіхом ми можемо ставити новий незламуваний замок на картонні двері, що вибиваються ногою.

13

Re: Збираємо інформацію стосовно XSRF-атак

P.Y. написав:
VTrim написав:
P.Y. написав:

Ідеальний захист — заборонити в браузері виконання JS взагалі. Щоправда, перед цим треба буде забрати комп'ютери в JS-євангелістів, які наклепали сучасних сайтів, непридатних для роботи без JS...

Зараз - сайт без JS - "не сайт".

Якщо користувач не готовий ризикувати своїм банківським рахунком заради якихось свистілок — його право.

Якщо користувач не готовий ризикувати своїм рахунком, то йому не варто користуватись Інтернет- і телефонним банкінгом, а не одним js. Давно heartbleed був?

14

Re: Збираємо інформацію стосовно XSRF-атак

Якщо користувач не готовий ризикувати своїм рахунком, то йому не варто користуватись Інтернет- і телефонним банкінгом, а не одним js.

Але тоді йому доведеться частіше виходити з дому (чи навіть їхати кудись), що підвищує ризик потрапити в автокатастрофу.

15

Re: Збираємо інформацію стосовно XSRF-атак

P.Y. написав:

Якщо користувач не готовий ризикувати своїм рахунком, то йому не варто користуватись Інтернет- і телефонним банкінгом, а не одним js.

Але тоді йому доведеться частіше виходити з дому (чи навіть їхати кудись), що підвищує ризик потрапити в автокатастрофу.

Що там та аварія - головне, що рахунок в безпеці.

16 Востаннє редагувалося P.Y. (16.04.2015 16:02:59)

Re: Збираємо інформацію стосовно XSRF-атак

js це і є функціонал і не додатковий.

JS — опціональна функція браузера (як і флеш-плагін, наприклад), а тому робити сайт повністю залежним від нього без об'єктивної на те необхідності — небажано. Fault-tolerant design завжди був правильним стилем веб-розробника.

17

Re: Збираємо інформацію стосовно XSRF-атак

quez написав:
P.Y. написав:

Якщо користувач не готовий ризикувати своїм рахунком, то йому не варто користуватись Інтернет- і телефонним банкінгом, а не одним js.

Але тоді йому доведеться частіше виходити з дому (чи навіть їхати кудись), що підвищує ризик потрапити в автокатастрофу.

Що там та аварія - головне, що рахунок в безпеці.

Добре, аварія сталась, вийти з дому неможливо через відсутність ніг. Що далі?

18

Re: Збираємо інформацію стосовно XSRF-атак

одним словом пора завязувати ))
хто знає нормальні методи захисту від xsrf крім того як відключити javascript ?

19

Re: Збираємо інформацію стосовно XSRF-атак

funivan написав:

одним словом пора завязувати ))
хто знає нормальні методи захисту від xsrf крім того як відключити javascript ?

Встановлювати токен ключ в hidden поле для POST,і в адресний рядок для GET.
І якщо ключ empty/!isset або != сесії користувача,то error.

20

Re: Збираємо інформацію стосовно XSRF-атак

funivan написав:

одним словом пора завязувати ))
хто знає нормальні методи захисту від xsrf крім того як відключити javascript ?

Розробляти безпечний сайт так, щоб у ньому не використовувались cookies. Ідентифікатор сесії передавати виключно через дані форми (в вигляді прихованого поля).