| Каталог документации / Раздел "Web мастеру, CGI, Perl, PHP, Apache" / Оглавление документа |
| |
|
![[W3C]](i/w3c_home.gif){kind=small}
Вопросы и ответы по безопасности в 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 ([email protected])
Перевод - Дмитрий Громов
Last modified: Thu Apr 16 10:39:53 EST 1998
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |