Ви не увійшли. Будь ласка, увійдіть або зареєструйтесь.
Ласкаво просимо вас на україномовний форум з програмування, веб-дизайну, SEO та всього пов'язаного з інтернетом та комп'ютерами.
Будемо вдячні, якщо ви поділитись посиланням на Replace.org.ua на інших ресурсах.
Для того щоб створювати теми та надсилати повідомлення вам потрібно Зареєструватись.
Український форум програмістів → PHP → Збираємо інформацію стосовно XSRF-атак
Для відправлення відповіді ви повинні увійти або зареєструватися
...
Так ви за один запит збираєтесь відправляти і POST і GET. Ви таке пробували робити?
Зараз подумав про те що я оце написав Невже це я написав?! Це мабуть хтось CSRF-атакує!
funivan написав:одним словом пора завязувати ))
хто знає нормальні методи захисту від xsrf крім того як відключити javascript ?Розробляти безпечний сайт так, щоб у ньому не використовувались cookies. Ідентифікатор сесії передавати виключно через дані форми (в вигляді прихованого поля).
Як ви будете перевіряти цей ідентифікатор, окрім як через куки/сесію?
P.Y., зрозуміло, що ваш девіз: менше наворотів - більше надійності!
Але, нажаль, на чистому HTML далеко не поїдеш. Те що ви кажете про додаткову JS-функціональність, якої варто уникати якщо її можна зробити і на чисто HTML, то а хіба цього не дотримується більшість? Всі намагаються зробити на HTML, CSS.
VTrim написав:funivan написав:одним словом пора завязувати ))
хто знає нормальні методи захисту від xsrf крім того як відключити javascript ?Встановлювати токен ключ в hidden поле для POST,і в адресний рядок для GET.
І якщо ключ empty/!isset або != сесії користувача,то error.Так ви за один запит збираєтесь відправляти і POST і GET. Ви таке пробували робити?
Ні,окремо для POST i GET, (хоча можна і для обох разом).
Як ви будете перевіряти цей ідентифікатор, окрім як через куки/сесію?
Куки треба ігнорувати на стороні сервера. Механізм сесій можна реалізувати й без cookies — передаючи ідентифікатор через параметр URL чи приховане поле форми.
Куки треба ігнорувати на стороні сервера. Механізм сесій можна реалізувати й без cookies — передаючи ідентифікатор через параметр URL чи приховане поле форми.
Якщо зловмисник знайшов спосіб отримати ідентифікатор активної сесії, то йому доступно це вставити в будь-який запит POST або GET. Тобто немає сенсу комбінувати її "і там, і там", бо це якраз доступно для зловживань.
Якщо зловмисник знайшов спосіб отримати активну сесію, то міг він це зробити, використовуючи дані з cookies. Якщо ж безпечний сайт у куки нічого не пише й нічого звідти не читає, ідентифікатор сесії передається виключно через POST (навіть від параметру url відмовимось, щоб зловмисник не міг його прочитати з екрану), час існування сесії обмежено, дані передаються через безпечний протокол, то звідки у зловмисника ідентифікатор сесії?
Якщо зловмисник знайшов спосіб отримати активну сесію, то міг він це зробити, використовуючи дані з cookies. Якщо ж безпечний сайт у куки нічого не пише й нічого звідти не читає, ідентифікатор сесії передається виключно через POST (навіть від параметру url відмовимось, щоб зловмисник не міг його прочитати з екрану), час існування сесії обмежено, дані передаються через безпечний протокол, то звідки у зловмисника ідентифікатор сесії?
Та йому в такому разі взагалі не треба отримувати актуальний ідентифікатор сесії, бо на сервері перевіряється чи сходиться один параметр з іншим, тобто "пиши шо хоч, лиш би було те саме".
Оновлено:
Ні, знову ж таки, - щось перевіряти можна лише, якщо ви щось передаєте, десь собі це записуєте, а потім коли приходить форма, то звіряєтесь чи вона дорівнює тому що у вас зберігається. Як це можна зробити?
Без сесії, мабуть, тут не обійтись. І я теж виключав її якось з переліку кук. Мабуть коли пишуть про запобігання XSRF-атакам то говорять про куку, яка дозволяє ідентифікувати сесію.
Давайте почнемо з азів. Що собою являє сесія? Це дані (наприклад, ім'я користувача), що зберігаються на стороні сервера (у файлі чи базі даних), доступ до яких здійснюється за ідентифікатором, що генерується на сервері й передається (через cookies чи як get-параметр/post-параметр безпосередньо в html) клієнтові, а потім повертається на сервер з наступним запитом. Очевидно, складність цього ідентифікатора має бути такою, щоб його неможливо було отримати простим перебором. Якщо клієнт передає ідентифікатор неіснуючої сесії, то ніяких даних сесії сервер не знайде.
Щодо контрольного параметру. Якщо він передаватиметься тим же способом, що й ідентифікатор сесії, то що заважає зловмиснику вкрасти і ідентифікатор сесії, і контрольний параметр?
Давайте вияснимо:
1. чи може певний зловмисний код, на сайті атакуючого, прочитати будь-яку куку з браузера жертви
2. в який спосіб можна посилати POST запити із сайта атакуючого? Мабуть це можна зробити виключно через JS, але я не впевнений в цьому.
Оновлено:
Що до другого пункту, то мабуть POST запит можна відправити через форму 
. Я просто раніше уявляв собі що жертва повинна щось "безневинне клікнути", а не явно форму. Більше того - форму можна через CSS замаскувати під лінк...
Нехай на сайті зловмисника є скрипт(js), що зчитує сторінку з банківського сайту (де розміщена форма переказу коштів), заповнює форму й відправляє її на сайт банку, щоб здійснити переказ. Якщо cookies використовуються сайтом банку для ідентифікації сесій, то скрипт словмисника в браузері жертви зможе це зробити від імені жертви?
1. Ні. (куки прикліпляються до домену)
2. POST запит можна відправляти на інший домен прямою формою зі схованим полями але видимою кнопкою (для натиску). Або ж через кроссдоменний AJAX.
Якщо на сайті жертви є XSS,але куки ми викрасти не можемо (допустимо тому,що вони встановлені в режимі HttpOnly),то ми можемо вставити схований AJAX запит,до локальної сторінки с формою (без захисту від XCRF).
І кожен хто зайде на ту сторінку,відразу відправить від себе post запит.
Нехай на сайті зловмисника є скрипт(js), що зчитує сторінку з банківського сайту (де розміщена форма переказу коштів), заповнює форму й відправляє її на сайт банку, щоб здійснити переказ. Якщо cookies використовуються сайтом банку для ідентифікації сесій, то скрипт словмисника в браузері жертви зможе це зробити від імені жертви?
Так, зможе це зробити без будь-якого скрипта, бо ідентифікатор сесії перевіряє, в нашому випадку, банк, а не зловмисний сайт. Тобто зловмисний сайт передає параметри в рядку запиту POST або GET без будь-яких додаткових маніпуляцій. Коли цей запит приходить на сайт банку, то вже банк перевіряє чи її клієнт має актуальну сесію.
Отже що я для себе більш чітко вияснив:
1. куки потрібно використовувати, бо без них неможливо ідентифікувати той токен, який ми вставляємо у форму
2. JavaScript має доступ виключно до тих куків, на чийому домені він зберігається (якщо, звичайно ж, не використовувати додаток до браузера невідомого походження).
3. оскільки JavaScript може читати куки тільки на "своєму" домені, то JavaScript можна використовувати для відправки додаткового (секретного) ідентифікатора в заголовку разом з будь-яким запитом. В такому разі навіть не потрібно додавати приховані поля у форму.
Шо ще?
Допустимо у вас на сайті є лінк (GET запит),по якому користувач може видалити своє повідомленяя,типу.
/del_message.php?id=777
І може залишити у себе картинку (картинки) типу <img src="http://yoursite.com/del_message.php?id=777">
Після відвідування вами його сайту,ваші записи видаляться,ну і так далі по прикладу лайків,дізлайків і тому подібне..
Шо ще?
Допустимо у вас на сайті є лінк (GET запит),по якому користувач може видалити своє повідомленяя,типу.
/del_message.php?id=777І може залишити у себе картинку (картинки) типу <img src="http://yoursite.com/del_message.php?id=777">
Після відвідування вами його сайту,ваші записи видаляться,ну і так далі по прикладу лайків,дізлайків і тому подібне..
За умови, що немає прив'язки до сесії/кук/авторизації/прав.
Хто в здоровому стані стане робити видалення без перевірки, через get-запит?
IMHO приклад надто надуманий.
За умови, що немає прив'язки до сесії/кук/авторизації/прав.
Хто в здоровому стані стане робити видалення без перевірки, через get-запит?
Хоча приклад, звичайно ж, надуманий, але якщо робити якісь аналогічні дії, то навіть після завершення авторизації, надаються права (по-суті) браузеру у вигляді встановленої куки, яка буде ідентифікатором сесії - тобто якраз все що ви перерахували не забезпечує захисту.
Забезпечує захист додатковий ідентифікатор, який вставляється в сесію - на стороні сервера, та додатково або в приховане поле форми, або в окремі куки - на стороні клієнта. Потім, коли приходить запит від клієнта, звіряються ці два ідентифікатори.
Таким чином, виконуючи запит переадресований із зловмисного сайта, браузер видасть серверу куку з ідентифікатором сесії на автоматі, але додатковий ідентифікатор не видається на автоматі, в цьому й полягає захист від XSRF-атак.
Хоча приклад, звичайно ж, надуманий, але якщо робити якісь аналогічні дії, то навіть після завершення авторизації, надаються права (по-суті) браузеру у вигляді встановленої куки, яка буде ідентифікатором сесії - тобто якраз все що ви перерахували не забезпечує захисту.
.
Саме це я і мав на увазі,якщо користувач буде авторизований,то запит воконається.
І я наводив приклад того,що буде якщо без захисту.
До чого тут права? Якщо така атака розрахована на певного користувача.
Для відправлення відповіді ви повинні увійти або зареєструватися
