Вероятно, Вы не очень хорошо себе представляете механизм работы сессии. На деле, при открытии сессии, ключ доступа к ней отправляется клиенту, но данные сессии хранятся на сервере. Распространённым способом хранения ключа сессии является кука (та самая PHPSESSID как пример).

Теперь вспомните о том, как работает HTTP-протокол. При переходе по ссылке он отправит (на самом деле "он" - это, конечно, браузер, который следует HTTP-протоколу) в Request-запросе куки, относящиеся к домену того хоста, на который делается запрос. И, значит, ключ сессии будет передан таким образом через HTTP-запрос. Если соответствующая сессия открыта на сервере, то есть ключ распознался - клиент получает доступ к данным сессии.

Так вот, собственно, http_only означает, что ключ сессии может быть получен/передан/установлен только через HTTP-протокол, но не через иные средства. То есть, к примеру, нельзя будет оперировать с ним в javascript через document.cookie - любыми способами. Это приводит к невозможности чтения этой куки - и, значит, если имеется XSS-уязвимость, то злоумышленник не сможет прочитать ключ сессии, хранящийся в куки, и, значит, атака не будет успешной. Разумеется, такой функционал должен поддерживаться именно браузером - ведь именно он решает, допускать ли чтение куки или нет - поскольку исполнение того же javascript происходит в контексте браузера.

так тс говорит,если нет xss,то зачем упираться в ограничения браузеров?

likvidator
ТС сторонник того, что бы передавать эти данные посредством http. А вы наоборот. Видимо, мы друг друга не понимаем. Вам EuGen уже написал, мне нечего повторять... отпостил он по поводу вашего возражения, при чем тут я ?

Если нужен 404 - mod-rewrite вам в помощь. Однако проще заинуть все инклуды в папку на уровень выше DOCUMENT_ROOT и к ним стопудово никто не получит прямого доступа.


Если он не получит session_id - он не сможет оправить этот id серверу, а сервер не сможет опознать какая сессия используется.
session_id передается в любом случае, но с установкой этого параметра идентификатор нельзя будет передать, например, аяксом. Но не все браузеры поддреживают данное ограничение. (Так написано в мануале, если я правильно понял)


это две совершенно разные атаки - XSS и SQL-injection. Фильтрация данных при записи в базу защищать должна именно от инъекций.

по кэшированию статейка http://www[dot]codenet[dot]ru/webmast/php/caching.php


Если в течение одного http-запроса происходит несколько одинаковых запросов к БД имеет смысл сделать таие запросы подготовленными.

http_only следует устанавливать. Суть в том, что никогда нельзя быть уверенным в том, что в веб-приложении нет уязвимостей. Дополнительную возможность защиты это обеспечит - по крайней мере для тех браузеров, которые этот флаг поддерживают. Если же браузер не распознаёт такой флаг - то будет попросту обычное поведение. Иными словами, если предположить, что 70% браузеров поддерживают такой режим (цифра взята с потолка, более предметно - здесь), то, устанавливая http_only, можно приобрести дополнительную защиту от XSS в 70% случаев. Это намного лучше, чем 0% случаев, и при этом оно даётся таким простым способом. Поэтому не вижу причины, чтобы не пользоваться такой возможностью.

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


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


Да, это я в общем смысле спросил, может нарвусь на какие замечания )

А за статью спасибо, как только дочитаю ссылку от vanicon-а перейду на вашу )
(Добавление)
EuGen
Да, честно говоря, я тоже так думаю... Как раз хотел получить более точный ответ, благодарю что смогли объяснить мне это окончательно в двух словах...

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

Нет, это не бред. Это один из хороших способов защитить кратковременный сеанс. Суть в том, что применимость данного подхода ограничивается длительностью сеанса и интервалом смены внешнего адреса. У некоторых ISP действительно бывает так, что адрес меняется с периодичностью порядка нескольких часов. Если продолжительность сеанса работы с веб-приложением превышает данный интервал (это нечасто, но всё же - бывает), то такой способ защиты может вызвать проблемы - от неудобств до серьёзных потерь. На практике описанный случай встречается нечасто, поэтому проверка IP-адреса при работе с авторизованной частью - как правило, хорошая практика. При этом следует помнить, что, так как пользователи часто находятся за NAT, то эта проверка не подойдёт для отсеивания запросов от другого пользователя, расположенного за тем же NAT

Не юзаю. Не знаю как поведет себя ajax в таком случае. И еще настройка окружения - ЗАДАЧА СИСАДМИНА

Правильней всего сделать единую точку входа. В вашем же случае сделайте файл(например bootstrap.php) и подключайте его во всех фалах. А внем уже делайте session_start и прочую инициализацию

abs - по модулю. значит он не нужен. Если пользователь указал в строке id=-1 то выдаем 404. У вас же будет контент от id=1 а ето уже не правильно
(int) делает то же самое что и intval. разницы нету. Мне больше нравиться (int)

только при запросах к базе. но никак не такое: