Вертикальне підвищення привілеїв

Що таке Вертикальне підвищення привілеїв?

Горизонтальне підвищення привілеїв — це рух убік, до даних іншого користувача. Вертикальне — це підйом сходами, бо перевірка авторизації довіряє значенню, яке тримає зловмисник. Ви побачите, як ваша роль передається всередині сесійного cookie з токеном JWT, перепишете поле з viewer на admin і потрапите до операційної консолі без викраденого пароля й без коду експлойта. Бар'єр декодує токен і читає поле, не перевіряючи підпис, а декодування нічого не доводить. Виправлення спершу перевіряє підпис, а страховкою слугує визначення привілеїв на боці сервера за довіреними записами.

Що ви дізнаєтесь у Вертикальне підвищення привілеїв

• Розрізняйте вертикальне й горизонтальне підвищення привілеїв за тим, куди зловмисник переміщується в ієрархії ролей
• Пам'ятайте, що автентифікація (доказ того, хто ви) — це не те саме, що авторизація (доказ, що вам це дозволено)
• Усвідомлюйте, що будь-яка роль, рівень чи дозвіл у токені або cookie, які зберігає клієнт, перебувають під контролем зловмисника, доки не перевірено їхню цілісність
• Застосовуйте виправлення, що перевіряє підпис токена, перш ніж довіряти полю, щоб підроблену роль відхиляли
• Додавайте страховку на боці сервера: заново визначайте привілеї за довіреними записами й дотримуйтеся принципу найменших привілеїв

Вертикальне підвищення привілеїв — Кроки навчання

1. Обліковий запис лише для читання

   Боб має легітимний, але малопривілейований обліковий запис в операційній консолі Talveyn: роль viewer підрядника, лише для читання. Він входить зі своїми обліковими даними, як і має право. Жодного викраденого пароля, жодного зламаного облікового запису. Він потрапляє на свою домашню сторінку з роллю viewer. Він бачить свої черги підтримки й одну картку, яка не для нього: «Консоль адміністратора».

2. Зачинені двері

   Боб усе одно відкриває консоль адміністратора зі своєї панелі, щоб подивитися, як далеко сягає його доступ. Сервер відмовляє йому повідомленням про обмеження доступу. Бар'єр справжній. Цікаво інше: що він насправді перевіряє.

3. Роль передається в токені

   Боб відкриває інспектор cookie в браузері. Його сесія — це токен JWT, і консоль декодувала його у зрозумілі поля: під яким іменем він увійшов і яку роль це йому дає. Ось вона, на видноті: поле role зі значенням viewer. Те значення, яке перевіряє бар'єр, лежить у токені в його власному браузері.

4. Підробіть роль

   Якщо консоль бере роль безпосередньо з токена, а токен лежить у браузері Боба, то Боб може її переписати. Він змінює поле role з viewer на admin. Інспектор знову кодує токен з новим полем. Підпис токена вже не збігається з вмістом, але це має значення, лише якщо сервер узагалі його перевіряє.

5. Усередині консолі адміністратора

   Боб перезавантажує адміністративну частину, цього разу з підробленим токеном. Бар'єр бачить у його полях admin і відчиняє двері навстіж. Тепер у нього повні адміністративні можливості: записи кожного користувача, право змінювати будь-яку роль, експортувати весь каталог користувачів, а також доступ до виставлення рахунків і виплат. Двадцять секунд тому це був обліковий запис лише для читання.

6. Назвіть, що сталося

7. Viewer із правами адміністратора

   Аліса відповідає за контроль доступу в консолі. Уночі моніторинг позначив те, що мало бути неможливим: сесія з роллю viewer виконувала дії, доступні лише адміністраторам. Центр моніторингу безпеки надіслав їй лист із висновками.

8. Відкрийте бар'єр адміністратора

   Усі адміністративні маршрути захищає один бар'єр, require-admin.js . Аліса відкриває файл, щоб побачити, як бар'єр визначає, хто вважається адміністратором.

9. Бар'єр довіряє токену

   Бар'єр бере роль того, хто викликає, із сесійного токена й порівнює її з admin. Чого він не робить ніколи — не перевіряє, що токен справжній. Вміст, переписаний у браузері, декодується без проблем, тож підроблена роль проходить без перешкод.

10. Виберіть справжнє виправлення