Мне интересно, если что-либо из массива $ _SESSION нужно экранировать, прежде чем использовать его в SQL-запросе.
Обратите внимание, что я не использую файлы cookie в своем приложении, так как я слышал, что они могут использоваться для захвата сеанса (?)
большое спасибо
Вам нужно избежать каждой строки, которую вы передаете в sql-запрос, без ущерба для его происхождения.
Даже если это данные, которые вы извлекли из своей базы данных.
Исходя из предположения, что еще предстоит выявить эксплойты в PHP, все должно быть экранировано с помощью подготовленных операторов или mysql_real_escape_string, прежде чем вы позволяете что-либо касаться вашей базы данных.
Данные, хранящиеся в $ _SESSION, не всегда чисты. Для многостраничных форм вы можете хранить ввод пользователя в $ _SESSION до последней страницы, когда вы записываете все это в базу данных. Если вы столкнетесь с какой-либо привычкой думать, что $ _SESSION «чист», вы в конечном итоге попадете в неприятности.
Вы должны абсолютно привыкнуть к тому, что каждая часть данных в вашей системе загрязнена, пока вы не ускользнули от нее. Обратите внимание: если вы используете динамические имена таблиц, экранирование не поможет вам. Никогда не используйте имена таблиц или столбцов в запросе, который когда-либо был рядом с пользователем. Различные экранирующие механизмы не ускользают от обратных сигналов. Если у вас есть подготовленный запрос:
"SELECT * FROM `:aTable`;"
и aTable исходит от пользователя, пользователя, который вводит что-то вроде
` WHERE id IN (DELETE FROM user);
потенциально просто удалил все ваши записи пользователя.
Переменная $_SESSION такая же, как переменная $_GET если она используется неправильно, поэтому ответ на ваш вопрос да, если ваш пользователь RAW загружает сеанс (который вы не должны делать), вам нужно будет его избежать ,
Переменные сеанса так же, как и любые другие переменные. Данные там должны откуда-то появиться. если вы прямо храните там размещенные переменные, то это в основном похоже на использование опубликованной переменной.
Единственный различие заключается в том, что переменная сеанса сохраняется в разных доступах, и это связано с этим.
Одно золотое правило никогда не является доверительным пользователем, кроме того, если данные не были получены от вас (т.е. ваша система), его следует рассматривать как «пользовательский ввод», и это, безусловно, включает данные сеанса.
С точки зрения экранирования данных сеанса для SQL вы можете и должны эффективно очищать данные для использования sql, например, используя mysql_real_escape_string (), но в зависимости от того, какие данные содержатся в сеансе, я также проверил бы сессию против того, что вы ожидаете, она должна содержать ,
Не слишком уверен в том, что вы имеете в виду в отношении комментария к хитрому файлу cookie / сессии, я полагаю, вы имеете в виду, что используете только сеанс для хранения данных? В типичных сеансах установки php по-прежнему используют файлы cookie исключительно как указатель на сеанс пользователя.