Здравствуйте! Вот я доделал админку, но понятно никак не обойтись без совета знатоков. В первую очередь меня интересует безопасность. Код (Text): <?php class Memberships{ public function authorization($user,$pass) { require ('db_connect.php'); $res = valid_data($user,$pass); if($res == 1){ session_start(); $_SESSION['status'] = 'admin'; header("Location:http://".$_SERVER['HTTP_HOST']."/"); } else return $false = '<script>alert("Введіть вірний логін і пароль!");</script>'; } public function log_out() { if(isset($_SESSION['status'])){ unset($_SESSION['status']); if(isset($_COOKIE[session_name()])) setcookie(session_name(), '', time - 1000); session_destroy(); header("Location:http://".$_SERVER['HTTP_HOST']."/"); } } } ?> Также меня интересует вопрос на счет проверки является ли посититель сайта админом. И насколько я знаю снала нужно стартовать сессию, а потом уже проверять. Код (Text): session_start(); if(!$_SESSION['status'] == 'admin'){ $_SESSION = array(); setcookie(session_name(), '', time - 1000); session_destroy(); }
А потом проверять соответсвует ли сессия юзверю, и соотвественный флаг в бд у записи юзера. Не знаток... Просто мысли в слух)))
если пользователь логинился, то переменные сессии были созданы, что-то типа такого Код (PHP): $_SESSION['login'] = $login; $_SESSION['pass'] = $pass; Значит не особо то и нужно создавать сессию.. А если пользователь не логинился, то можно просто проверить её на существоване Код (PHP): if(isset($_SESSION)){...} или (если я не ошибаюсь) так Код (PHP): if(!is_null($_SESSION)){...}
всегда было интересно. зачем в сессии хранить пароль? чиво? $_SESSION будет существовать после session_start(); на вопрос - логинился юзер или нет - это никак не ответит. надо проверять сответствующий ключ в массиве.
Замечу, что "взрослые" фреймворки не используют сессию для аутентификации. В то же время новички только так и делают, как будто все в одном месте списывали.
аутентификация - операция одноразовая. когда юзер ввел логин и пароль. далее в сессии ставится флаг для этого пользователя. да даже тупо его ИД. и все. если ИД есть находим его в базе по этому ИД и получаем пользователя. ни логин ни пароль ненужны.
хорошо, не аутентификация, это уже идентификация пользователя. фактически он идентифицируется по куке с именем PHPSESSID. если какой-то иной независимый кусок программы (корзина товаров, каптча, чертов хелпер заполения форм) вдруг решат сбросить сессию, сбросится и идентификация. т.е. это лишняя зависимость. криптостойкость PHPSESSID тоже невысока. я наблюдаю что повсеместно в движках начинают использовать HMAC а уж какое веселье бывает с под-доменами ))) если программист явно не настраивает параметры session cookie (а кто вообще слышал про эти параметры?). если пользователь посетил "независимые" домены и 2й и 3й уровня и в каждом есть какая-то своя работа с session… хаос и ахтунг! короче, если аутентификацию/идентификацию/авторизацию делать абы как, лишь бы побыстрее заработало, вылазят интересные побочные эффекты )
отдельная кука для идентификации пользователя, пишется с явным указанием домена + папки + времени жизни, защищенная HMAC.
а где тут уникальность? И второе, если пользователь указал при аутентификации "Запомнить меня", как тут быть со временем?
вопросом на вопрос отвечать невежливо... но отвечу на ваш. тут нельзя сказать что лучше а что хуже. все зависит от преследуемой цели. чуть выше я описал простейший варинт аутентификации и идентификации юзера с помощью сессий в php. там хранить пароли и логины нет необходимости. тоесть дял меня хранение пароля в сессии - является избыточным а потом - НЕ ЛУЧШИМ решением. для вас возможно иначе. вы предлагаете его хранить. я и спрошиваю - зачем это в вашем случае? когда объясните зачем - тогда сможем продолжить обсуждение, плюсы и минусы этого решения. Добавлено спустя 18 минут 15 секунд: что это значит? даже сайты банков используют эти механизмы. а для вас недостаточно? )) ближе к телу, сам механизм прост и надежен до безобразия: -сервер выставляет вам куку с случайным набором символов(идентификатором) -клиент(браузер) при каждом запросе отсылает эту куку. и сервер видит какая именно сессия сделала запрос. все! что именно в этом механизме, по вашему, недостаточно криптостойко? - что у юзера могут стащить ИД его сессии? да. если есть доступ к компу то ничего уже не поможет, ни HMAC ни что другое - канал передачи данных? юзайте https - простота самого идентификатора? 26 символов из букв и цифр брутфорсить почти бесполезно. но если хочется большей криптостойкости то никто не мешает сделать свою обертку над сессиями. заюзать session_set_save_handler(хранить сессии в шифрованной БД) и генерить ИД своим супер-пупер надежным методом. так что я лично особых проблем невижу. надежность на высоте, + есть возможность поднять еще выше.
Ну я пользуюсь двумя способами. 1-й простой: Пользователь логинится, проходит вся проверка и в сессию пишется пароль, не сам конечно, а смесь md5+соль 2-й: Есть база сессий. В неё кидаю хэш (смесь пароль+логин+браузер+...) и идентификатор пользователя Вот этот хэш и храню в сессии. Когда надо получаю хеш из сессии, получаю id из таблицы , формирую хэш, сравниваю... Правда в последнее время я стал пароль формировать по следующему правилу... Есть уникальное значение полученное допустим при установке сайта, например, md5(time+домен) При регистрации пользователя я получаю случайную длину строки из уникального значения со случайным смещением. Далее вставляю в md5(пароль) этот кусок с указанным смещением. В итоге у пользователей формируется пароли со случайной длинной. Соответственно в базе пользователей хранится смещение и длина. Так что храня пароль в сессии, я не переживаю за взлом самого пароля
я про другое... Если комп включен, браузер включен, то теоретически можно получить содержимое сессии... Получаем из сессии пароль и пытаемся путём перебора найти его... Опять же, говорю это теоретически. Я вообще из той части людей что считают что сам хэш md5 самодостаточен без всяких солей.. И перебирать пароли - дело не благодарное, если конечно кто-то не додумался три единицы поставить в пароль
да действительно. я про одно - вы про другое. вы мне про взлом пароля,ранящегося в сессии. я вам про то что пароль вообще НЕ НУЖНО там хранить. храните там флаг is_authorized и все. безопаснее и намного проще. зачем так усложнять.
Пожалуйста приведи пример где и для чего сайты банков используют пэхапэшные сессии. Я кое-что знаю про сайты банков, мне интересно расширить кругозор.
опять двадцать пять. на мои вопросы ответа нет, зато есть новые вопросы ко мне. получается не диалог - а монолог - причем мой. вообще, когда я говорил про сессии, имел в виду вообще сам механизм сессий. неважно где, в php или java например. для своих интернет-банков они зачастую используют ASP. так как там выходят на первый план вопросы лицензий, сертификации, соответсвие стандартам безопасности и т.д. так как microsoft везде где можно лицензии получила, как самая защищеная ОС и её технологии )) ага. в стане php не все так гладко, сертификатов на все случаи жизни нет, вот и не используют его корпорации так массово как яву или микрософтовские технологии. так вот. сам механизм сессий - одинаков везде. отличается только незначительными деталями. я описал, что в случае с пхп положение дел не хуже чем в других языках. и при необходимости можно наворотить все что угодно , повысить секурность как будет угодно, в рамках работы тех же сессий. так чем сессии вас не устраивают. конкретно чем?
Мне вообще-то пофигу. Я просто тебе не верю. "сессия" это способ сохранения состояния в среде без постоянного соединения. Сами по себе они не плохие и не хорошие. Считаю, что в вопросах приватности необходимо держать всё под контролем, а не полагаться на некие значения по умолчанию. Аргументы я уже изложил, кому интересно, тот найдет слова и пороет тему глубже. Например слово "криптостойкость".
не согласен с позицией artoodetoo если мы исходим из того, что куку сворют или id сессии подделают, то надо юзать другие более крепкие механизмы. например хардварные ключи. Это раз. Два, никто не мешает генерить id сессии исходя из своих собственных измышлений. Три. Всё это не имеет отношения к галочке "запомнить меня".
про галочку не понял ) подумайте над такими фактами: 1. сессионная кука живет недолго, но файл с данными сессии может лежать на диске достаточно долго. по крайней мере неделю запросто. т.е. если на сайт заходил админ, то перебирая неделю случайные значения PHPSESSIONID мы с некоторой вероятностью вдруг обнаружим, что мы — админ ))) а если знать, что значение PHPSESSIONID не совсем случайное, то нащупать можно с еще большей вероятностью. 2. если специально не управлять параметрами сессии, то сессионная кука доступна для javascript и любая дыра для JS-инъекции приведет у угону админской сессии. так что не расслабляйтесь. да, аналогично надо беречь задницу и для авторизации-через-куки, но там мы по крайней мере сами указываем параметры (см. "httponly")! 3. на дурных хостингах все сессионнае файлы доступны всем клиентам на этом сервере, вот такая вот хуйня, малятки. подломают другой сайт, а сессионные данные заберут ваши. 3a. ок, хостинг не совсем дурной и я не могу прочитать содержимое чужого сессионного файла, но я вижу имя файла, следовательно я могу создать куку с таким значением и попробовать ее на всех доменах с тем же IP что у моего сайта ))) круто, да! я просто Кевин Митник, мать его так что сессии сами по себе не плохи, просто надо знать как они работают, чем можно управлять. и сами решайте можно ли в них держать приватные данные. просто держите глаза открытыми.
откуда цифры? по дефолту сессия в пхп живёт 24 минуты. нащупай, расскажешь ну дыры разные бывают с разными последствиями. может быть такая дыра что и сессия не понадобится, что уж об этом говорить. А если уж и говорить, ну давайте тогда в сессию писать IP+агента. о, давайте поговорим о дурных хостингах, или нет, давайте не поговорим.
-что за фантазии? кука живет столько сколько ей скажут. (см. параметр expire в setcookie()) -даже если сессия еще живет на сервере, то файл куки в браузере то будет удален. так что случайно админом стать очень сложно. либо админ - дурак, если но на чужом компе зашел под собой и при авторизации поставил галочку "запомнить меня на неделю". это полностью вина человека. с таким же успехом он может оставить ключи бумажник на лавочке - а обвинять потом производителей кошельков. -вообще предполагается что Админу своему мы доверяем. если нет - то о какой секурности вообще мы говорим? вы уж определитесь что, где и от кого вы защищаете. это ежу понятно. хочешь секурности - делай. механизм это позволяет! чтото я непойму. вы что собрались делать супер секурный сайт на бесплатном шаред хостинге? ))) если все по взрослому - берите отдельный или ставьте свой сервак. если нет - то что мы тут обсуждаем? опять же. есть виртуализация и всякие safe mode, open_basedir .... те это вопросы правильной настройки хостинга. - это выходит за рамки нашего обсуждения! это продолжение предыдущего пункта. да вы кевин митник. вы сможете стать модером на соседнем по хостингу сайте любителей домашних тапочек! поздравляю. а мой сайт(если мне нужна безопасность хоть какаято) будет хостится на отдельном серваке. и ничего вы к нему не подберете, таким образом.
пацаны, я вас понимаю, рвать шаблоны больно. но вы просто перечитайте внимательно и найдете что-то новое и полезное. по хорошему предлагаю ))) потом будет больнее. Добавлено спустя 1 минуту 49 секунд: и не надо за меня говорить, что я супер-секурности ищу. достаточно простой отдельной защищенной HMAC куки. это недорого и все так делают, кроме самых упертых. Добавлено спустя 1 минуту 30 секунд: если чему-то не верите — проверьте экспериментально. а не хотите — просто проходите мимо.