Внутренние классы. Часть 7 – безопасность

Как уже говорилось вложенные классы имеют доступ ко всем членам внешнего класса включая даже private поля и методы. Может возникнуть вопрос, каким образом вложенные классы получают дополнительные привилегии доступа, ведь они преобразуются в обычные, а виртуальной машине вообще о них ничего не известно?

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

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

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

И так! У нас есть класс PassCheck, у которого есть private поле PASSWORD содержащее пароль. Так же у него есть метод, который позволяет проверить переданное в него значение.

И затем выводит соответствующее сообщение.

Но прошу заметить этот метод не возвращает значение private поля, а лишь проверяет соответствует ли переданный аргумент паролю.

В классе Main просто происходит создание экземпляра класса PassCheck и передача в его метод значения полученного из командной строки.

Пример запуска программы приведен слева.

Как мы видим программа очень простая.

Но в ней нет метода выводящего пароль. Мы же хотим его получить.

И так представим ситуацию что у нас есть только класс файлы с этой программой, то есть файлы имеющие расширение .class, но нет исходных текстов. И нам надо как то получить заветный пароль.

Теперь начинаем исследование наших .class файлов при помощи утилиты javap. Сразу же хочу предупредить некоторых умников, что да, если запустить javap с ключом –c, то в дизассемблированном коде можно увидеть наш пароль в чистом виде, но это не то что мы хотим. Мы хотим написать свою программу которая выведет значение private поля на экран.

Если мы дадим команду javap -p PassCheck.class, то увидим следующий вывод на экран:

Мы видим что у класса PassChek есть private поле PASSWORD, а так же метод, который ни чего не возвращает (void), а просто получает значение типа String и как можно предположить, сравнивает его с паролем. Ну мы то знаем что сравнивает :) сами же писали. Но сейчас мы как будто потеряли исходники и забыли пароль.

 

В классе Main как видим ни чего интересного нет. Мы можем предположить что там просто создается экземпляр класса PassChek и в него передается аргумент командной строки.

То есть нам надо работать с классом PassCheck и получить значение поля PASSWORD.

Для этого постараемся использовать внутренние классы, так как они имеют доступ даже к private полям внешнего класса. Но тут есть одна заковырка. Внутренний класс в априори должен быть в том же пакете что и внешний. Для этого нам придется создать еще один проект и в нем создать пакет pro.java.inner07. И в этом пакете мы создадим свой класс Main, назвав его MainHack, и свой класс PassCheck, название его надо нам будет сохранить и внутри него создадим внутренний класс. Затем откомпилируем все это дело и в каталог где лежат наши атакуемые .class файлы перепишем MainHack.class и внутренний класс, внешний же оставим на месте, так как нам надо атаковать именно класс PassCheck в его изначальном виде.

Мы создали два класса. Наш класс PassCheck содержит внутренний класс, который к тому же наследуется от внешнего класса PassCheck, а значит наследует и поле PASSWORD.

Хотя, в принципе, наследоваться было и не особо нужно, но это задел на следующую тему, где мы будем более подробно рассматривать наследование.

Класс MainHack создает экземпляр класса PassCheck и вызывает на нем метода сравнения паролей. Затем создает экземпляр внутреннего класса Hack и вызывает на нем унаследованный им и переопределенный метод comparePassword().

Этот метод на самом деле ни чего не сравнивает, а должен просто вывести значение поля PASSWORD.

То что у нас получилось я зафиксировал в коммите Git под шагом 1. Это если кто то захочет повторить этот эксперимент.

Запуск и работа класса MainHack и модифицированного класса PassCheck показана слева. Теперь к сути. У нас получилось три файла:

И нас интересует файл PassCheck$Hack.class.

 

Что будет если его подставить в пакет где у нас находится настоящий атакуемый нами класс PassCheck?

И естественно для его запуска нам нужен будет класс MainHack. На скрине слева показаны те файлы которые мы скопировали в пакет с атакуемым классом PassCheck.class. Запустим MianHack и посмотрим что будет…

И мы наблюдаем очень интересное поведение. Мы видим что атакуемый класс PassCheck, отработал, но правда с ошибками с которыми мы чуть позже разберемся. А пока надо понять что в классе MainHack и в классе PassCheck$Hack нет кода который бы выводил сообщение "Пароль не правильный", он есть только в классе PassCheck, что и доказывает что наш класс MainHack запустил атакуемый нами класс PassCheck. Мы так же видим номера строк где вылезла ошибка. Про трассировку ошибок мы еще поговорим но гораздо позже. А пока обращаем внимание на строку под номером 18, которая находится во внутреннем классе PasccChek$Hack.

То есть как видно из отрывка кода, ошибку вызывает строка отмеченная стрелкой:

println("PASSWORD = " + PASSWORD);

Но есть и хорошая новость! Этот облом показывает что наш класс PassCheck$Hack выполняется, и что очень важно пытается получить доступ, но получает по шаловливым ручкам.

Давайте закомментируем эту строку. Откомпилируем наш класс PassCheck$Hack и попытаемся запустить все снова.

Когда мы закомментировали 18 строку выполнение нашего класса PassCheck$Hack прошло без ошибок! То есть экземпляр нашего класса PassCheck$Hack подцепляется к экземпляру атакуемого класса PassCheck. Сбой происходит только тогда, когда наш класс хочет получить доступ к private полю. Теперь осталось понять почему вылетает ошибка и как это обойти.

Для этого придется поговорить о более продвинутых вещах, чем начальное изучение Java :)

И так, поехали!

В Java Language Specification (section 13.1.11) говорится: "A construct emitted by a Java compiler must be marked as synthetic if it does not correspond to a construct declared explicitly or implicitly in source code, unless the emitted construct is a class initialization method".

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

Еще одно упоминание о синтетических методах можно найти в документации на метод Member.isSynthetic().

Компилятор Java, так же, должен создавать синтетические методы для вложенных классов в случаях когда происходит доступ к private членам из вложенного класса во внешнем или наоборот, из внешнего к вложенным.

Чтобы это продемонстроровать расскоментируем строку println("PASSWORD = " + PASSWORD); но не будем запускать программу, а просто откомпилируем и посмотрим при помощи javap.

Как мы видим в подчеркнутой красной линией строке, появился новый статический метод с именем access$0. Это и есть синтетический метод который был создан компиляротом. В нашем коде класса PassCheck такого метода нет. Этот метод был создан для того чтобы предоставить доступ к private члену внешнего класса, нашему внутреннему классу. Синтетические методы создаются для доступа к каждому private члену. Если бы у нас было несколько private членов и обращений к ним, то для каждого бы был создан отдельный синтетический метод. Надо заметить, что синтетические метды создаются при прямом доступе к ним, если доступ к ним предоставляют public методы, то синтетические методы создаваться не будут. На этом, пока с синтетическими методами закончим и пойдем дальше.

А дальше без хирургического вмешательства ни как. Тут еще надо понять, что в изначальном, атакуемом (откомпилированном) классе PassCheck содержится пароль, который мы хотим увидеть, но там нет метода который его ввыводит. И нет синтетического метода который бы обращался к private полю PASSWORD. Поэтому нам туда его надо внеднить. То есть пропатчить непосредственно файл PassCheck.class.

Для этого сравним откомпилированные классы (файлы .class) – атакуемый и атакующий.

Как видим разница есть. Ну это и естественно :) И поэтому нам надо пропатчить атакуемый файл CheckPass.class.

После того как он будет пропатчен изменениями из атакующего файла PassCheck.class, надо еще будет переписать файлы MainHack.class и PassCheck$Hack.class в каталог с атакуемым классом. Копирование этих классов уже было показано на одном из сркинов выше. Ну и теперь запускаем наш MainHack.class…

Тадааааммммм! Мы получили то что хотели. Правда с хирургическим вмешательством.

Конечно до приватного поля можно было добраться и через reflection, но эту тему мы пока не проходили поэтому оставим ее на потом :)

Внутренние классы. Часть 2 – статические вложенные классы.

Статические вложенные классы (nested) очень похожи на классы верхнего уровня. Их обычно используют если необходимо логически связать два класса – внешний и внутренний. Интерфейсы так же могут быть статическими вложенными интерфейсами располагающимися внутри внешнего класса или интерфейса.

Статический вложенный класс определяется внутри другого внешнего класса. Это может выглядеть так:

Как видно из кода, внешним классом является класс OuterClass, статическим вложенным классом является StaticNesterdClass, статическим вложенным интерфейсом является StaticNestedInterface.

Обратите внимание на границы внешнего класса, а так же вложенного статического класса и интерфейса.

По существу внешний класс для статического вложенного класса является как бы мини пакетом.

 

Статический вложенный класс или интерфейс определен как static член окружающего класса, что делает его аналогом поля и метода класса, которые так же объявлены как static. Как и метод класса, статический вложенный класс не связан ни с одним экземпляром внешнего класса, то есть может использоваться без создания экземпляра внешнего класса. Тем не менее статический вложенный класс имеет доступ ко всем static членам окружающего класса, включая любые другие статические вложенные классы и интерфейсы. Статический вложенный класс может использовать любой статический член окружающего класса без указания имени этого окружающего класса.

Статический вложенный класс имеет доступ ко всем статическим членам окружающего класса, включая private члены. Обратное тоже верно: методы окружающего класса имеют доступ ко всем static членам статического вложенного класса, включая его private static члены, однако при обращении к ним необходимо указывать имя статического вложенного класса, которому они принадлежат.

Поскольку статические вложенные классы сами являются членами класса, то статический вложенный класс может быть объявлен с любыми модификаторами доступа. Эти модификаторы имеют одно и то же значение для статических вложенных классов и для остальных членов класса.

Статический вложенный класс не может называться так же, как называется любой из окружающих классов. Кроме того, статические вложенные классы и интерфейсы могут быть объявлены только в классах верхнего уровня и других статических вложенных классах и интерфейсах. В действительности это часть более общего запрета на использование static членов любого вида во внутренних, локальных и анонимных классах.

Из статических вложенных классов вы не можете обращаться к нестатическим членам внешнего класса. Обратное тоже верно – из внешних классов вы не можете обращаться к нестатическим членам вложенного статического класса. Статический вложенный класс для доступа к нестатическим членам и методам внешнего класса должен создавать его объект. Обратное так же верно – для доступа к нестатическим членам вложенного класса, внешний должен создать его объект.

Если в статический вложенный класс вкладывается еще один класс, то это не делает его автоматически статическим, он будет вложенным inner классом, даже если его окружающий класс является вложенным в интерфейс. Чтобы класс вложенный в статический класс был статическим необходимо это явно указать при помощи ключевого слова static.

Ну и теперь немного практики…

Вывод данной программы представлен слева. Обратите внимание на то, каким образом был создан экземпляр класса Nested. Перед ним использовалось уточняющее имя внешнего класса Outer. Данный синтаксис можно изменить импортом внутреннего класса Nested.

nst.getName() выводит private поле nestedName. Заметьте что оно не статическое и private. nst.getOuterName() выводит статическое private поле outerName внешнего класса Outer. Далее выводиться статическое поле out внешнего класса Outer. Мы смогли это сделать так как оно статическое. Далее выводится статическое поле nst вложенного класса Nested через уточнение именем класса Outer.

Затем мы создаем экземпляр класса Outer и получаем через него доступ к private static полю outerName через вызов метода getName() на экземпляре класса Outer. И последняя строка выводит private static поле вложенного класса через метод внешнего класса getStnst(), который имеет доступ даже к private static полям вложенного класса. Ну как не запутались? :) По идее пока все не очень сложно :)

Ну и еще стоит отметить, что компилятор все равно нам создал три .class файла. Но вложенный класс Nested создан с уточняющим именем внешнего класса Outer через знак $. Поэтому все вложенные классы являются чистым синтаксическим сахарком, но достаточно нужным и удобным.

В коде, расположенном вне окружающего класса, на статический вложенный класс или интерфейс ссылаются по имени внешнего класса с последующим добавлением имени внутреннего класса (например, Outer.Nested). Для импорта статических классов-членов можно применять директиву import:

import pro.java.nested.Outer.Nested; // импорт вложенного класса Nested
import pro.java.nested.Outer.*; // импорт всех вложенных классов из класса Outer

Импортировать внутренние классы не рекомендуется, потому что данная операция скрывает факт того, что класс тесно связан с содержащим его классом. Поскольку строка создания экземпляра класса будет уже выглядеть, например, вот так:

Nested nst = new Nested("MyNested");

То есть в данном случае мы уже не видим что класс Nested является вложенным классом класса Outer, как это было явно видно до импорта:

Outer.Nested nst = new Outer.Nested("MyNested");

 

Теперь еще немного поговорим о вложенных интерфейсах. Я добавил в класс Outer вложенный интерфейс IGetNames и вложенный класс GetNames в котором реализовал этот интерфейс, а так же в класс Main добавил создание экземпляра класса GetNames и использование его методов.

Здесь я привел лишь отрывки кода который был добавлен. В этом примере класс GetNames является вложенным в класс Outer, но ни что не мешает вложить его в интерфейс IGetNames.

 

Но тогда уже придется уточнять имя класса вложенного в интерфейс через имя внешнего класса и имя вложенного интерфейса:

Outer.IGetNames.GetNames gn = new Outer.IGetNames.GetNames();

Для наглядности, так же приведу отрывки измененного кода в классе Outer. в классе Main была изменена лишь строка создания экземпляра класса GetNames, которая уже была приведена выше.

Оба два предыдущих примера генерируют следующий вывод:

Три последние строки генерируются вызовом методов на экземпляре класса GetNames.

Вызов этих методов приведен на отрывке кода представленного на скриншоте выше.

Интересно так же посмотреть на те .class файлы которые получились в результате наших изменений в коде классов.

Как видим у нас получилось пять .class файлов. По одному на каждый из наших классов и интерфейсу. Особое внимание следует обратить на имена вложенных классов и интерфейса. Уровень вложенности классов разделяется знаком $. Знак доллара является валидным символов в именах классов, но предназначен для использования только компилятором и JVM.

Кстати сказать избавиться от длинной строки создания экземпляра класса GetNames можно все тем же импортом. Для этого нам надо импортировать этот класс по его полному имени:

import pro.java.nested.Outer.IGetNames.GetNames;

Тогда строка создания экземпляра класса GetNames будет выглядеть так:

GetNames gn = new GetNames();

Но опять же тут не очевидно что GetNames это вложенный класс, хотя эта запись гораздо короче.

Вложенные классы можно размещать и просто в интерфейсах. Любой класс, помещенный в интерфейс, автоматически объявляется как открытый (public) и статический (static). Так как класс объявляется как static, он не нарушает правил обращения с интерфейсом – этот вложенный класс всего лишь размещается в пространстве имен интерфейса. И как я уже показывал, вы даже можете реализовать окружающий интерфейс во внутреннем классе. Хитрый пример показан слева. И если вы его просто попробуете запустить из Eclipse, то ни чего не выйдет, хотя этот файл без проблем и ошибок скомпилируется. И он даже работает и его даже можно запустить, но используя магию правильное понимание. Это понимание можно почерпнуть здесь. Но все же его стоит чуть обновить до нынешних наших знаний.

И поможет нам в этом магия утилиты javap

То есть нам надо запускать класс содержащий метод main() по его полному имени и делать это правильным образом из правильного места.

Но можно сделать это и из Eclipse указав класс где находится метод main():

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

Статические вложенные классы можно так же использовать для проверки работоспособности классов, то есть для их тестирования. Поскольку в них вы можете расположить метод main(). Как вы уже знаете при компиляции будет скомпилирован отдельный .class файл для вложенного класса, который вы можете запускать для тестирования работы отдельного класса не запуская всю программу. Кроме того, в окончательную сборку программы можно не включать файлы .class которые были сгенерированы для тестирования, их можно просто удалить и собрать программу, таким образом в ней не будет лишнего кода, который вы создали для тестирования.

На примерах слева и сверху представлены два класса Main, содержащий метод main() и SomeClass, содержащий вложенный класс Test, который так же содержит метод main().

После компиляции получается соответственно три файла с расширением .class:

Если посмотреть на содержимое файлов SomeClass.class и SomeClass$Test.class при помощи javap, то увидим следующее:

Как видим в байт коде класса SomeClass не присутствует код вложенного в него класса Test, поскольку он находится в отдельном своем .class файле, в котором есть метод main(). И этот .class файл мы можем запустить отдельно от класса Main. Так же мы можем запустить на исполнение и класс Main, и даже если мы удалим откомпилированный .class файл класса Test, то наша программа все равно будет работать правильно.

В дополнение ко всему вышесказанному предлагаю посмотреть хорошее видео по вложенным статическим классам:

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

Что тут стоить отметить, так это то что в классе Human, а так же в его вложенном классе Relations используется идентификатор relations во множестве мест и при этом не происходит ни какой путаницы. Кроме того, в отличие от примера на видео, я сперва создал объект статического вложенного класса, а уже только потом создал объект внешнего класса, чтобы подчеркнуть независимость одного от другого.

Теперь еще стоит поговорить о наследовании в статических вложенных классах.

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

И теперь опять попрактикуемся…

Вывод у программы следующий:

Как видим в этом примере у нас есть два класса наследника вложенного класса Nested. Это классы Ext1 и Ext2. Причем Ext1 является внутренним классом для класса Nested и соответственно имеет доступ ко всем полям внешнего класса Outer. Обращаю внимание что класс Ext1 не статический, а внутренний, то есть inner (это наша следующая тема). Класс же Ext2 не является внутренним классом Nested хотя и наследует его и поэтому он не имеет доступа к полям класса Nested. Следует обратить внимание на интересный синтаксис создания экземпляра класса Ext1. Поскольку класс Ext1 не статический, то он не может быть создан без привязки к экземпляру его внешнего класса.

Если же класс Ext1 сделать статическим, то строка создания его экземпляра будет выглядеть для нас уже привычным образом:

Outer.Nested.Ext1 ext1 = new Outer.Nested.Ext1();

Во всем остальном программа не изменится и будет работать так же как и работала.

Можно так же привести примеры использования статических вложенных классов из реальной жизни. Что может быть более реального чем стандартная библиотека java в которой существует класс java.awt.geom.Rectangle2D который имеет два вложенных класса, Float и Double. Это очень простые классы форм и было бы просто ни к чему умножать количество высокоуровневых классов в этом пакете еще на два.

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

Тут представлен окончательный вариант с реализацией интерфейса IStack двумя классами FixedStack и DynStack. Причем класс DynStack является вложенным в класс FixedStack, который в свою очередь вложен в интерфейс IStack. Класс DynStack наследуется от класса FixedStack и поэтому там переопределен только один метод push(), который увеличивает размер стека в два раза при его заполнении.

Стоит обратить внимание на то что для класса FixedStack мы не писали слово static, хотя он таковым и является поскольку является вложенным в интерфейс классом. А вот для класса DynStack нам уже пришлось написать слово static, так как если бы мы этого не сделали, то этот класс был бы внутренним, то есть inner – не статическим.

Ну и на последок длинная портянка вывода данной программы:

Первая строка выводится сразу же после создания объекта fix. Тогда еще стек пустой.

Затем мы добавили в стек единицу и вывели его состояние.

После добавили строку и опять вывели состояние.

Затем добавили значение типа double 55.55 и вывели состояние.

Затем попытались добавить ссылку null, что вполне легитимно для Object, но нам выдалось сообщение что стек полон.

После этого мы произвели операцию изъятия из стека значения и вывели опять стек, теперь у нас там два элемента – строка и единица.

После этого напечатали звездочки и создали объект динамического стека.

Добавили туда 10 вывели значение.

Добавили другую строку и снова вывели значение.

Затем добавили туда значение 77.77, но поскольку стек у нас был из двух элементов, то произошло увеличение размера стека, о чем мы и получили сообщение и уже в увеличенные стек было помещено значение 77.77 что мы и видим в выводе программы.

После этого значение 77.77 было изъято из стека и содержимое стека было выведено на экран.

За сим все! Кино про статические вложенные классы закончено :)

Далее в программе изучение внутренних inner классов.

Да и вообще далее еще много чего :)