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

  • ktretyak
  • Replace Group
  • Поза форумом
  • Дата реєстрації: 30.01.2014
  • Повідомлень: 2 080
    • Репутація: 758

Тема: Збираємо інформацію стосовно 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 Відповідь від funivan

  • funivan
  • funivan
  • Replace Team
  • Поза форумом
  • Звідки: Київ
  • Дата реєстрації: 24.09.2012
  • Повідомлень: 2 005
    • Репутація: 927

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

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

funivan вебсайт

3 Відповідь від VTrim

  • VTrim
  • VTrim
  • =)
  • Поза форумом
  • Дата реєстрації: 07.09.2014
  • Повідомлень: 3 319
    • Репутація: 2298

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

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

4 Відповідь від yarko

  • yarko
  • yarko
  • Користувач
  • Поза форумом
  • Звідки: Тернопіль
  • Дата реєстрації: 19.06.2014
  • Повідомлень: 233
    • Репутація: 83

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

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

5 Відповідь від P.Y.

  • P.Y.
  • P.Y.
  • Replace Team
  • Поза форумом
  • Дата реєстрації: 19.02.2013
  • Повідомлень: 7 668
    • Репутація: 4987

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

funivan написав:

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

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

6 Відповідь від VTrim

  • VTrim
  • VTrim
  • =)
  • Поза форумом
  • Дата реєстрації: 07.09.2014
  • Повідомлень: 3 319
    • Репутація: 2298

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

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

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

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

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

7 Відповідь від quez

  • quez
  • quez
  • Replace Team
  • Поза форумом
  • Звідки: Новий Єрусалим
  • Дата реєстрації: 01.05.2014
  • Повідомлень: 3 103
    • Репутація: 1621

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

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

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

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

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

8 Відповідь від yarko

  • yarko
  • yarko
  • Користувач
  • Поза форумом
  • Звідки: Тернопіль
  • Дата реєстрації: 19.06.2014
  • Повідомлень: 233
    • Репутація: 83

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

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

9 Відповідь від funivan

  • funivan
  • funivan
  • Replace Team
  • Поза форумом
  • Звідки: Київ
  • Дата реєстрації: 24.09.2012
  • Повідомлень: 2 005
    • Репутація: 927

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

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

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

funivan вебсайт

10 Відповідь від P.Y.

  • P.Y.
  • P.Y.
  • Replace Team
  • Поза форумом
  • Дата реєстрації: 19.02.2013
  • Повідомлень: 7 668
    • Репутація: 4987

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

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

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

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

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

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

11 Відповідь від funivan

  • funivan
  • funivan
  • Replace Team
  • Поза форумом
  • Звідки: Київ
  • Дата реєстрації: 24.09.2012
  • Повідомлень: 2 005
    • Репутація: 927

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

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

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

funivan вебсайт

12 Відповідь від P.Y.

  • P.Y.
  • P.Y.
  • Replace Team
  • Поза форумом
  • Дата реєстрації: 19.02.2013
  • Повідомлень: 7 668
    • Репутація: 4987

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

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

13 Відповідь від quez

  • quez
  • quez
  • Replace Team
  • Поза форумом
  • Звідки: Новий Єрусалим
  • Дата реєстрації: 01.05.2014
  • Повідомлень: 3 103
    • Репутація: 1621

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

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

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

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

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

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

14 Відповідь від P.Y.

  • P.Y.
  • P.Y.
  • Replace Team
  • Поза форумом
  • Дата реєстрації: 19.02.2013
  • Повідомлень: 7 668
    • Репутація: 4987

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

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

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

15 Відповідь від quez

  • quez
  • quez
  • Replace Team
  • Поза форумом
  • Звідки: Новий Єрусалим
  • Дата реєстрації: 01.05.2014
  • Повідомлень: 3 103
    • Репутація: 1621

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

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

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

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

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

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

  • P.Y.
  • P.Y.
  • Replace Team
  • Поза форумом
  • Дата реєстрації: 19.02.2013
  • Повідомлень: 7 668
    • Репутація: 4987

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

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

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

17 Відповідь від P.Y.

  • P.Y.
  • P.Y.
  • Replace Team
  • Поза форумом
  • Дата реєстрації: 19.02.2013
  • Повідомлень: 7 668
    • Репутація: 4987

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

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

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

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

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

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

18 Відповідь від funivan

  • funivan
  • funivan
  • Replace Team
  • Поза форумом
  • Звідки: Київ
  • Дата реєстрації: 24.09.2012
  • Повідомлень: 2 005
    • Репутація: 927

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

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

funivan вебсайт

19 Відповідь від VTrim

  • VTrim
  • VTrim
  • =)
  • Поза форумом
  • Дата реєстрації: 07.09.2014
  • Повідомлень: 3 319
    • Репутація: 2298

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

funivan написав:

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

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

20 Відповідь від P.Y.

  • P.Y.
  • P.Y.
  • Replace Team
  • Поза форумом
  • Дата реєстрації: 19.02.2013
  • Повідомлень: 7 668
    • Репутація: 4987

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

funivan написав:

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

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