Анатомия на CSRF и механизми за превенция
Фалшифицирането на заявки между сайтове (CSRF) е известно също като „Session Riding“ или „One-Click Attack“. Това е атака, която позволява на атакуващ да изпълнява неупълномощени POST/GET произволни HTTP заявки от името на жертвата, която в момента е удостоверена за уеб приложението. CSRF е атака, насочена конкретно към заявки за промяна на състоянието, а не към кражба на данни, тъй като атакуващият няма начин да види отговора на фалшивата заявка.
Въздействието на CSRF атака
При успешна CSRF атака нападателят може да накара жертвата да извърши действие неволно. Например, това може да бъде промяна на имейл адреса на техния акаунт, промяна на паролата им или извършване на превод на средства. В зависимост от естеството на действието, нападателят може да получи пълен контрол върху потребителския акаунт на жертвата. Ако компрометираният потребител има администраторска привилегирована роля в рамките на уеб приложението, тогава атакуващият може да успее да поеме пълен контрол върху всички данни и функционалност на приложението.
За да предотвратим тази CSRF атака, има два основни модела за сигурност, които можем да приложим.
I. Модел на токен за синхронизатор
II. Двойно подаване на модел на бисквитка
И така, в тази публикация в блога ще се опитаме да приложим един от моделите за сигурност, наречен Synchronizer Token Pattern. Нека да разгледаме, можете да получите този проект от 👉Моето хранилище на GitHub.👈
Модел на токен за синхронизиране (STP)
Това е метод, при който тайна, токен и уникална стойност за всяка заявка се вграждат от уеб приложението във всички HTML форми и се проверяват от страната на сървъра. Това е едно от идентифицираните решения за предотвратяване на атаки с фалшифициране на заявки между сайтове (CSRF).
Как работи?
При този метод стойността на произволен низ се генерира от страната на сървъра и се добавя към тялото на предния край и проверява и двете стойности, когато потребител изпрати уеб страница. Обикновено тази произволна низова стойност е достатъчно дълга и кодирана в base64.
Токени за синхронизиране
· Голяма случайна стойност
· Уникална стойност за потребителска сесия
· Генерира се криптографски защитен произволен номер
· Сесията съдържа токен и е проверена в задния край
· Ако токенът не премине проверката, сървърът отхвърля исканото действие
Създадено е просто уеб приложение за прилагане на шаблона на токен за синхронизиране, това уеб приложение е разработено с помощта на PHP и JavaScript. Това изглежда като нормална страница за вход, но в крайна сметка не е. Всички идентификационни данни са твърдо кодирани (потребителско име: arun & парола: pass1).
Потребителските идентификационни данни се изпращат чрез този формуляр за вход с помощта на метод POST. Валидният потребител може да влезе успешно, в противен случай ще се появи съобщение за грешка. В момента на успешно влизане, уникален идентификатор на сесия и токен ще бъдат създадени заедно със създадената сесия и ще генерират идентификатор на сесия, зададен като бисквитка в уеб браузъра.
Този токен се съхранява от страната на сървъра. За този проект токенът се съхранява в текстова плочка.
След като потребителят влезе, браузърът ще изпрати Ajax извикване, за да получи токена до csrf_token_generator.php. Това Ajax повикване съдържа идентификатора на сесията и след това сървърът ще отговори на съответния токен заедно с тялото на отговора.
Екранната снимка изобразява маркирания ред, където токенът се вгражда в скрито поле при изпращане на формуляр. Използвана е функцията openssl_randon_pseudo_bytes() в PHP за генериране на 32-битов дълъг CSRF токен. След това генерираната стойност се преобразува в своята стойност base64 с помощта на base64_encode(), за да стане по-сигурна. Въпреки че всичко се случва, но потребителят не вижда това, когато страницата се зареди.
Тук се прилага POST заявка за актуализиране на потребителския статус. Тази заявка за публикуване съдържа генерирания CSRF токен и сесийната бисквитка.
Когато потребителят щракне върху бутона „Актуализиране“, се изпраща заявката за публикуване. След това сървърът ще потвърди идентификатора на сесията, който идва от заглавката на заявката и CSRF токена в тялото.
Ако токенът е валиден, сървърът приема заявката и изходът излиза както следва,
Ако токенът не е валиден, сървърът отхвърля заявката.
Заключение
Това защитава формуляра срещу атаки за фалшифициране на заявки между сайтове (CSRF), тъй като нападател, който създава заявка, също ще трябва да отгатне анти-CSRF токена, за да може успешно да подмами жертвата да изпрати валидна заявка. И този токен се анулира след известно време, когато потребителят излезе.
Благодаря ви, че четете моя блог. Надяваме се, че този блог ще бъде полезен за прилагане на Synchronizer Token Pattern в уеб приложения. И също така проверете моята следваща публикация в блога, която е „Модел за двойно изпращане на бисквитки“.
