Если я выгружаю настройки отображения разных данных в сессионную переменную, насколько это безопасно? Существует ли вероятность "подмены" или все зашифровано?

И как лучше хранить настройки тогда? Каждый раз из сервера брать?

Если, допустим, не брать пока вариант с кражей по вифи, а просто исключить вариант подмены. Хранить настройки в зашифрованном виде или они уже?

vkleНа нормально настроенном сервере файлы сессий недоступны для посторонних. Как вариант, можете определить свои функции работы с сессиями и хранить/шифровать данные так как считаете нужным.


_Промешан_И как лучше хранить настройки тогда? Каждый раз из сервера брать?Пользовательские настройки имеет смысл хранить в БД. Ибо сессия помрет вместе с настройками по истечении времени или при рестарте вебсервера.

Как "нормально" настроить сервер? Или как понять, нормально ли он у меня настроен? Где посмотреть?

Пользовательские настройки и так в бд хранятся. Но строкой. И чтобы при гулянии по страницам не грузить каждый раз сервер, я их скачиваю в переменюю сессионную. Вот тут как быть? Понятно что умрет сессия, умрут и настройки. Вроде бы очевидно. Настройки я гружу один раз при лоигне.

vkle_Промешан_Или как понять, нормально ли он у меня настроен? Где посмотреть?Это называется аудит безопасности. В данном конкретном случае доступ на чтение сессионных файлов должен быть только у пользователя, от имени которого работает сайт. Другие пользователи сервера не должны иметь доступа. Разумеется, и вебсервер с php должен быть соответствующим образом настроены, с использованием suexec, например. Ну, это по месту смотреть...


_Промешан_Пользовательские настройки и так в бд хранятся. Но строкой. И чтобы при гулянии по страницам не грузить каждый раз сервер, я их скачиваю в переменюю сессионную.Это же, наверняка, не единственное обращение к БД при генерации странички. Не думаю что операция чтения из БД столь накладна. Кроме того, хранение данных в файле так же потребует обращения к диску и распаковки данных из строки (именно так хранится сессия) в память. Конечно, можно говорить о файловых буферах, но и у мускуля есть кеш запросов. ИМХО выигрыш от хранения копии данных в сессии весьма сомнителен.

У меня веб сервер на хостинге. МНе у хостеров спросить про suexec?

А можно объяснить "другие пользователи сервера не должны иметь доступа". Это как? Если вы про соответствующий логин/пароль к бд - то подозреваю что он единый и админский. Вы про это?

vkle,

авторНу это же основы безопасности.А можно в двух-трех словах про это? Как что возможно и как этого избежать.

vkle_Промешан_в двух-трех словахНачните с этого . Ну и смотрите, можете ли Вы своим скриптом прочитать файлы сессий (да и остальные тоже) соседа по хостингу, может ли он прочитать Ваши файлы.
Я наверное чего то не понимаю. Кто то может войти на сервер кроме меня? и что то скачать или редактировать?

Как определяется, смотрит страницу владелец или обычный пользователь. Про chmod я немного в курсе.

vkleДругих пользователей нет на сервере? Это Ваш личный, выделенный сервер?
вы имеете в виду доступ через консоль?

Просто как это в купе относится к первоначальному вопросу про сессии?

Ренат_Промешан_пропущено...

вы имеете в виду доступ через консоль?

Просто как это в купе относится к первоначальному вопросу про сессии?
если вы покупаете хостинг у стороних фирм, значит вы арендуете у них часть компьютера (либо весь, но стоит десятки тысяч в год). И посколкьу это только часть, то на этом же сервере у них хостятться еще от 10 до 100 человек. Если хостинг это не VDS и все его производные, то одна операционная система будет на всех.енто как бы понятно. какое это отношение имеет к сессиям? Я говорил пока что про подмену при использовании браузера.

stopkran_Промешан_,

с помощью браузера подменить что-то на сервере нельзя. Но с помощью, например, FTP-клиента - можно. Закачиваете на свой сайт файл php, в нём пишете любую команду (например, `ls`), и читаете список файлов (ну, открыв файл php из браузера...). Потом поднимаетесь на уровень вверх (..), и опять читаете. И так - до '/'. А потом опускаетесь, но уже не в папку своего shared-аккаунта, а в папку соседа... И воруете там у него всё: файлы, сессии...

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

Ок. Я правда не совсем понял, как мне это проверить. Завести новый акк что ли на том же хостинге?

А то каким образом некто может что то загрузить в мою папку через фтп. С какой стати?

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

вот такая команда на пхп:

вот такая команда на пхп:
$output = `ls -al`;
echo "<pre>$output</pre>";

Warning: shell_exec() has been disabled for security reasons in some.php on line 2

Ренат,

вы правы. Прокатывает. Можно выполнить. Но если у пользователя нет доступа к фтп, то есть чего опасаться?

vkle_Промешан_если у пользователя нет доступа к фтп, то есть чего опасаться?Уязвимости в ПО (в том числе в скриптах движков) таки иногда находят. Самописные скрипты бывают написаны "на коленке", лишь бы работало, без полной проверки входных данных. Отсюда и спам-рассылки через формы заказов, и заливка скриптов злоумышленниками...

ТОже понятно.
Вернемся к сессиям. Что с ними, кто-то знает? Безопасно ли?

так, кажется я все понял. Причину своих вопросов. Невежество.
Я то думал, что информация о настройках скачивается пользователю в куку. А в куке только Ид сессии. Все переменные на сервере. Блин. Ну надо же я так тупанул. пхп ж с пользователем не связана никак.

vkle,

Вот теперь хотя бы понятно, почему лучше из базы грузить настройки и что ничего тут не сделаешь.

или можно обезопасить?

А и вопрос - где хранится сессия на сервере? Я могу получить доступ у хостера к этим данным, с учетом вышеизложенных запретов?

nscl1). Пишем в сессию IP и User_Agent пользователя.
2). Если пришел запрос с другого адреса или из другого браузера - скрипт считает запрос невалидным и выбрасывает на страницу логина.
Если у вас есть или планируется работа через WiFi - включаем HTTPS.
Дешево и сердито.Хм. Я так понял что и это бесполезно. Точнее, тогда надо будет каждый запрос сверять агента и ип?

Как это сделать? А что если у человека ИП не постоянный? А если он из подсети?