Почему мы используем private в Java, если у нас есть отражение [duplicate]
Я думаю, что это должно сработать ...
var query = from m in context.MyTable, где m.MyContainerId == '1' // или какое бы имя внешнего ключа. .. выберите m; var count = query.Count (); 5 ответов
1 - Отражение (как концепция) действительно ортогонально безопасности / безопасности.
В дизайне java большое внимание уделялось дизайну java, чтобы сделать его безопасной платформой со статической типизацией, менеджером безопасности, дисциплинированное использование загрузчика классов, а также отсутствие возможности наведения указателей / памяти. Вы можете прочитать интервью Джеймса Гослинга в Учреждениях программирования , что интересно об этом.
Но чем больше отражающей способности, тем сложнее обеспечить безопасность вещей, как им следует. Отражение поражает, в частности, статическую типизацию и может привести к ошибкам во время выполнения.
Но возможны и более тонкие вещи. Например, загрузчики классов, которые можно рассматривать как рефлексивный крючок в системе, были неправильно разработаны в ранней версии Java, что привело к потенциальной замене типа. Статья Загрузка динамического класса в JVM, Гиладом Брахой, проницательна по таким вопросам.
Отражение нельзя полностью отключить; всегда можно задуматься о своих собственных общественных полях / методах. Однако отражение в частных структурах с AccessibleObject.setAccessible может быть отключено, поскольку оно прерывает инкапсуляцию. Доступ к закрытым полям и т. Д. Возможен осмотр и изменение внутренних данных. Это может привести к различным вредоносным атакам, например.
-
строкибольше не являются неизменяемыми и могут быть изменены (см. этот вопрос ) - вы можете выявить разумную информацию объектов, которые у вас нет
- ... другие эксплойты ...
Наконец, есть другой механизм, который ставит под угрозу безопасность, особенно sun. misc.Unsafe , который дает прямой доступ к указателям памяти.
2 - Теперь вопрос заключается в том, приведет ли отражение (на практике) к множеству рисков.
Я прочитал ссылку, указанную @dbyrne но это в основном около .net. Также я точно не знаю, что отключено для приложения Google. Это только ReflectPermission или другое разрешение диспетчера безопасности? Одна опасность заключается в том, чтобы получить доступ к файловой системе и беспорядок.
Проблема доступа к конфиденциальным данным и прерывания инкапсуляции может быть доказана на практике. Написание защищенного кода действительно чрезвычайно сложно, и даже без изменения модификатора доступа вы можете подклассифицировать классы неприемлемым образом - если они не являются final или даже лучше, закрыты - и передают их. Это, например, то, что защитное копирование пытается защитить.
Тип-безопасность также в любом случае угрожает ошибкой во время выполнения из-за downcast, поэтому этот аргумент также может быть аргументирован.
В общей / размещенной среде безопасность относительна. На уровне языка вы можете, например, не мешать модульной форме, потребляющей 100% процессора, или потребляющей всю память до OutOfMemoryException .
Таким образом, мой личный ответ был бы следующим: отражение - это риск безопасности, но не такой большой в по сравнению с другими потенциальными атакующими векторами.
Во-первых, если вы не установили SecurityManager , то вы все равно не защищены.
Во-вторых, отражение не открывает значительных отверстий, если только setAccessible () включен, и сам он подвергается проверке безопасности (управляемой разрешением setAccessChecks ] ). Без этого, хотя вы можете знать, что существует личное поле или метод (хотя для этого требуется разрешение accessDeclaredMembers ), вы не можете ничего с этим сделать знание. Лучшая ставка для атаки может заключаться в работе с сериализованными объектами, но это цельный «шарик из воска».
Обратите также внимание на то, что писать безопасный менеджер безопасности и загрузчик классов нетривиальны. Лучше оставить их другим, если вы не стремитесь к мега-гуру-домику (или, скорее, смущающим уровням неудачи).
GAE - это общедоступная среда хостинга и содержит файлы WAR от нескольких пользователей. Очень вероятно, что несколько файлов WAR размещены в одной JVM, потому что нереста процесса на WAR просто смешно. Таким образом, единственный способ изолировать каждый файл войны - через пользовательский загрузчик классов для каждого файла WAR.
Теперь предположим, что отражение разрешено. Вы могли бы затем пройти иерархию загрузчика классов и перечислить классы / методы из файлов WAR, принадлежащих разным пользователям. Очевидно, это большая проблема.
Приложение может использовать API отражения Java для доступа и обновления полей и выполнять методы, которые запрещены нормальными правилами доступа / видимости Java. С некоторой изобретательностью это достаточно для:
- доступа к информации, которая должна быть скрыта,
- подорвать изолированную программную среду Java, чтобы вы могли вмешиваться в другие вещи запуск в JVM, доступ к файлам на локальном компьютере и т. д.
При определенных обстоятельствах это может даже позволить ввести вредоносный код.
-
1Интересно, не могли бы вы предоставить более подробную информацию? Возможно, ссылка. – rook 9 June 2010 в 08:13
AccessibleObject.setAccessible, когда это запрещено. Я не знаком с GSON и почему ему нужно изменить модификатор доступа. Я думаю, вы должны посмотреть на код GSON, если хотите это понять. Возможно, вы можете создать свою собственную версию GSON, которая использует отражение, но не используетAccessibleObject.setAccessibleи убедитесь, что вы передаете объекты для сериализации, где все поля / методы являются общедоступными. – ewernli 10 June 2010 в 08:49