Как подменить сессию в браузере
Здравствуйте. Я прекрасно понимаю, где и как создаются и хранятся сессии. Браузер к этому не имеет ни какого отношения. Это прерогатива сервера. Когда эти сессии удалять. Но, есть один странный момент. У меня на сайте для админов есть дополнительное телодвижение) Если некая сессия не установлена - админ должен ввести определенный типа пинкод. Он получает сессию и продолжает работать на сайте. По идее, после закрытия браузера. через определенное время эта сессия должна удалиться и при следующем заходе на сайт опять необходимо ввести этот пинкод. И вот, что интересно. Работая в Хроме Гугла, мне не нужно вводить этот пинкод. даже, если я не заходил на сайт уже продолжительное время. В Хроме на Винде. На других браузерах я это не замечал. Проверял на Линуксе и на Винде в других браузерах. Только стоит закрыть любой из браузеров, а потом опять открыть через некоторое время и попытаться зайти на сайт - будет предложена эта дополнительная проверка. Только в Хроме Гугла это не происходит. Что это может быть за хрень? Создается впечатление, что этот Хром как будто постоянно остается висеть на сервере, заставляя его не удалять эту сессию.
Браузер который одновременно во вкладах держит разные сессии прокси и куки
Доброго времени суток! У меня появилась одна идея, но для этого мне нужен браузер который способен.
PHP сессии, сортировка массива сессии
Доброе время суток, существует такая ситуация, у меня есть корзина, которая основана на сессиях.
Как "увидеть" именованные объекты ядра (event), созданные в одной сессии, из другой сессии ?
Добрый день! Появилась неожиданная задача: Win 2008 Server, и в нём несколько сессий различных.
Вулкан в Хроме выскакивает периодически. Когда закрыт браузер грузит браузер и открывает рекламу
Доброго времени суток господа. Сначало выскакивал вулкан в гугл хроме, в остальных не наблюдал.
Эта баг фича хрома.
Поробуй перейти в настройки - расширенные настройки и снять чекбокс "не отключать работающие в фоновом режиме сервисы при закрытии браузера"
Да. дело еще в том, что все остальные установленные мною сессии, работают правильно. Некоторые я удаляю принудительно. В некоторых я делаю инкремент и после определенного значения они обнуляются. Вот только с этой сессией какая-то беда. И еще. На другом сервере этот код работал. Когда я перешел на новый сервер - началась эта непонятка.
Код простой.
Супер! Спасибо. А я и не знал про этот чекбокс. Проверю при снятой галочке, а потом скажу результат. Но в любом случае большое спасибо. Честно говоря, уже этот Хром достал. Иногда очень сильно подвешивает комп. хоть я все что мог отключил. Но про это не знал.
Добавлено через 2 часа 28 минут
Не сработало( Закрывал браузер на более часа. Эта сессия не удалилась. Подскажите настройки на сервере. У меня есть доступ по SSH протоколу.
Очень странно, что в работая в других браузерах, такого не происходит. Как браузер вообще может влиять на удаление сессий на сервере?
Тут не все так просто. Есть параметр session.gc_maxlifetime , он определяет когда данную сессию считать "мусором", но чтобы очистить устаревшие сессии должен быть запущен сборщик мусора, а вероятность его запуска вычисляется как session.gc_probability / session.gc_divisor, по умолчанию это 1%. Можно конечно увеличить это значение, но это скажется на производительности.
Есть параметр session.cookie-lifetime, который устанавливает сколько сессионная кука хранится в браузере, но даже уничтожив куку в браузере сессия на сервере не уничтожается, можно самому создать куку с "уничтоженным" id и сессия продолжит работу как ни в чем не бывало.
Если сессии храняться в файлах, то возможно использовать cron для периодического запуска скрипта, который будет удалять устаревшие файлы, но тут сразу возникает проблема когда в 1 месте хранятся сессии разных сайтов с разным session.gc_lifetime. В Debian/Ubuntu так и сделано, там отключен стандартный сборщик установкой session.gc_probability = 0 и есть cron (/etc/cron.d/php5). В качестве времени жизни используется максимальный session.gc_lifetime из всех php.ini, или 24 минуты, если gc_lifetime не найден.
Из выше сказанного следует вывод что не стоит полагаться на стандартные механизмы. Если принципиально убивать сессии в определенный промежуток времени, то нужен дополнительный контроль со стороны программиста
Безопасность веб-сайтов основывается на управлении сессиями. Когда пользователь подключается к безопасному сайту, он предоставляет учетные данные, как правило, в форме имени пользователя и пароля. Веб-сервер не имеет представления о том, какой пользователь уже вошел в систему и как он переходит от страницы к странице. Механизм сессий позволяет пользователям не вводить пароль каждый раз, когда они хотят выполнить новое действие или перейти к новой странице.
В сущности, управление сессией гарантирует, что в настоящее время соединен тот пользователь, который проходил авторизацию. Но, к сожалению, сессии стали очевидной мишенью для хакеров, поскольку они могут позволить получить доступ к веб-серверу без необходимости проверки подлинности.
После аутентификации пользователя, веб-сервер предоставляет ему идентификатор сессии. Этот идентификатор хранится в браузере и подставляется всякий раз, когда нужна проверка подлинности. Это позволяет избежать повторяющихся процессов ввода логина/пароля. Все это происходит в фоновом режиме и не доставляет дискомфорта пользователю. Представьте, если бы вы вводили имя и пароль каждый раз, когда просматривали новую страницу!
В данной статье я постараюсь изложить все известные мне способы защиты идентификатора сессии в PHP.
Использование cookie
По умолчанию вся информация о сессии, включая ID, передается в cookie. Но так бывает не всегда. Некоторые пользователи отключают cookie в своих браузерах. В таком случае браузер будет передавать идентификатор сессии в URL.
Использование шифрования
Если на вашем сайте должна обрабатываться конфиденциальная информация, такая как номера кредитных карт (привет от Sony), следует использовать SSL3.0 или TSL1.0 шифрование. Для этого при установке cookie следует указывать true для параметра secure.
Если вы храните пароль сессии в переменной $_SESSION (все-таки лучше использовать sql), то не стоит хранить его в открытом виде.
Приведенный выше код не безопасный, так как пароль хранится в виде обычного текста в переменной сессии. Вместо этого используйте md5-шифрование, примерно так:
Проверка браузера
Срок действия сессии
Ограничьте время жизни сессии, а также время действия cookie. По умолчанию срок действия сессии 1440 секунд. Изменить это значение можно через php.ini и .htaccess. Пример для .htaccess:
Привязка по IP-адресу
В определенных ситуациях (не всегда) следует установить привязку по IP-адресу. В основном когда количество пользователей ограничено и имеют статичные IP. Проверка может быть либо по списку разрешенных IP-адресов,
либо по IP-адресу для каждого запроса (только для статичных IP):
Следует осознавать, что полностью избежать взлома невозможно. Можно только максимально усложнить этот взлом любыми известными способами. Однако следует также не забывать о своих легальных пользователях, чтобы не осложнить им жизнь такой защитой.
Браузер я так понимаю, создает cookie с id юзера в зашифрованном виде (скажем с помощью md5). То есть если генерировать с помощью md5 user_id другой (17 к примеру) и заменить cookie, то получается можно получить доступ к юзеру с id 17? Или я что-то не понимаю?
Браузер ничего не создаёт. PHP создаёт куку со случайным значением — идентификатором сессии, и файл соответствующий этой куке. Подделать (или украсть) можно только эту куку.
@AlexeyTen как понять со случайным значением? то есть он его зашифровывает? Если зашифровать с другим значением доступ получается получить можно если других проверок нету(ip. ) и как php ставит файл, он отдает браузеру, а браузер, я так понимаю ставит.
Никто ничего не шифрует. Просто генерируется случайная последовательность символов, которая является идентификатором юзера.
Не юзера, а сессии. А что хранится в сессии, PHP вообще не волнует (пока это можно правильно сериализовать/восстановить)
Ну да. Только генерировать случайные идентификаторы и надеяться, что попадёшь в существующую сессию. Шансы на это крайне малы. В общем, сессии не подделывают. Их крадут, но это уже совсем другой разговор.
3 ответа 3
У сервера есть ящик. В ящике лежит user_id = 22. Сервер на ящик прибивает табличку с какой-нибудь аброкадаброй и хранит у себя все время сам ящик, никому не дает его.
Затем сервер говорит браузеру: "Запиши, браузер, аброкадабру с таблички этого ящика. В следующий раз, когда придешь снова, сообщи мне ее и я загляну в ящик с этой табличкой, чтобы узнать тебя".
На самом примитивном уровне концепции "сессия-кука" это действительно так, но на практике такой простой подход уже используется редко - хотя бы потому, что с увеличением "табличек"(пользователей) увеличивается и вероятность их случайного "угадывания" - брутфорс. Многие используют простую модификацию, опирающуюся на второй фактор - например, привязка идентификатора к IP
У каждой PHP сессии уникальный код который нельзя так просто подобрать, а все данные сессии хранятся только на сервере этот "уникальный код" который устанавливается в cookie т.е работает так
Проще говоря можно представить что $_SESSION это файл сессии, user_id ячейка в этом файле, а 22 это значение ячейки user_id
P.s данные сессии не как нельзя получить на стороне пользователя (если их только самому не отдать ему к примеру выводом через echo $_SESSION['user_id']; )
Условно говоря, кука (в данном случае, айдишка в куке) прокидывается к атакующему.
Если кука прокинулась к атакущему, простейший скрипт позволит ему при получении куки автоматически сделать какие-нибудь нехорошие действия, например, зайти под вами в админку, перезаписать какой-нибудь файл, сохранить его, вы даже и не заметите, что произошло. Просто какой-то сервер в интернете за 1-2 секунды авторизовался под вами и сделал все что нужно. Изменил плагин вордпресса, например. А автор заразы в это время спит себе спокойно. Скрипт работает. А он спит. А у тебя сифилис на сайте. И какой-нибудь вредоносный код, заражающий пользователей.
В итоге - сервер заражен, пользователи заражены, "и мы в аду и ты горишь, сынок."
Это одна из причин, почему некоторые сайты не позволяют заходить одновременно с двух ip-адресов. Для идентификации пользователя используется пара id+ip.
И именно поэтому, например, какой-нибудь альфа-банк разлогинивает вас автоматически через, кажется, 10-15 минут неактивности. Пришел к тебе друг, а ты вышел собаку прогулять, а комп забыл залочить. Находясь в одной и той же подсети, например, можно стащить куку, и пара cookie/ip с другого компьютера в той же подсети вполне себе сработает без всякого ip spoofing. (тут я не в курсе, насколько защита от ip spoofing продвинулась за последние несколько лет)
p.p.s. если вы решите создавать куки самостоятельно, при помощи md5 от id пользователя, то не решайте так.
Какой-нибудь милый человек посмотрит сколько у вас примерно пользователей, после этого будет время от времени (в зависимости от количества пользователей) делать запросы с подходящим md5. Если вы еще приделаете список пользователей онлайн - будет еще легче. Про соль вы забудете, про перец забудете и в итоге сессия вашего юзера будет md5(1), md5(2), md5(n). Можно просто сделать md5(1) = авторизован = творю что хочу. Не балуйтесь с крипто, не прочитав про него.
Пользуйтесь встроенными механизмами генерации куки от php/почитайте про шифрование и хэширование.
p.p.p.s еще бывает очень смешно, когда session_id передают через get-запрос, т.е. session_id появляется в адресной строке браузера. Если посетителя вашего сайта попросят прислать ссылку на материал вашего сайта, или он сам выложит ее куда-нибудь, то произойдет авто-логин
Какой-то детсадовский механизм вы описали. Так ни кто не делает. Разве что студент или школьник какой. Уровень безопасности = 0 в данном примере.
Я вообще не использую встроенный механизм сессий.
А детсадовский в том, что из всей возможной информации сохраняется только логин.
В зависимости от задачи нюансы могут отличаться, но в общем случае примерно так:
1. Используем форму входа: Логин, Пароль. Пароль отправляется на сервер не в открытом виде, а в виде специального хеша (модификация на базы md5), который расчитывается на JS (если JS отключён, отправляется открытый пароль).
2. Если логин и пароль верны, в БД записывается рандомный код сессии, User_Agent и часть IP-адреса (обычно, первые 3 байта). В куки браузера записывается код сессии (вообще говоря, я обычно использую 2 разных кода сессии, 1 для идентификации, а 2-й для форм).
3. Идентификация пользователя происходит по совпадению кода сессии и User_Agent'а с частью IP-адреса.
Ни логин, ни пароли или ещё чего-либо подобное для идентификации уже не используется. Исключение: автовход, но это немного другая тема.
А если юзер зайдет с другого браузера или у него статичный айпи (или же он зашел с другого компьютера/через другой провайдер) то что тогда?
А если злоумышленник займется спуффингом и также подделает строку userAgent? Украдет куки? Заходи, бери, что хочешь?
На счёт захода с другого браузера не совсем понял, т.к. с другого браузера в любом случае придётся авторизироваться, будет новый код сессии.
А на счёт злоумышленника. Так идеальных способов защиты не существует (тем более, если мы говорим о случае простого сайта, без каких-либо специальных требований по безопасности). Что бы злоумышленнику воспользоваться чужой сессией, ему надо:
1. Украсть куки. Если писать скрипты аккуратно, то украсть куки через сайт не удастся, тогда вариант типа трояна. Но тут проще сразу пароль захватить при вводе.
2. Узнать, под каким браузером сидит юзер.
3. Подделать свой IP адрес так, что бы он совпадал (пусть даже первые 3 байта) с адресом жертвы. Для этого, как минимум, надо ещё и IP жертвы узнать.
Довольно много препятствий, которые рядовому хакеру преодолеть будет не так-то и просто. И куда надёжнее, чем просто хранить имя пользователя в сессии без какой-либо иной информации.
Модуль сессии не позволяет гарантировать, что хранимая информация доступна только пользователю, который создал сессию. Необходимо принять дополнительные меры по защите конфиденциальности сессии, основываясь на ассоциированных с ней данных.
Существует несколько способов утечки существующего идентификатора сессии третьим лицам. Такая утечка позволяет злоумышленнику получить доступ ко всем данным, ассоциированным с конкретным идентификатором сессии. Во-первых, передача идентификатора сессии в URL. При переходе на внешний сайт идентификатор сессии пользователя и адрес ресурса могут попасть в статистику переходов данного сайта. Во-вторых, при более активной атаке возможно прослушивание сетевого трафика злоумышленником. Если канал передачи данных не зашифрован, идентификаторы сессии будут переданы в виде простого текста. В таком случае решением является обязательное использование SSL пользователями при доступе к сайту. Для этих целей следует применять HSTS.
Вызов функции session_regenerate_id() может привести к персональной DoS атаке как и при use_strict_mode=On. Однако, DoS лучше, чем компрометация аккаунта. Пересоздание сессионного ID должно происходить хотя бы при аутентификации пользователя. Пересоздание ID уменьшает риск кражи сессии, поэтому рекомендуется периодически выполнять его. Разработчик не должен полагаться на устаревание сессионного ID. Атакующий может обращаться с сессионным ID жертвы периодически для предотвращения его истекания. Разработчик должен самостоятельно реализовать функционал для истекания старых сессий.
Обратите внимание, что session_regenerate_id() по умолчанию не удаляет старые сессии. Старая аутентифицированная сессия может оставаться доступной. Если разработчик хочет предотвратить дальнейшее использование старой сессии, то он должен уничтожать сессию, установив delete_old_session в TRUE . Однако, незамедлительное удаление старых сессий может привести к неожиданным побочным эффектам. Сессия может быть утеряна в случае нескольких конкурентных соединений к web-приложению и/или если сетевое соединение нестабильно. Вместо незамедлительного удаления вы можете установить маленькое значение времени истекания для $_SESSION. Если пользователь обращается с устаревшей сессией, отклоните его запрос.
Читайте также: