Каков риск безопасности отражения объекта?

Question

Таким образом, после нескольких часов обхода ограничения на отключение отражения в Google App Engine, мне стало интересно, может ли кто-нибудь помочь мне понять, почему отражение объекта может представлять угрозу. Это потому, что я могу проверять закрытые переменные класса или есть другие более глубокие причины?

Answer 1

1 - Отражение (как концепция) действительно ортогонально безопасности / безопасности.

При разработке Java был сделан большой упор на то, чтобы сделать его безопасной платформой, с статической типизацией , менеджер безопасности , дисциплинированное использование загрузчика классов , и нет возможности прикрутить указатели / memory .Вы можете прочитать интервью Джеймса Гослинга в Мастер программирования , что интересно об этом.

Но чем больше у отражающей мощности, тем труднее ее обеспечитьвсе безопасно, как и должно.Отражение побеждает, в частности, статическую типизацию и может привести к ошибкам во время выполнения.

Но могут происходить и более тонкие вещи.Например, загрузчики классов - которые можно рассматривать как отражающий хук в системе - не были спроектированы должным образом в ранней версии Java, что привело к потенциальной замене типов.Статья Динамическая загрузка классов в JVM, Гилада Брача, проницательна по таким вопросам.

Отражение нельзя отключить вообще;всегда можно поразмышлять над своими открытыми полями / методами.Однако отражение в частных структурах с AccessibleObject.setAccessible можно отключить, поскольку оно нарушает encapsulation .При доступе к приватным полям и т. Д. Возможна проверка и изменение внутренних данных.Это может привести к различным вредоносным эксплойтам , например

• strings больше не являются неизменяемыми и могут быть изменены (см. Этот вопрос )
• вы можете раскрыть разумную информацию об объектах, которые вам не принадлежат
• ... другие эксплойты ...

Наконец, есть другой механизм, который ставит под угрозу безопасность, в частности sun.misc.Unsafe, который дает прямой доступ к памяти - указатели вернулись.

2 - Вопрос в том, приводит ли рефлексия (на практике) к такому множеству рисков.

Я прочитал ссылку, указанную @ dbyrne , но в основном этоо .net.Также я не знаю точно, что отключено для Google App.Это только ReflectPermission или другое разрешение администратора безопасности?Очевидно, одна опасность - получить доступ к файловой системе и бездельничать.

Проблема доступа к частным данным и нарушения инкапсуляции может быть обсуждена на практике.Написание защищенного кода действительно чрезвычайно сложно, и даже без изменения модификатора доступа вы можете подклассировать классы ненадлежащим образом - если они не являются final или даже лучше - запечатаны - и передавать их.Это, например, то, от чего защитное копирование пытается защитить.

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

В общей / размещенной среде безопасность относительно.На уровне языка вы можете, например, не запретить модульной форме, потребляющей 100% ЦП или потребляющей всю память вплоть до OutOfMemoryException.Такие проблемы необходимо решать другими способами, обычно на уровне ОС, с виртуализацией и квотами.

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

Answer 2

Приложение может использовать API отражения Java для доступа к полям и их обновления, а также для выполнения методов, запрещенных обычными правилами доступа / видимости Java. С некоторой изобретательностью этого достаточно, чтобы:

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

При определенных обстоятельствах он может даже позволить внедрить вредоносный нативный код.

Answer 3

Прежде всего, если вы не установили SecurityManager, значит, вы все равно не защищены.

Во-вторых, отражение не открывает значительных дыр, если только setAccessible() не включено, и оно само подвергается проверке безопасности (регулируется setAccessChecks разрешением отражения ). Без этого, в то время как вы могли бы знать, что частное поле или метод существует (хотя само по себе это требует accessDeclaredMembers разрешения времени выполнения ), вы ничего не сможете сделать с этими знаниями. Лучшим вариантом для атаки может быть работа с сериализованными объектами, но это всего лишь «второй шарик воска».

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

Answer 4

GAE - это среда общего хостинга, в которой хранятся файлы WAR от нескольких пользователей.Весьма вероятно, что несколько файлов WAR размещены в одной и той же JVM, потому что порождение процесса на WAR просто смешно.Таким образом, единственный способ изолировать песочницу для каждого файла войны - через пользовательский загрузчик классов для каждого файла WAR.

Теперь предположим, что отражение разрешено.Вы могли бы тогда пройтись по иерархии загрузчиков классов и перечислить классы / методы из файлов WAR, принадлежащих разным пользователям.Очевидно, это большая проблема.

Answer 5

Моя теория состоит в том, что Google пытается что-то скрыть.Отключив Отражение Google может скрывать имена переменных, вызовы функций и даже полный API.Если Google скрывает что-то вроде API, то они наверняка не скажут вам об этом.

Я точно знаю, что Reflection играет очень важную роль в тестировании безопасности.Например, вы можете автоматически создавать Fuzz-тесты, используя отражение. AxMan использует TypeLib для идентификации всех классов и их вызовов методов, которые составляют COM-объект.Используя эту информацию, AxMan создаст экземпляр каждого класса и вызовет каждый метод с перестановками длинных строк и больших чисел.Аналогичное тестирование проводится SOAP Fuzzers с использованием файла WSDL для отражения.