«Плюшки» по вкусу

Либо сценарий выполняется на клиенте в браузере, либо он выполняется на сервере для динамической генерации страниц Web.

Наверняка многие из вас тем или иным образом участвуют в создании узла Web компании. Когда я писал о сценариях для генерации домашних страниц порталов Intranet в предыдущих выпусках рубрики, мне пришло в голову, что сценарии стоило бы рассмотреть со стороны клиента. Даже если обслуживание сервера Web ложится на вас тяжким бременем и вам и так хватает хлопот по противодействию вирусам и переходу на Windows 2000, тем не менее включение одного-двух сценариев в ваши корпоративные страницы может значительно расширить их функциональность при весьма небольших затратах времени.

В наши дни даже порталы Intranet должны предусматривать возможность настройки в соответствии с предпочтениями индивидуальных пользователей, не так ли? Чтобы пользователь мог настраивать домашнюю страницу портала Intranet точно так же, как домашнюю страницу MSN компании Microsoft (хорошо, хорошо, не точно так же, но похоже), все, что требуется, — это весьма небольшой JavaScript.

Я не стану утомлять вас подробностями (соответствующий код вы можете найти на моем сервере Web по адресу: http://www.smallofficetech.com), но общий принцип состоит в задействовании «плюшек» (cookies) для хранения предпочтений каждого пользователя в отношении конкретных частей домашней страницы Intranet, чтобы они могли их видеть в определенном порядке. Использовать «плюшки» с JavaScript много проще, чем создавать базу данных на сервере Web для хранения мандатов и предпочтений пользователей. И это еще одна возможность применения сценариев для получения полезных результатов при нехватке времени.

Злоупотребление «плюшками»

Комментарий редактора. Конечно, «плюшки» ставят множество вопросов с точки зрения защиты. Однако по большей части скромные «плюшки» становятся жертвой необоснованных слухов и непонимания того, что они могут, а что не могут делать. Любой специалист может представить себе множество ситуаций, когда использование «плюшек» приносит несомненную пользу в среде Intranet. Как бы то ни было, опасения в отношении поступающих извне «плюшек» имеют под собой определенные основания, особенно если эти «плюшки» являются постоянными (т. е. когда их срок годности не заканчивается с текущим сеансом). Ниже мы приводим заметку на эту тему специалиста по защите Ричарда М. Смита (подробности можно найти на его сервере Web по адресу: http://www.tiac.net/users/smiths/).

С тех самых пор, как Netscape изобрела «плюшки» для браузеров Web, сторонники их применения всегда утверждали, что они являются анонимными, и их невозможно соотнести с какой-либо персональной информацией, если только кто-нибудь не пожелает ее предоставить.

На самом деле, «плюшки» браузеров можно увязать с адресами электронной почты без ведома их владельцев. Эта техника опирается на дыру в защите браузеров Internet Explorer компании Microsoft и Navigator компании Netscape.

Она может, например, использоваться компанией баннерной рекламы для установления соответствия между адресом электронной почты и «анонимным» профилем, созданным для данного лица, когда он путешествовал по Web. Как только соответствие между адресом электронной почты и профилем установлено, компания баннерной рекламы может предоставлять услугу рекламодателям заказных объявлений в виде рассылки «сорных» сообщений электронной почты. Такие объявления могут базироваться на профилях, созданных на основании посещений серверов Web. Кроме того, компании баннерной рекламы могут предлагать услугу рассылки «сорных» сообщений электронной почты тем, кто посещает конкретный сервер Web. Эта последняя услуга делает серфинг Web намного менее конфиденциальным занятием.

Установление соответствия между «плюшкой» и адресом электронной почты осуществляется с помощью сообщения электронной почты. Кроме того, сообщение должно иметь формат HTML, чтобы получившее его лицо было вынуждено использовать HTML-совместимую программу чтения электронной почты. Большинство из подобных программ сегодня — такие, как Outlook, Outlook Express, Netscape Messenger и Eudora, — понимают HTML. Системы электронной почты на базе Web, например Hotmail и Yahoo Mail, также понимают HTML.

Основной метод установления соответствия между «плюшкой» и адресом состоит во включении в HTML-сообщение электронной почты изображения, загружаемого с сервера Web, принадлежащего компании баннерной рекламы. Эта графика определяется с помощью стандартного HTML-тега IMG. Например, тег IMG приводит к загрузки графического файла по имени SYNC.GIF с сервера, принадлежащего MyBannerAds.com (вымышленная компания):

.

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

Кроме того, если «плюшки» в браузере Web не блокированы и «плюшка» для MyBannerAds.com присутствует на компьютере, то она будет послана на http://www.mybannerads.com вместе с запросом HTTP GET на файл SYNC.GIF. Это может показаться удивительным, потому что большинство людей считают, что только страницы Web используют «плюшки». Однако ввиду того, что браузеры Web задействуются для отображений HTML-сообщений электронной почты, «плюшки» могут также посылаться во время чтения электронных сообщений. В этом и состоит дыра в защите.

Таким образом, загрузка графики приводит к отправке «плюшки» на MyBannerAds.com, но как она увязывается с адресом электронной почты? Ответ очень прост. Строка запроса URL на файл SYNC.GIF может содержать в качестве параметра адрес электронной почты, например:

.

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

В окончательном виде запрос HTTP GET для получения SYNC.GIF будет выглядеть в Outlook приблизительно так:

GET/sync.gif?e-mail=john@doe.com HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 
(compatible; MSIE 5.0; Windows 98; DigExt)
Host: www.mybannerads.com
Connection: Keep-Alive
Cookie: id=943977050

В Netscape Messenger запрос GET будет выглядеть следующим образом:

GET/sync.gif?e-mail=john@doe.com 
HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.7 [en] (Win98; I)
Host: www.mybannerads.com
Accept: image/gif, 
image/x-xbitmap, image/jpeg, image/pjpeg, image/png
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: 
iso-8859-1,*,utf-8
Cookie: id=c643640a

В результате запросы GET из Outlook и Messenger содержат и адрес электронной почты и «плюшку». При обработке запроса GET сервером MyBannerAds, он сначала извлекает из «плюшки» идентификатор пользователя и просматривает свою базу «анонимных» профилей путешественников по Web. Найдя искомый профиль, он извлекает адрес электронной почты из строки запроса URL, и в результате когда-то «анонимный» профиль превращается в «идентифицированный».

Но где же MyBannerAds добывает адреса электронной почты для рассылки сообщений с файлом SYNC.GIF? Ответ очень прост: она «арендует» адреса электронной почты. Точнее говоря, она арендует место в рассылаемых «сорных» сообщениях. Теги IMG занимают обычно менее 100 байт, так что они без труда могут быть включены в сообщения, рассылаемые в рамках рекламной кампании с использованием HTML-сообщений электронной почты.

Другой любопытный вопрос — что пользователи видят на экране на месте файла SYNC.GIF? Ответ — ничего. Файл GIF может представлять собой изображение размером 1*1 пиксел и таким образом быть полностью невидим. Практика включения невидимых изображений в «сорные» сообщения получила весьма широкое распространение, она используется для установления факта чтения «сорной» почты.

Я называю эти изображения 1*1 пиксел в формате GIF «жучками Web». Они также называются «пустыми GIF» и «невидимыми пикселами».

Эти «жучки Web» очень похожи на тег IMG для файла SYNC.GIF, используемого для синхронизации «плюшки» с адресом электронной почты. Единственная разница состоит в том, что «жучки Web» возвращаются назад в компанию, рассылающую сообщения электронной почты, а не в компанию, занимающуюся баннерной рекламой. Это означает, что компания по рассылке электронной рекламы имеет готовую технологию для установления соответствия между «плюшками» и адресами электронной почты. Единственное изменение, которое им требуется внести, — это указать другое имя сервера в качестве URL.

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

Этот подход оказывается еще проще, если компания баннерной рекламы сама занимается рассылкой сообщений электронной почты.

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

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