![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]()
![]()
|
![]() |
приемы безопасного программирования веб-приложенийИтак, раскрываю секрет: допустим, хакер вводит заведомо несуществующее имя пользователя и пустой пароль. При этом в результате выборки из базы переменная $rpassword принимает пустое значение. А алгоритм шифрования паролей при помощи функции СУБД MySQL Password(), так же, впрочем, как и стандартный алгоритм Unix, при попытке шифрования пустого пароля возвращает пустое значение. В итоге - $password == $rpassword, условие выполняется и взломщик получает доступ к защищенной части приложения. Лечится это либо запрещением пустых паролей, либо, на мой взгляд, более правильный путь - вставкой следующего фрагмента кода: if (mysql_numrows($result) != 1) { Header("HTTP/1.0 401 Auth Required"); Header("WWW-authenticate: basic realm="My Realm""); exit;} То есть - проверкой наличия одного и только одного пользователя в базе. Ни больше, ни меньше. Точно такую же проверку на авторизацию стоит встроить и в скрипт admin2.php. По идее, если пользователь хороший человек - то он приходит к admin2.php через admin1.php, а значит, уже является авторизованным и никаких повторных вопросов ему не будет - браузер втихомолку передаст пароль. Если же нет - ну, тогда и поругаться не грех. Скажем, вывести ту же фразу "hacker? he-he...". К сожалению, не всегда удается воспользоваться алгоритмом авторизации через код 401 и приходится выполнять ее только средствами приложения. В общем случае модель такой авторизации будет следующей: Пользователь один раз авторизуется при помощи веб-формы и скрипта, который проверяет правильность имени и пароля. Остальные скрипты защищенной части приложения каким-нибудь образом проверяют факт авторизованности пользователя. Такая модель называется сессионной - после прохождения авторизации открывается так называемая "сессия", в течение которой пользователь имеет доступ к защищенной части системы. Сессия закрылась - доступ закрывается. На этом принципе, в частности, строится большинство www-чатов: пользователь может получить доступ к чату только после того, как пройдет процедуру входа. Основная сложность данной схемы заключается в том, что все скрипты защищенной части приложения каким-то образом должны знать о том, что пользователь, посылающий данные, успешно авторизовался. Рассмотрим несколько вариантов, как это можно сделать: Продолжение статьи: ч.1 Продолжение статьи: ч.2 Продолжение статьи: ч.3 Продолжение статьи: ч.4 Продолжение статьи: ч.5 Продолжение статьи: ч.6 Продолжение статьи: ч.7 Продолжение статьи: ч.8 Продолжение статьи: ч.9 Продолжение статьи: ч.10 Продолжение статьи: ч.11 Другие статьи по теме: - Php и web. кэширование- встроенные функции в php - PHP - система разработки скриптов - гостевая - это просто! - обзор сетевых функций php ![]() |
![]() |
![]() |
![]()
![]()
![]() ![]() ![]() |
![]() |
![]() |
2006-2025 © SMTI.RU Главная страница | Связаться с нами |