Защита более чем одной страницы с помощью сценариев наподобие рассмотренных ранее немного сложнее. Поскольку в HTTP-протоколе отсутствует механизм поддержки состояний, то не существует автоматической связи или ассоциации между последовательными запросами, поступающими от одного и того же посетителя. Это усложняет перенос введенных пользователей данных, таких как данные аутентификации, между страницами.
Наиболее простой способ защиты нескольких страниц — использование механизмов контроля доступа, предоставляемых веб-сервером.
Чтобы самостоятельно создать такие функциональные возможности, придется включитьчасти листинга secret.php в код каждой страницы, которую необходимо защитить. С помощью директив auto_prepend_file и auto_append_file требуемый файл можно автоматически вставить в начало (prepend) или конец (append) каждого файла в указанных каталогах. Использование упомянутых директив обсуждалось ЗДЕСЬ.
Что происходит, когда пользователь открывает несколько страниц сайта, если воспользоваться таким подходом? Понятно, что недопустимо запрашивать пароль отдельно для каждой страницы, которую желает просмотреть пользователь.
Введенную пользователем информацию можно было бы включить в каждую гиперссылку на странице. Поскольку пользователи могут указывать проблемы или другие символы, применение которых запрещено в Интернет-адресах, следует обратиться к функции urlencode(), выполняющей безопасное кодирование подобных символов.
Однако с этим подходом связаны еще некоторые проблемы. Поскольку данные аутентификации будут присутствовать в отправляемых посетителю веб-страницах, защищенные страницы, которые посетил пользователь, могут быть просмотрены любым человеком, работающим за тем же компьютером. Для этого достаточно просмотреть кэшированные копии страниц или заглянуть в список посещенных страниц браузера. Поскольку пароль пересылается в браузер и обратно вместе с каждой запрошенной или предоставленной страницей, чувствительная информация передается чаще, чем это необходимо.
Решить проблему можно с помощью двух механизмов — базовой HTTP-аутентификации и поддержки сеансов. Базовая аутентификация позволяет решить проблему кэширования, но сервер все равно отправляет пароль веб-браузеру в каждом вопросе. Управление сеансами позволяет решить обе проблемы. Сначала мы рассмотрим базовую HTTP-аутентификацию, а затем подробно исследуем управление сеансами.
Базовая аутентификация
Аутентификация пользователей — это достаточно распространенная задача, и существуют возможности аутентификации, встроенные в протокол HTTP. Сценарии и веб-серверы могут запрашивать аутентификацию у веб-браузера. После этого веб-браузер должен вывести на экран диалоговое окно или нечто подобное и запросить у пользователя необходимую информацию.
Хотя веб-сервер запрашивает новые сведения аутентификации в каждом запросе пользователя, веб-браузеру нет необходимости запрашивать эту информацию для каждой страницы. В общем случае браузер хранит сведения аутентификации до тех пор, пока открыто его окно, и автоматически отправляет их без вмешательства со стороны пользователя.
Это свойство протокола HTTP называется базовой аутентификацией. Базовую аутентификацию можно включить средствами PHP или с помощью механизмов, встроенных в веб-сервер.
базовая аутентификация передает имя пользователя и пароль в виде открытого текста и поэтому не особо безопасна. Протокол HTTP1.1 предоставляет более безопасный метод, называемый аутентификацией с помощью дайджеста. Этот метод использует алгоритм хеширования (как правило, MD5) для сокрытия подробностей выполнения транзакции. Аутентификация с помощью дайджеста поддерживается многими веб-серверами и большинством современных браузеров. К сожалению, она не поддерживается многими устаревшими браузерами, которые все еще находятся в употреблении.
В дополнение к очень слабой поддержке в наборе доступных браузеров, аутентификация с помощью дайджеста к тому же и не очень-то безопасна. И базовая, и дайджест-аутентификация обеспечивает низкий уровень безопасности. Ни один из этих методов не дает пользователю гарантий, что он работает именно с тем компьютером, доступ к которому он планировал получить. Оба метода позволяют взломщику повторить тот же запрос серверу. Поскольку базовая аутентификация передает пароль пользователя в открытом виде, любой взломщик, способный перехватить пакеты, может сымитировать любой запрос пользователя.
Базовая аутентификация обеспечивает (низкий) уровень безопасности, подобный тому, который обеспечивается при подключении к протоколу Telnet или FTP. Эти методы также передают пароли в виде простого текста. Аутентификация с помощью дайджеста несколько более безопасна, поскольку она шифрует пароли перед передачей. Комбинация базовой аутентификации с протоколом SSL и цифровыми сертификатами позволяет надежно защитить все части транзакции в веб.
Методы надежной защиты будут рассматриваться далее. Однако во многих ситуациях наиболее подходящим будет быстрый и относительно незащищенный метод, такой как базовая аутентификация.
Базовая аутентификация позволяет защитить именованные области и требует от пользователей ввода правильного имени и пароля. Ввиду того, что области именованные, на одном сервере может существовать множество областей. Различные файлы и каталоги на одном сервере могут принадлежать разным областям, каждая из которых защищена своими наборами имен пользователей и паролей. Именованные области позволяют также сгруппировать в одну область несколько каталогов на одном физическом или виртуальном хосте и защитить всю область одним паролем.
Использование базовой аутентификации в PHP
В общем случае PHP-сценарии являются кросс-платформенными, но в основе использования базовой аутентификации лежат переменные среды, устанавливаемые сервером. Сценарий HTTP-аутентификации должен определить тип серверв и вести себя соответствующим образом в зависимости от того, выполняется он как модуль Apache или как ISAPI-модуль на сервере IIS. Показанный ниже сценарий будет выполняться на обоих серверах.
http.php — базовая аутентификация средствами PHP
<?php
// Если используется сервер ISS, потребуется установить переменные среды
if (substr ($SERVER_SOFTWARE, 0, 9) == 'Microsoft' &&
!isset($PHP_AUTH_USER) &&
!isset($PHP_AUTH_PW) &&
substr($HTTP_AUTHORIZATION, 0, 6) == 'Basic'
)
{
list($PHP_AUTH_USER, $PHP_AUTH_PW) =
explode(':', base64_decode(substr($HTTP_AUHORIZATION, 6)));
}
// Заменим этот оператор if запросом к базе данных или чем-то подобным
if ($PHP_AUTH_USER != 'user' || $PHP_AUTH_PW !='pass')
{
// Посетитель еще предоставил детали либо его имя пользователя и пароль некоррктны
header( 'WWW-Authenticate: Basic realm="Realm-Name"');
if(substr ($SERVER_SOFTWARE, 0, 9) == 'Microsoft')
header('Status: 401 Unauthorized');
else
header('HTTP/1.0 401 Unauthorized');
echo '<h1>Покиньте эту страницу!</h1>';
echo 'Вам не разрешено просматривать данный ресурс.';
}
else
{
// Посетитель предоставил корректную информацию
echo '<h1>Вы на месте!</h1>';
echo '<p>Добро пожаловать! Вы попали на секретную страницу.</p> ';
}
?>
Если пользователь не передал данных аутентификации, ему запрос на аутентификацию. Если пользователь предоставил неправильную информацию, для него отображается сообщение об отказе в доступе. Если же пользователь предоставил соответствующую пару имя-пароль, он увидит содержимое страницы.
Интерфейс данного примера несколько отличается от интерфейса предыдущих примеров. Мы не создаем HTTP-форму для ввода имени и пароля. Диалоговое окно для аутентификации выведет браузер пользователя. Некоторые считают это улучшением, другие предпочитают иметь полный контроль над визуальными аспектами интерфейса. На рисунке показано диалоговое окно входа, которое выводит браузер Internet Explorer.
Поскольку аутентификация поддерживается встоенными возможностями браузеров, последние демонстрируют некоторую осторожность в обработке неудачных попыток аутентификации. Internet Explorer предоставляет пользователю три попытки для аутентификации, и если все они оказываются неудачными, выводят сообщение об отказе в доступе.
Как и код из secret.php и secretdb.php, код данного примера можно поместить во все страницы, которые требуется защитить, или автоматически вставить его в начало каждого файла в каталоге.
Комментарии(0)
Для добавления комментариев надо войти в систему и авторизоватьсяКомментирование статей доступно только для зарегистрированных пользователей:Зарегистрироваться