Я знаю аутентифікацію на основі файлів cookie. SSL та HttpOnly прапор можна застосувати для захисту аутентифікації на основі файлів cookie від MITM та XSS. Однак необхідно буде застосувати більш спеціальні заходи, щоб захистити її від КСВР. Вони просто трохи складні. ( довідник )

Нещодавно я виявив, що веб-маркер JSON (JWT) досить гарячий як рішення для аутентифікації. Я знаю, що стосується кодування, декодування та перевірки JWT. Однак я не розумію, чому деякі веб-сайти / навчальні посібники не вимагають захисту CSRF, якщо використовується JWT. Я читав досить багато і намагаюся узагальнити проблеми нижче. Я просто хочу, щоб хтось міг надати широку картину JWT та уточнити поняття, які я неправильно зрозумів щодо JWT.

1. Якщо JWT зберігається у файлі cookie, я вважаю, що це так само, як ідентифікація на основі файлів cookie, за винятком того, що серверу не потрібно проводити сеанси для перевірки файлу cookie / маркера. Існує ризик щодо КСВР, якщо не буде здійснено спеціального заходу. Чи не зберігається JWT у файлі cookie?

2. Якщо JWT зберігається в localStorage / sessionStorage, то жодному файлу cookie не потрібно захищати від CRSF. Питання в тому, як відправити JWT на сервер. Я знайшов тут запропонувати використовувати jQuery для надсилання JWT за допомогою HTTP заголовка запитів ajax. Отже, тільки запити ajax можуть зробити аутентифікацію?

3. Крім того, я знайшов ще одне шоу в блогах, щоб використовувати "Заголовок авторизації" та "Носій" для надсилання JWT. Я не розумію метод, про який розповідає блог. Чи не могли б хто-небудь пояснити більше про "Заголовок авторизації" та "Носій"? Це робить JWT, переданим заголовком HTTP ВСІХ запитів? Якщо так, то як щодо CSRF?

Маркери JWT популярні, оскільки використовуються як формат токенів за замовчуванням у нових протоколах авторизації та автентифікації, таких як OAuth 2.0 та OpenID Connect .

Коли маркер зберігається у файлі cookie, браузер автоматично надсилатиме його разом із кожним запитом до одного домену, і це все ще вразливе для атак CSRF.

Аутентифікація носія є однією із схем аутентифікації, визначених у HTTP. Це в основному означає, що YOUдотримуйтесь маркер (JWT) у заголовку HTTP авторизації запиту. Веб-переглядач NOTзробить це автоматично для вас, тому він не підходить для захисту вашого веб-сайту. Оскільки браузер автоматично не додає заголовка до вашого запиту, він не є вразливим до CSRF-атаки, що залежить від того, що інформація про аутентифікацію автоматично надсилається до вихідного домену.

Схема носія часто використовується для захисту веб-API (REST-сервісів), які використовуються через дзвінки AJAX або від мобільних клієнтів.

Нам потрібно зберігати JWT на клієнтському комп'ютері. Якщо ми зберігаємо його в LocalStorage / SessionStorage, то його можна легко схопити нападом XSS. Якщо ми зберігаємо його у файлах cookie, то хакер може використовувати його (не читаючи) під час атаки CSRF і видавати себе за користувача, зв’язуватися з нашим API та надсилати запити на виконання дій або отримання інформації від імені користувача.

Але є кілька способів закріпити JWT у файлах cookie, щоб їх не вкрали легко (але все-таки є деякі передові методи їх викрадення). Але якщо ви хочете покластися на LocalStorage / SessionStorage, то до нього можна дістатися простою атакою XSS.

Тому для вирішення проблеми CSRF я використовую у своїй заяві «Double Submit Cookies».

Метод подвійного надсилання файлів cookie

1. Зберігайте JWT у файлі cookie HttpOnly і використовуйте його в захищеному режимі для передачі через HTTPS.

2. Більшість атак CSRF мають інше походження або заголовок реферала з оригінальним хостом у своїх запитах. Тож перевірте, чи є у вас якийсь із них у заголовку, вони надходять із вашого домену чи ні! Якщо не відхилити їх. Якщо і запит, і посилання, не доступні в запиті, не хвилюйтесь. Ви можете розраховувати на результат перевірки заголовка X-XSRF-TOKEN, який я пояснюю на наступному кроці.

3. Хоча браузер автоматично надає ваші файли cookie для домену запиту, є одне корисне обмеження: JavaScript-код, який працює на веб-сайті, не може читати файли cookie інших веб-сайтів. Ми можемо використовувати це для створення нашого рішення в галузі CSRF. Щоб запобігти атакам CSRF, ми повинні створити додатковий файл, який читається в JavaScript, який називається: XSRF-TOKEN. Цей файл cookie повинен бути створений, коли користувач увійшов у систему, і він повинен містити випадкову невідповідну рядок. Ми також зберігаємо це число в самому JWT як приватну претензію. Кожен раз, коли програма JavaScript хоче надіслати запит, потрібно буде прочитати цей маркер і надіслати його у власному заголовку HTTP. Оскільки ці операції (зчитування файлу cookie, встановлення заголовка) можна проводити лише в тому самому домені програми JavaScript,

Кутовий JS полегшує ваше життя

На щастя, я використовую Angular JS в нашій платформі та Angular пакетах підходу маркера CSRF, що робить його більш простим у здійсненні. Для кожного запиту, який робить наш $httpсервісний додаток Angular, служба Angular виконає такі дії автоматично:

• Шукайте файл cookie на ім'я XSRF-TOKEN у поточному домені.
• Якщо цей файл cookie знайдений, він зчитує значення та додає його до запиту як заголовок X-XSRF-TOKEN.

Таким чином, реалізація на стороні клієнта для вас обробляється автоматично! Нам просто потрібно встановити файл cookie XSRF-TOKENна поточному домені на стороні сервера, і коли наш API отримав будь-який дзвінок від клієнта, він повинен перевірити X-XSRF-TOKENзаголовок і порівняти його з XSRF-TOKENJWT. Якщо вони відповідають, то користувач справжній. В іншому випадку це підроблений запит, і ви можете його проігнорувати. Цей метод натхненний методом "Подвійне надсилання файлів cookie".

Обережність

Насправді ви все ще сприйнятливі до XSS, це просто те, що зловмисник не може викрасти вам JWT-маркер для подальшого використання, але він все одно може робити запити від імені ваших користувачів за допомогою XSS.

Незалежно від того, чи зберігаєте ви свій JWT в localStorageабо ви зберігаєте свій XSRF-маркер у файлі cookie не HttpOnly, обоє можуть бути легко схоплені XSS. Навіть ваш JWT у файлі cookie HttpOnly можна схопити за допомогою вдосконаленої атаки XSS, як метод XST .

Отже, окрім методу "Double Submit Cookies", ви завжди повинні дотримуватися найкращих практик щодо XSS, включаючи вміст, що відмічається. Це означає видалити будь-який виконуваний код, який призведе до того, що браузер зробить те, чого ви не хочете. Зазвичай це означає видалення // <![CDATA[тегів та атрибутів HTML, які викликають оцінку JavaScript.

Детальніше читайте тут:

• XSRF Angular: як це працює
• Де зберігати свої JWT - файли cookie та HTML5 Web Storage

Ще один кут до всього питання зберігання JWT:

1. JWT ніколи не слід зберігати у вашому локальному сховищі
2. Насправді вони навіть не повинні зберігатися у ваших файлах cookie , якщо тільки ви не зможете застосувати дуже суворий захист CSRF

Оформити замовлення на мотивацію

• JWT як id_token - це як ваші облікові дані користувачів
• JWT як access_token - це як маркер вашого сеансу

Найбільш безпечний варіант - це пам'ять . Отримайте замовлення на глибоке занурення