Илья Медведовский - Атака на Internet

int port;

Hashtable cache = new Hashtable();

NetworkClassLoader(String aHost, int aPort)

{

host = aHost;

port = aPort;

}

private byte loadClassData(String name)[]

{

// собственно загрузка класса

. . .

}

public synchronized Class loadClass(String name, boolean resolve)

{

Class c = cache.get(name);

// Хэш-таблица используется для исключения

if (c == null)

// повторной загрузки класса

{

// и формирования пространства имен

byte data[] = loadClassData(name);

c = defineClass(data, 0, data.length);

cache.put(name, c);

}

if (resolve)

resolveClass(c);

return c;

}

}

ClassLoader loader = new NetworkClassLoader(host, port);

Object main = loader.loadClass("Main", true).newInstance();

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

1. Определить, не был ли загружен этот класс раньше, и, если да, вернуть его.

2. Проконсультироваться с первичным загрузчиком на предмет существования внутреннего класса с этим именем.

3. Запросить у менеджера безопасности разрешение на загрузку данного класса.

4. Считать файл класса в виде массива байтов – по сети, с диска и т. п.

5. Создать экземпляр класса Class.

6. Загрузить используемые классы.

7. Передать класс верификатору на проверку.

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

Класс SecurityManager отвечает за политику безопасности приложения. Он позволяет приложению перед выполнением потенциально опасной операции выяснить, выполняется ли она классом, загруженным первичным загрузчиком, либо с помощью некоторого ClassLoader (к последнему, особенно при загрузке из сети, доверия должно быть гораздо меньше). Далее менеджер безопасности может определить, разрешить ли эту операцию или наложить на нее вето. Класс SecurityManager выявляет ряд методов, начинающихся со слова «check» (checkDelete, checkExec, checkConnect и т. п.), которые вызываются всеми методами стандартной библиотеки, выполняющими потенциально опасные действия (работа с файлами, сетевыми соединениями и т. п.). Выглядит это обычно следующим образом:

SecurityManager security = System.getSecurityManager();

if (security != null)

{

security.checkXXX(argument, . . . );

}

При разрешении операции функция check просто возвращает управление, при запрещении – возбуждает исключение SecurityException. Реализация по умолчанию для любого метода check* предполагает, что вызываемый метод не имеет права на выполнение данной операции. В обязанности менеджера безопасности, работающего с апплетами, входит защита от загрузки новых загрузчиков классов, защита потоков и групп потоков друг от друга, контроль за обращением к системным ресурсам, к ресурсам виртуальной машины, к сетевым соединениям и т. п.

Текущий менеджер безопасности устанавливается с помощью функции System.setSecurityManager, причем, если менеджер безопасности уже был установлен, эта функция также вызывает SecurityException.

В JDK 1.1 система безопасности получила дальнейшее развитие (рис. 10.2). Принципиально ничего не изменилось, но была добавлена возможность цифровой подписи классов – аналог сертификатов в ActiveX. Теперь можно решить, заслуживает ли подписанный удаленный код полного доверия, и не накладывать на него стандартные ограничения.

Рис. 10.2. Модель безопасности JDK 1.1

Побочным эффектом введения этого механизма стало появление в составе стандартной библиотеки Java криптографических функций – Crypto API.

Модель безопасности JDK 1.1 отличалась черно-белым взглядом на мир – мы либо полностью доверяем загруженному коду, либо нет. В Java 2 (JDK 1.2), вышедшей в декабре 1998, была представлена новая гибкая модель безопасности, основанная на привилегиях и правах доступа (рис. 10.3).

Рис. 10.3. Модель безопасности JDK 1.2

Дополнительно к существующим классам в Java 2 добавились:

• новый загрузчик классов java.security.SecureClassLoader;

• класс java.security.Permission, наследники которого используются для определения прав доступа к различным ресурсам, и класс java.security.PermissionCollection, позволяющий группировать права доступа. За доступ к файлам отвечает java.io.FilePermission, к сети – java.net.SocketPermission, к графическим ресурсам – java.awt.AWTPermission и т. д.;

• класс java.security.AccessController, используемый для контроля доступа FilePermission p = new FilePermission("/tmp/junk", "read"), и AccessController.checkPermission(p);

• класс java.security.ProtectionDomain, позволяющий объединить классы, которым предоставляются одинаковые права доступа;

• класс java.security.Policy, отвечающий за политику безопасности. В каждый момент активен только один объект Policy, считывающий настройки из файла конфигурации. В этом файле можно описать, какие права доступа связаны с той или иной подписью и/или местом расположения файлов:

grant codeBase «http://www.somehost.com/*», signedBy «Signer»

{

permission java.io.FilePermission "/tmp/*", "read";

permission java.io.SocketPermission "*", "connect";

};

Новая модель безопасности имеет следующие особенности:

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

• легко конфигурируемая политика безопасности. Опять же ключевое слово здесь – «легко»;

• возможность легкого расширения множества прав доступа, то есть фактически контролируемых действий. Если раньше это требовало введения новых методов check* в SecurityManager, теперь достаточно описать еще одного наследника класса java.security.Permission;

• усиление контроля за всеми Java-приложениями: в настоящее время никакой код не считается безопасным априори. Локальный код может быть подвержен тем же проверкам, что и код апплета, хотя, конечно, никто не мешает ослабить этот контроль с помощью настроек.

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

Суровая действительность

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

Апплеты, мешающие работе

Java-приложения зависят от существующей для данной платформы виртуальной Java-машины. Java-машины реализованы для всех наиболее распространенных платформ, а также входят в состав самых популярных браузеров, но они достаточно ресурсоемки и зачастую довольно нестабильны. Кроме того, остаются проблемы совместимости – поскольку Java изначально проектировалась для написания многоплатформенных приложений, в нее преимущественно входили элементы, существующие на всех платформах, что привело к некоторой аскетичности доступных средств. Отдельные разработчики расширяют возможности виртуальных машин для конкретной платформы, и получается, что Java-приложение, использующее все эти возможности, утрачивает способность запускаться на других платформах.

Читать дальше