Небезопасная безопасная JAVA Крис Касперски
    Безопасность java-технологий оказалась решающим аргументом при продвижении в сферу корпоративных enterprise-приложений с конкурентом в лице с#. Однако пограничная полоса, отделяющая рекламный маркетинг от реальной жизни, оказалась довольно тернистой. Java многое обещает, но каждый раз откладывает исполнение своих обещаний на неопределенный срок. Рассмотрим модель безопасности java на макро-, микроуровнях и проанализируем сильные и слабые стороны этой технологии.
    В 1994 г. порядком разросшийся коллектив программистов предпринял попытку проникновения на рынок Web-приложений. Они сфокусировались на вопросах безопасности и подготовили специальную редакцию языка HotJava (в "девичестве" WebRunner), предназначенную для встраивания в браузеры и ставшую доступной для публичного скачивания в 1995-м. Попытка оказалась успешной. И с момента поддержки HotJava браузером Netscape Web-серфинг перестал быть безопасным, а сам браузер превратился в один из основных объектов хакерских атак. Несмотря на это, Java просочилась практически во все сферы рынка и сегодня встречается повсеместно: от сотовых телефонов до enterprise-серверов и суперкомпьютеров.
    Внедрение Java-технологий обычно происходит под эгидой лозунгов о повышении безопасности, а все дыры списываются на ошибки реализации конкретных виртуальных машин. Однако истинная причина в том, что Java уязвима на концептуальном уровне. Впрочем, у конкурентов дела обстоят не лучше и основной соперник Java-C# содержит еще больше лазеек, порой умышленно привнесенных разработчиками для достижения большей производительности в ущерб безопасности. Безопасность - весьма абстрактное понятие, не поддающееся измерению и не имеющее числового представления, в то время как тесты производительности - мощное маркетинговое средство. Разумеется, это еще не означает, что Java и С# должны быть с позором выброшены на свалку истории. Достаточно знать пути достижения безопасности и иметь в виду ловушки, которые подстерегают на пути. Многоликая Java
    Прежде чем приступать к обсуждению системы безопасности Java-приложений, проведем водораздел между Java-технологиями и одноименным языком программирования, с которым, собственно говоря, и ассоциируется торговая марка Java. Общеизвестно, что Java является интерпретируемым языком, но он существенно отличается от большинства других интерпретируемых языков, таких, например, как Perl, PHP или Python. Если в Реrl'е интерпретации подвергается непосредственно сам исходный код, то программа, написанная на Java, транслируется в байт-код, исполняемый на виртуальной Java-машине (далее-JVM).
    Согласно терминологии, предложенной компанией Sun, реализатор JVM называется клиентом, и всякий клиент вправе исполнять байт-код так, как ему заблагорассудится (естественно, в рамках спецификации JVM). Наряду с программными реализациями JVM существуют и аппаратные, демонстрирующие производительность, ничуть не уступающую (а зачастую даже превосходящую в силу грамотной оптимизации байт-кода JVM) чистому машинному коду с процессором семейства х86, Alpha и др. С другой стороны, большую популярность завоевали JIТ-компиляторы (Just-ln-Time-компиляторы), на лету транслирующие байт-код в "нативный" (native) машинный код соответствующего процессора и сочетающие высокое быстродействие с дешевизной реализации.
    Таким образом, Java-приложения представляют собой двоичные файлы, не имеющие ничего общего с исходными текстами, составленными на языке Java. ............