Лістинг 6.13. createauthdb.sql —создание бази даних, таблиці і двох користувачів.

create database auth;

use auth;

create table auth (

name varchar(10) not null

pass varchar(30) not null

primary key (name)

);

insert into auth values ('user', 'pass');

insert into auth values

( 'testuser', password('test123'));

grant select, insert, update, delete

on auth.*

to webauth@localhost

identified by 'webauth';

Шифрування паролів.Незалежно від того, де зберігаються паролі — в базі даних або у файлі — зберігання паролів у вигляді простого тексту зв'язане з невиправданим ризиком. Однонаправлений алгоритм хешування забезпечить додатковий захист при незначних додаткових витратах.

РНР-функция crypt() є однонаправленою криптографічною хэш-функцию. Прототип цієї функції такий:

string crypt (string str[, string salt])

Отримавши на вході рядок str, ця функція повертає псевдовипадковий рядок. Наприклад, якщо передати у функцію рядок "pass" і аргумент salt рівний "хх", то crypt() поверне рядок "xxkTlmYjlikoII". Цей рядок не може бути дешифрований і перетворений назад в "pass" навіть її творцем, тому на перший погляд рядок може і не здатися настільки вже корисним. Що робить функцію crypt() корисною, так це те, що результат цієї функції детермінований. При кожному виклику з одними і тими ж параметрами str і salt ця функція повертатиме один і той же результат.

Замість РНР-кода, такого як

if( $username == "user" && password == "pass" )

{ // Пароль збігається

}

можна скористатися таким кодом

if($username= 'user' && crypt($password,'хх')== 'xxkTlmYjlikoII')

{ // Пароль збігається

}

Нам не потрібно знати, як виглядав рядок "xxkTlmYjlikoH" перед використанням функції crypt(). Необхідно лише знати, чи збігається введений пароль тим паролем, для якого застосовувалася функція crypt().

Як уже згадувалося, жорстке кодування правильних імен і паролів відвідувачів - погана ідея. Для цього слід організувати окремий файл або базу даних. Якщо для зберігання даних аутентифікації використовується база даних MYSQL, можна скористатися РНР-функцией crypt() або MySQL-функцией PASSWORD(). результат цих функцій не збігається, але вони мають одне призначення. Обоє функції — crypt() і PASSWORD() — отримують рядок як аргумент і застосовують до поденного рядка алгоритм хешування, що не обертається.

Аби задіювати функцію PASSWORD() у лістингу 14.2 запит SQL слід переписати так:

select count (*) from auth where

name = '$name' and

pass = password('$password')

Цей запит порахує кількість рядків в таблиці auth, в яких значення поля name збігається з вмістом змінної $name, а поля pass - з результатом функції PASSWORD(), застосованою до значення змінної $password. Якщо ми заставляємо відвідувачів вибирати унікальні імена, результатом запиту може бути 0 або 1.

Захист безлічі сторінок.Захист більш ніж однієї сторінки за допомогою подібних сценаріїв трохи складніший. Оскільки в HTTP-протоколе немає механізму станів, то не існує автоматичного зв'язку або асоціації між послідовними запитами від одного і того ж відвідувача. Це ускладнює перенесення між сторінками введених користувачем даних, таких як дані аутентифікації.

Аби самостійно створити таку функціональність, потрібно буде включити частини лістингу 6.11 в кожну сторінку, яку необхідно захистити. За допомогою директив auto_prepend_file і auto_append_file необхідний файл можна автоматично вставити в початок (prepend) або в кінець (append) кожного файлу у вказаних каталогах.

Якщо скористатися таким підходом, то що станеться, коли користувач відкриє декілька сторінок на сайті? Недопустимо запрошувати пароль окремо для кожної сторінки, яку бажає проглянути користувач.

Можна включити введену користувачем інформацію в кожне гіперпосилання на сторінці. Оскільки користувачі можуть застосовувати пропуски або інші символи, запре­щенные в URL, слід звернутися до функції urlencode(), аби безпечно упакувати подібні символи.

З цим підходом зв'язані ще деякі проблеми. Оскільки дані аутентифікації будуть присутні в тій, що відправляється відвідувачеві Web-сторінці, захищені сторінки, які відвідав користувач, можуть бути проглянуті будь-якою людиною, що працює за тим же комп'ютером. Для цього досить клацнути на кнопці "Назад" у вікні браузеру і проглянути кэшированные копії сторінок або заглянути в історію відвідин сторінок. Пароль пересилається в браузер і назад з кожною запитаною або наданою сторінкою, що відбувається частіше, ніж це необхідно.

Вирішити проблему можна за допомогою двох механізмів — базової HTTP-аутентификации і підтримки сеансів. Базова аутентифікація дозволяє вирішити проблему кешування, але сервер все одно відправляє пароль Web-браузеру в кожному запиті. Управління сеансами дозволяє вирішити обоє проблеми. Спочатку розглянемо базову HTTP-аутентификацию, а управління сеансами освітлює далі.

Базова аутентифікація.На щастя, аутентифікація користувачів — це досить поширене завдання і існують можливості аутентифікації, вбудовані в HTTP-протокол. Сценарії і Web-серверы можуть запрошувати аутентифікацію в Web-браузера. Після цього Web-браузер повинен вивести на екран діалогове вікно або щось подібне і запитати у користувача необхідну інформацію.

Хоча Web-сервер запрошує нові деталі аутентифікації в кожному запиті користувача, Web-браузеру немає необхідності запрошувати цю інформацію для кожної сторінки. У загальному випадку браузер зберігає деталі аутентифікації, поки відкрито вікно браузеру, і автоматично відправляє їх без втручання з боку користувача.

Описана можливість HTTP-протокола називається базовою аутентифікацією. Ба­овую аутентифікацію можна включити засобами РНР або за допомогою Web-сервера, Apache і IIS. Далі розглядаються методи, що передбачають використання РНР.

Базова аутентифікація передає ім'я користувача і пароль у вигляді простого тексту і тому не особливо безпечна. Протокол HTTP 1.1 володіє безпечнішим методом, званим дайджест-аутентификацией (digest authentication). Цей метод використовує алгоритм хешування (як правило, MD5) для маскування деталей транзакції. Дайджест-аутентификация підтримується в багатьох Web-серверах, але не підтримується в значному числі браузерів. Дайджест-аутентификация підтримується в браузері Microsoft Internet Explorer починаючи з версії 5.0. Підтримка дайджест-аутентификации включена в Netscape Navigator версію 6.0.

На додаток до дуже слабкої підтримки в наборі доступних браузерів, дайджест-аутентификация до того ж і не дуже безпечна. І базова, і дайджест-аутентификация надають низький рівень захищеності. Жоден з цих методів не дає користувачеві гарантій, що він працює саме з тим комп'ютером, доступ до якого він планував отримати. Обоє методу дозволяють зломщикові повторити той же запит серверу. Оскільки базова аутентифікація передає пароль користувача у відкритому вигляді, будь-який зломщик, здатний перехоплювати пакети, може сымитировать запит користувача.

Базова аутентифікація надає низький рівень захисту, подібний тому, який забезпечується при підключенні по протоколу Telnet або FTP. Ці методи також передають паролі у вигляді простого тексту. Дайджест-аутентификация декілька безпечніша і шифрує паролі перед передачею. Використання протоколу SSL і цифрових сертифікатів дозволяє надійно захистити всі частини транзакцій в Web.

Проте в багатьох ситуаціях найбільш відповідним буде швидкий і відносно незахищений метод, такий як базова аутентифікація.

Базова аутентифікація дозволяє захистити іменовані області і вимагає від користувачів введення правильного імені і пароля. Області іменовані, тому на одному сервері може бути існувати безліч областей. Різні файли і каталоги на одному сервері можуть належати різним областям, кожна з яких захищена своїми наборами імен користувачів і паролів. Іменовані області дозволяють також згрупувати в одну область декілька каталогів на одному фізичному або віртуальному вузлі і захистити всю область одним паролем.

Використання базової аутентифікації в РНР.РНР-сценарии, в основному, можна назвати платформеними для кросу, але використання базової аутентифікації базується на змінних середовища, що встановлюються сервером. Сценарій HTTP-аутентификации повинен визначати типа сервера і поводитися відповідним чином залежно від того, чи виконується він як модуль Apache на сервері Apache або як ISAPI-модуль на сервері IIS. Показаний в лістингу 6.14 сценарій виконуватиметься на обох серверах.