2015-04-01
526
WWW— это наиболее развитая служба Интернета. Соответственно, ее значение в электронной коммерции наиболее велико. Web-страницы — это простое и естественное средство для того, чтобы представить товар, услугу или фирму. С технологиями, используемыми в WWW, мы познакомимся в этом разделе.
Простейшие Web-страницы. Web-страница — это один отдельный документ в информационном пространстве WWW. Он не слишком сильно отличается от обычных текстовых документов. Кроме обычного текста в нем содержатся так называемые теги — коды, управляющие тем, как документ форматируется в окне броузера при воспроизведении. Правила записи тегов описаны в спецификации языка HTML (HyperText MarkUp Language — язык разметки гипертекста). Кроме текста, простейшая Web-страница может содержать графические и другие встроенные мультимедийные объекты (аудиоклипы, видеоролики).
Web-страницы — это простейшее средство опубликования сведений об юридическом или физическом лице, то есть, они являются простейшими средствами реализации информационной функции Интернета. С точки зрения электронной коммерции, их можно рассматривать как “визитные карточки”, частично реализующие рекламную и представительскую функцию (рис. 10.4).
На компьютер клиента Web-страницы передаются по протоколу HTTP. Это один из простейших протоколов Интернета прикладного уровня. В своей основе он “одноразовый”, то есть, броузер отправляет серверу запрос на поставку ресурса (HTML-документа), находящегося по заданному адресу URL, в ответ сервер поставляет этот ресурс, разбив его на TCP-пакеты, после чего под управлением операционной системы клиентского компьютера эти пакеты собираются вновь в цельный документ, и броузер воспроизводит его на экране. После поставки одного-единственного ресурса связь разрывается, и сервер ждет нового запроса от броузера, а броузер, в свою очередь, ждет действий от пользователя.
Если Web-страница имеет встроенные графические объекты, обладающие своими адресами URL, то современные броузеры не дожидаются, когда пользователь их запросит, а автоматически выдают HTTP-запросы серверу на их поставку. Но и в этом случае общий принцип одноразовости протокола HTTP остается тем же — сколько объектов имеется в составе одной Web-страницы, столько происходит циклов “запрос—поставка” по протоколу HTTP.
Web-узлы. Простейшим Web-страницам не хватает двух элементов, играющих в электронной коммерции чрезвычайно важную роль: динамичности и интерактивности. О коммерческой значимости динамичности и интерактивности мы расскажем ниже, а пока рассмотрим приемы того, как динамичность и интерактивность достигаются или хотя бы имитируются.
Поскольку в основе службы WWW лежит протокол связи HTTP и язык форматирования документов HTML, то естественно было бы ожидать, что они должны иметь в своем составе средства для создания динамичных и интерактивных Web-страниц. Такие средства действительно есть, но они отличаются крайней простотой и неразвитостью.
Самое простое средство для имитации интерактивности, имеющееся в языке HTML, — это гиперссылки. Они создаются с помощью несложного тега, связывающего определенный текст Web-страницы (или ее графический объект) с произвольным адресом URL. При просмотре этого текста в окне броузера пользователь может видеть, что текст выделен цветом (обычно синим) и подчеркиванием. Если гиперссылка графическая, то изображение может иметь цветную рамку.
При щелчке кнопкой мыши на объекте, являющемся гиперссылкой, броузер формирует новый запрос к серверу на поставку Web-ресурса, URL-адрес которого связан с данной гиперссылкой. Благодаря этому и образуется возможность интерактивной навигации по информационному пространству WWW.
Возможность связи с помощью гиперссылок нескольких Web-страниц в единую структуру используют для создания Web-узлов (в просторечии именуемых сайтами или Web-сайтами).
ª Между терминами Web-узел и сайт имеется только контекстное различие. Сайт рассматривается как законченный объект интеллектуальной собственности, например как книга. Web-узел рассматривается как структурное объединение Web-страниц, связанных по признаку содержания либо принадлежности. Таким образом, термин сайт используется в потребительском контексте, характерном для пользователей, а термин Web-узел — в структурном контексте, характерном для разработчиков.
По последним данным средний размер Web-узла составляет примерно 15 Web-страниц. Для организаций, использующих модель В2В, характерны небольшие Web-узлы с количеством страниц 5—8, достаточные для представления предприятия потенциальным партнерам. Для организаций, использующих модель В2С,характерны Web-узлы повышенного размера. Чем шире сфера деятельности организации, тем больше размер ее Web-узла. Так, например, для торговых организаций, занимающихся продажей потребительских товаров, доставляемых традиционными средствами, средний размер Web-узла составляет несколько сот Web-страниц. Для организаций, оказывающих информационные услуги или торгующих материалами, доставляемыми по Сети (например программами), средний размер Web-узла значительно выше и может достигать тысяч Web-страниц. Размеры Web-узлов электронных газет, журналов и информационных архивов могут достигать десятков тысяч Web-страниц.
Рекламная ценность Web-узла во много раз выше, чем отдельной Web-страницы. Для успеха электронной коммерции очень важно, чтобы клиент не только мог успешно воспользоваться Web-представительством организации в Сети, но и чтобы он раз за разом вновь к нему возвращался, даже и без конкретных целей приобретения товара. Поэтому Web-узлы наполняют не только рекламным, но и информационным содержанием, выполняющим функции пропаганды товара и формирования образа жизни с его использованием.
Так, например, на Web-узлах компаний, торгующих СВЧ-плитами, непременно присутствуют Web-страницы с кулинарными рецептами блюд, приготовляемых с помощью этих плит. Для обеспечения интерактивного общения с покупателями там же организуются Web-форумы по обмену рецептами, проводятся конкурсы на лучшее блюдо и т. п.
Компании, торгующие лекарственными препаратами, публикуют на своих Web-узлах отзывы покупателей, комментарии специалистов, рассказывают о природе заболеваний и мерах по их предотвращению. С целью повторного привлечения пользователей к своему Web-узлу организуются бесплатные консультации специалистов. Все это уже не реклама, а пропаганда.
Web-формы. Чтобы связь между клиентом и Web-сервером была интерактивной, пользователю надо дать в руки какое-то средство управления взаимодействием, например средство управления просмотром. Если оставаться в строгих рамках протокола HTTP и языка HTML, то таких средств очень мало. Выше мы рассмотрели использование гиперссылок, но их возможности крайне ограничены. Фактически, выбор адреса URL для запроса нового ресурса (то есть, выбор гиперссылки) — вот и все возможности пользователя. Это связано с соображениями безопасности — протокол HTTP устроен так, чтобы минимизировать возможность несанкционированного управления чужим аппаратным и программным обеспечением.
Однако кое-что для организации взаимосвязи между пользователем и сервером все-таки имеется. Согласно протоколу HTTP, броузер может передать серверу не только запрос на поставку ресурса, но и некоторые простейшие параметры (значения). Что сервер будет делать с этими числами или символами — его дело. Например, он может использовать их как входные параметры для какой-либо программы, которая выполнит некоторую операцию. В частности, пользователь может передать серверу, что его любимый цвет красный, а сервер может обработать параметр цвета с помощью специальной программы и впоследствии начнет передавать Web-страницы, оформленные в красной гамме цветов.
Существует множество самых разнообразных приемов использования Web-форм, но в простейшем виде их используют для того, чтобы пользователь мог отправить серверу какие-либо данные о себе или о своих предпочтениях. На рис. 10.5 представлен пример Web-формы компании “Космос ТВ”, с помощью которой она собирает от будущих клиентов заявки на подключение. Web-формы могут содержать такие элементы управления, как текстовые поля, флажки, переключатели, списки выбора и командные кнопки. Текстовые поля пользователь заполняет собственноручно и, тем самым, сообщает сведения о себе. С помощью прочих элементов управления он выбирает какие-то параметры из предложенных.
Два подхода к обеспечению интерактивности и динамичности. Еще раз вернемся к Web-формам. Повторим, что с их помощью можно не только получать ресурсы от сервера, но и передавать ему ограниченный набор параметров, в общем случае числовых, поскольку текст тоже представляется в компьютере числами. То есть, Web-формы позволяют пользователю передать данные в направлении сервера. Однако это еще далеко не интерактивность, хотя и хорошая основа для нее. Для подлинной интерактивности здесь не хватает возможности управления какой-либо программой.
Если мы хотим, чтобы пользователь находился в интерактивном общении с сервером, то должны, прежде всего, решить вопрос, где находится та программа, которой он будет управлять: на его компьютере или на сервере. Возможны оба подхода, но оба имеют недостатки с точки зрения безопасности.
1. Если сервер предложит пользователю какую-то программу, обеспечивающую возможность интерактивного общения, то пользователь, строго говоря, обязан ее отвергнуть. Для бытовых компьютеров ситуация, когда удаленный сервер устанавливает на компьютере пользователя свое программное обеспечение, еще может как-то считаться терпимой, но для служебных систем это в принципе недопустимо.
2. Второй, безопасный вариант: установка программы, взаимодействующей с клиентом, непосредственно на сервере. В этом случае пользователь может управлять ею с помощью, например, тех же параметров, отправляемых из Web-форм, но надо сначала разобраться с тем, кому принадлежит сервер, и здесь опять-таки возможны два варианта.
а. Физическая, и программная части Web-сервера принадлежат самой коммерческой организации, занимающейся электронной коммерцией. В этом случае организация вольна устанавливать на нем любое программное обеспечение и организовывать его взаимодействие с удаленным клиентом. Все ошибки и уязвимости такой системы находятся под контролем самой организации-владельца, и она сама несет ответственность за свои действия.
Такой подход возможен только для организаций, способных приобрести необходимое серверное оборудование, программное обеспечение, арендовать производительные линии связи и нанять квалифицированных специалистов, способных обслуживать сервер и обеспечивать его безопасность. Еще сравнительно недавно (три-четыре года назад) рабочие станции, способные выполнять серверные функции, стоили очень дорого. Весьма дорогим было и серверное программное обеспечение. Величину капиталовложений, необходимых для создания собственного Web-сервера, тогда оценивали в несколько десятков тысяч долларов США, что было доступно лишь сравнительно крупным корпорациям.
Сегодня цены на серверное оборудование значительно снизились, появилось доступное по цене (а иногда и условно-бесплатное) серверное программное обеспечение. В несколько раз снизились тарифы на аренду каналов связи, и сегодня объем инвестиций, необходимых для создания коммерческого Web-сервера, составляет лишь несколько тысяч долларов США, что не выглядит невозможным даже для большинства малых предприятий. Поэтому с каждым днем удельный вес средств обеспечения интерактивности (и ответственности за безопасность) все более перекладывается на серверную сторону.
б. Второй вариант — когда физическая и программная часть Web-сервера принадлежат одной организации (назовем ее системным интегратором), а содержание Web-узла, размещенного на сервере, принадлежит арендатору, занимающемуся электронной коммерцией. В этом случае арендатор крайне ограничен в возможности установки на сервере программного обеспечения для интерактивного взаимодействия со своими клиентами. Системный интегратор не может разрешить своим арендаторам запускать произвольное программное обеспечение на его оборудовании, поскольку этим он ставит под угрозу как свою безопасность, так и безопасность своих клиентов, других арендаторов.
Такая ситуация была типичной в период 1994-1997 гг., но и сегодня многие компании предпочитают не создавать свой Web-сервер, а арендовать место у системных интеграторов. Ныне к такому решению приходят уже не столько по экономическим, сколько по кадровым причинам. Многие большие и малые предприятия способны приобрести программное и аппаратное обеспечение Web-сервера, но при этом испытывают затруднения с подбором кадров достаточной квалификации — их просто не хватает.
При такой системе взаимодействия между системным интегратором и коммерсантом есть несколько подходов к решению вопроса о размещении специального программного обеспечения, предназначенного для интерактивного взаимодействия между клиентом и сервером.
1. Системный интегратор может заранее установить на сервере ограниченный комплект типовых программ, предоставить их в лизинг арендатору и обеспечить ему ограниченное количество точек входа в эти программы и выхода из них. Полученные от клиента данные вводятся в виде параметров, а результаты, выданные программами, используются при формировании новых Web-страниц. По такому принципу, например, работают счетчики числа посетителей, которые можно видеть на многих Web-узлах.
С точки зрения арендатора сервера основной недостаток такого подхода — малая гибкость. Арендатор получает ограниченный набор функций. Например, ему предоставляют средство функционирования счетчика посетителей, средство для обработки данных, полученных из Web-форм (это можно использовать для сбора заказов от клиентов), средства для установки и анализа маркеров cookie,может быть, даже защищенные средства для обработки данных платежных карт. Но при всех условиях набор доступных функций ограничен, стереотипен и негибок в настройке.
Стереотипность используемых средств, с одной стороны, благотворно сказывается на безопасности функционирования системы. Это связано с тем, что эти средства распространены очень широко, а значит, тщательно проверены в ходе реальной эксплуатации в различных системах. С другой стороны, ориентация на типовые средства может компрометировать безопасность, так как если где-то, в какой-то системе, злоумышленники найдут метод неправомерного использования этих средств, то есть высокая вероятность того, что незаконный метод быстро распространится и приведет к атакам на все системы, использующие аналогичное программное обеспечение.
ª Безопасность в данном случае зависит от оперативности действий системного администратора и от его информированности о том, какими методами пользуются злоумышленники в каждый момент времени. Это предполагает, что системный администратор должен обладать в определенной мере квалификационными признаками, характерными для подготовленных нарушителей, и должен иметь доступ к каналам обмена информацией, которыми пользуются злоумышленники. То есть, системный администратор должен обладать весьма специфическим опытом, который трудно приобрести, изучая лишь документированные функции компьютерных систем. В этом одна из причин трудностей, связанных с подбором высококвалифицированных технических кадров в области электронной коммерции.
2. Второй вариант — компромиссный, когда системный интегратор разрешает арендатору использовать его программное обеспечение для связи с клиентом, но оговаривает это разрешение тщательной проверкой размещаемых программ и материальными санкциями в случае возникновения ущерба по вине арендатора.
В данном случае арендатор может получить такую гибкость и функциональность системы, какие ему необходимы, но он не избавлен от необходимости наличия квалифицированных разработчиков программного обеспечения и несет повышенные затраты на его разработку, тестирование и страхование.
Нередко арендаторы заказывают изготовление программного обеспечения сторонним разработчикам, но в этом случае они подвергаются дополнительному риску. Неподконтрольные программисты могут заложить в программы скрытую функциональность для несанкционированных действий. Чтобы убедиться в отсутствии тайных “закладок”, требуются опять-таки услуги профессионалов высокой квалификации и дополнительные затраты.
3. Третий вариант — заказ специфического программного обеспечения самому системному интегратору. В этом случае арендатор получает необходимую функциональность и гибкость при минимальных угрозах безопасности серверу. Часто такое решение оказывается наиболее экономически оправданным, но и у него есть важный недостаток.
Этот недостаток состоит в непереносимости используемых программных средств на другое аппаратное обеспечение. Если в будущем потребуется сменить системного интегратора (а экономические, технические и организационные потребности в этом возникают весьма часто), то для нового системного интегратора программное обеспечение, разработанное третьей стороной, опять-таки будет представлять угрозу безопасности, и вся проблема повторится заново, на новом уровне.
Сценарии и приложения CGI. Вернемся ненадолго к рассмотренным нами ранее Web-формам. Web-формы -- это простейшее средство передачи набора параметров от броузера к Web-серверу, то есть предпринимателю от потребителя. Однако Web-сервер может только принять эти параметры, но ничего не может с ними сделать — для этого нужна специальная программа. Она должна работать на сервере в качестве отдельного серверною приложения. Строго говоря, она может быть совершенно произвольной (“черным ящиком”) — важно только, чтобы ее разработчик учел, что ей предстоит работать не самостоятельно, а обмениваться с Web-сервером данными по заданным правилам. Этот набор правил представлен в спецификации CGI (Common Gateway Interface — общепринятый шлюзовый интерфейс).
ª Шлюзовыми называются программы, выполняющие функции согласования работы программных и аппаратных средств.
Серверные программы, разработанные с учетом спецификации CGI, могут быть написаны на многих языках программирования, лишь бы операционная система серверной стороны могла их исполнять. Если эти программы написаны на таких языках, как C++, Pascal и др. (компилируемые программы), то они напрямую работают с операционной системой сервера и называются приложениями CGI. Если же они написаны на таких языках, как Perl, Tcl и т. п. (интерпретируемые программы), то они выполняются под управлением промежуточного посредника (интерпретатора), который, в свою очередь, работает под управлением операционной системы. В этом случае программы CGI называют сценариями CGI.
О том, какие сложности возникают с размещением на сервере произвольных программ, если публикатор коммерческого Web-узла не владеет сервером, а арендует его, мы рассказали в предыдущем разделе. Некорректно написанные сценарии и приложения CGI представляют опасность для сервера, но зато они не представляют опасности для пользователей — для них общение с программой происходит через вполне безопасный механизм Web-форм. Ничего такого, что пользователь не ввел в Web-форму собственноручно, серверу передано не будет.
Активные объекты. Не желая подвергать сервер опасности из-за работы на нем не вполне исследованных программ СGI (или не удовлетворяясь теми проверенными стандартными приложениями CGI, которые хотя и безопасны, но не интересны из-за своей стереотипности), владелец Web-узла может повысить динамичность и интерактивность своих Web-страниц путем размещения на них так называемых активных объектов. Кстати, при этом он одновременно увеличит и быстродействие интерактивных средств. Однако в этом случае все проблемы безопасности перемещаются со стороны сервера на сторону клиента. Понятно, что информированные клиенты воспримут это негативно и могут отказаться от услуг такой электронной коммерции, а корпоративные клиенты даже обязаны от них отказаться, чтобы не ставить под угрозу служебные компьютерные системы.
Активные объекты встраиваются в Web-страницы точно так же, как и пассивные элементы оформления (рисунки, видеофрагменты, звуковые клипы). Особенность активных объектов состоит в том, что они содержат в своем составе не только данные (текст, графику, музыку), но и программный код, то есть, являются по своей сути микропрограммами, работающими на компьютере клиента.
ª Никогда нельзя забывать, что Интернет—это среда, в которой для программ действует принцип презумпции небезопасности. Любая программа считается опасной до тех пор, пока квалифицированная экспертиза не докажет обратное.
Далее мы рассмотрим активные объекты и активные сценарии, такие, как апплеты Java, сценарии JavaScript, сценарии VBScript, элементы ActiveX. Но прежде чем приступать к их рассмотрению, следует сделать ряд важных замечаний о нецелесообразности их использования в электронной коммерции.
1. На ранних этапах развития коммерческой деятельности в Сети эти средства нашли широкое применение (пока не было более совершенных технологий), но сегодня их использование в коммерческой деятельности значительно сократилось. Добросовестные коммерсанты использовали эти объекты для создания аудиовизуальных эффектов оформления, но сегодня для этой цели есть более эффективные и безопасные средства. В то же время, недобросовестные предприниматели использовали (и используют) активные объекты и сценарии для получения дополнительной информации о пользователе и его компьютерной системе с целями, не имеющими ничего общего с обслуживанием. Как правило, собранные сведения об участниках коммерческой деятельности в Сети ложатся в классифицированные базы данных с последующей их перепродажей заинтересованным структурам, а также для негласного проведения “маркетинговых исследований” средствами, нарушающими права граждан.
2. Использовать активные объекты и активные сценарии в составе Web-страниц предприятий электронной коммерции достаточно бессмысленно по той причине, что информированный клиент все равно отключит возможность их работы посредством настройки своего броузера. Современные средства оформления Web-страниц позволяют успешно обходиться без подобных излишеств, и потому их использование негативно характеризует предпринимателя, как отставшего в развитии и не проявляющего заботу о потребителе.
3. Пользователям рекомендуется настроить средства просмотра Web-страниц таким образом, чтобы они предупреждали о наличии активных объектов и сценариев в составе просматриваемых ресурсов (рис. 10.6). При обнаружении активных объектов или сценариев целесообразно отказаться от коммерческого взаимодействия с данным сервером и найти другого поставщика, работающего более корректно.
Апплеты Java. Апплеты Java — это микропрограммы, написанные на языке Java и поставляемые в составе Web-страниц как встроенные объекты. После загрузки они работают на компьютере клиента под управлением его броузера, находятся во взаимодействии с пользователем и выполняют функции, предусмотренные автором Web-страницы. Использование языка Java для создания апплетов связано с особенностями, отличающими его от других языков программирования.
Языки программирования делятся на компилируемые и интерпретируемые. Программы, разработанные на компилируемых языках, таких, как C++, Pascal и др., проходят предварительную обработку (компиляцию), после чего превращаются в машинный код, напрямую работающий с процессором. Это делает их очень эффективными, но в определенном смысле оставляет без внешнего контроля.
Программы, разработанные на интерпретируемых языках программирования (классический пример — язык Basic), работают под управлением интерпретатора. Это делает их весьма медленными в работе и неудобными в транспортировке, но зато они машиннонезависимы. Поскольку такая программа представляется не машинным кодом, а обычным текстом, то она может работать на любом компьютере, имеющем соответствующий интерпретатор.
Создатели языка Java смогли сочетать в нем быстродействие, характерное для компилируемых языков, и машиннонезависимость, характерную для интерпретируемых языков программирования. Это достигнуто двухступенчатым процессом подготовки программы к исполнению. После ее написания происходит предварительная компиляция в некий промежуточный код, который обладает эффективностью машинного кода, но не связан ни с каким конкретным процессором или операционной системой. Работа программы на компьютере происходит под управлением интерпретатора, переводящего инструкции промежуточного кода в код конкретного процессора. Такой интерпретатор называется виртуальной машиной Java и существует для большинства компьютерных платформ и операционных систем. Поэтому один и тот же код Java может выполняться без каких-либо модификаций на самых разных компьютерах.
Как и любой программный код, код, созданный на языке Java, может быть сколь угодно вредоносным, но для создания Java-апплетов разрешается использовать не все средства языка. В частности, запрещены операции, связанные с записью данных на жесткий диск пользователя (как наиболее опасные). Контроль за тем, что реально содержится в Java-апплете, возложен на броузер. Он должен проверять каждую исполняемую инструкцию Java-апплета и блокировать те операции, которые представляют потенциальную опасность для компьютера клиента.
Тем не менее, вся история создания и развития броузеров всех типов за годы существования Java-апплетов представляется непрерывной чередой обнаружения и устранения уязвимостей в их системах защиты. Безопасных броузеров, в смысле полноценного контроля за работой Java-апплетов, история техники пока не знает. Поэтому все броузеры предоставляют пользователю средства для отключения приема этих активных объектов.
Если Java-апплеты не отключены, пользователь принимает на себя весь риск, связанный с запуском неизвестного кода на компьютере. Он может принять решение самостоятельно, если это личный компьютер. Для служебных компьютеров режим работы Java-апплетов определяется политикой предприятия, за которую отвечает системный администратор.
Сценарии JavaScript. Сценарии JavaScript — это фрагменты программного кода, написанные на интерпретируемом языке программирования JavaScript. Этот язык был введен компанией Netscape Communications для своих броузеров, начиная с броузера Netscape Navigator 2.0. Интерпретатором сценариев выступает сам броузер. Компания Microsoft, развивающая альтернативную технологию VBScript, сравнительно долго сопротивлялась поддержке сценариев JavaScript, но поскольку они быстро завоевали популярность, начиная с Internet Explorer 3 она тоже поддерживает это средство.
Сценарии JavaScript — это не активные объекты, как Java-апплеты, но это тоже рабочий код, поэтому их называют активными сценариями. Язык JavaScript можно условно рассматривать как “фирменное расширение” стандарта HTML. Операторы этого языка записываются в составе Web-страницы.
Назначение сценариев JavaScript несколько отличается от Java-апплетов. В то время как апплеты — это микропрограммы, работающие в отдельном окне, сценарии JavaScript работают в составе броузера и оказывают влияние на всю Web-страницу и на все окно броузера. Так, в частности, с помощью этого средства Web-страница может открывать новые окна броузера, управлять их размером, составом командных кнопок и т. п.
Угроза, которую представляют сценарии JavaScript, тоже несколько отличается от угрозы апплетов Java. Так, например, апплеты Java могут приводить к несанкционированным действиям на компьютере клиента, а сценарии JavaScript могут приводить к несанкционированному получению информации о клиенте. Здесь, как и в случае Java-апплетов, броузер должен стоять на страже интересов пользователя, но справляется он с этой задачей неудовлетворительно. Более того, положение с безопасностью сценариев JavaScript даже хуже, чем с безопасностью Java-апплетов. Это связано с тем, что Java-annneты представляют угрозу всей компьютерной системе, и потому при каждом обнаружении новой уязвимости производитель броузера спешит ее устранить и выпустить улучшенную версию своей программы. В случае сценариев JavaScript угроза общей безопасности меньше, а возможность неправомочного доступа серверов к частной информации клиентов рассматривают как не очень критичный недостаток. Поэтому в данном случае производители броузеров обычно не слишком спешат принимать меры к исправлению ошибок.
ª Уровень безопасности программного средства, имеющего уязвимость, резко снижается в момент опубликования сведений об ее обнаружении. На кратковременный период между опубликованием сведений об уязвимости и ее устранением приходится лавинообразный рост атак на систему защиты. Поэтому оперативность разработчиков программных средств в устранении каждой выявленной уязвимости имеет очень важное значение. Счет идет буквально на дни.
Сценарии VBScript. Про сценарии VBScript можно сказать все то же самое, что и про сценарии JavaScript, за единственным исключением, что эту технологию развивает компания Microsoft в своих броузерах Internet Explorer, и, кроме нее, никто не спешит ее использовать. Для авторов Web-страниц использование языка VBScript проще, чем JavaScript, поскольку он имеет свои корни в относительно простом языке Visual Basic. Однако применение таких сценариев в составе Web-страниц чревато тем, что заметная часть клиентов не сможет с ними работать, так как далеко не все используют броузеры от компании Microsoft.
С точки зрения безопасности, сценариям VBScript присущи все те же проблемы, о которых рассказано выше применительно к сценариям JavaScript.
Элементы ActiveX. Это еще одна технология, применение которой в электронной коммерции не очень желательно. Во-первых, она введена компанией Microsoft и поддерживается только компьютерами, работающими с операционными системами Windows (большой процент клиентов, работающих с иными операционными системами, теряется), а во-вторых, она еще менее безопасна, чем апплеты Java.
Как и апплеты Java, элементы ActiveX — это программные объекты, встраиваемые в состав Web-страниц. После загрузки они запускаются и работают на компьютере пользователя. Однако если в случае Java-апплетов на страже интересов пользователя стоит броузер, предотвращающий исполнение потенциально опасных операций, то за работой элементов ActiveX вообще нет никакого контроля.
Отсутствие рабочего контроля связано с иной моделью безопасности. Она основана на принципе пассивной безопасности. Предполагается, что за безопасность активного объекта должен отвечать его разработчик. Каждый объект ActiveX имеет электронную цифровую подпись. Он поставляется вместе с открытым ключом разработчика и сертификатом удостоверяющего центра. То есть, прежде чем произойдет запуск объекта ActiveX, броузер должен проверить наличие подписи и сертификата и выдать предупреждающий сигнал, если содержимое объекта кем-то изменено или сертификат разработчика отсутствует, не действителен или не может быть проверен (рис. 10.7). Если же с подписью и сертификатом все в порядке, объект будет работать на компьютере без какого-либо контроля, и, что именно он будет делать, знает только его создатель. Пользователю остается лишь полагаться на “доброе имя” разработчика и на то, что в аварийной ситуации он теоретически может знать, кому предъявлять претензии.
По понятным причинам использование элементов ActiveX при обслуживании клиентов средствами электронной коммерции совершенно недопустимо. Тем не менее, эту технологию широко используют как внутрифирменную. Внутри корпоративных сетей ее вполне можно использовать для связи между подразделениями предприятий, например между руководством и отделом реализации, между складом и группой приема заказов и т. п.
