Здравствуйте, у меня вот какой вопрос. На своем сайте Я пытаюсь реализовать систему регистрации пользователей по которой у меня есть несколько вопросов касающихся безопасности. Я использую такую систему:
1) на главной странице index.php в самом начале Я запускаю session_start()
2) далее проверяю следующее:


Подскажите есть ли в моем примере дыры с помощью которых хакер сможет взломать его. И вообще целесообразно ли использовать в работе сессии или их тоже можно легко обойти. Буду признателен за любую помощь!

Это сообщение отредактировал(а) yngwie19 - 4.2.2010, 18:19

как минимум, SQL инъекция

1) SQL-inj. У специалиста их не может быть впринципе. Стремись.
2) Не в том месте подключается СУБД.
3) Сессии хранятся на сервере.

подскажите пожалуйста где нужно соединяться с базой?


т.е мне нужно самому генерить хеш сессии и хранить в БД? а чем вариант session_start() не подходит? 

пароль в md5()
логин пропускаем через mysql_real_escape_string

Добавлено через 21 секунду
в запросе лучше указать LIMIT 1

Добавлено через 53 секунды
с СУБД надо подключаться в самом начале

по поводу места подключения к бд я не понял. 
про сессии на сервере - это, как я понимаю, был туманный ответ на вопрос "можно ли обойти сессии". 
вопрос, впрочем, не менее туманный, и звучит как "можно ли обойти трамвай". 
что значит - "обойти"? что значит "тоже"? теоретически обойти можно все что угодно. 
что значит "можно обойти" - синоним "никто не использует сессии для авторизации"? а сами как думаете?

по поводу кода
1. большая просьба исправить синтаксис. смотреть на подсветку невозможно.
2. нет собственно работы с сессией. для чего в нее записываются логин и пароль?

нашел пример регистрации от Mal Halk http://forum.vingrad.ru/faq/topic-158301.html
посмотрите пожалуйста, есть ли у Вас замечания? это действительно безопасный подход или его следует усложнить (ну кроме пункта 8. где он сам объясняет как можно улучшить). Большое спасибо!

код нужно не усложнять, а понимать

Ипатьев, Я имею в виду улучшить защиту. Ну а вообще подход правильный?

ЩИТО? Геноцид SHA1()   ?


зачем? у него, как будто, результат другой будет?


нет, у тебя совершенно безграмотный код

см. мою тему:
http://forum.vingrad.ru/topic-283105/view-all.html

Бгг...
Во-первых, тема там не твоя.
Во-вторых, твой код в той теме от вышеприведеного отличается наличием mysql_real_escape_string в лучшую сторону, но при этом имеет абсолютно тупые проверки

Если был запрос такой


Это еще зачем? Или это из серии 

А в плане подхода код абсолютно одинаковый. Но самокритика это хорошо... Полезно знать что ты пишешь безграмотный код, есть куда расти.

Simpliest, Подскажите пожалуйста не могли бы Вы дать ссылку на статью, где будет описан правильный(с точки зрения безопасности) подход к регистрации пользователей на сайте. А то в инете много разных подходов, а какой лучше выбрать и дальше не знаю.

Давай ты лучше будешь писать свой алгоритм общими словами, а мы ответим.

пруф ор die();

nerezus, Мне пока сложно описать последовательность реализации данной задачи. На текущий момент Я ищу в инете различные варианты и пытаюсь разобраться какой наиболее безопаснее. Посматрите пожалуйста вот эту ссылку http://www.itseazy.ru/post46
как Вы считаете можно ли создать безопасную регистрацию используя его. Большое спасибо!

Правильный подход постараюсь описать несколькими тезисами,
кто не согласен, высказать свои возмущения.

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

Иначе, нужно включить мозг и подумать.

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

2) При регистрации, если пользователь сам выбирает пароль, проверять не слишком ли простой пароль, и если это так, 
то просить ввести другой, более сложный.

3) Не хранить важной информации в куках, которые хранятся на машине пользователя и передаются с каждым запросом серверу.
Единственное, что позволяется хранить в куках - это идентификатор сессии.
Под каждый номер (идентификатор) сессии, на самом сервере сохраняется файл - сериализованный массив.
И именно в этом файле записан пароль пользователя (или хешь) и конечно же имя пользователя.

Но этого нам конечно же не достаточно для более менее серьёзной безопасности. 
Ведь злоумышленник может украсть куку с идентификатором сессии жертвы и войти на сервер под его именем.

Для этого нам нужен пункт 4, а именно дополнительная защита, путем проверки ip и браузера, с которого входит потенциальный пользователь.


4) При успешной авторизации пользователя. Рассчитать переменную хэшь и поместить ее в массив $_SESSION


При каждом запросе, если сессия ссылается на правильного пользователя, мы проверяем, а такой ли у него брузер и ip, который был при прошлом входе на сайт.

Для этого мы опять вычисляем хешь, и если он не совпадает с тем, который записан в $_SESSION['hesh'], то просим его ввести пароль и имя пользователя еще раз. 


Это очень сильно повысит безопасность, по сравнению с обычный авторизацией через сессию, 
но тем не менее не обеспечит 100% безопасности, т.к. информацию, которая лётает по проводам, можно при очень огромном
желении перехватить.

5) Для этого остаётся последний метод борьбы - шифрование. Т.е. нужно организовать шифрование информации между браузером и сервером. Все серьёзные организации, связанные с деньгами делают это в обязательном порядке. Втроенный в браузеры алгоритм ширования называется SSL.


В заключение, еще раз повторю, что все это нужно только тогда, если речь идет о чем то действительно серьёзном. Иначе же, можно не парить мозг и спокойно ограничится только первыми тремя пунктами. 








Это сообщение отредактировал(а) NLspieler - 5.2.2010, 00:10

К сожалению не могу, поскольку никогда не занимался поиском таких статей.

В целом подход верный. Нужно просто не упускать таких казалось бы мелочей как:
mysql_real_escape_string()
хранение пароля в виде хеша md5, sha1, а не в открытом виде.
обязательной проверки логина на допустимые символы 
обязательной проверки, что мы таки получили все необходимые параметры, а не только была ли нажата кнопка.
и т.д.


пруф чего?  примера выше недостаточно?
Ты только что получил значение из базы где логин был условием.
Ты надеешься что полученное значение будет отличаться от логина в условии запроса?  Или как?
Пароль у тебя хранится в открытом виде что тоже не есть хорошо.
Абсолютно не проверяется, а есть ли что-то вообще в $_POST - что неправильно, в отличии кода того же топикстартера. 

Прошу проверить мою писанину о безапасности на полноту и на дыры. 
Ведь тема действительно серьёзная и
не допускающая никаких холиваров, т.е. религиозных войн. 

NLspieler, 



Зачем куда либо писать пароль (или его хешь) ?



ip может быть динамическим, идентификатор браузера подделать очень просто.   Так что ИМХО пункт 4 бессмысленный. 




А вообще - желательно не забывать про существование ООП и MVC. Ни того ни другого нет ни в одном примере упомянутом в этой теме.

Смысл таки определенный есть. Это еще одна дополнительная помеха взломщику.


Эм?
Каким образом это относится к безопасности авторизации? 

При динамическом ip пользователя будет периодически выкидывать . Оно надо? 

Ну а информация о браузере не дает никакой доп защиты.



Разделяй и властвуй.   

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

Как следствие, меньше ошибок - меньше уязвимостей.

Это зависит от требований задачи.



Аааа, ну тогда могу порекомендовать еще подбирать хороших программистов  они тоже делают меньше ошибок и меньше уязвимостей.
А так же не кодить с похмелья и т.д. 

Но к теме топика это относится опосредованно.

Лучше что-бы выкидывало, чем пользователя взломали.))
______________

У меня следующий подход, как вам?

Simpliest, 



Да нет - напрямую.  Человек учится, так пускай учится мыслить объектно, пускай учится разбивать приложение на слои.

Идеология должна быть примерно такой:

Есть сущность пользователя. Класс UserEntity cо свойствами id, userName, userHashPasswd, userEMail.....
Есть DAO в котором осуществляется вся работа с БД связанная с юзером. Класс UserDao с методами saveUser(), getUserById, getUserByName, getUserByNameAndPasswd.....

Есть классы контроллеров (контроллер для регистрации пользователя, контроллер для логина).

Могут быть командные объекты для представления POST запросов в виде объектов. Вспомогательные классы (валидаторы и тд....)

Могут быть менеджеры, но для начала можно и без них.

Добавлено через 7 минут и 14 секунд


Ок. Давай посмотрим когда человек может получить id сессии. Тогда когда он либо имеет доступ к компьютеру, а соответственно и к его браузеру и к его ip.

Или когда он мониторит трафик. А соответственно в данном случае он может спокойно отмониторить и пароль. Особенно, если его придется вводить часто.

Защита тут только шифрование канала.

а что же тогда делать? надо все на сервере хранить.
Весь канал что-ли шифровать?

Это сообщение отредактировал(а) Spiker - 5.2.2010, 02:23

Я тебя понимаю, но так же понимаю, что все это скопом сразу не влазит в одну голову 
Поэтому постепенность и последовательность.

Spiker, 
Уже писали, для особо тяжелых случаев используется SSL

Но в особо тяжелых случаях и это не панацея 

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

Ведь только последний помешанный идиот станет пытатся взламывать сайт анекдотов, что бы написать матершинный комментарий от имени другого пользователя.



Ну слава богу, что только 4 пункт бессмысленный, 
хотя на самом деле он не такой и беесмысленный.

Проведем такой мысленный эксперимент.

Есть сервер, есть взломщик, есть жертва, которого пытается взломать этот взломщик.
Сразу обговорим, что php-код, который хранится на сервере взломщику не известен. И узнать он его не может.


Допустим, что взломщик удалось встроится в провод и он теперь может видеть, какой трафик проходит между сервером и потенцильаной жертвой.
Он обнаруживает, что жертва передаёт определенный id-сессии. 
Наш взломщик пытается авторизоватся на сайте при помощи этого идентификатора, 

но
сервер, обнаружив, что у него другой ip и даже другой браузер, и что хеши не сходятся, мирно просит его ввести логин и пароль.
короче, такой метод не взлома не действует. Пусть user_agent и можно подобрать, но как подобрать нужный ip?
Я, если честно, не знаю. И мне кажется, что это не возможно, кроме нескольких редких исключений.

Кроме того, взломщик же не знает, что ему нужно отослать одновременно правильный user_agent и правильный ip? 
Он же не знает исходный код.


Но конечно, же отсутствие пятого пункта (шифрования) практически полностью убивает пользу от описанного четвертого.


Но даже если есть даже шифрование, то дыры все равно остаются. 

Ведь если злоумышленник мониторит трафик, то он спокойно сможет подменить публичные пароли на свои. Если интересно, опишу этот процесс более подробнее.


Короче, делаю вывод, что никакой абсолютной безопасности не существует. Можно только достигнуть безопасность порядка 99,99%, но
стопроцентая не возможна впринципе. 

каждый использует то что ему роднее и привычные, разницы так таковой нету!



хотя бы для того чтобы:
1. БД не продолжала искать по таблице, после того как нашла уже одну запись
2. при безграмотном кодинге бывает что на один и тот же логин принадлежит N пользователям, в этом случае его конструкция не пройдет




      
два запроса!!!


yngwie19 если тебе не важна красота формы авторизации то можешь использовать вот это

Ребят спасибо Вам всем большое за то что столько времени уделили моему вопросу. Я думаю, что Я найду для себя правильный путь решения моей задачи. Единственное что бы Я хотел у Вас спросить это про использование SSL. Подскажите толковое руководство по нему. И вообще человек, который создал эту тему (т.е Я) сможет это реализовать? или тут нужны серьезные знания? Поскольку Я смотрю что все крупные сайты используют SSL.

Вообще, я бы начинал не с авторизации.
Ведь дыра в работе с SQL к собственно авторизации не относится. 
Сначала надо осваивать элементарные вещи, "кирпичики", из которых строится веб-приложение. Работа с базой, куками. Строкамии, почтой.
Авторизация - это уже здание, которое строится из этих кирпичиков. Если их не знать, ксли они будут пустые внутри - здание развалится. Даже если на форуме покажут чертежи супер-проекта.

Согласен, потому,  прежде чем что-то писать, надо выучить язык, неотъемлемой  частью которого  является ООП.

Надо знать что такое http, как строятся запросы и ответы, что такое GET, POST, сессия, куки....

Надо разобраться с подходом к построению web приложений (основным, на данный момент является MVC).

Потом, решив написать что-то для web, не изобретать велосипед, а воспользоваться web-фрэймворком, но понимая, как он работает.

неужели?!



  
они не всегда хороши

Вы считаете, что человек не знающий ООП в php может называться php программистом? 
Интересно, найдет ли он нормальную работу, или сможет разобраться в коде какого-нибудь современного продукта (большинство из которых используют ООП и MVC )
К тому же рано или поздно ему все равно придется работать с библиотеками написанными в объектном стиле. 


Но в большинстве случаев их применение экономит силы и время, а соответственно, позволяет быстрее создать готовый продукт.

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

представил и?!...

Добавлено @ 14:20
могу даже пару ссылок привести крупных проектов (не свои)

Это сообщение отредактировал(а) MoLeX - 5.2.2010, 14:20

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

я могу проект показать, весит за 10-20мб без никакого ООП))

Это сообщение отредактировал(а) Spiker - 5.2.2010, 19:58

Spiker, 




У тебя возможна инъекция SQL в doLogin()

все данные тогда надо через mysql_real_escape_string пропускать


Добавлено через 13 секунд
все данные тогда надо через mysql_real_escape_string пропускать

Для пропуска всех нужных переменных из пост через mysql_real_escape_string, я использую слудующий код.

по-моему еще кроме кодировки сессии больше не чего нельзя добавить?

а htmlspecialchars() не подходит?

а что по вашему делает эта функция? каково её назначение?

Это сообщение отредактировал(а) bars80080 - 5.2.2010, 23:26

Преобразует специальные символы в HTML сущности

зачем это для авторизации?
это для других вещей, к примеру для проверки - что написал пользователь в гостевой книге.
логин и пароль в мд5 закатал и проверяй))

Это сообщение отредактировал(а) Spiker - 6.2.2010, 00:34

NLspieler, 


Ну и что ... большинство путей проходят через прокси сервера!!!
И твоя система хватает IP именно прокси через который работает и хацкер, ну а агента это уже понятно ....
Всё каюк ... 
Это проблема много сложнее.

Добавлено @ 10:24
Vasay, 


Угу, а потом появляются системы с классами в 20 -30 методов с кучей свойств, не соблюдая основные правила ООА/П.
И думаешь а где здесь всё таки ООП   

Это я к тому , что прав  Simpliest, всему своё время.

Добавлено @ 10:32
yngwie19, 


Основная проблема новичков, начни с анализа требований и последовательности, в особенности начни с карандаша и листа бумаги.
"Форест Гамп прекрасно выразил эту идею, когда сказал: 
    Если вы не знаете куда идете, то вы вряд ли туда дойдете." (Разработка и управление требованиями Практическое руководство пользователя )

Это сообщение отредактировал(а) Sentox - 6.2.2010, 11:46

 Лучше на код.
Тут один из наших постоянных посетителей занимался рефакторингом переписыванием одного из ссамых популярных сайтов рунета.  Который был структурным.

По-моему, прежде чем крыть крышу, нужно построить фундамент.  

Это я к тому, что прежде чем заниматься авторизацией, надо выучить язык и разобраться с общепринятыми шаблонами проектирования.

подскажите мне пожалуйста вот на таком примере. У меня есть форма: 


Скажите, когда данные этой формы отправятся по нажатию кнопки "зарегистрировать" в обработчик addNewUser.php, какие проверки этих данных нужно выполнить, чтобы предотвратить возможность взлома? Спасибо.

preg_match, htmlspecialchar и mysql_real_escape_string

Spiker, этого достаточно?

yngwie19,
рассказываю по шагам.
Во-первых, на многих хостингах включены волшебные слэши.
Т.е. строка "привет" превращается в \"привет\"
что бы избежать этого, нужно либо отключить эту опцию, либо пропускать все принимаемые данные, через функцию 
 
Кроме того, некоторые поля нужно пропускать при приеме через функцию trim, которая удаляет пробелы в начале и в конце.

preg_match позволяет проверить на правильность емейл, url, да и любые другие поля на соответствие правильному шаблону.


Через mysql_real_escape_string обязательно нужно пропустить все данные (ну почти все), которые попадут потом в sql запрос.

Пароль в БД лучше вообще не писать, а записать md5-hesh.

Насчет htmlspecialchar не знаю. По-моему, ее нужно применять, когда в БД вносятся текстовые комментарии.
Впринципе и другие данные можно через нее пропустить. Но вопрос это спорный.


К безопасности из приведенного списка относится только mysql_real_escape_string и в некоторой степени md5-хешь для пароля
 


Это сообщение отредактировал(а) NLspieler - 7.2.2010, 09:15

нет, назначение функции - форматировать специальные символы, применяемые в хтмл в соответствующие сущности. то есть её надо применять для вывода текста в браузер. к БД она никакого отношения не имеет

я лично ereg использую, у меня проверка на любой тип поля есть... как то не охота все переписовать))

т.е так:

и все?

Добавлено через 5 минут и 15 секунд

а если проверять вводимые данные по такому шаблону:

то тогда Вам вариант можно пропустить?

Это сообщение отредактировал(а) yngwie19 - 7.2.2010, 17:09

Да, этого достаточно. 
Но нужно еще и при попытке пользователя войти на сайт, сравнивать не пароль, а его md5.


md5($string) всегда равен md5($string)  не зависимо от значения $string. 
Но получить из md5 хеша исходное значение практически не возвомжно.

Таким образом мы получаем следующие плюсы: 
1) никто не сможет узнать пароль пользователя, даже имея в распоряжении базу данных.
2) md хэш всегда имеет одинаковую длинну, таким образом можно экономить место в БД, прописав в соответствующее поле эту длинну.




И зря. ereg мало того, что работает значительно медленние, так еще и не может обработать такие мощные регулярные выражения, которые допустимы в preg.
А переписать несколько регулярных выражений особого труда не составит.



Если данные принимаются из формы с лишними (волшебными слэшами), то избавлятся от них нужно в обязательном порядке.


Разумется, никакого отношения к БД она не имеет, но в ряде случаев она просто не заменима.
Можно конечно записывать в БД данные как есть, а можно записать в БД уже обработанные данные, готовые к выводу.
Таким образом достигнется небольшая экономия мощностей процессора. Так как данные нужно будет пропускать через эту функцию только один раз.

 А иногда незаменимы другие функции. Но как и эта, они не относятся к теме. Совсем.

 Если у вас простая геста и больше, чем к выводу в html эти данные не нужны - то да.

 А теперь расскажите, какие ;) При том условии, что структура данной ф-ии примитивна и оверхед не будет замечен.

ктото пробовал делать следущее?

Такое вряд-ли кто-то взломает... до тех пор пока хакер не в курсе сколько раз все было зашифровано.

Это сообщение отредактировал(а) Spiker - 7.2.2010, 23:59

Spiker, и зачем? лучше использовать соль и все

Spiker, тогда уж так:

     

Добавлено через 1 минуту и 2 секунды
P.S. может хватить страдать ерундой? если уж такие параноики то следует написать свой алгоритм хеширования и радоваться жизни

Это делается намного проще

yngwie19, 
Spiker, 

что такое, по-вашему md5 и зачем он нужен?

md5 128-битный алгоритм хеширования
если получить пароль в мд5, то это не проблема его расшифровать

Это сообщение отредактировал(а) Spiker - 8.2.2010, 15:04

  

пожалуйста, расшифруй (а вернее подбери, так как хэш нельзя расшифровать)


Добавлено через 35 секунд
пасс: 16 символов

можно по легче задачу)
16 цифр через чур)
этого хеша не было в базе данных

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

а не надо было начинать. Назвался груздем, полезай в кузов. Ждем пароль....

Можно и так.

есть ресурсы с базой мд5 и расшифрованным мд5.
но которые я просматривал имели базы с мд5 до 8-12 букв\цифр.
поэтому я данный хеш не как не узнаю разве что если MoLeX сам его не скажет.
если раз-читывать на обычного пользователя то вряд-ли у него будет длинный и трудный пароль.

Это сообщение отредактировал(а) Spiker - 8.2.2010, 20:41

ребят а подскажите, использование массива $_SESSION является безопасным? его используют? или есть что-то лучше?

зато стоит своеобразным способом поставить свою соль (не забывая её менять от проекта к проекту), и все эти базы идут лесом

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

вполне хватает:


Добавлено через 35 секунд
P.S. f68cb9f45c7395a04747db9781186afd == Rt!s8Gd$5&0-L+93

Добавлено через 2 минуты и 27 секунд

да нет нормальный, я на работе запрещаю использовать пароли меньше 10 символов, и всякий подбор сводиться к нулю