возможно все.

если используются куки, то хакер должен перехватить куки пользователя для этого. И отправить их, сессионную куку в том числе, сам, скажем, cURL'ом.

если используется параметр GET в ссылках, то достаточно просто узнать урл, по которому появлялся пользователь. и из него извлечь id сессии.

Блин с куками у меня напряг придётся изучать!!! а может использовать хэшированный айди юзера в имени сессии?

если украдут - ничего не поможет. только сверение id сессии с какими-то данными клиента. useragent, ip и т.п.

Спасибо блин хорошо что спросил теперь пока с куками не разберусь не выпущу сайт в свет
А вот ещё вопрос канечно не в тему но всё же он меня интересует в общем создал новостник у каждой новости есть свой айди по которой пользователь обращается к ней т.е выглядит так news.php?id=2 например и вот если вписать в строку браузера любое число больше истеного айди news.php?id=215468998 вот так например то открывается новость и коменты только новость пустая в общем я решил избавится от этого греха и сделал запрос к базе вытащил самый последний(большой) айди и сверяю его с айди переданным юзером по ссылке гетом если айди больше того который самый большой в базе то выдаю сообщение типа иди далеко и на долго проблема в том что он ещё ругается на последний айди который существует а с другими всё ок!

А нееет он ругается на все новости кроме 1 айди

Код. В. Студию.

Только не смейтесь

а такой запрос не пробовал?

Не надо тебе такая проверка. Проверяй результат запроса. Если вернул шиш, то и пиши - нет такого id

Вот мои комментарии:
По поводу зашиты id пользователя, на мой взгляд, самое безопасное использовать куку. Куки тяжело упереть.
У меня куки существуют, пока браузер открыт, потом удаляются. Таким образом еще тяжелее ее спереть. Но если нужно будет, например, запомнить пользователя на какой то срок. То куки должны сохраняться, даже после закрытия браузера.
Дальше.
В твой код, любой "дэбил" загонит инъекцию, дырень страшная (прорва)
А по поводу проверки, я бы сделал проще, по крайней мере -1 запрос к базе.
Смысл такой.
Мы с twin одинакого думаем
Зачем постоянно проверят самый большой id в базе?
Пусть id будет любое число. Ты ищешь в базе новость с таким id, а если она не найдена, что возвращается? Правильно ничего.
Делаешь проверку: если запрос ничего не вернул, тогда вывести сообщение, типа: Такой новости не существует.
И будет тебе счастье.

Ух ты спс запахало

Действительно я чёто не додумался так сделать всё сделал запахало всем спасибо вот сам код

Ну например кто нибудь напишет так:

Так это же чудесно!

При яваскрипте поможет https.
А при забывчевом пользователе поможет одноразовый вход.
Я на то и указываю, что с одной кукой, можно зайти только ОДИН раз.

Конечно же, 100% гарантии безопасности нет. Просто хочется, сделать все максимально безопасно.

twin, ладно.
Как тогда быть? Если не куки, тогда пользоваться добавлением sesid к ссылке браузера?

P.S. Я использую куки, только для хранения данных сессии.

Так.. стоп. А как их в базе то хранить?

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

Если все грамотно сделать, то куки не крадутся в принципе. Обычно куки, если они отправляются по http (опечатка была), очень легко получаются при помощи сниффера.

Хранение данных в сессии тоже не обеспечивает их защиту, потому стоит получить мне чужой id сессии, и я уже для сервера тот самый пользователь.

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

PS: ну я опечаток и наделал...

glock18 вот такой вопрос:

Допустим ты получил id сессии. И ты пытаешься авторизоваться.

Методы борьбы с этим есть?

А как их можно украсть?
Ну.. самые распространенные варианты

коспати, ну ты не читаешь что ли?

1. сниффер
2. xss - дырка в сайте.

В этой ветке точно оба варианта уже называли.

Прости

Ночь не спал. Тормажу сильно.

Я все понял, огромное спасибо!

https это слишком жестко.
Вообще что бы защитить на 100% сайт от взлома, нужно не делать его вообще. Но меры принимать необходимо. Все зависит от важности информации, которая на нем имеется.
Получить можно все что угодно, любые данные, используя прокси. Для сервера он клиент, а для клиента - сервер. Только это уж очень накладно и делать такое будут если игра стоит свечь. В остальных случаях вполне достаточно аунтифицировать пользователя и поставить в сессию флаг.
Сессия закроется сама через 24 минуты по умолчанию либо при закрытии браузера. Хранить отдельно в куках идентификатор сессии смысла нет, так как он и так там хранится. А вот любые другие данные о юзере, особенно пароль в любом виде или id не стоит вообще. Потому что нет человека - нет проблемы.
Есть простой способ аунтификации по случайной уникальной строке. Её нужно использовать как ключ и хранить в кукисах. Это при автологине. Потому что такая информация ничего не стоит. При повторном входе этот ключ лучше сменить. Ну и как уже сказал glock18, желательно прявязать его к клиенту. Другого алгоритма я по крайней мере не знаю.
Ну а при одноразовом входе вполне достаточно сессии с привязкой. Все равно на какое то время сервер должен как то различать свой-чужой.