В зависимости от контекста вы полагаетесь на менеджера безопасности и связанную с ним политику безопасности. Как правило, если вы не делаете свою собственную магию загрузчика классов, вам не нужно делать ничего особенного. Если у вас есть контроль над политикой безопасности (например, в приложении Java, а не в апплете), вы можете предоставить разрешения на вызов ваших банок только для определенного другого кода. Если вы полагаетесь на кодовую базу для различения кода, лучше использовать URL-адрес https. Также не вредно ограничить доступ к банкам на веб-сервере, если вы знаете, откуда/от кого должен исходить доступ, но, вероятно, это больше проблем, чем того стоит.
Однако вы всегда должны помнить, что вызывающая сторона вашего API может быть не вашим кодом и может быть злонамеренной. Таким образом, при моделировании угроз вы должны подумать о том, что может сделать злоумышленник, если он каким-то образом получил доступ к функциям, предоставляемым API, предоставляемым вашим кодом. Менеджер безопасности должен проверять стек вызовов, чтобы предотвратить подобные вещи. Но если, например, в вашей подписанной банке есть метод LaunchMissiles() ... вы можете спросить пользователя, уверены ли они в любом случае. И вы также можете аутентифицировать пользователя.
Вы также не должны обязательно полагаться на то, что пользователь нажмет правую кнопку при любом предупреждении безопасности, особенно если оно относится к сертификатам, URL-адресам и т. д. — большинство пользователей попадают в одну из двух категорий: те, кто нажимает «ОК» в любом предупреждении, потому что они не понимают его, и тех, кто нажимает «Отмена» в любом предупреждении, потому что они его не понимают.
person
frankodwyer
schedule
17.12.2008