会话存储安全吗？
我想使用会话存储来查询数据库中的用户数据一次，然后简单地使用JS来检索它，所以我正在考虑使用会话存储。接下来我的问题是，这样安全吗？
请注意：
1. JS 无法插入到带有表单的页面（表单只接受字母数字值），因此只能来自 URL
1.1 > php 中不使用像 www.website.com/?q=blablabla 这样的查询字符串（php 不会从 url 中检索任何数据）
1.2 在 url 中使用 javascript:script 调用 js... 不是这不是一个大问题，因为用户只能访问他自己的数据，更不用说他已经可以访问它 - 这就是用户数据的要点
1.3 是否有第三种方式将用户重定向到通过包含 JS 的链接访问会话存储的站点？即：类似 - www.website.com/script...
我的猜测是，只有像 1.3 这样的东西才会构成威胁（除此之外，我是否遗漏了一些东西？）但这是否存在？如果是的话有没有办法预防呢？
感谢您的时间和回复。
I would like to use session storage to query user data in the database only once and then simply use JS to retrieve it, so I'm thinking about using session storage. My question is next, is that safe?
Please note:
1. JS can't be inserted to pages with forms (forms only accept alphanumeric values) so it can only come from URL
1.1 Query strings like www.website.com/?q=blablabla are not used in php (php doesn't retrieve any data from url)
1.2 Calling js in url with javascript:script... isn't a big concern since the user can only asccess his own data, not to mention that he can already access it - that's the point of user data
1.3 Is there a third way of a user being redirected to the site via a link that contains JS that will than be able to access session storage? i.e.: somthing like - www.website.com/script...
My guess is that only something like 1.3 would be a threat (in addition to that, am I missing something?) but does that even exist? And if so is there a way to prevent it?
Thanks for your time and replys.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您本质上依赖于会话存储安全的两件事：
现在，您对第一无能为力，因为这是供应商的问题，并不是特别针对任何人，但是，大多数他们通常非常擅长此类事情。
因此，您可以相当确定任何其他选项卡、域、浏览器或进程上的其他代码都无法看到您的存储对象。
然而，第二个更困难，您必须自己评估您的页面对于脚本攻击的安全性，有大量关于最佳实践的文档，但您可以持续几天。您确实需要判断数据的敏感程度以及保护数据所需的工作量和可能的功能损失。
如果它确实是敏感数据，我会质疑为什么您要冒险将其存储在客户端并只能通过 HTTPS 进行访问。但是您的站点应该受到大多数脚本攻击的保护，因为如果第 3 方 javascript 正在运行，会话 cookie 就会被窃取，因此您的服务器安全也会受到损害。
You're essentially relying on two things for session storage security:
Now there's not a whole lot you can do about No. 1 because that's the vendor's issue and, not pointing at anyone in particular but, most of them are usually pretty good at this kind of thing.
So you can be fairly sure no other code on any other tab, domain, browser or process is going to be able to see your storage object.
However, No. 2 is more difficult, You'll have to evaluate by yourself how secure your page is to script attacks, there's plenty of documentation out there on best practices but you could go on for days. You really need to judge how sensitive the data is versus how much work and possible loss of features it would be to secure against it.
If it's really sensitive data I'd question why you'd risk storing it client side at all and have access only through HTTPS. But you're site should be secured for most scripting attacks because if 3rd party javascript is running session cookies are up for grabs and therefore your server security is compromised too.
由于会话存储只能由页面上运行的 JavaScript 读取，因此我认为您的问题可以归结为“如何将 JavaScript 执行/插入到我的页面中？”有两种攻击方法： XSS， 意思是通过发布某种方式将 JavaScript 注入您的页面数据到您的网站。如果未过滤此数据，它可能会将脚本标记或 JavaScript 事件插入到您的 HTML 中。有很多方法可以做到这一点并防止它，所以我不能更具体。
较小的威胁是欺骗网站通过特制的链接调用您页面上的特定操作来显示或更改信息。这种技术称为CSRF。示例：有人制作了一个指向“更改电子邮件”页面的链接，并欺骗登录的用户单击此链接，这会更改会话存储中的电子邮件信息。
如果您的应用程序是公开的，任何人都可以在其浏览器中打开会话存储并查找密钥的名称。因此，除非它们是随机的，否则模糊性在这里无法提供保护。
Since the session storage can only be read by JavaScript that is running on your page, I think your question boils down to "How can JavaScript be excuted/inserted into my page?" There are two attack methods: XSS, meaning some way to inject JavaScript into your page through posting data to your site. If this data is not filtered, it may insert script tags or JavaScript events into your HTML. There are many ways to do this and to protect against it, so I can't be more specific.
A lesser threat would be to trick the site into displaying or changing information through specially crafted links that call specific actions on your page. This technique is called CSRF. Example: Someone crafts a link to the "change email" page and tricks a user who is logged into clicking this link, this changing the email info in the session storage.
If your application is public, anyone can open the session storage in his browser and look up the names of the keys. So unless they are randomized obscurity offers no protection here.