javascript 会话存储可以安全吗？

Can session storage be safe?

提问by AppBuilder

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?

我想使用会话存储只查询一次数据库中的用户数据，然后简单地使用JS来检索它，所以我正在考虑使用会话存储。接下来我的问题是，那安全吗？

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.JS 不能插入带有表单的页面（表单只接受字母数字值）所以只能来自 URL

1.1Query strings like www.website.com/?q=blablabla are not used in php (php doesn't retrieve any data from url)

1.1php中没有使用像www.website.com/?q=blablabla这样的查询字符串（php不从url检索任何数据）

1.2Calling 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.2使用 javascript:script 在 url 中调用 js... 不是一个大问题，因为用户只能访问他自己的数据，更不用说他已经可以访问它了——这就是用户数据的重点

1.3Is 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...

1.3是否有第三种方式将用户通过包含 JS 的链接重定向到该站点，该链接将能够访问会话存储？即：类似 - 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?

我的猜测是只有像 1.3 这样的东西才会构成威胁（除此之外，我是否遗漏了什么？）但这是否存在？如果是这样，有没有办法防止它？

Thanks for your time and replys.

感谢您的时间和答复。

回答by Paystey

You're essentially relying on two things for session storage security:

您基本上依赖于会话存储安全性的两件事：

1. The browser limiting access only to the javascript on the page from this domain
2. javascript that is running on the page to be secure

1. 浏览器限制仅访问来自该域的页面上的javascript
2. 在页面上运行的 javascript 是安全的

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, mostof them are usually pretty good at this kind of thing.

现在，对于第 1 项，您无能为力，因为那是供应商的问题，并且不是特别针对任何人，但是，他们中的大多数通常都非常擅长这种事情。

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.

但是，第 2 条更难，您必须自己评估您的页面对脚本攻击的安全性，那里有大量关于最佳实践的文档，但您可以继续使用数天。您确实需要判断数据的敏感程度与保护数据的工作量和可能丢失的功能。

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.

如果它真的是敏感数据，我会质疑您为什么要冒险将其存储在客户端并且只能通过 HTTPS 访问。但是对于大多数脚本攻击，您的站点应该是安全的，因为如果 3rd 方 javascript 正在运行，会话 cookie 就会被抢夺，因此您的服务器安全也会受到影响。

回答by chiborg

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.

由于会话存储只能由在您的页面上运行的 JavaScript 读取，我认为您的问题归结为“如何将 JavaScript 执行/插入到我的页面中？” 有两种攻击方法：XSS，意思是通过向您的站点发布数据将 JavaScript 注入您的页面的某种方式。如果未过滤此数据，它可能会将脚本标记或 JavaScript 事件插入到您的 HTML 中。有很多方法可以做到这一点并防止它发生，所以我不能更具体。

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.

较小的威胁是通过在您的页面上调用特定操作的特制链接来诱使站点显示或更改信息。这种技术称为CSRF。示例：有人制作了一个指向“更改电子邮件”页面的链接并欺骗登录的用户单击此链接，这会更改会话存储中的电子邮件信息。

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.

如果您的应用程序是公开的，任何人都可以在他的浏览器中打开会话存储并查找密钥的名称。因此，除非它们是随机的，否则默默无闻在这里没有任何保护。