Раздел: Документация
0 ... 45 46 47 48 49 50 51 ... 169 В заключение — ответы на некоторые интересные вопросы, которые позволят яснее выразить смысл данной статьи. Возможно, я сильно увлекся примерами в ущерб главной мысли. Еще диалоги из форума «клуба hackzone» Отправитель: REAn, January 13, 2000, 14:59:03 /195.133.82.ххх/: >И много ли найдется почт, где не спрашивают старый пароль при установке >нового. Увы, много. Да и необязательно менять пароль (нередко защи- щённый), достаточно изменить адрес форвардинга, секретный вопрос или резервный e-mail, которые крайне редко защищены. Тут и hot- mail.com, увы, не исключение. >да еще разрешены зловредные апплеты? Не в конкретном дело, хотя авторам почтовой WEB-систе-мы их всех быстро не выловить (есть ведь и недокументированные) без существенного ущерба для приходящих писем. В конце концов, можно просто дать в письме ссылку на якобы интересную страничку (которая содержит ловушку), и пользователь, щелкнувший по ссылке во время сеанса (или открывший ее в новом окне, как большинство из нас делает), рискует остаться без почтового ящика, практически независимо от типа службы (hotmail.com, netscape.net, webber.com и т. д.). Скажите, многие Web-интерфейсы предупреждали вас, что нельзя открывать другие сайты во время чтения писем? Проблема в том, что отсылка настроек при помощи форм опасна в принципе. Даже проверку местонахождения формы нетрудно обойти. Из почты - Отправитель: РомаМ. >-Не считаете же Вы возможным отказываться от использования новой идеи хпотому, что она >иебезопасна. Так бы и СЕТИ не было. Может, чем >подставлять тысячи пользователей mail.ru, стоило придумать, как упростить >им жизнь . а безопасные средства коммуникации рано или поздно появятся. 146 С рабочимипохоже, погорячился. С другой сторо- ны, кто бы эту статью читать стал? А безопасные средства уже давноНапример, тот же Java. Что стоит написать на нем пользовательский интерфейс для тех пользователей, которые желают безопасности и анонимности. Ведь, по сути, нашу почту читают все, кому не лень — от администраторов до провайдеров. Java дает прекрасные возможности отказаться от средств CGI и шифровать пересылаемую информацию, благодаря чему несанкционированная отсылка реэтов или подмена апплета пресекается в принципе средствами браузера, т.к. JA разрешено связываться только с сервером, откуда он пришел. Разместить же свой код на почтовом сервере злоумышленнику вряд ли удастся. SOT примерная реализация Пользователь загружает апплет. Пользуясь открытым ключом, тот высылает уникальный (на данный сеанс) случайный ключ и в дальнейшем весь обмен (включая логин и пароль пользователя) идет в зашифрованном, симметричном крпптоалгорптмиом виде. Никто, ни провайдер, ни администратор, ни пресловутое ФСБ не смогут установить даже логин пользователя. При желании можно (пользуясь возможностями Netscape LiveConnect, частичная поддержка которого уже введена и в IE) просматривать письма и в HTML-формате. И теги /скрипты/объекты в них можно разрешить, не так ли? Подделать аутентификацию теперь вряд ли возможно. 147 Глава 6 ПРОБЛЕМЫ ИНФОРМАЦИОННОГО ШПИОНАЖА  0 ... 45 46 47 48 49 50 51 ... 169
|
