Зачем нам нужна безопасность на уровне метода?


14

В реальном мире, почему мы должны реализовать безопасность на уровне метода?

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

Так, где методы доступа непосредственно входят в картину здесь?

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

что-то вроде :

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

1. повторно использовать код, не думая о проблемах безопасности 2. легко интегрировать с веб-сервисом 3. быть уверенным в безопасности, когда вы не доверяете механизмам безопасности верхних уровней
Эркан Эрол

Ответы:


23

В правильно разработанном приложении сервер и интерфейс отключены. Бэкэнд-система безопасности не может предполагать, что какой-либо конкретный интерфейс будет правильно обрабатывать безопасность, поэтому он должен сам ее обрабатывать.


Вы не ответили на вопрос: почему метод уровня?
Кодизм

@Codism - Он действительно ответил на это. Б / к вы не можете ничего предположить. Вы делаете проверку авторизации на уровне метода b / c, независимо от того, как кто-то туда попал, вам нужно убедиться, что у него есть соответствующие права.
Джозеф Ласт

@JosephLust: ответ и ваш комментарий могут быть применены к любой системе безопасности на любом другом уровне. Оригинальный вопрос был конкретно спрашивать, почему на уровне метода.
Кодизм

1
Потому что это самый низкий доступный уровень, который легко применить, используя AOP или AspectJ. Я не верю, что это относится ко всем другим реализациям безопасности.
Джозеф Ласт

5

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

В отношении более детального контроля доступа на основе ролей рассмотрим следующее:

  • Удобно группировать все действия вокруг ресурса. То есть ваши действия Create / Read / Update / Delete (CRUD) для статей, учетных записей и т. Д. Это облегчает написание и сопровождение API в стиле REST.
  • Многие системы имеют разные учетные данные / роли, необходимые для действий Создать / Обновить / Удалить, чем для действий Чтение.
  • Если все действия с учетными записями пользователей выполняются на одном контроллере, вы хотите разрешить всем входить в систему, но только определенным пользователям создавать новые учетные записи или назначать роли.

Нравится вам это или нет, но когда Ruby on Rails появился в эфире несколько лет назад, почти каждая инфраструктура MVC копировала свой фундаментальный подход к проектированию. Раньше считалось, что действия - это отдельные классы, но логика действий имеет тенденцию быть небольшой и сфокусированной, поэтому полная нагрузка на класс оказывается излишней. Отображение метода на контроллере на действие для страницы действительно имело большой смысл. Просто знайте, что многим людям нужен детальный контроль над тем, какие роли могут выполнять какие функции.


3

Безопасность на уровне метода полезна по двум основным причинам:

  • как еще один уровень безопасности (в дополнение к другим слоям)

  • в случаях, когда более удобно или логично иметь разрешения на уровне метода, рассмотрим случай, когда разные пользователи могут выполнять одни и те же «прямые» действия (поэтому безопасность клиента не имеет значения). но в некоторых случаях их действие может вызвать поведение, которое вы хотите ограничить, - в этом случае безопасность на уровне метода может быть подходящим решением.


0

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

Безопасность жесткая, многоуровневая безопасность повысит шансы блокировать попытки обхода. Поскольку безопасность уровня метода напрямую кодируется внутри класса, после добавления AOP при вызове метода вы всегда будете вызывать проверку безопасности раньше.


-2

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

Если так, то они не существуют в целях безопасности. Они существуют для того, чтобы упростить или гарантировать правильную модульность программного обеспечения. (Удастся ли им в этом - это спор, который я оставлю для других. Однако это видение того, для чего они нужны.)

Предположим, что я доставляю библиотеку, затем я могу свободно доставить другую версию библиотеки и изменить содержимое, помеченное как личное, сколько захочу. Напротив, если бы я не пометил этот материал как частный, то я не смог бы изменить какие-либо внутренние компоненты моего программного обеспечения, потому что кто-то где-то, вероятно, имеет к нему доступ напрямую. Конечно, в теории это их вина за то, что они не использовали документированный API. Но клиент воспримет это как мою ошибку, что мое обновление программного обеспечения сломало их программное обеспечение. Они не хотят оправданий, они хотят, чтобы это исправили. Но если я не позволю им иметь доступ с самого начала, то мой API - это именно публичные методы, которые я намеревался использовать в качестве API, и проблема устранена.

Вторая наиболее вероятная вещь, о которой вы могли бы говорить, это модель безопасности Java. Если вы говорите об этом, то причина, по которой он существует, заключалась в том, что первоначальное видение Java включало людей, отправляющих, возможно, ненадежные апплеты для интерактивной работы внутри сторонних программ (например, браузеров). Поэтому модель безопасности должна была предоставить пользователям некоторую защиту от вредоносных апплетов. Поэтому угроза безопасности, о которой следует беспокоиться и защищать, - это ненадежные апплеты, пытающиеся взаимодействовать с другим программным обеспечением, которое может быть загружено.


2
вы не поняли, он говорит не о публичном, частном и защищенном, а о проверке, имеет ли пользователь роль в AOP или нет
stivlo
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.