Чи нормально мати рівень перевірки перед рівнем контролю доступу

Я створюю розроблений веб-додаток API, і в цьому додатку у нас є різні шари, які роблять свою роботу.

Першим шаром є рівень перевірки, який підтверджує введення користувача, і якщо він передає перевірку, ми переміщуємо його на другий рівень (який є шаром контролю доступу ), інакше повертаємо повідомлення про помилку

Другий рівень - це контроль доступу, який перевіряє, чи має користувач дозвіл на виконання завдання, яке він хоче виконати. Якщо користувач має дозвіл, він переносить запит на наступний рівень, інакше поверне повідомлення про помилку

Третій шар - це контрольний шар, де ми маємо логіку застосування

Моє запитання полягає в тому, що гаразд, щоб мати рівень перевірки перед контролем доступу? Що робити, якщо користувач намагається виконати завдання, на яке користувач не має дозволу, і ми надсилаємо повідомлення про помилку перевірки? Користувач буде надсилати запити до кінцевої точки і спілкуватися з шаром перевірки, і як тільки він пройде перевірку, тільки тоді він побачить повідомленняYou can't access this!

Мені це здається дивним, так це добре, як це, або які мої інші варіанти в цій інфраструктурі?

Це залежить від того, чи знає обгрунтованість певного входу для завдання, яке вам заборонено виконувати, - це витік безпеки. Якщо це так, ви дійсно повинні зробити це навпаки.

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

Як приклад, ви могли б перевірити перевірку завдання "видалити документ", що названий документ існує. Хтось, хто не має дозволів, зможе визначити, чи існує щось, намагаючись видалити його та порівняти, яку помилку вони отримують назад. Особливо рішучий зловмисник може перерахувати всі назви документів (під певну довжину), щоб побачити, що існує.

Ну, є кілька типів перевірки:

1. Недорога базова перевірка рівня доцільності, яка підтверджує, що запит не є явно неправильним.

   Це, як правило, принаймні частково дублюється на стороні клієнта, щоб уникнути марних туди-назад.

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

2. Більш дорога перевірка, яка все ще не залежить від будь-яких захищених даних програми.

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

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

3. Додаткова перевірка залежно від захищених даних програми.

   Це робити перед контролем доступу, очевидно, ризикує витік інформації. Таким чином, спочатку зробіть контроль доступу.

Перед контролем доступу має бути певна перевірка. Скажімо, API SO має кінцеву точку "редагувати відповідь", то чи може користувач може редагувати конкретну відповідь, може залежати від відповіді (нижче певної репутації користувач може редагувати лише власні відповіді). Таким чином, добре сформований параметр "Ідентифікатор відповіді" повинен бути перевірений до того, як рівень контролю доступу вступатиме в гру; можливо також, що відповідь існує.

OTOH, як зазначають Калет і Грег, ставить більш широку перевірку до контролю доступу - це потенційний ризик безпеки.

Тож жорсткі правила є

1. Ви не повинні розголошувати будь-яку інформацію за допомогою перевірки, яку користувач не повинен іншим способом дізнатися.
2. Ви повинні перевірити дані, перш ніж контроль доступу може використовувати їх у тій мірі, в якій потрібен контроль доступу.

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

На додаток до можливих розладів отримання «доступу заборонено» після перевірки даних; також пам’ятайте, що шару перевірки , якщо він не є дуже простим, завжди може знадобитися інформація від контролера . Маючи на увазі це, я вважаю, що розміщення валідації за контролем доступу ближче до контролера має більше сенсу.

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

Ви, безумовно, повинні мати перевірку стану безпеки перед тим, як намагатися контролювати доступ, але слід подбати про те, щоб дуже чітко повідомляти всім обслуговуючим особам (поточним та майбутнім), що ця частина не повинна використовувати привілейовану інформацію; Будь-які такі перевірки слід проводити на окремому етапі перевірки після аутентифікації.

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

Ні. Це не нормально.

Якщо у вашому шарі перевірки є помилка, вона може обійти захисний шар.

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

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