Предположим, что у меня есть класс в моем пакете org.jake, и у него есть метод с доступом по умолчанию (без модификатора). Тогда метод видится внутри пакета.
Однако, когда кто-то получает банку моего фреймворка, что мешает им писать новый класс, объявляя его пакет как org.jake и используя мой якобы невидимый метод?
Другими словами, есть ли что-нибудь, что я могу сделать, чтобы предотвратить это?
Вы можете запечатать пакет в своем файле jar. Однако он не пуленепробиваемый.
Главное, чтобы на самом деле не полагаться на модификаторы доступа и т.д. с точки зрения безопасности. Если кто-то запускает код с неограниченными разрешениями, у них будет доступ ко всем видам вещей. Модификаторы доступа действительно просто помогают помешать людям случайно выстрелить себе в ногу.
Если кто-то хочет помещать классы в ваш пакет, чтобы обойти вашу инкапсуляцию, они явно игнорируют ваши лучшие намерения - я говорю, давайте продолжим с ним, но не поддерживаем этот сценарий.
Вы ничего не можете сделать, чтобы предотвратить это. Даже частные члены могут получить доступ через отражение. Вы должны учитывать, что модификаторы доступа в java просто наводящие на размышления.
Во-первых, это сценарий "DRM": в конечном счете, кто-то достаточно определил, может победить любые защитные меры, которые вы создали, предоставив фанки модифицированное время выполнения или другие подобные вещи. Обратный сценарий - когда среда выполнения доверена, но некоторые из пакетов не являются - правильно обрабатывается Java с использованием подходящих ограничений ClassLoader, но это может работать только там, где есть что-то, что может принудительно применять ограничения; почему ваш сценарий в основном обречен.
Однако , если мы предположим, что сама среда выполнения является надежной, вы можете попробовать в своем суперсекретном методе получить трассировку стека текущего исполняемого стека (см. fooobar.com/questions/11738/...) и тестирование, чтобы узнать, является ли вызывающий объект текущего метода тем, которому вы доверяете, чтобы получить доступ. Менеджер безопасности будет еще более подходящим, но вы не можете доверять окружающей среде, чтобы один из тех, которые вам нравились (это гораздо более четко под контролем атакующего). Обратите внимание, что я не пробовал варианты в этом параграфе!
Другая альтернатива заключается в том, чтобы поместить свои секреты в службу, которую вы контролируете, и предлагать только удаленный доступ к ним. Или перестать беспокоиться об использовании технических механизмов для решения проблемы, которая в основном связана с деловыми и юридическими проблемами (например, почему вы имеете дело с людьми, которых вы не можете доверять?)
Я бы сказал, просто не разрешаю им запускать код, где он может позвонить, т.е. в той же JVM. Вместо этого вы могли бы предложить только услугу (интернет), которую они могут вызвать извне. Я не очень в курсе лучших способов реализовать это.