приемы безопасного программирования веб-приложений

Итак, раскрываю секрет: допустим, хакер вводит заведомо несуществующее имя пользователя и пустой пароль. При этом в результате выборки из базы переменная $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
- приемы безопасного программирования веб-приложений
- 21 ошибка программиста php
- встроенные функции в php

Другие голосования

Приглашаем Вас обменяться кнопочками! Обращайтесь к администратору.

• Как выбрать браузер
• Средства структурного анализа и проектирования систем
• Классификация case-средств
• Case-технология проектирования программного обеспечения информационных систем
• Технология intranet
• Технологии Internet
• Средства доступа к базам данных
• Средства быстрой разработки прикладных программ
• Объектно-ориентированный подход к созданию программных средств
• Этапы проектирования при разработке программного продукта