alhames.ru
Так вот, я вновь вернулся к этому вопросу =)

Порылся по интернету, в итоге ориентируясь на советы собрал вот такой вот код:
читать дальше

Собственно, какие ошибки я тут допустил и как их избежать?
Что еще можно дополнить?
+ по ходу кода оставил еще несколько вопросов.

P.S. Хотел изначально весь алгоритм выложить ввиде блок-схемы, но понял что это займет черезчур много времени.
P.P.S. Касательно передачи идентификатора сессии через get-запросы, то думаю что лучше вообще этого не делать, так как черезчур легко украсть.


@темы: Безопасность, PHP

Комментарии
10.08.2009 в 21:19

Всё будет Кока-Кола.
Рекомендую сделать здержку если авторизация не удалась. И зачем привязка к ip?
10.08.2009 в 21:39

There I was on a July morning, Looking for love


Ну и какого ? Если найдена запись в БД, ты возвращаешь FALSE. А потом внизу проверка, где для авторизации нужен TRUE. Зачем тут ? Вроде нужно

Или я что-то недосмотрел ?
10.08.2009 в 22:19

Всё будет Кока-Кола.
SpiritEagle ну вы и наплодили белых окошек. )
Кстати насчет запросов, наверное лучше уж использовать mysql_result. )
10.08.2009 в 22:46

alhames.ru
Джей Ди
Рекомендую сделать здержку если авторизация не удалась.
В каком плане задержку? Чтобы с одного ip можно было посылать запросы с интервалом не менее числа n?

Рекомендую сделать здержку если авторизация не удалась.
В случае кражи сессии если попытаться зайти с другово ip - сессия уничтожится.. Думаю будет очень полезно.

лучше уж использовать mysql_result
Ну в данном случае - да, но помимо id вероятно потребуются и другии поля - тут я просто упростил до мксимума.

SpiritEagle
Ну и какого ?
Это опечатка) Я сначала написал mysql_num_rows($sql) > 0, потом подумал, что число строк по идеи должно равняться 1, т.к. LIMIT 1, а вот нолик исправить забыл).


Я имел ввиду не синтаксические ошибки - их я и сам найду. А именно ошибки в логике алгоритма.
Ну и:
1. нужно ли проверять браузер при старте сессии? по идеи если хранить мд5-хэш в куках, то при краже кук он не поможет..
2. Случаи с ошибками - как их обрабатывать? И как уведомлять пользователя об ошибке?
Самый наверное банальный вариант - это создать отдельную переменную, инициалировав ее нулем, и в случае ошибки присвоить ей номер. А по номеру ниже уже обрабатывать..
3. И, собственно, самое главное - а как именно вообще можно украсть сессию?
Я лишь смутно знаю, что какой-то там троян может скопировать инфу из кук и отослать куда-либо - от этого я не спасусь. А как еще можно?
10.08.2009 в 22:55

Всё будет Кока-Кола.
alhames как делаю я:

а) При авторизации происходит задержка - исключает возможность брутфорса, пользователь не заметит 500 мс, а бот поляжет.
б) В случае успешной авторизации в куки закидывается логин и специальный ключ (длинная строка никак не зависящая от пароля), далее пара ключ ип заносится в базу.
в) При получении куков проверяется массив ключей пользователя, за счет того что ключей может быть несолько пользователь может быть как дома так и на работе с одного логина. Чистка устаревших ключей производится автоматически, и не зависит от времени жизни куков. Если куки кривые - задержка.
г) Дополнительно есь возможность авторизации через post запрос, иначе не работют некоторые флеш загрузчики.

И напоследок. Хранить логин и пароль в куках - плохо. Украдут будет плохо. У меня при наличии связки ключ-ип каждый ключ действует для своего ип (нажимая "запомнить" дествует две недели).
Плюс пользователь может видеть все свои сессии. Т.е. когда и с какого ип в его аккаунт входили и грохнуть сессии (как в гугле).

Вот так.
10.08.2009 в 23:26

alhames.ru
Джей Ди При авторизации происходит задержка - исключает возможность брутфорса, пользователь не заметит 500 мс, а бот поляжет
sleep(5); чтоль?

б) В случае успешной авторизации в куки закидывается логин и специальный ключ (длинная строка никак не зависящая от пароля), далее пара ключ ип заносится в базу.
По сути ключ - это тот же session_id привязанный к ip, только существующий после завершения работы браузера.
+ Пароль не хранится в куках
+ Доступ в этом случае с нового IP можно будет получить только вводом логина-пароля
Но:
1 А если IP у пользователя динамический? То каждый раз ему придется авторизироваться заного?
2 Как хранить массив данных - сериализация, explode () или отдельные поля для ограниченного количества IP?

пользователь может видеть все свои сессии
Хм.. А это интересно)
10.08.2009 в 23:42

Всё будет Кока-Кола.
alhames я в принципе образно описал принципы работы, на деле все очень стабильно. :)

sleep(5); чтоль?
Ну вот одна буковка и куча нервов: usleep(500);

2 Как хранить массив данных - сериализация, explode () или отдельные поля для ограниченного количества IP?
Как душа ляжет, в любом случае их обработка уже после выборки. Мой выбор serialize как наиболее быстрый и удобный.

1 А если IP у пользователя динамический? То каждый раз ему придется авторизироваться заного?
Вы переоцениваете динамические ип. ) Я делал так что можно и отрубить слежку по ип, но в любом случае смена ип = выброс из интернета.
10.08.2009 в 23:53

alhames.ru
Джей Ди во времена диал-апа я заходил в Нет, скачивал форму добавления записи (отправки письма или еще чего-нибудь), отрубал Нет, потом писал, заново соединялся и отправлял сообщение.
Тогда проблема динамического ип для меня была весьма актуальна)

Ладно, мысль понял - завтра переработаю скрипт :)
Ах, да, кстати, насколько я понял сессии в этом случае и вовсе не понядобятся?
11.08.2009 в 00:38

Всё будет Кока-Кола.
alhames не понадобятся. Используй сессии с умом. )

Расширенная форма

Редактировать

Подписаться на новые комментарии
Получать уведомления о новых комментариях на E-mail