Наш чат в Telegram для обмена идеями, проектами, мыслями, людьми в сфере ИТ г.Ростова-на-Дону: @it_rostov

Ставим пароль на страницу

Дмитрий Леонов

Итак, наша задача - установить пароль на доступ к некоторой странице. Начнем с самого примитивного способа, если можно так сказать, защиты - нескольких строчек на JavaScript:

var pass = prompt("Enter the Password:", "");
if (pass == null)  window.location = "wrong.html";
else if (pass.toLowerCase() == "wwvsfc")  
      window.location = "temp.html";
else  window.location = "wrong.html";

Ухищрения наподобие скрытия скрипта в отдельном файле с помощью конструкции <script src="security.js"></script> принципиально ничего не меняют.

Аналогичная система, реализованная на Java:

import java.applet.*;
import java.awt.*;
import java.net.*;
public class Password extends Applet{   TextField login, password;   
String Login = "login";   
String Password = "Password";   
public Password()   {   }   
public void init()   {      
Panel panel = new
Panel();      
panel.setLayout(new GridLayout(2,2));      
login = new TextField(20);      
password = new TextField(20);      
panel.add(new Label("Login:"));      
panel.add(login);      
panel.add(new Label("Password:"));      
panel.add(password);      
add(panel);      
add(new Button("Ok"));   }   
public boolean action(Event evt, Object obj)   
{      if(evt.target instanceof Button)      
{         String s;         
if(login.getText().equals(Login) && password.getText().equals(Password) )         
{            s = "http://www.hackzone.ru/articles/ok.html";         }         
else         {            s = "http://www.hackzone.ru/articles/bad.html";         }         
try         {            getAppletContext().showDocument(new URL(s));         }         
catch(Exception e)         {            password.setText(e.toString());         }         
return true;      }      return false;   }}

Включив этот апплет на страницу, можно получить нечто такое (во всех последующих примерах используются ok.html и bad.html):

Password check

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

Последнего недостатка лишено решение, основанное на использовании CGI. Простенький скрипт на Perl'е выглядит примерно так:

#!/usr/bin/perluse CGI qw(:standard);
$query = new CGI;$ok = 'ok.html';$address = 'bad.html';
$login = "login";$password = "password";
$l = $query->param("login");
$p = $query->param("password");
if(($p eq $password) && ($l eq $login)){  $address = $ok;}print $query->redirect($address);
Пример использования
Password check
Login:
Старый пароль:

Чтобы справиться с первым недостатком, можно динамически сформировать новую страницу на основе спрятанной где-то там внутри, не выдавая при этом URL.

Модифицированный код:

#!/usr/bin/perluse CGI qw(:standard);
$query = new CGI;
$ok = 'ok.html';
$address = 'bad.html';
$docroot = $ENV{'DOCUMENT_ROOT'};
$localpath = "/articles/";
$login = "login";$password = "password";
$l = $query->param("login");
$p = $query->param("password");
if(($p eq $password) && ($l eq $login)){  $address = $ok;}
print $query->header();
open (FL, $docroot.$localpath.$address);
while(<FL>){# Здесь заодно можно на лету модифицировать html-код# Зачем ? Ну мало ли... :)  
		print $_;}
close (FL);
Пример использования:
Password check
Login:
Старый пароль:

Как видно, URL файла уже не светится, правда ценой SSI (впрочем, их как раз можно отлавливать при выводе и обрабатывать вручную). Но и здесь остается теоретическая возможность угадывания URL, при этом не надо забывать, что медвежью услугу могут сослужить всевозможные картинки, включаемые в страницы - при использовании относительных путей, конечно.

Наконец, наиболее надежный способ установки пароля на доступ - это воспользоваться средствами сервера - не зря ж их люди делали, в конце концов. Остановлюсь на двух - Апаче как самом популярном и IIS кактоже популярном :)

С IIS все совсем просто - защита осуществляется средствами NTFS, что, конечно, несколько ограничивает возможности не-администраторов сервера. Идея следующая: у пользователя IUSR_xxxx, под аккаунтомкоторого по умолчанию работают все посетители узла, отбирается доступ к желаемому файлу/каталогу. После чего доступ к этим файлам будут иметь только те пользователи, для которых это явно указано в Properties→Security. Понятно, что их гораздо удобнее объединять в группы.

Здесь есть пара тонкостей:

  1. Указанным пользователям должно быть дано право Logon locally (Policies->User Rights в User Manager'е).
  2. Если не выбрать в настройках WWW service Basic authentication (Clear Text), внутрь будут пропущены только пользователи Internet Explorer'а.

В Apache все делается несколько иначе.

Защита ставится на уровне каталогов. Соответствующие директивы могут быть помещены как в общий конфигурационный файл php.ini, так и в файлы .htaccess. Набор директив в обоих случаях одинаков, а для большинства людей, арендующих место под сайт/страницу на чужом сервере, первый вариант недоступен.

Итак, вы создаете в каталоге, доступ к которому планируется ограничить, файл .htaccess, после чего вставляете в него следующие директивы:

AuthType тип контроля - обычно используется Basic.

AuthName имя - задает имя области, в которой действительны имена и пароли пользователей. Это то самое имя, которое браузер показывает в диалоге ввода пароля. Задав одно такое имя для разных каталогов, можете сэкономить пользователям время по вводу лишнего пароля.

AuthGroupFile имя - задает имя файла, в котором хранятся имена групп и их членов. Его формат:
group1: member1 member2 ...
group2: member3 member4 ...

AuthUserFile имя - задает имя файла с паролями. По большому счету для его формирования надо воспользоваться утилитой htpasswd из поставки Apache. Но по крайней мере для некоторых версий сервера этот формат такой:
user1:passwordhash1
user2:passwordhash2

Passwordhash вполне можно получить стандартной функцией Perl'а:
$hash=crypt($pass,$salt);
где $pass - пароль, $salt - строка из двух символов, участвующая в формировании хэша.

Так что вполне можно автоматизировать процесс добавления новых пользователей, смену паролей через html-формы и т.д.

require user user1 user2 и require group user1 user2 позволяют указать, какие пользователи и группы получат доступ к данному каталогу.

require valid-user разрешает доступ всем пользователям, указанным в файле паролей системы.

<Limit method1 method2 ...> ...</Limit>, где methodi определяет HTTP-метод. Например, <Limit GET POST> ограничивает применение вложенных в неедиректив случаями использования методов GET и POST (обычно этого более чем достаточно). Вложенными могут быть директивы require, order, allow и deny.

Еще пара полезных директив - deny и allow - соответственно запрещения и разрешения доступа. Применяются примерно так:
deny from all
allow from 192.168

По умолчанию сначала выполняются все deny, потом все allow, так что allow from all разрешит доступ всем пользователям, невзирая ни на какие deny. Порядок можно изменить директивой order: order allow, deny.

deny from all отлично сочетается со вторым способом защиты страниц через CGI, именно этой директивой лучше всего прикрывать всякие пароли к гостевым книгам и т.д. При попытке обращения к страницам из этого каталога пользователь получит сообщение о несуществующей странице.

Кстати, тут между делом демонстрируется самостоятельная обработка ошибок: в данном случае - код 403, Forbidden. Аналогично обрабатывается и всеми любимая 404 - Not Found, и 401 - Unauthorized. Для этого достаточно добавить в .htaccess директиву ErrorDocument код url:
ErrorDocument 404 /cgi-bin/bad.pl
ErrorDocument 403 /cgi-bin/badaccess.pl
ErrorDocument 401 /cgi-bin/badaccess.pl

Подробнее о кодах ошибок можно почитать здесь

Все, что делает скрипт - формирует сообщение об ошибке, используя переменную окружения REQUEST_URI, так что всместо него вполне можно просто указать какую-нибудь подходящую страницу.

Для заключительного примера используем файл .htaccess со следующим содержимым:

AuthType BasicAuthName TestAuthGroupFile /my/local/path/tgroupAuthUserFile /my/local/path/tuser<Limit GET POST>require group test</Limit>

В файле tgroup всего одна строчка - test: login test, в файле tuser - зашифрованные пароли для login (password) и test (test). Обратите внимание, при повторном обращении к этой странице браузер понимает, что только что обращался к этой области, и не утруждает пользователялишним запросом пароля.

Таков вкратце минимальный набор сведений, необходимых для защиты web-страниц. Как показывает практика, более-менее доверять стоит лишь решениям, основанным на средствах, предоставляемых сервером (и то до тех пор, пока в сервере не обнаружится очередная дырка), так что если есть возможность, лучше выбирать именно их.

Поробнее об установке пароля с помощью файла .htaccess.


.