У минулій статті я спробував описати що саме представляє з себе дана уразливість і, що не маловажно, виконання яких умов необхідно для проведення атаки типу CSRF.
У даній статті я спробую розповісти про захист від атак даного типу зі сторін:
- З боку клієнта - основні способи захистити себе самому
- З боку сервера - правильне проектування додатку
Якщо вам цікаво як захиститися від CSRF то ласкаво просимо під кат.
Загальна інформація
Загалом то хочу нагадати, CSRF - це НЕ вразливість, це вид атаки. І дана атака проводиться на кінцевого користувача веб додатки за допомогою вразливості в даному додатку, яку можна назвати як «Відсутність належної перевірки джерела запиту» (назва я придумав сам, не судіть строго, але це так). Але тут і далі я буду називати CSRF вразливістю і атакою в одній особі так, як це простіше, та й саме так прийнято =)
І раз атака проводиться на користувача, то і користувачеві захищатися ... жарт =) Справа в тому що будь-який користувач може знизити можливість проведення даної атаки на будь-якому сайті, яким він користується (навіть якщо на цих сайтах немає вбудованої захисту від CSRF). Але крім користувачів, самі розробники сайтів можуть спроектувати свій додаток так, щоб не допустити можливість проведення даної атаки на своїх користувачів.
Розглянемо захист з обох сторін.
Захист з боку користувача
Вообщем тут все дуже банально:
На цьому все. Тепер перейдемо до головного.
Захист з боку розробників
Як вже було сказано, вразливість полягає у відсутності належної перевірки джерела запиту. Тобто при розробці програми нам потрібно вбудувати функціонал перевірки цього джерела. І чтоже насамперед нам приходить в голову? Правильно! Перевірка Referer.
Перевірка Referer
Відразу скажу, для тих хто читає статті по діагоналі. Засновувати свій захист тільки на перевірці цього заголовка - погано (!). Чому - див. Далі.
Для початку розберемося, в чому полягає цей спосіб.
А ось хрін. І справа тут не в тому що можна підробити реферер (який розсудливий зломщик буде просити жертву про те, щоб вона підмінила реферер і перейшла за вказаним URL). А в тому що за моєю статистикою у близько 5% користувачів передача Referer відключення. Тобто або ці п'ять відсотків не зможуть працювати з сайтом взагалі, або вони будуть уразливі до цієї атаки (залежить від політики вашого застосування).
Вооще як самостійний спосіб даний метод безглуздий.
підтвердження дії
Ну і тепер єдиний правильний і надійний спосіб.
Зміст даного способу полягає в додаванні параметра містить певний «токенов» до кожного посилання, формі відправки та ін. А при отриманні запиту сервер повинен перевіряти наявність даного токена в прийнятих параметрах. Природно кожен токен для кожного користувача повинен бути унікальним, а ще краще якщо кожен токен буде унікальним.
Один з найпростіших і надійних прикладів реалізації - токен генерується при кожному запиті новий і встановлюється в cookies користувача а також додається в параметри форм і посилань на сторінці:
І потім при отриманні кожного запиту порівнюється токен з куків і токен вказаний в параметрах форми. І якщо вони однакові, то джерело запиту легальний. Потім токен генерується знову, і знову встановлюється в куки, і т.д. по колу.
Взагалі реалізація може бути інша, але проблема в тому що перехід на токени це досить складно так як доводиться враховувати кожну посилання, кожну форму, кожну сторінку ... Можна захищати тільки важливі сторінки / форми / посилання, але тоді є шанс якісь з них упустити.
Я особисто захищаю тільки POST форми і дуже важливі посилання. Тобто POST в моїх програмах не працює без наявності правильного токена. Це позбавляє від шансу забути захистити якусь форму, так як вона просто не буде працювати і я відразу це зауважу.
Сподіваюся з даної статті ви зрозуміли яким чином слід захищатися від CSRF атак.
PS: далі буде :)
Дивіться також
- Уразливість CSRF. Приховуємо Referer при редирект
Практична реалізація прикладу вимкнути реферера при редирект. Перенаправлення без відсилання Referer. Опис атаки Csrf при відключеному реферера.
Добрий день. Сьогодні я доповню цикл статей про CSRF. Але тепер я буду плавно переходити на «ту сторону барикад». Як кажуть.
Загальний опис атаки типу CSRF. Простий приклад практичної експлуатації уразливості підробки міжсайтових запитів. Наочна схема уразливості CSRF.
Так я пам'ятаю що я обіцяв в попередньому повідомленні написати про капчу, але, чесно кажучи, писати про ці капчи у.
Опис критичної уразливості в CMS NetCat. Виконання коду. NetCat search_query Code Execution.
Буквально сьогодні один з моїх клієнтів написав мені що його сайт зламали. Чесно кажучи мене це сильно здивувало. Настільки сильно.
Приклад захисту від PHP include. Спосіб запобігти виявлення і проведення атаки хакером.
Давайте з вами подумаємо хто такий хакер? Хакер - це не зломщик! Люди часто плутають ці поняття. Хакер - це.
Ну що ж, давайте спробуємо з вами подискутувати на цю тему. Припустимо я знаю як працює капча (зауважте у мене в блозі є майже цілий розділ, їй присвяченій).
Реалізація капчи може бути різною, і, напевно, правильніше буде сказати, що більшість її реалізацій все ж зможе захистити від CSRF (за деяким винятком). Ну і знову ж таки якщо глянути таку пропозицію йде під заголовком «Токени»: Ну і тепер єдиний правильний і надійний спосіб .. Я думаю, ця пропозиція має наштовхнути на думку, що все ж ідея з капчі не зовсім розумна) - в контексті статті, це всього лише приклад нестандартного мислення.
Ну а говорити про те що деякі реалізації капчи не зможуть захистити від CSRF ... Ну тут вже вибачте. Це помилка програміста, який реалізував діряву капчу. І аж ніяк не проблема останньої. З таким же успіхом можна говорити і про токени, мовляв оні не приносять користі «якщо знати механізм роботи токенов і трохи подумати».
токен генерується при кожному запиті новий і встановлюється в cookies користувача
А якщо cookie у користувача відключені? Таких напевно> 5% ..
Сесії без використання кук? Якщо ви про стандартний механізм сесій php, то ідентифікатор цієї сесії також зберігається в куках. Немає куків - немає сесій.
Ех ... допоможіть краще фрагмент запиту etext = розшифрувати, який залишається в REFERER після приходу користувача з пошуку Yandex.
Ви дуже доступно підносите матеріал, спасибі
Один з найпростіших і надійних прикладів реалізації - токен генерується при кожному запиті новий і встановлюється в cookies користувача а також додається в параметри форм і посилань на сторінці:
Все правильно, захист потрібно робити тільки токеном, але за чим кожен раз генерувати новий токен і класти його в куку?
Просто не зрозумію навіщо в куках зберігати непотрібні речі?
Ну зберігання токена в Кука - річ не принципова. Це просто простіше ніж зберігати його в базі. Зверніть увагу я писав:
Один з найпростіших і надійних ...
Можна зберігати його і в базі. В принципі пофіг абсолютно ... Можна і не зберігати його взагалі ніде, а генерувати на основі унікальних даних користувача, і який-небудь секретної серверної солі.
Варіантів то маса, в статті вказано єдиний з них :)
Доброго дня. Підкажіть, як токени, прописані в коді сторінки, захищають від csrf? Чому злоумишоеннік не зможе Спарс сам токен і передати в post запиті?
Парс одну зі сторінок на сайті витягуємо токен і наступним кроком отправляемм на потрібну команду вже з токеном.
У чому захист?
А я то думаю чому деякі сервіси іноді просять ввести пароль при здійсненні важливих операцій, ось це захист.
Ви мабуть неуважно читали про те в чому полягає сама атака. У зловмисника немає можливості Спарс токен. Токен для кожного користувача унікальний.
Повторний вод пароля - захист від інших проблем.
Я зви-ний веб-раз-ра-бот-чик. Пі-шу тут про те, що мені інституті-рес-но, з чим я ви-нуж-ден став-ки-вать-ся в сфе-рі WEB, свої мис-ли, рас-суж-де-ня , раз-ме-щаю соб-ного-ні ста-тьі.
Не забувайте підписуватися:
І дуже про-шу, не за-б-вай-ті залишати-лять кому-мен-та-рії до про-чи-тан-ним за-пі-сям.