Является ли $ _SESSION правильным способом для безопасной передачи данных по многим страницам?

Как всегда, детали реализации наиболее важны. В общем, использование сеанса для сохранения состояния, связанного с сеансом входа пользователя в систему, является хорошим, на самом деле, это является целью сеансов. Однако есть предостережения.

Объекты и сериализация

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

Сессионные магазины

У вас есть несколько вариантов для вашего магазина сессий. Это может быть память вашего приложения / веб-сервера, ваш сервер может сохранять содержимое сеанса в файлах или сохранять их в базе данных SQL или NoSQL и т. Д. Контроль доступа к хранилищу сеансов является ключевым, любой, имеющий доступ к хранилищу сеансов, может изменять сеанс содержимое для любого пользователя. Например, Redis часто используется для хранения данных сеанса, но контроль доступа Redis не очень силен. Кроме того, если данные сеанса хранятся на веб-сервере, любой администратор на сервере будет иметь практически неограниченный доступ к любому сеансу пользователя, вошедшего в систему, что может быть или не быть проблемой, в зависимости от вашего сценария.

Проблема аннулирования кэша

Если вы запрашиваете базу данных только один раз и сохраняете данные в сеансе после первого запроса, вы по существу используете сеанс в качестве кэша со всеми связанными проблемами. Наиболее важным из них с точки зрения безопасности, вероятно, является недействительность кэша. Представьте, что вы сохраняете права доступа пользователя к сеансу при входе в систему, поэтому вам больше не нужно их запрашивать. Что если пользователь войдет в систему и сохранит свою сессию в течение длительного времени (если позволяет абсолютный тайм-аут сеанса, если он есть), но его права доступа тем временем изменяются, что наиболее важно, если права аннулируются? Ваш кеш в сеансе будет недействительным, если вы не разработаете логику для аннулирования кеша, что может быть довольно сложно в некоторых хранилищах сеансов, но все же сложнее в более простых. Одним из способов снижения этого риска является принудительный выход из системы, но это также влияет на используемое хранилище сеансов.

Связанные с сеансами уязвимости приложений

Еще одна угроза, которая приходит на ум, заключается в том, что из-за недостатков безопасности в вашем исходном коде ваше приложение может позволить пользователю в некоторой степени редактировать содержимое сеанса. Если вы сохраняете весь объект в сеансе и больше никогда не обращаетесь к базе данных, такая уязвимость может позволить злоумышленнику повысить свои привилегии и получить доступ к вещам, к которым у него не должно было быть доступа. Очевидно, что вероятность такой уязвимости, которая позволила бы редактировать содержимое сеанса, вероятно, не очень высока, и, если такая уязвимость существует, это также повлияет на ваше приложение, если оно будет обращаться к базе данных при каждом запросе. Тем не менее, влияние такой атаки может быть ниже в последнем случае.

Заключение

По сути, небезопасно хранить пользовательские объекты в сеансе. Вы можете сделать это, если вы смягчаете или принимаете риски. Тем не менее, вы должны знать о проблемах, описанных выше и решить для себя, являются ли они подлинными рисками для вашего приложения, и можете ли вы смягчить или принять их.