Внешние классы обращаются к закрытым методам пакета

Question

Предположим, у меня есть класс в моем пакете org.jake, и у него есть метод с доступом по умолчанию (без модификатора). Тогда метод виден только внутри пакета.

Однако, когда кто-то получает банку моей платформы, что мешает им написать новый класс, объявить его пакет как org.jake и использовать мой предположительно невидимый метод?

Другими словами, что я могу сделать, чтобы предотвратить это?

Answer 1

Вы можете запечатать пакет в вашем файле jar. Это не пуленепробиваемый, хотя.

Главное - не полагаться на модификаторы доступа и т. Д. С точки зрения безопасности. Если кто-то запускает код с неограниченными разрешениями, он будет иметь доступ ко всем видам вещей. Модификаторы доступа действительно помогают предотвратить случайное *1006* попадание людей в ногу.

Если кто-то желает поместить классы в ваш пакет, чтобы обойти вашу инкапсуляцию, он явно игнорирует ваши лучшие намерения - я говорю, давайте продолжим, но не обеспечим поддержку этого сценария.

Answer 2

Вы ничего не можете сделать, чтобы предотвратить это. Даже частные члены могут быть доступны через отражение. Вы должны рассмотреть модификаторы доступа в Java, чтобы быть просто наводящим на размышления.

Answer 3

Во-первых, это сценарий «DRM»: в конечном счете, кто-то определил, достаточно ли может победить любые средства защиты, которые вы установили, предоставив измененную среду выполнения или другие подобные вещи. Обратный сценарий - когда среда выполнения является доверенной, а некоторые пакеты - нет, - надлежащим образом решается Java посредством использования подходящих ограничений ClassLoader, но это может работать только там, где есть что-то, что может обеспечить ограничения доверенным способом; вот почему ваш сценарий в основном обречен.

Однако, , если мы предположим, что сама среда выполнения является надежной , тогда вы можете попытаться в своем сверхсекретном методе получить трассировку стека текущего выполняемого стека (см. stackoverflow.com / Вопросы / 1069066 /… о том, как) и тестирование, чтобы определить, является ли вызывающая сторона текущего метода доверенной для получения доступа. Менеджер безопасности был бы еще более подходящим, но вы не можете доверять среде, чтобы установить одну из тех, которые вам нравятся (это намного более четко под контролем злоумышленника). Обратите внимание, что я не пробовал варианты в этом пункте!

Другой альтернативой является передача ваших секретов службе, которой вы управляете, и предоставление только удаленного доступа к ним. Или перестаньте беспокоиться об использовании технических механизмов для решения проблемы, которая в основном связана с бизнесом и правовыми вопросами (например, почему вы имеете дело с людьми, которым вы не можете доверять?)

Answer 4

Я бы сказал, просто не позволяйте им запускать код там, где он может вызывать ваш, то есть в той же JVM. Вместо этого вы можете рассмотреть вопрос о предложении только (веб) службы, которую они могут вызывать извне. Я не очень в курсе о лучших способах реализации этого.