Условие "Вошедший пользователь". Улучшить безопасность

Здравствуйте. После того как пользователь вошел на сайт я запускаю куки или сессию(зависит от того что он выбирает) и затем постоянно (на каждой странице) делаю проверку на вход
Как можно улучшить эту проверку с точки зрения безопасности и какие подводный камни существуют? Спасибо.

0

Сообщение от SanychBY PHP 1 (isset($_COOKIE['email']) and isset($_COOKIE['password'])) or ...

Я сам себе могу повесить куку с именем email и куку с именем password и твой сайт меня залогинет

0

Сообщение от crautcher Я сам себе могу повесить куку с именем email и куку с именем password и твой сайт меня залогинет

И как этого избежать?

Сообщение от SanychBY Как можно улучшить эту проверку с точки зрения безопасности и какие подводный камни существуют?

0

Не логинить тех, кто себе повесил любую куку с именами email и password.
p.s.

Сообщение от SanychBY я запускаю куки или сессию(зависит от того что он выбирае

Зачем вообще юзеру выбор как хранить данные о его логине, работай с сессией всегда?

0

Сообщение от crautcher Зачем вообще юзеру выбор как хранить данные о его логине, работайте с сессией всегда?

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

Сообщение от crautcher Не логинить тех, кто себе повесил любую куку с именами email и password.

И как проверить любая эта кука или не любая. Спасибо.

0

Сообщение от SanychBY Сессия хранится только на время сеанса, а куки на указанное время.

Кто вам такую чушь сказал?

Добавлено через 1 минуту
Сессия такаяже кука как и любая другая.

0

Сообщение от crautcher Кто вам такую чушь сказал?

Не знаю=)
А как тогда и в чем разница?

Добавлено через 58 секунд

Сообщение от crautcher Сессия такаяже кука как и любая другая

И как тогда указать сколько времени ей "жить".?

Добавлено через 56 секунд

0

Сообщение от SanychBY А как тогда и в чем разница?

В том что в куках данные у клиента в браузере и он может их менять как угодно, а в сессии данные на сервере, а у юзера только индикатор сессии - билеберда. Сессия - защищена, куки нет.

Сообщение от SanychBY И как тогда указать сколько времени ей "жить".?

http://php.net/manual/ru/funct... params.php
п.с. ухожу домой

0

Сообщение от crautcher В том что в куках данные у клиента в браузере и он может их менять как угодно, а в сессии данные на сервере, а у юзера только индикатор сессии - билеберда. Сессия - защищена, куки нет.

Зачем тогда вообще использовать куки?

0

Сообщение от SanychBY Зачем тогда вообще использовать куки?

Для хранения данных о пользователе. Например, определенный вид сортировки, которую обычно выбирает пользователь, тема на сайте и тому подобное. Это все - некритичные данные, в отличии от пользователя и пароля.
Пароль можете хранить и в куках, но тогда шифруйте его и делаете проверку в php.

0

Сообщение от AxelPAL Для хранения данных о пользователе. Например, определенный вид сортировки, которую обычно выбирает пользователь, тема на сайте и тому подобное. Это все - некритичные данные, в отличии от пользователя и пароля. Пароль можете хранить и в куках, но тогда шифруйте его и делаете проверку в php.

Ну а кроме использования кук или сессии, как это условие можно улучшить?

0

Сообщение от SanychBY как это условие можно улучшить?

О каком условии идет речь?

0

Да вроде пока об этом=)

0

Чуть дополню, если позволите. HTTP -- stateless протокол, т.е. пришел запрос, сервер его обработал, и забыл о клиенте. Да, в версии 1.1 (ну и неофициально в 1.0 тоже вроде как) появились постоянные соединения (keep-alive), но дизайна протокола эта штуковина не изменила, она служит совершенно в других целях. Поэтому, без каких-либо "извращений", сразу после авторизации сервер забудет о том, что Вы зашли на сайт, где побывали, что видели, кому что отправляли и так далее. Поэтому был введен механизм cookies: он позволяет поддерживать состояние. Суть его заключается в простом принципе: когда пользователь входит на сайт (или даже с самого начала посещения сайта), сервер отправляет ему сверхсекретную длинную комбинацию буковок, и запоминает, что с этой комбинацией связан такой-то пользователь. А значит, что когда он войдет, сервер это запомнит, и выдаст новую страницу, в которой он уже учтет то, что пользователь "зашел" на сайт.
В пхп нативно поддерживается механизм сессий (google: session_start, $_SESSION). С его помощью автоматически создается эта секретная строка, автоматически отдается в заголовке Set-Cookie, и автоматически запоминается на сервере. А в конечном итоге, программист сервера (т.е. Вы) получает в свое распоряжение т.н. суперглобальный массив $_SESSION, куда можно засовывать данные, связанные с конкретным клиентом. Таким образом, отпадает необходимость в ручной манипуляции с самими cookies, эта работа за вас уже сделана.
По поводу безопасности, в вашем коде она отсутствует, более того, выражение (A and B) or (B and A) эквивалентно (A and B). Поэтому вторая часть выражения явно лишняя, в вашей проверке.
В действительности, как уже упоминали, вам следует создать базу логинов(емейлов) с паролями. И говоря "базу" я не обязательно имею ввиду СУБД, достаточно простых файлов, если с ними будет удобнее манипулировать в вашем приложении. При авторизации необходимо проверять введенный емеил и пароль на соответствие (ну а если я представлюсь админом сайта, и введу пароль 123 -- вы меня тоже пустите?). Другие способы авторизации (нативная протокола http(s), номер мобильного телефона, идентификация через емеил итд), а равно многофакторный способы авторизации также существуют, но пока не забивайте себе этим голову, попробуйте реализовать "классический" (умпомянутый) выше способ.

Сообщение от SanychBY Ну а кроме использования кук или сессии

в smf, а также, я слышал, что и в одноклассниках, если клиент не поддерживает куки, то на каждый запрос добавляется специальная переменная в строку запроса (get-параметр), url-ка выглядит слегка коряво: вместо http://example.com/index.php будет что-то вроде http://example.com/index.php?t... D567BCA347, при этом серверные методы "запоминания" пользователя остаются прежними: эта секретная строка запоминается на сервере, и с ней ассоциируются некоторые данные. В дальнейшем, клиент отсылает строку с таким же значением, и сервер его "узнает", и считывает все данные, связанные с ним.
Можно попробовать аналогичный способ с передачей не GET, а POST параметра, тогда в строке запроса не будет лишней информации, но при этом вы лишаетесь кеширования, и кроме того, нельзя при обращении методом GET передавать POST параметры. Например, вы не сможете просто взять и впихать ссылку на страницу и забыть о ней. Придется либо делать кучу форм (раз уж клиент не поддерживает COOKIES, то наверняка он не поддерживает и JS), ну либо же, если встретилась редкая комбинация, через xhr, скрытые ифреймы,хоть WebSockets или jsonp -- вообщем, на ваш выбор, транспортов полно. Главное, это преобразовать все GET в POST запросы, и передать эту уникальную строку обратно на сервер, чтобы он нас "опознал". Вообщем, такой способ подойдет, скорее всего, только лишь для "богатых" (rich) веб-приложений, где почти все пользователи почти всегда авторизованы, и каждое действие по своей сути является не чтением, а изменением состояния (семантика метода POST).

Сообщение от SanychBY с точки зрения безопасности

Это следующий этап. Необходимо защититься от следующих угроз:

• Фиксация сессии. Простейший способ в php: время от времени делать session_regenerate_id. Тут есть небольшие подводные камни (например, http://habrahabr.ru/qa/4962/), но их можно зачастую избежать, и/или обойти.
• CSRF. Один из способов представлен тут же.
• другие. пожалуй, наиболее полный список с советами по устранению приведен тут, более общий список (касательно не только аутентификации и авторизации, но и их тоже) -- http://projects.webappsec.org/... sification .

Сообщение от SanychBY какие подводный камни существуют

Дофига. например: против целевых атак обязательно нужно учесть, что функции mt_rand и rand в пхп небезопасны. Они же используются для генерации ID сессии, и довольно часто ими пользуются для генерации паролей. по-русски об этой проблеме можно почитать тут, тут и тут (первые три ссылки в гугле, последняя, на мой взгляд, наиболее содержательная).

Также, стоит помнить о параметре httponly в куках, а если используется https, то еще и secure.
Вообщем, пожалуй все. Спасибо, что дочитали до конца, надеюсь я несильно взорвал вам мозг. Удачи!

2

генерируй случайной число от 1 до [много]. Потом отправляй его как куки при входе, затем проси обратно это куки и сверяй его в базе данных с ником

0

NEbO, А на русском есть? И что бы понятно было как от этого защититься?
Greeezly, И что это нам даст?

0

То, что рандомное куки не смогут подобрать

0

Сообщение от Greeezly То, что рандомное куки не смогут подобрать

Украл и все.
Сессии надежнее

Добавлено через 44 секунды
Greeezly, Я считаю Вашу идею бесполезной тратой ресурсов.

0

сессии так-то используют куки

0

Сообщение от Greeezly сессии так-то используют куки

Сессия так - то защищена

0