Форум PHP

Собственно это и есть вопрос, подскажите, как это обычно делается(автозаполнение имеется в виду)? И еще вопросик по session, чем грозит в плане безопасности не уничтожение сессии. Т.е. после нажатия пользователем кнопки выйти сессия не уничтожается, а просто абнуляются значения ее переменных? также вопрос по MD5 шифрованию: шифрование для одного и тогоже слова выдает разные результаты в разные моменты поступления переменной в функцию MD5, или одинаковые?

Если мы говоирм о спаммерах, то формы они не заполняют, а сразу отсылают данные обработчику.
При первом старте сессии ее номер передается через URL. Этим можно воспользоваться и, перехватив его, украсть сессию. Тут на сайте есть статья про это.

Результаты одинаковые. На этом и построены принципы авторизации с хэшированием пароля.

А насчет опасности, возникающей при неуничтожения сессии? Она есть потенциально, или нет?

ну если у вас используется авторизация на сессиях, то можно войти под чужим логином в течение жизни сессии. у меня так несколько раз получалось.

Насколько я понимаю, это, если пользователь закрыл окно, при его открытии произойдет авторизация? А что такое флуд? И если можно укажите на недостатки системы авторизации в аттаче. Там почемуто с обработкой пароля функцией md5 не получается.

Нет. Окно пользователя не нужно. Достаточно идентификатора сессии.
Бегло просмотрел файл авторизации в запросе не должно быть никаких LIKE, только строгое соотвествие. Но это мелочь, основное то, что вы используете одинаковые имена переменных и для массива POST и для SESSION. На некоторых хостингах это вообще не заработает, на некоторых могут появится труднолокализуемые глюки. Но самое главное, вы оставляете злоумышленнику возможность ломать вас через GET.
Кроме того, логины модержащие спецсимволы, скорее всего будут отображаться неправильно.
Ну и кроме того, ваша авторизация уязвима для sql инъекций через GET и COOKIE
В общем, блок авторизации проще переписать сначала. Остальное смотреть не стал.

Если не сложно, киньте ссылочку, как ломаются сайты через GET и Coocki. Я не очень понял где конкретно дырки.

Дырка в том, что вы обрабатываете только $_POST['login'], а потом проверяете наличие $login. Так что если я передам значение login через GET, то оно пройдет мимо вашей обработки прямо в sql запрос.

Но ведь если register_globals = off то этого не должно произойти, ведь на это register_globals и нужна?

Прошу прощения. Я почему-то решил что у вас код под register globals on

Оно конечно не должно, только переменную всё равно стоит инициализировать.
Тогда, если вдруг окажется применить этот код на хостинге с включенным register_globals - он все равно заработает (массивы _GET, _POST и пр. существуют и там), а пробем с безопасностью не будет.

А как можно отправить данные обработчику, если форма и обработчик находятся в одном файле пхп? Всмысле, как узнать, какому скрипту передавать данные, если в форме стоит action="" ?

смотрим какие есть поля в форме, забиваем для них начения в скрипт, и натравливаем на файл с формой. Получается спам. Если скрипт зациклить, то получится флуд:)

Если сессия имеется и всегда назначена, то флуд и спам не страшен.
При первом входе на страницу (сайт) объявляется сессионная переменная, а при посте на форму она проверяется.
Ни робот ни скрипт не будет сохранять сессию (хотя могут) и при посте из скрипта она не будет определена, поэтому вы проверите, есть сессия и сколько времени прошло после предыдущего поста с этой сессии и если глюкен - то exit();