Максимальная Безопасность:

Руководство Хакера по Защите Вашего Internet Сайта и Сети

Предыдущая главаСледующая главаСодержание

30

Языки, Расширения и Безопасность

Эта глава исследует отношения между языками, расширениями и безопасностью. Традиционно, термин язык относится (в компьютерном мире) к некоторой форме компьютерного языка, набору общих команд, которые, когда должным образом с осемблированные, создают программу или приложение. Большинство пользователей хорошо знают по крайней мере один компьютерный язык: БЕЙСИК, Паскаль, ФОРТРАН, C, C++ и так далее. Такие языки, как понимают, являются реальными языками, потому что ими можно создать программу, которая может работать без потребности внешней поддержки от интерпретатора.

Язык

Это все, что касается традиции. Сегодня, климат различен. Например, популярность языков оболочки, которые используются, прежде всего, на платформе UNIX, существенно увеличилась. Они имеют синтаксис, который выполняет требования оболочки или интерпретатора команд данной платформы. Эти языки не могут создавать полностью автономные программы, которые выполняются без интерпретатора команд, но все же они стали значительно популярными. Программист, который может умело программировать на таком языке, как гарантируют, to land a job somewhere.

ПРИМЕЧАНИЕ: Для пользователей MS-DOS и Windows, которые никогда не работали с платформой UNIX: Программы на языке оболочки похожи на большие пакетные файлы. Они составлены из различных операций регулярных выражений, каналов, перенаправлений, системных вызовов и т.д.

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

Точно так же имеются интерпретируемые языки типа Perl, которые предлагают пользователю чрезвычайную мощь. Они могут часто связываться с помощью интерфейса не только с их собственным интерпретатором, но и с различными языками оболочек и системными вызовами. Они могут даже быть вложены в другие языковые конструкции. Типичный пример сценарий Perl, вложенный в сценарий TCL или в программу на C. Это настоящие языки, которые пересекают барьеры между (или возможно объединяют) одними или более реальными языками.

Но где кончается определение языка? Например, Язык Разметки Гипертекста (HTML - Hypertext Markup Language) это язык, даже при том, что он полностью бесполезен, если не интерпретируется гипертекстовым просмоторщиком (Navigator, Internet Explorer, Grail, Arena, Lynx, Opera, Powerbrowser, Netcruiser и т.д.). Правда, HTML это язык, но его приложение ограничено (PostScript в этом подобен ему).

JavaScript и VBScript это языки, которые фактически стоят прямо между Perl и HTML. JavaScript и VBScript выполняют только ограниченный набор задач. Они разработаны для интерпретации броузером, правда, в отличие от HTML, эти языки выполняют задачи динамически (примеры их включают получение и обработку переменных для выполнения вычисления или другого процесса). Вероятно, чтобы создать полностью функциональную и динамическую среду Web страницы, Вы будете использовать комбинацию языков.

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

Расширения

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

Например, рассмотрим использование таблиц в HTML. Таблицы это расширения. Это выражения, которые изменяют поверхность Web страницы. Использование таблиц становится более общим, потому что они обеспечивают почти попиксельное управления появлением Web страницы. Чрезвычайно высококачественные пакеты Web разработки используют таблицы, чтобы предложить управление на уровне текстового процессора видом и чувством вашей Web страницы. NetObjects пример этого явления. В среде что видишь, то и получишь пользователь может размещать изображения, текст, звук, или видео где-нибудь на странице. Таблицы математически вычерчивать позицию. Конечный результат выполнен с использованием невидимых табличных структур, которые окружают рассматриваемый объект, таким образом давая местоположение объекта произвольной формы. NetObjects часто упоминается как "PageMaker WWW".

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

HTML

При поверхностном взгляде это звучит глупо. HTML нединамический язык, который не служит другим целям, кроме как чтению броузером. Как это могло иметь значения для безопасности? Непосредственное. Чтобы понять, почему и какие меры предпринимаются, чтобы адресовать эти значения, рассмотрим первоначальную идею HTML. Первая цель состояла в том, чтобы обеспечить независимый от платформы метод распределения данных. Как случается, первоначальная реализация была предназначена для использования с простым (ясным) текстом. В наиболее простой форме, тогда, Web страница состояла из чистого текста. Исследуйте следующий код HTML: 

<HTML>
<HEAD>
</HEAD>
<BODY>
<P>Это страница</P>
</BODY>
</HTML>

Довольно простой материал. Этот HTML делает не больше, чем печатает страницу, которая говорит Это страница. Никакие расширения не используются; страница была бы скучна. Однако мы можем добавить расширение, чтобы изменить цвет фона на белый: 

<HTML>
<HEAD>
</HEAD>
<BODY bgcolor = "#ffffff">
<P>Это страница.</P>
</BODY>
</HTML>

Тэг <BODY> устанавливает цвет. Есть множество других тэгов, которые мы могли использовать, чтобы добавить звук, анимацию, видео, и т.д. Однако все они все еще появляются в чистом тексте. Аналогично, когда Вы представляете информацию в форме HTML, она обычно принимается (и анализируется Perl программой или другим CGI приложением) в чистом тексте.

Когда WWW использовалась прежде всего для исследования и образования, это было прекрасно. Материал мог быть перехвачен по сети, но это было относительно низким риском. Однако время прошло, и в конечном счете люди стали беспокоиться. К спецификации HTML были добавлены расширения, включая поле пароля. Это поле вызывалось выдачей следующей инструкции в форме: 

INPUT TYPE=PASSWORD

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

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

Правда, средние пользователи, когда встречаются со страницей, защищенной таким образом, уклоняются и предполагают, что если они не имеют пароль, они не могут войти. Однако для любого с даже минимальным знанием реализации HTML, это современный эквивалент "Beware of Dog" или "Keep Off the Grass". Входя в структуру каталогов целевого сервера, любой пользователь может обойти эту так называемую меру безопасности.

Например, предположим, что адрес защищенного паролем сайта следующий:

Когда пользователь приземляется на этой странице, ему выдается поле, которое запрашивает пароль. Если введен неправильный пароль, пользователю подается страница (возможно www.bogus_password_protection.com/~mypage/wrong.html), чтобы сообщить ему об отказе аутентификации. С другой стороны, если пользователь вводит правильный пароль, его перенаправляют на страницу любимых ссылок, забавных шуток, или другую (например, www.bogus_password_protection.com/~mypage/jokes).

Используя любой механизм поиска можно быстро идентифицировать страницы ниже страницы пароля. Это делается выдачей явной, с учетом регистра, с точным соответствием строки поиска, которая содержит базовый адрес, или адрес, где начинаются документы HTML для этого пользователя (в этом случае, http://www.bogus_password_protection.com/~mypage). Возвратом будет список страниц, которые связаны с этой страницей. Естественно, проектировщик сайта включит кнопку Домой или связь с каждой последующей страницей. Таким способом пользователи могут удобно перемещаться по сайту.

Открывая местоположение всех последующих страниц на этом сайте, пользователь может обходить защиту паролем страницы. Он может непосредственно загружать все страницы, которые загружены после того, как пользователь обеспечил правильный пароль. Единственный момент, при котором эта методика не будет работать, когда поле пароля привязано к алгоритму пароля, который динамически генерирует следующую страницу (например, сценарий Perl мог бы сравнивать пароль со списком и, если пароль правильный, откомпилировать последующую страницу с чувствительной ко времени информацией, перемещенной с других переменных, типа страницы "совет дня").

СОВЕТ: Такие реализации единственный допустимый способ, чтобы использовать поле пароля. In other words, you use the field to obscure the password to passers-by and point that form to a script on the server's local drive. Все сравнения и другие операции делаются в пределах границ этого сценария, который также постоянно находится в защищенном каталоге.

Это приводит нас к одному из чаще всего задаваемых вопросов: Как сделать эффективную защиту паролем сайта?

Защита Паролем Для Web Сайтов: htpasswd

Защита паролем выполняется любой реализацией htpasswd. Эта программа (которая поставляется в заготовке с большинством дистрибутивов Web серверов) предназначена для обеспечения реальной аутентификации пароля. Вы будете знать, когда остановитесь на сайте, использующем htpasswd, потому что будет немедленно выдано диалоговое окно, требующее пароль от пользователя. В Netscape, это диалоговое окно выглядит, как показанное на Рисунке 30.1.

Приглашение htpasswd
Рисунок 30.1. Приглашение htpasswd.

Те, кто использует Mosaic для Системы X Window будут видеть слегка отличную подсказку (смотрите Рисунок 30.2).

Подсказка htpasswd в Mosaic для X
Рисунок 30.2. Подсказка htpasswd в Mosaic для X.

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

Экран ошибки авторизации htpasswd
Рисунок 30.3. Экран ошибки авторизации htpasswd.

htpasswd рассматривается довольно сильным. Он полагается на основную схему аутентификации HTTP, но также соответствует MD5.

ПРЕДОСТЕРЕЖЕНИЕ: Будьте внимательным при установке опции для MD5. Не все броузеры поддерживают эту опцию, и ваши пользователи могут остаться весьма расстроенными не сумев подтвердить свою подлинность. В настоящее время поддерживаются броузеры Mosaic, NCSA и Spyglass.

Мудрые слова: хотя пароли пользователей, в конечном счете, хранятся в зашифрованной форме, они не передаются в зашифрованной форме в основной HTTP аутентификации. Как сообщено NCSA в Mosaic User Authentication Tutorial (Справочный Документ по Аутентификации Пользователя Mosaic):

В Основной HTTP Аутентификация пароль передается по сети не зашифрованным, но не как простой текст, а как "uuencoded". Любой наблюдая движение пакетов в сети не увидит пароль в чистом виде, но пароль будет легко декодирован любым, кто захватит правильный сетевой пакет.
Ссылка: Найдите Mosaic User Authentication Tutorial в Web на
http://hoohoo.ncsa.uiuc.edu/docs-1.5/tutorials/user.html.

Это отличается от MD5 реализации. Как сообщено в том же документе:

В MD5 Аутентификации Обзора Сообщения (Message Digest Authentication) пароль не передается по сети вообще. Вместо этого на основе пароля и другой информации о запросе генерируется ряд чисел, эти числа затем хэшируются, используя MD5. Затем результирующий "обзор" посылается по сети и объединяется с другими элементами на сервере для сверки с сохраненным обзором на сервере.

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

Кто Может Использовать htpasswd? Любой может использовать htpasswd для защиты паролем любого каталога в его дереве каталогов. То есть системный администратор может защитить весь Web сайт, или пользователь может выборочно защитить каталоги паролем в пределах его /~user иерархии. Однако есть некоторые практические препятствия. Во-первых, программа должна быть доступна для вашего использования. Это означает следующее:

Проверьте, все ли условия выполнены. Вы можете обычно найти местоположение htpasswd (не беспокоя вашего сисадмина) выдав команду whereis из приглашения оболочки. Однако htpasswd обычно располагается в каталоге /usr/local/etc/httpd/support.

СОВЕТ: Ваша переменная окружения PATH вероятно не установлена, чтобы отразить этот каталог, и я не потрудился бы изменить ее. Вы будете использовать программу только один-два раза, если не заняты в системном администрировании.

Что, Если Мой Сисадмин не Имеет htpasswd и не Будет Получать Ее? Некоторым системным администраторам может быть трудно получить ее, или они могут просто игнорировать просьбы пользователя об утилите htpasswd. Если Вы столкнулись с такой ситуацией, есть альтернатива: htpasswd.pl. htpasswd.pl это сценарий Perl разработанный, чтобы заменить текущую реализацию htpasswd. Он был написан Ryun Whitfield Schlecht (также известного как Nem), 22-летний специалист по Информатике Государственного Университета Северной Дакоты.

Ссылка: Вы можете найти Nem наhttp://abattoir.cc.ndsu.nodak.edu/~nem/.
Код htpasswd.pl расположен на http://abattoir.cc.ndsu.nodak.edu/~nem/perl/htpass.html.

Использование htpasswd реализации htpasswd занимает только несколько секунд. Первым шагом необходимо создать файл с именем .htaccess в целевом каталоге. Это простой текстовый точечный файл, который может быть отредактирован любым редактором на платформе UNIX (я предпочитаю vi). Содержание файла имеет следующий вид: 

AuthUserFile /directory_containing_.htpasswd/.htpasswd
AuthGroupFile /directory_containing_a_group_file
AuthName ByPassword
AuthType Basic

<Limit GET>
require user _some_username_here
</Limit>

Давайте пройдем каждую строку:

СОВЕТ: Все пути должны быть введены в абсолютной форме. То есть должен быть введен полный путь. Если Вы не сделаете так, алгоритм аутентификации не сможет работать.

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

htpasswd -c /каталог_содержащий_htpasswd/.htpasswd ИмяПользователя

Это создаст файл и запросит Вас о пароле и имени пользователя. Вы будете должны напечатать пароль дважды: один раз, чтобы установить его и один раз, чтобы подтвердить.

ПРЕДОСТЕРЕЖЕНИЕ: Убедитесь что Вы создали файл .htpasswd в том же каталоге, какой Вы указали в файле .htaccess. Иначе система не сможет найти файл .htpasswd и, независимо от того, какой пароль введен, пользователи извне встретятся со сбоем аутентификации.

Если Вы исследуете файл .htpasswd после того, как закончите, то увидите, что он содержит имя пользователя и зашифрованную строку, которая является паролем в зашифрованной форме. Это будет выглядеть так: 

username: o3ds2xcqWzLP7

В этой точке каталог защищен паролем. Любой остановившийся на этой странице встретится с диалоговым окном пароля.

Если Вы не имеете доступа Telnet, то не сможете выполнить предшествующую операцию. Если ваш провайдер запретил доступ к Telnet, разъясните ситуацию; возможно он может предложить Вам Telnet в ограниченной форме, так чтобы можно было устанавливать htpasswd. Я бы не использовал провайдера, который не предлагал доступ к Telnet.

ПРЕДОСТЕРЕЖЕНИЕ: В прошлом я видел, что пользователи пытаются устанавливать эти файлы, без Telnet, использование FTP клиенты. Не пытайтесь делать этого, или Вы будете неспособны обратиться к вашей странице позже. После того, как эти файлы помещены в ваш каталог, диалоговое окно будет появляться каждый раз. Вы тогда должны будете возвратиться к FTP и удалить файлы. Однако в зависимости от того, как были установлены разрешения, Вы могли бы не смочь сделать этого. Если Вы не имеете доступа к Telnet и очень немного знаете о UNIX, не пытайтесь устанавливать такие файлы на диске вашего сервера.

Расширения Безопасности HTML

Ранее в этой книге я упомянул несколько расширений безопасности HTML. Теперь пора получить немного более специфическую информацию.

Поскольку Сеть теперь стала популярной средой для торговли, есть огромный толчок для безопасности в HTML. Поскольку большинство разнообразного трафика HTML это чистый текст, развитие криптографических и других скрывающихся данных методов, стало большим бизнесом. Таким образом, большинство предложений частно. Я сошлюсь к двум из них: Уровень Безопасных Разъемов (SSL - Secure Sockets Layer) и S-HTTP.

Уровень Безопасных Разъемов (Netscape) это система, разработанная и предложенная Корпорацией Netscape Communications. Протокол SSL поддерживает широкий диапазон схем аутентификации. Они могут быть осуществлены, используя различные криптографические алгоритмы, включая популярный теперь DES. Как сообщено Netscape, в ее спецификации SSL:

Основная цель протокола SSL состоит в том, чтобы обеспечить секретность и надежность между двумя сообщающимися приложениями. Протокол составлен из двух уровней. На наименьшем уровне, на вершине некоторого надежного транспортного протокола (например, TCP), находится Протоколом Записи SSL. Протокол Записи SSL используется для инкапсуляции различных высокоуровневых протоколов. Один такой скрытый протокол, Протокол Рукопожатия SSL, позволяет серверу и клиенту подтверждать подлинность друг друга и договариваться об алгоритме шифрования и криптографическом ключе прежде, чем протокол прикладной программы передаст или получит первый байт данных.

SSL охарактеризован как чрезвычайно безопасный, прежде всего, потому что безопасность подключения также включает использование MD5. Протокол поэтому обеспечивает целостность подключения также как аутентификацию. Проект SSL считается достаточно безопасным, так что очень мощные программные фирмы включили технологию в свои продукты. Один такой продукт Информационный Сервер Internet Microsoft.

ПРИМЕЧАНИЕ: Ранняя реализация Microsoft SSL требовала, чтобы Вы получили свидетельство от третьего лица, в этом случае от VeriSign. Это свидетельство проверяет вашу личность, чему не каждый рад.

SSL был обнародован и в значительной степени принят кругами безопасности, прежде всего, потому что система объединила некоторые из наиболее мощных методов шифрования, доступных в настоящее время. Но яркое будущее SSL скоро было омрачено. Реализация, первоначально представленная Корпорацией Netscape Communications просто не была достаточно сильной. 19 сентября 1995 новости о том, что SSL был взломан, пестрели в заголовках. Как отметил John Markoff в своей статье "Security Flaw Is Discovered In Software Used In Shopping" ("Недостаток Безопасности Обнаруженый в Программном Обеспечении, Используемом в Торговле"), которая появилась в Нью-Йорк Таймс 19 сентября 1995:

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

Несколько студентов (включая Ian Goldberg и David Wagner) нашли, что в за несколько минут они могут обнаружить ключ, используемый в процессе шифрования. Это (по крайней мере на какое-то время) сделало SSL крайне бесполезный для серьезной безопасности.

Ссылка: в Internet был послан исходный код C, который Вы можете использовать для нападения на ранние, испорченные реализации SSL. Вы можете получить этот исходник на
http://hplyot.obspm.fr:80/~dl/netscapesec/unssl.c.

Недостаток лучше выражен консультацией Netscape ("Potential Vulnerability in Netscape Products" - "Потенциальная Уязвимость в Продуктах Netscape") выпущенной вскоре после того, как история закончилась:

Текущие версии Netscape Navigator используют случайную информацию, чтобы генерировать ключи шифрования сессии 40 или 128 битов длинной. Случайная информация находится через разнообразные функции, которые изучают машину пользователя на предмет информации о том, сколько процессов выполняется, идентификационные номера процессов, текущее время в микросекундах, и т.д. Текущая уязвимость существует, потому что размер случайного ввода меньше чем размер последующих ключей. Это означает, что вместо поиска среди всех 2^128 возможных ключей грубой силой, потенциальный злоумышленник должен только перерыть значительно меньшее пространство ключей. Это существенно упрощает решение проблемы, потому что требуется намного меньше компьютерного времени, и означает, что 40- или 128-разрядная длина ключа существенно уменьшена.
Ссылка: "Potential Vulnerability in Netscape Products" может быть найдена в Web на
http://www.netscape.com/newsref/std/random_seed_security.html.

Netscape быстро указала, что не было известных случаев захвата сетевыми путешественниками финансовой информации таким способом. И при этом не было зарегистрировано случаев перехвата по Internet такой информации. В конце концов, используемая методика сложна и не та, которая обычно известна преступникам. Однако эпизод сделал многие продукты подозрительными, и снова, Безопасность Internet была скорее надеждой, чем действительностью.

Информация теперь говорит, что периферийные компоненты, используемые в реализации SSL, могут даже быть испорчены. Определенно, MD5 теперь под подозрением. 2 мая, 1996, член Немецкого Агентства Информационной Безопасности выдал отчет озаглавленный "Cryptanalysis of MD5 Compress" ("Криптоанализ MD5 Сжимается"). В нем автор демонстрирует слабость, свойственную MD5.

Ссылка: "Cryptanalysis of MD5 Compress" от Dr. Hans Dobbertin может быть найден на
http://www.cs.ucsd.edu/users/bsy/dobbertin.ps.

Ссылка: Некоторые силы в шифровании предлагают, что MD5 постепенно сокращается. Чтобы узнать больше об этих вопросах, проверьте Список Обсуждения Уровня Безопасных Разъемов. В этом списке рассылки члены обсуждают различные характеристики безопасности SSL. Вы можете подписаться на этот список, послав почтовое сообщение на ssl-talk-request@netscape.com. Почтовое сообщение должно быть пустым, и строка темы должна включать слово SUBSCRIBE. Материал, обсуждаемый в Списке Обсуждения Уровня Безопасных Разъемов весьма технический. Если Вы плохо знакомы с предметом, было бы мудро получить FAQ
(http://www.consensus.com/security/ssl-talk-sec01.html).

Сегодня более сильная версия SSL продается подобно лесному пожару. До настоящего времени не было успешных попыток взломать эти более новые реализации; они имеют намного более сильный алгоритм случайной генерации. Множества продуктов третьих лиц поддерживают SSL, включая большинство доступных коммерческих клиентов броузеров (и большое количество серверов).

Ссылка: Интересное сравнение продуктов третьих лиц, которые поддерживают SSL, доступно на
http://webcompare.iworld.com/compare/security.shtml.

S-HTTP (Secure Hypertext Transfer Protocol - Безопасный Протокол Передачи Гипертекста) отличается от SSL несколькими моментами. Во-первых, SSL Netscape опубликованная реализация; поэтому, есть широкий диапазон информации, доступной о нем. Напротив, S-HTTP часто обсуждаемый, но редко встречающийся протокол.

Основная часть информации о S-HTTP находится в "Internet Draft" ("Проект Internet") за авторством E. Rescorla и A. Schiffman из Enterprise Integration Technologies (Eit.com). Немедленно при исследовании этого документа, Вы можете видеть, что S-HTTP осуществлен совершенно другим способом, чем SSL. Для начала, S-HTTP работает на прикладном уровне TCP/IP связи, а SSL работает на уровне передачи данных.

Как Вы узнали из Главы 6, "Краткое Введение в TC/IP", эти уровни представляют различные стадии реализации TCP/IP стека. Обмены прикладного уровня доступны (и отображаются) оператору. Хорошо известные протоколы прикладного уровня включают FTP, Telnet, HTTP и так далее.

Компания Terisa Systems (www.terisa.com) лицензирует несколько комплектов инструментов разработки, которые включают S-HTTP в приложения. Эти комплекты инструментов идут с библиотеками и криптодвигателем от RSA.

Основная возможность S-HTTP (и которая очень привлекательна) состоит в требовании, чтобы пользователи участвовали в обмене открытыми ключами. Помните, как я писал о Microsoft реализации SSL, которая требовала, чтобы Вы получили свидетельство? Это означает, что Вы должны идентифицировать себя третьему лицу. Напротив, согласно Rescorla и Schiffman:

S-HTTP не требует удостоверений открытого ключа стороны клиента (или открытых ключей), поддерживая режимы симметричных сессий операции с ключом. Это существенно, так как означает, что непосредственные частные транзакции могут происходить не требуя, чтобы индивидуальные пользователи имели установленный открытый ключ.
Ссылка: Вы можете найти "The Secure HyperText Transfer Protocol" от E. Rescorla и A. Schiffman в Web на
http://www.eit.com/creations/s-http/draft-ietf-wts-shttp-00.txt.

На мой взгляд, это кажется более приемлемым. Не должно быть случая, когда индивидуум ДОЛЖЕН идентифицировать себя просто делая приобретение или заходя на страницу, так же, как не нужно идентифицировать себя в книжном магазине или универсаме в "реальном" мире. Необходимо подвергнуть сомнению побуждение корпораций типа Microsoft, которые настаивают на схемах открытого ключа и сертификатах. Почему они так заинтересованы тем, что мы идентифицируем себя? Я рассматривал бы любую такую схему с большим подозрением. Фактически, я лично выступал бы против таких схем прежде, чем они станут приемлемыми стандартами Internet. Много усилий в электронной торговле нацелены на полную анонимность клиента и потребителя. Эти усилия, кажется, прикладываются правильно, без потребности в таких твердых схемах идентификации.

Кроме того S-HTTP может быть более реалистичным выбором. Даже если системы обмена открытым ключом желательны (в противоположность анонимным транзакциям), число пользователей Internet с открытым ключом мало. Особенно новые пользователи более вероятные адресаты для онлайновых коммерческих сделок, и большинство этих личностей даже знают о существовании систем с открытым ключом. Если бы открытый ключ требовался, чтобы завершить сделку, используя безопасный протокол, многие миллионы людей не смогли бы торговать. Кажется очень нереалистичным, чтобы поставщики предлагали методы обучения (или подталкивания) потребителей в получение открытого ключа.

ПРИМЕЧАНИЕ: Хотя S-HTTP не требует аутентификации открытым ключом, он поддерживает такую аутентификацию. Также он поддерживает Kerberos аутентификацию, что является дополнительной выгодой.

S-HTTP также поддерживает аутентификацию и целостность сообщения темже способом, что и SSL. Как отмечено в "The Secure HyperText Transfer Protocol" ("Безопасный Протокол Передачи Гипертекста"):

Безопасный HTTP обеспечивает средства для проверки целостности сообщения и подлинности отправителя HTTP сообщения через вычисление Кода Аутентификации Сообщения (MAC - Message Authentication Code), вычисляемого как хэш по документу используя общедоступную секрет - который мог потенциально размещаться несколькими способами, например: ручным расположением или Kerberos. Эта методика не требует ни использования шифрования с открытым ключом, ни криптографии.

До настоящего времени мне было не достаточно общественной информации о S-HTTP, чтобы сформулировать истинно развитую консультацию. Однако кажется ясно, что проектировщики интегрировали некоторые из лучших элементов SSL при учете максимальной секретности пользователей. Также, я не знаю ниодного случая, когда S-HTTP был взломан, но это может быть так, потому что сообщества взлома не имеют столь же живой интерес к S-HTTP, как Netscape. Никто не может сказать наверняка.

HTML в Общих Чертах

Проблемы с безопасностью Web, которые основаны на HTML, главным образом включают трафик данных. Другими словами, основное беспокойство в том, может ли информация быть прервана по Internet. Поскольку торговля в Internet становится более общей, эти проблемы продолжат быть вопросом общественного беспокойства.

В настоящее очень немного сайтов фактически используют технологию безопасного HTML. Когда последний раз Вы попадали на страницу, которая использовала эту технологию? (Вы можете распознавать такие страницы по небольшому целому ключу в левом угле Netscape Navigator, в противоположность сломанному.) Это, конечно, зависит частично от того, какие сайты Вы посещаете в WWW. Если Вы проводите ваше время исключительно на сайтах, которые участвуют в торговле, то, вероятно, видите большее такой деятельности. Однако, даже произведя выборку 100 коммерческих сайтов Вы увидите, что число использующих технологию безопасного HTTP мало.

Java и JavaScript

Java и JavaScript две совершенно разные вещи, но они часто путаются не программистами. Для каждого есть определение:

JavaScript гораздо более легок в изучении непрограммистом; он может быть изучен почти любым. Кроме того, так как Netscape Navigator и поддерживаемые броузеры уже содержат интерпретатор, функции JavaScript могут быть замечены намного более широким диапазоном пользователей. Java, напротив, до некоторой степени зависит от файлов классов и поэтому имеет больше накладных расходов. Также, приложения Java требуют реальных среды выполнения Java, возможность, которая многие в настоящее время не обладают (пользователи Lynx, например). Наконец, Java апплеты берут для работы намного больше памяти, чем функции JavaScript; хотя, чтобы быть справедливый, плохо написанные функциями JavaScript могут рекурсивно забирать память при каждом загрузке страницы. Это может иногда привести к аварийному отказу броузера, даже если программист не имел никакого злого умысла.

Из этих двух языков Java гораздо более мощен. Фактически, Java столь же мощен, как его дальний кузен C++. На Java были написаны целые приложения. HotJava, известный броузер от Sun Microsystems, один такой пример. Поскольку Java более мощен, он также более опасен с точки зрения безопасности.

Java

Когда Java был выпущен, он пробежал по Internet подобно волне. Программисты были приведены в восторг перспективой независимого от платформы языка, и с серьезным основанием. Разработка межплатформенных приложений сложный процесс, который требует много расходов. Например, после написания программы на C++ для среды Microsoft Windows, программист стоит перед огромной задачей перенесения этого приложения на UNIX.

Для этого процесса были разработаны специальные инструментальные средства, но стоимость таких двигателей часто колеблется, особенно для маленького оборудования. Многие из этих продуктов стоят более чем $5,000 за однопользовательскую лицензию. Кроме этого, независимо от того, что заявляют поставщики о своих продуктах, процесс перенесения не совершенен. Как это может быть? Любому не тривиальному приложению свойственны различия между X и Windows 95. Весьма часто необходима человеческая рука, чтобы сделать гладкий переход к целевой платформе.

С этими факторами Java был замечательным шагом вперед в разработке межплатформенных приложений. И что более важно, Java был разработан (возможно не первоначально, но в конечном счете) с компонентами специально для разработки независимых от платформы приложений для использования в Internet. Из этого мы можем сделать вывод: Java был революционным шагом в основанной на Internet разработке (особенно, в разработке, которая включает мультимедиа, приложения с мультипликацией, звуком и графикой). Неудачно, что Java имел такие серьезные недостатки безопасности.

Я хотел бы объяснить процесс, как Java стал такой потрясающей проблемой безопасности в Internet. Это может помочь Вам понять концепцию того, как дыры в безопасности в одном языке могут затрагивать все Сетевое сообщество.

Некоторые типы языков и алгоритмов шифрования составлены из библиотек и функций, которые могут быть включены в другие приложения. Это общий сценарий, известный любому, кто использует C или C++ как язык программирования. Эти библиотеки состоят из файлов простого текста, которые содержат код, определяющий конкретные процедуры, постоянные переменные, и другие элементы, которые необходимы для выполнения желательной операции (шифрования, например). Чтобы включать эти библиотеки и функции в свою программу, программист вставляет их в программу во времени компиляции. Это обычно делается инструкцией #include, как 

#include <stdio.h>

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

Java стал таким известным, что Корпорация Netscape Communications включила его в некоторые версии своего передового продукта, Navigator. Это означает, что поддерживаемые версии Netscape Navigator допускали Java и могли отвечать на программные запросы Java изнутри Java апплета. Таким образом, Java апплеты могли непосредственно затрагивать поведение Navigator'а.

ПРИМЕЧАНИЕ: Среда выполнения Java, включенная в код броузера Netscape Navigator (и многие другие броузеры) стандартна и полностью отлична от двигателя времени выполнения Java, обеспеченного Комплектом Разработки Java (JDK - Java Development Kit).

Поскольку Navigator и Internet Explorer два чаще всего используемых броузера в Internet, на полный класс пользователей (на множестве платформ) может потенциально воздействовать проблемы безопасности Java. Некоторые из тех платформ

О Чём Вся Суета?

Большинство новостей первостепенной важности о безопасности Java исходят из горстки источников. Один такой источник Отдел Информатики Университета Princeton. Drew Dean, Edward W. Felten и Dan S. Wallach главные его исследователи. Felten, ведущее имя в этом списке, является Вспомогательным Профессором Информатики в Университете Princeton начиная с 1993 и бывшим получателем награды Молодого Национального Исследователя (National Young Investigator) (1994). Профессор Felten работает близко с Dean и Wallach (оба аспиранта информатики в Princeton) над обнаружением дыр в Java.

Дыры в системе Java не единственный интерес группы Felten'а. Вы можете еще раз просмотреть документ, обсужденный ранее в этой книге, по методике дублирования Web обмана. Группа Felten'а (вместе с Dirk Balfanz, также аспирант) авторы этого документа, который детализирует новый метод нападения человек в середине.

В любом случае, слабости языка Java, которые были идентифицированы этой группой, включают следующее:

Общественная реакция на результаты работы группы Felten'а не была хорошей. Это было особенно так, потому что исследователи написали, что уведомили о проблемах Sun и Netscape. Эти два гиганта ответили исправлением, но увы, многие из первоначальных проблем остались, открывая другие направлениями для нападения.

Ссылка: Документ группы Felten'а, озаглавленный "Java Security: From HotJava to Netscape and Beyond" ("Безопасность Java: От HotJava до Netscape"), может быть найден в Web на
http://www.cs.princeton.edu/sip/pub/secure96.html.

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

... один способ восстановиться от этого апплета состоит в том, чтобы уничтожить броузер, выполняющийся на вашем компьютере. В UNIX системе один способ выполнить это, дистанционно зарегистрироваться на вашем компьютере с другого компьютера в вашей локальной сети, используя ps чтобы найти идентификатор процесса, который соответствует идентификатору процесса похищенного броузера, и выдать kill -9 PID.
Ссылка: Консультация от JavaSoft может быть найдена на
http://java.javasoft.com/sfaq/denialOfService.html.

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

Было определено, что пользователи, выполняющие допускающие Java броузеры представляют риск для сетей, защищенных брандмауэрами. То есть Java прошла бы непосредственно через брандмауэр; если апплет был злонамеренный, безопасность брандмауэра могла бы быть нарушена прямо здесь. Сейчас взломщики живо обсуждают по Internet взлом брандмауэра этим способом. И, так как Java совместно использует так много атрибутов с C++ (о котором можно думать, как о надмножестве C), знание программирования, требуемое, чтобы сделать так, не является недостижимым для наиболее талантливых взломщиков.

Многие сторонники Java громко объявили, что такое нападение невозможно, и является словами паникера в лучшем случае. Эти силы заставляли замолчать сообщением озаглавленным "Blocking Java Applets at the Firewall" ("Блокировка Java Апплетов в Брандмауэре"). Авторы этого документа продемонстрировали метод, посредствам которого Java апплет мог обмануть брандмауэр произвольно открыв иначе ограниченные порты на узле апплета. Другими словами, апплет, разработанный таким образом, может полностью обойти основную цель (и функциональные возможности) брандмауэра. Таким образом, в дополнение к другим слабостям, которые Java уже представила, она является топориком для льда, наносящим удар через брандмауэр.

Ссылка: "Blocking Java Applets at the Firewall", от David M. Martin Jr., Sivaramakrishnan Rajagopalan и Aviel D. Rubin, может быть найден в Web на
http://www.cs.bu.edu/techreports/96-026-java-firewalls.ps.Z.

Хотя многие из этих вопросов были исправлены Sun и JavaSoft, некоторые проблемы все еще остаются. Далее, многие люди все еще используют более старые версии Java время выполнения и комплекты разработки, также как более старые версии допускающих Java броузеров. Однако, по справедливости, JavaSoft и Sun решили многие из проблем в новом языке.

Ссылка: Чтобы получить более близкое представление о исправлениях JavaSoft и Sun (по номерам версий), проверте
http://www.javasoft.com:80/sfaq/index.html.

Для среднего пользователя враждебные Java апплеты (по крайней мере, произведенные к настоящему времени академическим сообществом) могут произвести не больше, чем незначительные неудобства, требуя перезагрузку броузера или машины. Однако для тех, кто работает в информационной безопасности Java имеет совершенно другое лицо. Любой нежелательный элемент, который может проскользнуть через брандмауэр действительная угроза безопасности. Если Вы системный администратор внутренней сети, которая обеспечивает частичный или полный доступ к Internet, я советую Вам запретить (по крайней мере на время) использование броузеров, которые допускают Java, или предписать политику, при которой пользователи отключают Java доступ.

Полемика по Java учит нас следующему: Internet не безопасна. Кроме того, языки программирования и методы считавшиеся безопасными, почти неизменно становятся небезопасным завтра. В недавней книге New Riders по безопасности Internet (Internet Security: Professional Reference – Безопасность Internet: Профессиональная Рекомендация), авторы обсуждают замечательные возможности безопасности Java (имеется даже раздел озаглавленный "Java Безопасен"). Я уверен, что во время написания книги авторы понятия не имели о недостатках безопасности Java. Так что тщательно рассмотрите следующий момент: Любая новая технология Internet должна рассматриваться с подозрением. Мудро помнить, что даже сегодня в Sendmail иногда находятся дыры, много лет после его введения в сеть.

Возможно наиболее угрожающий элемент Java следующий: Мы еще не видели работу сообщества взломщиков с ним. Традиционно взлом делается используя разнообразные утилиты, которые используются уже много лет, включая C и Perl. Однако ясно, что Java может использоваться в информационной войне как инструмент для отключения машин или другого нарушения обслуживания.

Ссылка: Для интересной точки зрения по использованию Java в информационной войне, проверьте статью Mark D. LaDue, "Java Insecurity" ("Ненадежность Java"), планируемой появиться весной 1997 в выпуске Computer Security Institute's Computer Security Journal (Журнала Компьютерной Безопасности Института Компьютерной Безопасности). Статья может быть найдена в Web на
http://www.math.gatech.edu/~mladue/Java_insecurity.html.

Я должен указать здесь, что не было никаких зарегистрированных случаев нарушений безопасности Java. Все разработанные и протестированные схемы нападения были выращены в академической или корпоративной исследовательской среде. Кроме того, для среднего пользователя, безопасность Java не критическая проблема. Скорее, именно в пределах области системных администраторов и экспертов информационной безопасности эта информация наиболее критическая. Фактические опасности для ПК сообществ обсуждаются позже в этой главе, когда я подробно обращаюсь к технологии Microsoft ActiveX.

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

Java Security: Weaknesses and Solutions (Безопасность Java: Слабости и Решения). Jean-Paul Billon, Консультант VIP DYADE. Этот документ существенен, потому что это одна из самых последних обработок проблемы безопасности Java. Модификации в этом документе простираются до декабря 1996. Это неоценимый ресурс для программистов также как для широкой публики. Информация, содержащаяся в этом документе, адресует слабости в системе времени выполнения также как непосредственно языка. Более важно, документ дает два практических примера и предлагает некоторые возможные решения. Превосходно.

Low Level Security in Java (Низкоуровневая Безопасность в Java). Frank Yellin. Этот документ одни из первых документов адресующих безопасность Java. Это важный документ, особенно для программистов и системных администраторов, потому что он описывает основные характеристики языка Java и соображений о его безопасности.

Java Security (Безопасность Java). Joseph A. Банк (MIT). Этот документ должен прочитать любой, кто хочет узнать о безопасности Java. Это хорошо написанный и легко читаемый анализ Java и его возможностей безопасности. Наиболее важно, документ проводит читателя по этапам, делая понимание возможностей Java более простым для вновь прибывшему к программированию.

И так, вы задаетесь вопросом, что Java может делать на вашей машине. Во-первых, в течение некоторого времени люди упорно утверждали, что Java не может обращаться к информации, расположенной на жестком диске вашего компьютера. Возможности безопасности языка Java обычно запрещают это. Однако один независимый исследователь, Jim Buzbee, смог разработать апплет, который обращался к такой информации. На его Web странице (где Вы можете увидеть демонстрацию апплета), Buzbee объясняет:

В большинстве реализаций Java политика безопасности запрещает апплетам читать структуру локального каталога. Я обнаружил, что для апплета, использующего только Java, возможно определить существуют ли указанные файлы в файловой системе машины клиента. Апплет, который я смоделировал, не может читать или писать в файл, но он может обнаружить его присутствие. Затем мой апплет свободен тайно послать по электронной почте результат поиска файла на любую машину в Internet, например MarketResearch@microsoft.com.
Ссылка: Web страница Buzbee находится на http://www.nyx.net/~jbuzbee/hole.html.

Апплет Buzbee поистине экстраординарен. Он обращается к вашему жесткому диску и ищет некоторые хорошо известные (и ревниво защищаемые) файлы. Один из них файл /etc/passwd. Другой MSOffice (каталог на машинах, использующих Microsoft Office). По некоторым причинам апплет перемещается весьма медленно. Однако он способен идентифицировать, какие файлы существуют на диске.

Ссылка: Если Вы хотите проверить апплет сами (он не делает никакого вреда и не блокирует ваш броузер), то можете обратиться к нему на
http://www.nyx.net/~jbuzbee/filehole.html.

Превосходная страница по враждебным апплетам страница Mark DeLue'а. Она содержит список враждебных Java апплетов и их исходный код. Некоторые из наболее забавных включают

Ссылка: На странице DeLue'а находится больше дюжины апплетов. Проверьте их на
http://www.math.gatech.edu/~mladue/SourceCode.html.

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

Если Вы когда-либо участвовали в разработке WWW сайтов, то знаете насколько это трудно. В сегодняшней среде WWW сайт должен быть точен, чист и привлекательный. Дни сплошного серого фона и неформатированного текста закончены. Теперь, потребители ожидают кое-что интересного. Кроме того, функциональные возможности, как ожидается, превышают простые генераторы и автоответы почтой . Perl в значительной степени ответствен за многие из черных задач, вовлеченных в обработку данных в Сети, но Java намного более мощное приложение для развития мультимедиа Web страницы. Он, вместе с высококачественными инструментальными средствами типа Fusion от NetObjects и FrontPage от Microsoft, может поместить Вас на самый край Web дизайна.

Книги, Статьи, Газеты и Другие Ресурсы по Java

Java Security: Hostile Applets, Holes, & Antidotes (Безопасность Java: Враждебные Апплеты, Дыры и Противоядия). Gary McGraw и Ed Felten. John Wiley & Sons. ISBN: 0-471-17842-X. 1996.

Java Security (Безопасность Java). Gary McGraw и Edward Felten. SIGS. ISBN: 1-884842-72-0. 1996.

Java Developer's Guide (Руководство Java Разработчика). Jamie Jaworski и Cary Jardin. Sams.net. ISBN: 1-57521-069-X. 1996.

Java Developer's Reference (Справочник Разработчика Java). Mike Cohn, Michael Morrison, Bryan Morgan, Michael T. Nygard, Dan Joshi и Tom Trinko. Sams.net. ISBN: 1-57521-129-7. 1996.

Developing Intranet Applications with Java (Разработка Intranet Приложений с Java). Jerry Ablan, William Robert Stanek, Rogers Cadenhead и Tim Evans. Sams.net. ISBN: 1-57521-166-1. 1996.

The Java Handbook (Руководство по Java). Patrick Naughton. Osborne/McGraw-Hill. ISBN: 0-07-882199-1. 1996.

Just Java, 2nd Edition (Только Java, 2-ое Издание). Peter van der Linden. Sunsoft Press/Prentice Hall. ISBN: 0-13-272303-4. 1996.

Java in a Nutshell: A Desktop Quick Reference for Java Programmers (Java в Скорлупе: Настольный Справочник для Java Программистов). David Flanagan. O'Reilly & Associates, Inc. ISBN: 1-56592-183-6. 1996.

The Java Language Specification (Спецификация Языка Java). Addison-Wesley. James Gosling, Bill Joy и Guy Steele. ISBN: 0-201-63451-1. 1996.

"Java as an Intermediate Language" ("Java Как Промежуточный Язык"). Технический Отчет, Школа Информатики, Университет Carnegie-Mellon, Номер CMU-CS-96-161, Август 1996.

"Java & HotJava: Waking Up the Web" (Java и HotJava: Пробуждение Web). Sean González. PC Magazine. Октябрь 1995.

"Java: The Inside Story" ("Java: Внутренняя История"). Michael O'Connell. Sunworld Online. Том. 07. Июль 1995.

"Briki: A Flexible Java Compiler" ("Briki: Гибкий Компилятор Java"). Michael Cierniak и Wei Li. TR 621, URCSD, Май 1996.

"NetProf: Network-Based High-Level Profiling of Java Bytecode" ("NetProf: Основанный на Сети Высокогоуровнево Профилированный Байтекод Java"). Srinivasan Parthasarathy, Michael Cierniak и Wei Li. TR 622, URCSD, Май 1996.

MIME Encapsulation of Aggregate Applet Objects (MIME Инкапсуляция Составных Объектов Апплета) (mapplet). A. Bahreman, J. Galvin и R. Narayanaswamy.

"H-38: Internet Explorer 3.x Vulnerability" (" H-38: Уязвимость Internet Explorer 3.x). (Консультация CIAC) 4 Марта, 1997.

Internet Java & ActiveX Advisor (Internet Java и ActiveX Советник). Журнал.

Java Developer's Journal (Журнал Java Разработчика).

Java Report (Java Отчет). Журнал.

Javaworld (Мир Java). Журнал.

Gamelan. Максимальный архив Java.

Perl

Иногда, только иногда, продукт, появившийся из Internet, является поистине великолепной. Perl один такой продукт. Запущенный как маленький проект для Larry Wall (создатель Perl) он превратился в очень гибкий, наиболее легко реализованный из когда либо созданных язык.

Вообразите язык программирования, который объединяет некоторые из самых лучших атрибутов языков типа C, sed, awk и БЕЙСИК. Также помните, что размер Perl программ по размеру всего лиш доля откомпилированных программ C. Наконец, Perl очень хорошо для создания CGI приложений для использования в WWW. Манипуляция текстом в Perl, я думаю, вне конкуренции с любым компьютерным языком.

Perl наиболее подходящ как инструмент для реализации CGI. Подобно большинству инструментальных средств программирования, Perl не содержит много свойственных ему недостатков. Однако в неопытных руках Perl может открыть несколько дыр в безопасности.

Perl и CGI

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

Динамический здесь означает, что результат изменится в зависимости от ввода пользователя. Результат, обычно недавно сформированная Web страница, сгенерирован в течение работы CGI. Самый простой путь для Вас, чтобы понять это состоит в том, чтобы исследовать сценарий Perl в действии. Вообразите Web страницу с единственной формой, подобной на Рисунке 30.4.

Типовая CGI страница от SAMS
Рисунок 30.4. Типовая CGI страница от SAMS.

Страница на Рисунке 30.4 содержит единственное поле ввода с именем editbox, которое Вы можете видеть в следующем исходном коде HTML: 

<HTML>
<HEAD>
<TITLE>Пример CGI от SAMS</TITLE>
</HEAD>
<BODY bgcolor = "#ffffff">
<P></P>
<P>Анатомия CGI Программы</P>
<P></P>
<P></P>
<FORM ACTION = "getit.cgi" METHOD = "Get">
<P><INPUT TYPE = TEXT NAME = "editbox" SIZE = 20 MAXLENGTH = 20></P>
</FORM>
</BODY>
</HTML>

В этом коде форма, которая содержит editbox, также указывает на программу сценария на жестком диске. Этот сценарий, названный getit.cgi, появляется в полужирном в следующем HTML коде: 

<HTML>
<HEAD>
<TITLE>Пример CGI от SAMS</TITLE>
</HEAD>
<BODY bgcolor = "#ffffff">
<P></P>
<P>Анатомия CGI Программы</P>
<P></P>
<P></P>
<FORM ACTION = "getit.cgi" METHOD = "Get">
<P><INPUT TYPE = TEXT NAME = "editbox" SIZE = 20 MAXLENGTH = 20></P>
</FORM>
</BODY>
</HTML>

И так editbox ссылается к окну ввода в форме; Вы присваиваете это имя полю так, чтобы позже, когда необходимо, можно было обратиться к полю (и его содержимому) как к переменной. Вы знаете из предшествующего кода, что содержимое editbox будет послано сценарию Perl с именем getit.cgi.

getit.cgi очень простой сценарий Perl. Его функция состоит в том, чтобы брать ввод из editbox, удалять из него различные коды и странные символы, общие для HTML, и печатать ввод editbox на чистой странице. Код имеет следующий вид: 

# Печатает тип контекста для совместимости с HTTP/1.0
print "Content-type: text/html\n\n";

# Получает ввод из тестовой формы HTML
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});

# Разбивает пары имя-значение
@pairs = split(/&/, $buffer);

foreach $pair (@pairs)
{
    ($name, $value) = split(/=/, $pair);

    # Un-Webify plus signs and %-encoding
    $value =~ tr/+/ /;
    $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;

    $FORM{$name} = $value;
}

print "$FORM{'editbox'}\n";
print "<html>$FORM{'editbox'}\n</html>";

Из этих строк кода мы заинтересованы только в последней. Это строка означает "Напечатать совершенно новую Web страницу в HTML, и на этой странице напечатать слово или слова, которые пользователь ввел в editbox". Таким способом переменные извлекаются из HTML страницы и проходят через сценарий Perl. Естественно, после того, как переменные извлечены, они могут быть обработаны программистом любым способом, который он выберет. Например, если переменные состоят из чисел, программист может использовать Perl чтобы, скажем, сложить, умножить, или разделить эти числа. После того, как переменные были извлечены, программист может делать с ними почти все. Результирующая страница будет различна в зависимости от того, что пользователь введет в editbox. Если пользователь введет имя Джордж, результирующая страница напечатает Джордж. Если пользователь введет строку Безопасность CGI, результирующая страница напечатает Безопасность CGI. (Короче, Вы поняли.)

В течение этого процесса происходит кое-что очень важное. После того, как пользователь введет текст в editbox и нажмет Enter, текст будет послан getit.cgi. getit.cgi вызовет интерпретатор Perl на жестком диске сервера. Интерпретатор Perl оценит getit.cgi и затем автоматически выполнит его.

Вот где начинается безопасность (или небезопасность) CGI. Когда форма обрабатывается таким способом, выполняется интерпретатор Perl. Нет никакого человеческого вмешательства в этот процесс. Если сценарий Perl (в этом случае getit.cgi) написан без мысли о безопасности, могут случиться странные и ужасные вещи. Есть некоторые ловушки программирования CGI; эти ловушки могут открывать всю мощь и область действия языка Perl (или оболочку) посетившему взломщику.

Системный Вызов

Системные вызовы один общий источник взлома. Системный вызов это любая операция в Perl (или любом языке), которая вызывает другую программу, чтобы сделать некоторую работу. Это другая программа чаще всего обычно используемая команда, которая является частью операционной системы или оболочки.

Системные вызовы обычно вызываются с помощью функции system(). Программисты C, которые работают с платформой Microsoft (к кому я особенно обращаюсь здесь) узнают этот запрос, потому что, чтобы использовать эти запросы, им, вероятно, придется включить dos.h (и возможно даже process.h) файл в их откомпилированную программу. Для тех программистов, которые уходят с платформы Microsoft (которые могут быть плохо знакомы с Perl), этот момент очень важен: В Perl системный вызов не требует включений. Он может быть сделан просто выдачей запроса. Если запрос выдан, и не была сделана предшествующая проверка ввода пользователя, возникают проблемы безопасности. Выдача системного вызова в Perl работает подобно следующему: 

system("grep $user_input /home/programmer/my_database");
ПРИМЕЧАНИЕ: Этот системный вызов запрашивает grep искать файл my_database для любой строки $user_input введенной пользователем. Программы, которые работают подобно этой дешевые пути ухода от покупки частной лицензии CGI-to-database. Тысячи сайтов используют этот метод для поиска плоских файлов базы данных или даже каталогов.

Системные вызовы такого характера опасны, потому что никогда нельзя ожидать того, что введет пользователь. Правда большинство пользователей введут некоторую строку, которая соответствует ожиданию (или если не соответствует, тогда ту, которую они считают соответствующей). Однако взломщики работают по другому. Для взломщика основная проблема написан ли ваш CGI чисто. Чтобы определить, имеет ли это место, взломщик введет ряд строк, разработанных для проверки вашей методики безопасности CGI.

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

Почти все среды оболочек (включая command.com в MS-DOS) и большинство языков обеспечивают выполнение последовательных команд. В большинстве сред это выполняется, помещая команды одну за другой, отделенных метасимволом. Метасимвол может быть символ канала (|) или точкой с запятой (;). Кроме того, многие среды позволяют условное выполнение команды, помещая команды одной за другой, отделенных специальными метасимволами. (Например где выполнение зависит от успеха или неудачи предыдущей команды. Это работает в стиле "Если команды номер один терпит неудачу, выполняется команды номер два" или даже "Если команда номер один успешна, пропустить команду номер два.")

Если ваш CGI написан плохо (например, Вы не включили механизм исследования каждой представленной строки), взломщик может поместить дополнительные команды в список параметров. Например, классическая строка: 

user_string;mail bozo@cracking.com </etc/passwd

В этом примере файл /etc/passwd будет отправлен взломщику. Это работает, потому что точка с запятой сообщает интерпретатору, что другая команда должна быть выполнена после того, как поиск grep закончен. Это эквивалентно тому, когда программиста выдает ту же самую команду. Таким образом в действительности происходит следующее: 

system("grep $user_input my_database $user_string; mail bozo@cracking.com </etc/passwd");

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

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

Perl в этом отношении также имеет некоторые встроенные возможности безопасности. Например, как выборка из примечаний man страницы по Perl, следующее это то, что случается при обработке сценариев Perl setuid (которые для работы требуют специальных привилегий):

Когда Perl выполняет сценарий setuid, требуются специальные предосторожности, чтобы предотвратить Вас от любых очевидных западней. (Некоторыми способами сценарий Perl более безопасен чем соответствующая программа C.) Любой параметр командной строки, переменная окружения, или ввод отмечается как "зараженный", и не может использоваться, непосредственно или косвенно, в любой команде, которая вызывает подоболочку, или в любой команде, которая изменяет файлы, каталоги, или процессы. Любая переменная, которая установлена в выражении, которое предварительно сослалось на зараженное значение, также становится зараженной (даже если это логически невозможно для зараженного значения повлиять на переменную).

Однако, Вы никогда не должны выполнять сценарий в привилегированном режиме; я не единственный человек, который сообщит Вам это. "The World Wide Web Security FAQ" ("FAQ по Безопасности Всемирной Сети"), превосходный документ от Lincoln D. Stein о безопасном программировании CGI, уведомляет следующим образом:

Прежде всего, действительно ли Вы должны выполнять ваш сценарий Perl как suid? Это представляет главный риск, поскольку предоставление вашему сценарию больших привилегий чем "никакому" пользователю имеет также увеличения потенциала для повреждения, которое разрушающий сценарий может вызывать. Если вы думаете о предоставлении корневых привилегий вашему сценарию, обдумайте это чрезвычайно тщательно.
Ссылка: "The World Wide Web Security FAQ" от Lincoln D. Stein может быть найден в Web на
http://www-genome.wi.mit.edu/WWW/faqs/wwwsf5.html.

Проблема системного вызова не ограничивается Perl, а может происходить в любом языке, включая C. Один очень талантливый программист и автор, Eugene Eric Kim, говорит о проблеме в "Programming CGI in C" ("Программирование CGI в C"):

В CGI программах на C, функции C, которые разветвляют процесс оболочки Bourne (например system() или popen()) представляет серьезную потенциальную дыру в безопасности. Если Вы позволяете ввод пользователя в любую из таких функций без первоначального "исправления" ввода (добавления наклонной черты влево перед неверными символами), кто нибудь может злонамеренно воспользоваться преимуществом вашей системы, используя специальные, зарезервированные оболочкой "метасимволы".
Ссылка: "Programming CGI in C" от Eugene Eric Kim, может быть найден в Web на
http://www.eekim.com/pubs/cgiinc/index.html.

Я строго рекомендую последнюю книгу Kim'а, CGI Developer's Guide (Руководство Разработчика CGI) (изданной Sams.net). Глава 9 этой книги ("Безопасность CGI: Написание Безопасных Программ CGI") обеспечивает превосходный краткий обзор методов безопасности CGI. В частности она адресует некоторые сценарии, с которыми Вы вероятно столкнетесь в реальном программировании CGI, включая, но не ограничиваясь следующими:

Несколько Слов о Создания Файла

Маловероятно, что Вы создадите процесс CGI, который создает файл. Но если Вы сделаете это, должны быть соблюдены некоторые строгие правила:

Включения Стороны Сервера

Я против включений стороны сервера. О, они круты и могут обеспечивать интересную информацию, но они, по моему мнению, серьезная опасность для безопасности. Прежде, чем обсудить опасности, я должен определить то, что такое включения стороны сервера. Включения стороны сервера это механизм, которым Вы можете автоматически включать документы или другие элементы Web страницы в существующую Web страницу, вызывая эти элементами с локального (или удаленного) жесткого диска.

Позвольте мне вдаться в подробности. Включения стороны сервера (SSI - server-side includes) это расширенное создание HTML. SSI функция очень подобна стандартным файлам для включения в C или C++. Вызывая эти файлы в вашем HTML, Вы можете включать элементы в страницы вместо того, чтобы включать их вручную. Другими словами, предположим Вы хотите, чтобы каждая страница на вашем сервере имела один и тотже заголовок. Вы можете отредактировать ваши страницы так, чтобы в каждой появился стандартный блок кода, или можете вызвать SSI. Мой совет: Не Делайте этого.

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

<!--#include file="mybanner.html"-->

Содержымое файла mybanner.html может выглядеть следующим образом: 

<br><img src="banner.gif">

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

<TR VALIGN="top" ALIGN="left">
<TD COLSPAN=2 ROWSPAN=5 WIDTH=96 ALIGN="center" VALIGN="center">
Â<IMG HEIGHT=96 WIDTH=96 SRC="3ad06301.gif"
BORDER=0 ALT="Изображение" ></TD>
   <TD COLSPAN=9 HEIGHT=7></TD>
   </TR>
   <TR VALIGN="top" ALIGN="left">
     <!-- Эти 2 столбца заняты объектом -->
     <TD COLSPAN=5></TD>
     <TD COLSPAN=2 ROWSPAN=1 WIDTH=181>
<!-- Начало объекта Text -->
<P><B><FONT SIZE="-1" FACE="Verdana">Безопасность InfoBase SAMS</B></FONT></TD>
<!-- Конец Text -->

В таком случае Вы можете быть склонны использовать SSI. И снова, я советую не делают этого. Вот почему: SSI может также использоваться для выполнения команд. Это могут быть системные команды, 

<!--#exec cmd="date"--> (Получение даты)

или это могут быть сценарии оболочки. Один хороший способ полностью уничтожить вашу систему состоит в том, чтобы выполнить httpd сервер корневым и позволить SSI. Это эффективно дает взломщику возможность удаления всех ваших файлов, захвата ваших файлов паролей и т.д. Посмотрите на Рисунок 30.5, чтобы увидеть, как работает нормальный CGI.

Нормальный CGI процесс
Рисунок 30.5. Нормальный CGI процесс.

При нормальных обстоятельствах ввод пользователя представляется форме ввода HTML. Оттуда запрос передается серверу и затем непосредственно к некоторой программе CGI (обычно Perl программа), которая немедленно обрабатывает данные. Здесь Вы беспокоитесь только о том, является ли ваш CGI безопасным. Теперь исследуйте Рисунок 30.6.

Процесс CGI, которому предшествует SSI
Рисунок 30.6. Процесс CGI, которому предшествует SSI.

Когда SSI активен, процесс отличается. Ввод клиента передается и анализируется сервером. Часть этого процесс синтаксического анализа идентифицирует SSI директивы. Если существуют директивы exec (которые вызывают другие процессы), они выполняются.

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

Один способ состоит в том, чтобы выполнить внутренние сценарии, которые модифицируют эту информацию. При использовании комбинации Perl и или cron (две утилиты, которые могут выполнять задания по времени), Вы можете создавать заголовки и нижние колонтитулы, которые изменяются с изменением информации в другом месте. Другой способ сделать это состоит в том, чтобы написать программу (возможно на awk или Perl), которая может выполнять эту деятельность по требованию, в интерактивном режиме. Таким способом Вы можете управлять комбинацией заголовки/нижние колонтитулы в некоторые времена дня и делать так в интерактивном режиме, чтобы наблюдать за неожиданными проблемами.

В основном, если Вы администратор и не имеете полного понимания как работает SSI, не используйте его (по крайней мере, пока Вы не узнали как).

ПРЕДОСТЕРЕЖЕНИЕ: Эта консультация не просто для администраторов UNIX систем! Многие пакеты Web серверов поддерживают включения стороны сервера. Например, Web Сервер NetWare поддерживает широкий диапазон команд и директив SSI. Эта опция может быть установлена административным средством.

Microsoft Internet Explorer

В Microsoft Internet Explorer было найдено так много дыр, что кто-то едва знает, где они начинаются. Однако я хочу быстро пробежать по ним. Вы можете задаться вопросом, почему я ждал до этой главы, чтобы адресовать Internet Explorer. Мои рассуждения в значительной степени основаны на факте, что некоторые дыры в Internet Explorer связаны с технологией ActiveX.

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

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

В мире Microsoft меню должны быть по крайней мере немного совместимы с общим дизайном Windows. Таким образом, почти любое приложение, разработанное для Microsoft Windows, будет иметь список меню, который расположен сверху программы. Три меню, которые Вы будете неизменно видеть это Файл, Правка и Помощь (другие меню, которые очень популярны, но менее часто используются это Вид, Утилиты, Формат и т.д.). Разрабатывая приложения, которые предлагают такие меню, Microsoft гарантируют, что сложность изучения этих приложений минимальна. Другими словами, если Вы знаете одну программу Microsoft, то в значительной степени знаете их все. (Это подобно способу, которым каждое приложение помещает свое меню в область сверху рабочего стола MacOS.)

Microsoft таким образом создала свои собственные стандарты на рынке, который предварительно твердо придерживался немногих правил. В этом отношении Microsoft реконструировала мир вычислений на ПК. Кроме того, так как продукты Microsoft настолько популярны в мире, программистов спешат закончить приложения для использования на платформе Microsoft. На этом пути программисты должны строго придержаться стандартов дизайна, сформулированных Microsoft. Если Американский Министр юстиции ищет антимонопольную проблему, она могла бы находиться здесь.

Кроме того, Microsoft предприняла много усилий в интеграции и способности к взаимодействию приложений. Это означает, что электронная таблица Excel может быть без швов помещена в документ Word, база данных Access может быть легко связана с помощью интерфейса с программой на Visual Basic, и так далее. Все продукты Microsoft работают интегрированным способом.

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

Internet Explorer был разработан с такой способностью к взаимодействию. Например, Internet Explorer был, в начале, более интегрирован с операционной системой Windows чем, скажем, Netscape от Netscape. Г. Гейтс несомненно предполагал броузер, который принесет Internet к рабочему столу пользователя тем же самым способом, как если бы это было локальное приложение. Другими словами, Internet Explorer был разработан, чтобы принести Internet пользователю в форме, которая была бы проста для понимания, навигации и управлении. К ее чести, веселая компания программистов Microsoft сделала это. Проблема с Microsoft Internet Explorer состоит в том, что он выполняет свою цель до крайности.

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

Если хакер воспользовался преимуществом этой проблемы безопасности, Вы можете видеть значок, или графику в Web странице, которая, фактически, находится в регулярной папке Windows 95/Windows NT 4.0 на сервере Web сайта или вашем компьютере. Хакер может уменьшить кадр вокруг значка или графики так, чтобы Вы думали, что это безопасно, когда фактически это позволяет Вам или кому либо еще открывать, копировать, или удалять файл, или выполнять программу, которая, если автор имеет злое намерение, могла бы повредить ваш компьютер. Вы можете запускать программу, потому что папка обходит механизм безопасности Internet Explorer.
Ссылка: Общественная консультация Microsoft, Update on Internet Explorer Security issues UMD Security Problem (Модификация Безопасности Internet Explorer имеющая UMD Проблему Безопасности), может быть найдена в Web на
http://www.microsoft.com/ie/security/umd.htm.

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

К ее чести, Microsoft быстро ответила на каждый случай. Например, вторая дыра была подтверждена за часы после ее обнаружения. Авторы этой консультации говорили:

... эта проблема касается способности программиста написать код в Web странице, который используя Internet Explorer версии 3.x может обратиться к гиперссылке на Web странице, которая указывает на .LNK (файл ярлыка Windows) или .URL файл. Указывая на .LNK или .URL можно запустить программу, которая может вызвать повреждение компьютера.
Ссылка: Консультация Microsoft о второй дыре, "'Cybersnot' Security Problem" ("Проблема Безопасности 'Cybersnot'"), может быть найдена в Web на
http://www.microsoft.com/ie/security/cybersnot.htm.

было также послано исправление этой проблемы. Если это первое, что Вы услышали об этой проблеме (и Вы используете Internet Explorer), то необходимо немедленно загрузить заплату.

Ссылка: Заплата для дыры, обсуждаемой в консультации Microsoft, "'Cybersnot' Security Problem," может быть найдена в Web на
http://www.microsoft.com/msdownload/ie301securitypatch.htm.

Новости об этих дырах взбаламутили вычислительные сообщества, которые все еще были потрясены более ранними дырами. Исследуйте консультацию от Dirk Balfanz и Edward Felten из Университета в Princeton, посланную в августе 1996:

Мы обнаружили недостаток безопасности в броузера Microsoft Internet Explorer версии 3.0, работающего под Windows 95. Нападающий может эксплуатировать недостаток, чтобы выполнить любую команду DOS на машине пользователя Explorer, который посетит страницу нападающего. Например, нападающий может читать, изменять, или удалять файлы жертвы, или вставить вирус или закулисный вход в машину жертвы. Мы проверили наше открытие, создав Web страницу, которая удаляет файл на машине любого пользователя Explorer, который посетит страницу.
Ссылка: Консультация, написанная Dirk Balfanz и Edward Felten, может быть найден на
http://geek-girl.com/bugtraq/1996_3/0394.html.

Этот случай вынудил группу Felten предпринять полный анализ безопасности Internet Explorer. На сколько я знаю, результаты еще не были выпущены.

Ссылка: Хотя результаты анализа группы Felten еще не были выпущены, их исследовательская страница расположена на
http://www.cs.princeton.edu/sip/Research.html.

Ясно, на этот момент, что Microsoft Internet Explorer все еще имеет дыры в зубах с точки зрения безопасности Internet. Что делает проблему настолько коварной, так это то, что только пользователи, которые истинно знают безопасность, получают такую информацию как новости. Большинство получает такую информацию от третьих лиц, часто намного позже обнаружения дыр. Главное беспокойство составляет то, что почти все дыры, найденные в Internet Explorer, имеют Класс A.

ActiveX

Корпорация Microsoft предприняла много усилия по продаже ActiveX публике. Однако, даже без исследования риска безопасности от ActiveX (а есть некоторые серьезные риски), я могу сообщить Вам, что ActiveX имеет ловушки. Вот две очень практических причин не использовать ActiveX:

Недавняя статья в Network World (Мире Сети) от Ellen Messmer дает некоторое понимание чувств частных корпораций к ActiveX:

Подобно многим компаниям, Корпарация Lockheed Martin полагается на технологию Корпорации Microsoft. Но когда она входит в intranet Lockheed'а, одна вещь, которую компания не будет соблюдать, это ActiveX, краеугольный камень Web усилий Microsoft. Причина? ActiveX может предложить писателям вирусов и хакерам совершенный доступ к сети. "Вы можете загрузить ActiveX апплет, который является вирусом, производящим большие повреждения", объясняет Bill Andiario, технический руководитель Web инициатив в Lockheed Martin Enterprise Information Systems, рука информационных систем компании. "Или он может захватить вашу частную информацию и передать ее назад конкуренту, или еще хуже, другой стране."
Ссылка: "ActiveX Marks New Virus Spot" ("ActiveX Отмечает Новое Вирусное Пятно") (Network World) от Ellen Messmer'а может быть найден в Web на
http://www.nwfusion.com/.

Опасения корпаративного сообщества хорошо обоснованы. Технология ActiveX (по крайней мере на данный момент) бесспорно угроза безопасности Internet. Только спросите Клуб Компьютерного Хаоса (Chaos Computer Club), группу хакеров с центром в Гамбурге, Германия. Группа получила международную известность за несколько экстраординарныйх использований дыр, включая вторжение в NASA. Некоторые из более причудливых вторжений приписанных этой группе, включают

Вот классическое сообщение, зарегистрированное в феврале 1988, связанное с эпизодом, когда слух о нападении CCC вызвал панику (сообщение было зарегистрировано Jerry Leichter, в последствии студента Университета в Yale):

Неделю или около того назад Клуб Компьютерного Хаоса в Западном Берлине объявил, что собирается вызвать троянских коней, предварительно установленных на различных компьютерах в Space Physics Analysis Network (Сети Анализа Космической Физики). Возможно, причина вызова троянских коней состоит в желании сделать сеть неупорядоченной; если так, то угроза, к сожалению, с помощью многочисленных пятых комментаторов из SPAN, имеет успех. Прежде, чем кто нибудь из SPAN ответит, сказав: "Ерунда, они не смогут вызвать никаких троянских коней", позвольте мне подчеркнуть, что я сказал УГРОЗА успеха. Правильно, в течение последней недели SPAN не функционировал очень хорошо как сеть. Многие машины в ней были отключены от сетевой связи (или по крайней мере потеряли многое из нее...
Ссылка: Найдите сообщение Jerry Leichter'а полностью на
http://catless.ncl.ac.uk/Risks/6.27.html.

Экстраординарно. В прошлом различные спецслужбы пытались проникнуть в CCC по средствам широкого диапазона средств. Такие службы по сообщениям включили Французскую тайную полицию. Французское Руководство de la Surveillance du Territoire (внутренняя спецслужба) предположительно использовало агента провокатора в попытке получить сторонников в CCC:

В течение лет Jean-Bernard Condat несомненно был самым известным компьютерным хакером Франции. Появляясь в телевизионных ток-шоу, запуская провокационные операции и посещая компьютерные семинары, он основал в 1989 Клуб Компьютерного Хаоса Франции (CCCF - Chaos Computer Club France), как ответ Франции на известный Клуб Компьютерного Хаоса в Германии. Французский журналист Jean Guisnel показал на этой неделе в книге, имеющей название Guerres dans le Cyberespace, Internet et les Services Secrets (Война Киберпространства, Internet и Секретные Службы) и изданной Editions La Decouverte (ISBN 2-7071-2502-4), что Condat управлялся изначально Direction de la Surveillance du Territoire. Студент в Lyons, где он следовал за музыкой и курсами информационной технологии, Condat в 1983 после совершения некоторого "незначительного проступка" был принят в местное отдление DST. DST организовывала его участие на встречах хакеров за границей.
Ссылка: Предыдущий параграф это выдержка из документа A Computer Spy Unmasked: Head of the French Hackers Group was a Secret Service Agent (Компьютерный Шпион Обнаружен: Глава Французской Группы Хакеров был Агентом Секретной Службы) (Indigo Publications), который может быть найден в Web на
http://www.sec.de/sec/news.cccfnarc.

В любом случае, CCC долго был известен за его часто драматические общественные подвиги по хаку и взлому. Эти подвиги нанесли вред более чем одному гиганту: это были телекоммуникационные компании, или частные корпорации. В феврале 1997 голова Microsoft упала под топором Клуба Компьютерного Хаоса. Как сообщено CNET:

По немецкому национальному телевидению [CCC] хвастался элементом управления ActiveX, который был способен взять деньги с одной учетной записи банка и внести их на другую, и все без общепринятого персонального идентификационного номера (PIN), который, как предполагается, защищает от воровства.
Ссылка: "ActiveX Used as Hacking Tool" ("ActiveX, Используемый Как Утилита Взлома") от Nick Wingfield (CNET), может быть найден в Web на
http://www.news.com/News/Item/0,4,7761,4000.html.

Эти новости заставили взорваться Usenet и списки рассылки по безопасности. Горячие аргументы последовали между пользователями Microsoft и остальной частью мира. Говорили: ActiveX полностью небезопасен. Сообщения в списках по безопасности исходили от личностей, требующих брандмауэры или другие утилиты для фильтрации ActiveX на уровне маршрутизатора. Кроме того, есть фирма, называемая Aventail, которая специализируется на таком фильтрующем программном обеспечении.

Ссылка: Полная хронология этих аргументов может быть найдена на
http://www.iks-jena.de/mitarb/lutz/security/activex.en.html.

Ссылка: Если Вы системный администратор, то должны серьезно рассмотреть контакт с Aventail. Она может быть найдена в Web на
http://www.aventail.com/.

И так, Что Является Проблемой с ActiveX?

Проблема с ActiveX была кратко суммирована людьми из JavaSoft:

ActiveX ... позволяет произвольному двоичному коду быть выполненным. Может быть написан злонамеренный ActiveX компонент, чтобы удалить или изменить файлы на локальном диске пользователя или установить подключения с другими компьютерами без уведомления или одобрения пользователя. Есть также риск, что хороший ActiveX компонент может иметь прикрепленный вирус. К сожалению, вирусы могут быть зашифрованы также легко, как обычный код.
Ссылка: Предыдущий параграф это выдержка из "Frequently Asked Questions – Applet Security" ("Часто Задаваемые Вопросы – Безопасность Апплета"), который может быть найден в Web на
http://www.javasoft.com:80/sfaq/index.html#activex.

Проблема кажется более серьезной, чем есть. Только те, кто используют платформу Microsoft, могут быть реальными жертвами. Это так, потому что большинство продуктов Microsoft (исключая NT) не обеспечивают управление доступом. Таким образом, если злонамеренный элемент управления ActiveX прорвется, он получит доступ ко всему жесткому диску пользователя. В UNIX это не возможно из-за файловых разрешений и управления доступом. В среде UNIX злонамеренный апплет никогда не доберется дальше каталога текущего пользователя.

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

Некоторые силы в Microsoft приняли позицию, при которой инцидент с CCC доказывает, что личности не должны принимать неподписанный код. То есть люди в Microsoft приняли эту возможность чтобы обрисовать их план, при котором весь код должен быть подписан в цифровой форме. Однако это приводит обратно к проблеме относительно удостоверений и сигнатур, которую я обсуждал ранее. Почему Microsoft столь внимательна к тому, чтобы все, включая программистов, идентифицировали себя? Почему программист должен быть вынужден подписать свое приложения просто, потому что ActiveX не безопасен?

ПРИМЕЧАНИЕ: Фактически, даже подписанный код опасен. Не нужно много усилий, чтобы подписать код, и в настоящее время нет никакого механизма, чтобы предотвратить злонамеренных программистов от подписания их кода, безопасен он или нет.

Технология ActiveX должна быть переработана, и ответственность за это лежит на плечах Microsoft. В конце концов, изложенные риски существенны только для собственных пользователей Microsoft. Помните, что по крайней мере на данный момент, Microsoft Internet Explorer единственный броузер, которые истинно поддерживают ActiveX. Однако все это собирается измениться. ActiveX скоро станет разработкой, открытым стандартом, как отмечено Mike Ricciuti и Nick Wingfield (CNET):

Сегодня представители более 100 компаний, включая изготовителей программного обеспечения и менеджеров информационных системных, проголосовали за встречу, чтобы повернуть лицензирование, объявление и управление ActiveX спецификации к Открытой Группе, консорциуму промышленности, опытному в продвижении других межплатформенных технологий.

Сомнительно, что ActiveX когда-либо полностью ограничится от доступа к частям жесткого диска индивидуума из-за отношения, которое технология имеет к компонентам подобным Visual Basic. Знакомые с Visual Basic знают, что некоторые его команды позволяют Вам управлять приложениями Microsoft из удаленного местоположения, даже если Вы не имеете низкоуровневого сеанса связи (типа DDE) с целевой программой. (Функция SendKeys совершенный пример таких функциональных возможностей.)

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

Чтобы понять, что такое OLE, рассмотрите это: OLE это технология, которая имеет дело с составными документами, или документами, содержащими несколько типов данных или медиа. В старой "вырезать и вставить" технологии такие элементы (когда извлечены из их родного приложения) были бы искажены и приняли бы любую среду существующую в приложении, в котором они были депонированы (например, вставка электронной таблицы в документ текстового процессора приведет к беспорядку в данных электронной таблицы). В OLE эти объекты сохраняют свое родное состояние независимо от того, где они заканчиваются. Когда элемент документа заканчивается в приложении отличном от его собственного, это называется внедренный объект.

Каждый раз, когда Вы должны редактировать внедренный объект, вызывается первоначальное, родительское приложение, так что редактирование имеет место в родной среде элемента (например, чтобы редактировать электронную таблицу Excel, внедренную в документ Word, запускается Excel). Однако в расширенном OLE пользователь никогда не видит обмен между текущим и родительским приложениями. Значения безопасности этого очевидны. Если элемент управления ActiveX может маскироваться под сгенерированный в конкретном приложении, он может заставить выполниться образец этого приложения. После того, как приложение было запущено, им можно "управлять удаленно" из компонента ActiveX. Значения этого разрушительны.

И так, перед Microsoft стоит дилемма. Она имеет превосходное расширение Web, но которое приводит к критическому риску безопасности. Остается только ждать, когда Microsoft сможет придумать практические решения этих проблем. Тем временем было бы мудро отключить поддержку ActiveX в вашем броузере. Иначе Вы можете пасть жертвой злонамеренного элемента управления ActiveX. И опасность, представляемая этим затмевает опасности, представляемые Java апплетами. Фактически, это вне сравнения.

Итог

Эта книга едва захватывает поверхность безопасности Internet. Однако, я надеюсь, что некоторые моменты были указаны. Между дырами в операционных системах, CGI сценариях, TCP/IP демонах, клиентских броузерах, апплетах и расширениях, Internet не очень безопасное место. Приняв эти факторы в их полноте, Internet вообще не безопасна. Все же личности делают банковское дело по Сети.

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

Предыдущая главаСледующая главаСодержание


Macmillan Computer Publishing USA

Macmillan Computer Publishing.


Все мессаги сюда:yanich@inbox.ru
Hosted by uCoz