Навіщо нам потрібна безпека на рівні методу?

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

У нас є веб-додаток або настільний додаток, де користувач отримує доступ до користувальницького інтерфейсу (і тому безпосередньо не може отримати доступ до методу).

Тож де тут доступні способи доступу безпосередньо до картини?

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

щось на зразок :

 @ROLE_ADMIN
public void update() {
      //update
}

У правильно розробленому додатку підключення та інтерфейс відключені. Бекенд система безпеки не може припустити, що будь-який конкретний інтерфейс буде правильно керувати безпекою, тому він повинен сам обробляти.

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

Що стосується більш тонкого контролю над доступом на основі ролей, врахуйте це:

• Зручно групувати всі дії навколо ресурсу разом. Тобто ваші дії "Створення / читання / оновлення / видалення" (CRUD) для статей, облікових записів тощо. Це полегшує написання та підтримку API стилів REST.
• Багато систем мають різні облікові дані / ролі, необхідні для дій "Створення / оновлення / видалення", ніж для дій "Читання".
• Якщо всі дії облікового запису користувача виконуються в одному контролері, ви хочете дозволити будь-якому користувачеві входити, але лише певним людям створювати нові облікові записи або призначати ролі.

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

Безпека рівня методу корисна з двох основних причин:

• як ще один рівень захисту (крім інших шарів)

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

Майк Wiesner нагадав , що в цьому SpringSource презентації Введення в Spring Security 3 / 3.1 , навів приклад , що Tomcat, і багато інших сервлетів контейнерів була помилка , яка не в змозі правильно розпізнати «../», при кодуванні в Unicode, таким чином , що простий тест рівності не вдався б у Java, але переклав би у верхній каталог файлової системи.

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

Я припускаю, що ви тут говорите про публічні, приватні та захищені методи?

Якщо так, то вони не існують з метою безпеки. Вони існують з метою полегшення гарантії правильності модуляції програмного забезпечення. (Чи вдасться їм у цьому досягти дискусії, я залишу для інших. Це, однак, бачення того, для чого вони потрібні.)

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

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