Авторизация данных
Цели
- Понять какие грабли при авторизации
- Упорядочить механики авторизации
- Сделать так, чтобы механики авторизации были понятны разработчикам
- Вероятность того, что разработчик забудет авторизовать данные должна быть нулевой или, хотя бы, близкой к нулю
Авторизация
в Партнёрке
Причины
- По ощущениям: На вебах сложнее всего сделать единую авторизацию
- Много открытых уязвимостей
- Большое количество пользователей
⇒ выше вероятность эксплуатации уязвимости
Подготовительные работы
Проблемы
- Общие контроллеры
- Непонятно как впиливать авторизацию на уровне конкретного приложения
- Нет единого места для инфраструктуры
- BaseController, BaseUploadController, BaseApiController, GlobalBase ...
- Нет каких-то правил, непонятно где искать нужную логику
Что пришлось сделать
- Разнос контроллеров из общих либ
- Удаление блоков
- Единый механизм обработки исключений на контроллере (IExceptionHander + ExceptionTracker)
- Выделение BaseSubsystemController
- Выделение BaseWebController из BaseController
- Выпиливание BaseUploadController
Проблема механизма авторизации данных
Web
BusinessService
DB
Context
UserId
AuthService
ids[]
Web
BusinessService
DB
Context
UserId
AuthService
ids[]
Web
BusinessService
DB
DataService
Context
UserId
Web
BusinessService
DB
query
WHERE userId = '...'
Context
UserId
Web
BusinessService
DB
query
SearchIndex
ids[]
BasePartnerController
хорошо спроектированная система
хорошо защищенная система
⇔
Баланс при проектировании API
ничего нельзя сделать
слишком мало информации
излишняя связность
слишком много информации
Излишняя связность
Bill
- Id
- Number
- ...
- Comment
- ...
изначально
не использовался
можем поменять контракт?
а что если кто-то пользуется?
Баланс при проектировании API
ничего нельзя сделать
слишком мало информации
излишняя связность
слишком много информации
На макро уровне: Bounded context
На микро уровне: Interface Segregation Principle
Баланс в безопасности
ничего нельзя сделать
слишком мало информации
возможность злоупотребления
слишком много информации
Баланс в безопасности
ничего нельзя сделать
слишком мало информации
возможность злоупотребления
слишком много информации
Принцип наименьшей ответственности:
«не даём возможности что-либо делать, если нет разрешения»
Защита от дурака
Защита от злодея
⇔
Какая разница кто удалит чувствительные данные?
Слова-то красивые...
Client
API
Пример
-
/prospectivesales/{id}/postpone
Что если вместо того, чтобы говорить мне чего нельзя делать, система будет говорить что можно?
Client
API
auth
Пример
-
/prospectivesales/{id}/CanTransferTo -
/prospectivesales/{id}/TransferTo
Выводы
- Единый механизм вызывает сложности
- Авторизация данных — часть бизнес-логики
Результаты
- Закрыли 10 IDOR уязвимостей в Партнёрке
- Отсылаем данные в security log при попытке неавторизованного доступа
Наши данные
-
Партнёрка
- Сертификаты
- Все API
- SQL таблицы в BillyAccounting
- Redash
Планы
Текущая ситуация
- 18 задач в бэклоге трелло + 14 уязвимостей в YT
- ~ 2-2,5 месяца на человека
AuthData
By koteek
