Безшумен php регистър за удостоверяване. Създаване на база данни

Ограничаването на достъпа до всяка област на сайта обикновено изглежда така
монотонен: всеки потребител получава потребителско име и парола или той самият
избира ги, като за влизане в защитената част на сайта те трябва да бъдат въведени. От техническа гледна точка, за да проверят паролата, която използват
различни методи. Може да се използва HTML формуляр за въвеждане на потребителско име и парола.
В този случай паролата се изпраща на сървъра в чист текст в POST заявката.
Това е неприемливо, ако потребителят е местен, когато е възможно
с помощта на снифър. За решаването на този проблем е изобретен метод
удостоверяване с помощта на хешове, при които паролата не се предава, а
хеш низ се предава, в зависимост от паролата, някои еднократно
параметър и евентуално от някои други параметри. Този метод също е
наречен предизвикателство/отговор, защото при използването му клиентът
получава заявка с еднократен параметър и изпраща отговор, съдържащ хеша. На ниво протокол HTTP 1.1 удостоверяването с помощта на
Основно, което е нищо по-добра употреба HTML форми и Digest, които
ще го разгледаме подробно.

Когато използвате метода Digest, както вече споменахме, паролата
не се предава и не може да се надуши, но има и друга страна
проблеми. За да провери паролата, сървърът трябва да изчисли
отговор и го сравнете с отговора на клиента, следователно сървърът трябва
съхранете паролата или зависещите от нея данни, необходими за
преминаване на удостоверяване. От това следва, че лице, получило права
за четене на акаунти (например чрез SQL инжекция), ще можете да получите
достъп до страници, защитени с метода Digest. При използване на метода
Основно, възможно е да съхранявате хешове вместо пароли, което не ви позволява да повишавате права,
след като прочетете тези хешове (ще видим по-долу, че Digest може също да съхранява хешове,
но такива, че знанията им да са достатъчни за изчисляване на отговора). По този начин сме изправени пред дилема: или нашата парола ще бъде проучена,
или ще го получат чрез уеб уязвимост, която някой определено ще открие,
защото който търси винаги намира. Има метод за удостоверяване без
И двата недостатъка са методът за удостоверяване с публичен ключ:
необходими за проверка публичен ключ, и да премине проверката - секрет,
обаче HTTP 1.1 не предоставя такъв метод. RFC 2069
препоръчва използването на SSL, ако сигурността е толкова важна. Само предаването на паролата е защитено и съдържанието не е криптирано, така че
че няма смисъл да се защитават ресурси с този метод, откъдето е потребителят
получава секретна информация. Те изискват SSL. И има смисъл
защитите, например, форум или качване на съдържание в уебсайт. Така че, ако хостингът не поддържа SSL, и удостоверяването трябва
за да сме сигурни, ще използваме Дайджест. Apache предоставя модула mod_digest. За да го използвате
в конфигурацията (или в .htaccess) пишем:

AuthType Digest
AuthUserFile
AuthName
Изискване valid_user

Потребителските файлове се създават от помощната програма
htdigest. По едно време имаше съобщения за mod_digest, че е уязвим, така че
Може би там ще се появят други проблеми. Освен това, когато
Опитах се да го използвам у дома, получих грешка
500 Вътрешна грешка на сървъра. Освен това, ако трябва да се извърши добавяне на акаунти
автоматично и трябва да са много, трябва
съхранявани не в конфигурацията на Apache, а в MySQL. Решение -
използвайте PHP. PHP няма вградена поддръжка за това
метод, така че ще трябва да се приложи. За да направите това, трябва да учите
този метод в детайли. Нека веднага да отбележа, че информацията, дадена в тази статия
внедряването работи само на Apache, тъй като пълен достъп до заглавките
заявка (функция apache_request_headers) работи само в Apache, но на
може да не е достъпно на други сървъри. Трябва само да четем
Заглавка за оторизация.

Описание на метода

Пълното описание на метода може да се прочете в RFC 2069 и ако
Накратко, методът работи така. Когато сървърът получи заявка, свързана със защитената зона,
извежда грешка 401 Изисква се оторизация и заглавка на заявката
удостоверяване от този тип:

WWW-Authenticate: Digest realm="сигурна зона", nonce="123456123456"

realm е името на защитената зона, а nonce е еднократна употреба
значение. Има и незадължителни параметри, които ще обсъдим
ние няма. Клиентът повтаря заявката, като добавя заглавка като тази:

Упълномощаване: Digest realm="сигурна зона", потребителско име="123", uri="/index.php", nonce="123456123456", response="1234567890abcdef1234567890abcdef"

Параметърът uri трябва да съвпада с URI в заявката, а отговорът е
отговорът, който се изчислява по следния начин:

отговор = H(H(A1) + ":" + nonce + ":" + H(A2))
H - хеш функция, по подразбиране MD5
A1 = вход + ":" + област + ":" + парола
A2 = метод на заявка + ":" + URI
Методът на заявка е GET, POST и т.н.

Както виждаме, A1 не зависи нито от заявката, нито от еднократната
стойности, така че сървърът може да съхранява не парола, а
H(A1). Точно така е имплементирано в mod_digest в Apache.
Същите данни обаче са достатъчни за клиента. Нападателят, като е получил
този хеш може да изчисли отговора с помощта на горните формули и
генериране на HTTP заявка, например с помощта на програмата
AccessDriver и неговия HTTP инструмент
Дебъгер. Този процес ще бъде показан по-подробно по-долу. Сървърът трябва да провери дали стойността е еднократна
този, който е бил издаден преди това на клиента и дали е просрочен.
Ако отговорът съвпада с параметъра nonce, но със стойността на този параметър
не е от значение, описаният по-горе отговор с код 401 се издава само защото
разликата е, че параметърът се добавя към заглавката WWW-Authenticate
stale=true, което показва, че достъпът е отказан само поради тази причина,
и трябва да опита отново, без да пита потребителя нова парола. Това, IMHO, е неудобно, защото ако възникне такава ситуация
когато прави POST или PUT заявка с голям блок от данни, клиентът ще трябва
предавайте всички данни два пъти. За да се избегне това, стандартът предвижда
Заглавие на информация за удостоверяване, в което сървърът може да отговори
успешна заявка за съобщаване на клиента на следващия nonce.
Синтаксисът е същият като WWW-Authenticate, с изключение на nonce
се заменя със nextnonce. Въпреки това, съдейки по резултатите от моята
експерименти, Opera игнорира това заглавие. Друго решение: според
RFC 2068 (HTTP/1.1), сървърът може да отговори преди заявката да завърши,
така че клиентът да прекъсва ненужния трансфер на данни, но в Apache+PHP това
не се изпълнява, тъй като скриптът започва да се изпълнява едва след
как Apache ще получи напълно и анализира заявката.

Съхраняване на данни между заявките

Има един тънък момент в прилагането на метода предизвикателство/отговор в PHP.
Еднократен параметър се генерира и издава на клиента в един отговор и
се проверява в друга сесия на скрипта.
Тоест, трябва да бъде запазен от едно извикване на скрипт в друго и за това ще трябва да го направите
използвайте файлове или база данни. Моят пример използва файлове с име
съответстващи на еднократни стойности, а самите файлове съдържат
IP адреси на клиентите, на които се издават. Колекцията не е реализирана в примера
боклук: трябва периодично да изтривате стари файлове.

Разбор на код

Този скрипт проверява само паролата и работи независимо от
Влизам В зависимост от успеха на проверката се дават прости отговори.