0

我正在设计一个身份验证系统，将一些散列字符串作为“令牌”存储在客户端机器上

localStorage['tokens'] = [username, string1, string2, .... ]

并且还将这些标记与数据库表中的一行相关联

____________________________________
| Table: current_user_sessions     |
------------------------------------
| username | token1 | token2 | ... |

因此，每当用户尝试完成某个操作时，客户端计算机都会查询数据库，询问具有匹配令牌和用户名的行，以验证用户是否登录到有效会话中。

我将这些令牌作为变量发送到检查以确保会话有效的 php 页面。

$tokens = $_GET['tokens']
$session_is_valid = query_that_checks_db_for_tokens($tokens)
return $session_is_valid

某人是否有可能通过 XSS 攻击访问另一个用户的 localStorage，这是保持用户会话安全的不安全方式吗？

4

3 回答 3

2

您的浏览器使用同源策略保护本地存储，因此在托管的页面上运行http://a.com的 Javascript 代码无法访问在 的页面上运行的 Javascript 代码存储的本地存储http://b.com。如果您的网页存在 XSS 漏洞并且人们可以将 Javascript 代码注入其中，他们就可以访问您的本地存储。

话虽如此，您的方案似乎是合理的。花一点时间来确保您的页面没有任何 XSS 漏洞似乎是一种很好的利用时间。

于 2013-10-20T00:23:21.887 回答
0

这种方法的主要问题是本地存储易受 XSS 攻击，因为它可以通过 JavaScript 访问（当然，拥有易受 XSS 攻击的页面本身就是一个问题）。如果您的令牌小到可以放入饼干中，那么这是放置它们的最佳位置。

如果您在 cookie 上设置 HTTP-only 标志，浏览器将不允许 JavaScript 访问它。如果您在 cookie 上设置 Secure 标志，浏览器将仅使用 HTTPS 请求发送它。如果您要发送与安全相关的令牌，您可能应该同时使用这两个标志。

于 2013-10-20T05:14:47.997 回答
-1

如果用户数据很小（或可以压缩）并且适合用户 cookie，您应该使用 cookie。这避免了对本地存储的需求以及随之而来的安全问题。

如果不是这种情况，那么您将被迫使用本地/集中式存储，当您从 http 参数读取令牌并直接在 mysql 查询中使用时，您应该注意的主要事项是sql 注入。通常使用mysql_real_escape_string或参数化查询来防止这种情况（详见此处）。您还应该转义您的输入以防止XSS独立于您的会话存储策略。

一些需要注意的细节：

  • 用户名是唯一标识符（某种 guid）。
  • 通常用于存储会话的更快方法是使用 memcached 集群存储会话数据。
  • 由于您正在更新用户数据，因此请注意跨端请求伪造并使用碎屑。
于 2013-10-19T18:32:00.843 回答