Автентифікація на основі сеансу:

Під час автентифікації на основі сеансу сервер створить сеанс для користувача після того, як користувач увійде в систему. Тоді ідентифікатор сеансу зберігається у файлі cookie у браузері користувача. Поки користувач залишається в системі, файл cookie надсилатиметься разом із кожним наступним запитом. Потім сервер може порівняти ідентифікатор сеансу, що зберігається у файлі cookie, з інформацією про сеанс, що зберігається в базі даних, щоб перевірити особу користувача, і надсилає відповідь із відповідним станом!

Структура JWT

Токен в основному складається із заголовка, корисного навантаження та підпису, розділених крапками (.). JWT визначає структуру інформації, яку ми надсилаємо від однієї сутності до іншої, і вона буває двох форм – серіалізована та десеріалізована.

Форми структури JWT

1 Десеріалізована

JWT у десеріалізованій формі містить лише заголовок і корисне навантаження. Обидва вони є простими об’єктами JSON, які потім кодуються в BASE64URL.

2 серіалізована

JWT у серіалізованій формі представляє рядок такого формату: [заголовок].[корисне навантаження].[підпис]

ЩО ТАКЕ JWT?

Веб-токен JSON (JWT) — це відкритий стандарт (RFC 7519), який визначає компактний і самодостатній спосіб безпечної передачі інформації між сторонами як об’єкт JSON. Цю інформацію можна перевірити та довіряти їй, оскільки вона має цифровий підпис. JWT можна підписувати за допомогою секрету (з алгоритмом HMAC) або пари відкритих/приватних ключів.

Заголовок:

Заголовок у JWT здебільшого використовується для опису криптографічних операцій, які застосовуються до JWT. Він також може містити дані про тип медіа/контенту інформації, яку ми надсилаємо. Простий заголовок JWT виглядає як наведений нижче код:

{
"typ":"JWT",

"alg":"HS256"

}

HS256 і RS256 — це два основні алгоритми, які ми використовуємо в розділі заголовка JWT.

«alg» і «typ» є ключами об’єктів, які мають різні значення та різні функції. «typ» дає нам тип заголовка цього інформаційного пакета. «alg» повідомляє нам про використаний алгоритм шифрування. Деякі JWT також можна створити без підпису чи шифрування.

Корисне навантаження:

Корисне навантаження — це частина JWT, куди фактично додаються всі дані користувача. Ці дані також називаються «claims» JWT. Цю інформацію може прочитати будь-хто, тому завжди раджу не розміщувати тут жодної конфіденційної інформації. Ми можемо розмістити скільки завгодно тверджень у корисному навантаженні, хоча, на відміну від заголовка, жодні claims не є обов’язковими в корисному навантаженні. JWT із корисним навантаженням виглядатиме приблизно так:

{
"userId":"b07f85be-45da",
"iss": "https://provider.domain.com/",

"sub": "auth/some-hash-here",

"exp": 153452683

}

«userId» це ідентифікатор користувача, який ми зберігаємо.

«iss» повідомляє нам про емітент сайт

«sub» означає тему

«exp» означає термін придатності

Підпис:

Це третя частина JWT, яка використовується для перевірки автентичності токена. Заголовок і корисне навантаження в кодуванні BASE64URL об’єднуються за допомогою точки(.), а потім хешуються за допомогою алгоритму хешування, визначеного в заголовку з секретним ключем. Потім цей підпис додається до заголовка та корисного навантаження за допомогою точки(.), яка формує наш фактичний токен: Header.Payload.Signature.

Синтаксис:

HASHINGALGO( base64UrlEncode(header) + “.” + base64UrlEncode(payload),secret)

Атаки JWT

Що таке атаки JWT?

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

Існують різні типи атак залежно від використовуваного алгоритму шифрування:

● Зловживання алгоритмом

● Видалення підпису

● Злом слабких спільних секретів

1) Зловживання алгоритмом

і почнімо з атаки Зловживання алгоритмом, подивимось де можуть тут бути провтики, давайте представимо, що у нас є такий токен

Злом слабких спільних секретів

2) Метод другий

Якщо ви не можете видалити підпис і alg "HS256", спробуйте скрипіти секретний ключ

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

Другу лабу можна пройти тут

Ми створити новий обліковий запис, щоб повністю заволодіти обліковим записом користувача 1

●користувач 1

Користувач: huzhabzy@xqukjngm.bn

Пароль: YCE7Jt6d54knpcr

●користувач 2

Користувач: lA8APD0d@opZoATFw.bn

Пароль: eX;;IQGo/|!7=]*

тобто виконали такі кроки для виконання:

1. Взяв токен для першого облікового запису

2. Перейшли на веб-токени JSON - jwt.io

3.Ввели секретний ключ "ASD123"

4. Змінено «userId» з 118096 на 117829

5. Взяли токен у формі веб-токенів JSON з jwt.io

6. Поверніться до burp і вставте новий токен і воля

Найкращі практики

1 Виконайте перевірку алгоритму

Щоразу, коли потрібно перевірити JWT, алгоритм має бути явно вибраний, щоб запобігти передачі контролю зловмисникам.

2 Використовуйте відповідні алгоритми

Програми мають використовувати лише криптографічно актуальні алгоритми, які відповідають вимогам безпеки.

3 Вибирайте міцні ключі

Слабкий ключ можна вгадати або підібрати. Щоб цього не було, бібліотеки генерації ключів повинні покладатися на генератори чисел. У кращому випадку можна використовувати апаратний генератор чисел.

4 Виконайте всі перевірки

Виконання надійної перевірки підпису будь-яких отриманих JWT. У випадку вкладених токенів необхідно завжди виконувати всі кроки перевірки, як зазначено в заголовках кожного токена.

5 Завжди перевіряйте емітенти

Якщо JWT містить «iss» (видавця), програма повинна підтвердити, що криптографічні ключі, які використовуються для криптографічних операцій у JWT, належать емітенту.

6 Завжди перевіряйте аудиторію

Якщо один і той самий емітент може випускати JWT, які призначені для використання більш ніж однією довіряючою стороною, JWT має містити «aud» (аудиторія), за допомогою якої можна визначити, чи використовується JWT передбачуваною стороною, чи його було замінено. зловмисником.

7 Встановіть термін придатності

JWT дуже важко відкликати після того, як вони видані та доставлені одержувачу. Через це вам слід використовувати якомога коротший термін дії ваших токенів.

8 Не довіряйте отриманим claims

Переконайтеся, що ви не вразливі до обходу шляху або впровадження SQL через параметр заголовка kid.

Автентифікація на основі токенів:

У додатку на основі токенів сервер створює JWT із ключем шифрування та надсилає JWT клієнту. Клієнт зберігає JWT (зазвичай у локальному сховищі) і включає JWT у заголовок кожного запиту. Потім сервер перевіряє JWT з кожним запитом від клієнта та надсилає відповідь.

Давайте спробуємо тут змінити розділ даних корисного навантаження, щоб зробити нас адміністраторами або отримати будь-який інший обліковий запис користувача, змінивши «userId» і «isAdmin», як це показано на малюнку, де ми вставили в «userId» - admin, а в «isAdmin» - true. Якщо вийде, то це буде казати нам про те, що є атака IDOR і може призвести до ескалації привілеїв.

Видалення підпису

1) метод перший

1. Змініть параметр alg на None

2. Змінити рівень на адміністратора (права ескалації)

3. Змінити користувача на будь-якого користувача

4. Видалити частину підпису

Лабораторку на практикуватись можете знайти тут

Тулзи для того, щоб практикуватись:

• Плагін до burp Suite - я би обрав його, або

• jwtcrack - або любі інші тулзи

Підказка: використовуйте розширення веб-токенів JSON

У нашому сценарії тут ми можемо здійснити повне захоплення облікового запису з іменем користувача і підвищувати привілеї

Реальний сценарій злому JWT HS256

Щоб більше погратися з лабами по jwt, то можна на цьому ресурсі portswigger. А ще розглянемо вразливість з реального проекту де давали винагороди за помилки, які використовують JWT з HS256.

1) "Поганий токен; недійсний alg"

-Видалення підпису

-"Недійсний підпис"

Тому ми і будемо зламувати JWT, оскільки алгоритм тут «HS256».