【发布时间】:2015-11-17 16:24:58
【问题描述】:
注意:我已更新并重写了我的问题,以尝试逐点解决此问题。干杯。
我有一个问题,我不确定如何解决它。
我一直在 HTTPS 服务器上构建一个安全的登录系统(如果值得的话,SSL-labs 的等级为“A”),它工作正常,但是今天它拒绝让我登录,一些调试我发现了一些非常奇怪的东西(在我看来)。
我在网站上的会话处理有一些严重的问题,不同的页面使用相同的会话数据(当然)和相同的会话/cookie设置,并且它们正确地在彼此之间传递信息,但是 我的浏览器的行为似乎就像有两个浏览器访问相同的网站,使用相同的会话数据。
症状 - 因为我一直与页面生成的会话内容(唯一哈希令牌)不一致,不适合登录表单中保存的相同数据(作为$_POST 值),我发现只有一行在设置会话值的整个站点中,此行必须运行两次。所以我在会话中设置了一个计数器值,在表单页面上为session['counter']。每次页面加载时,计数器 +1。我的问题具体在于:
登录页面:
Opens page,
session hash-string is generated and saved to the post form.
session counter = counter + 1;
Form is filled in.
登录验证页面:
fails to verify the posted hash-string is the same as the session hash
string, despite there being no other cause for the session values to
change (well there must be, but I can't see it!)
但是,然后回到登录页面,我看到计数器 = 最后一个值 + 2!此外,记录在服务器上保存的会话文件中的计数器值始终是登录页面上显示的值的 +1。
一些图片:
登录表单页面:请注意,它位于 HTML 输出上方,并且是代码中编辑任何 SESSION 数据的最后一个位置。
输出:
请注意图 1 中与计数器相关的数字。
我的会话文件,这个文件与这个特定的浏览器会话有关,并且只有 1 个会话文件,因为我是网站上唯一的浏览器。
字符串CheckDrop 是要比较的哈希值,但计数器位于12 而不是11,如上图2 所示。
我的网站已通过 HTTPS 身份验证,尽管此作品位于子域上。
这个问题在过去 3 小时内一直存在,但不一致,它在今天早些时候神奇地工作了大约 40 分钟(就在发布这篇文章之前)。但我没有做任何我认为改变环境的事情。
我之前比较过 phpinfo 数据和会话设置数据,在浏览器输出点上看起来都正确。好像不是我的设置造成的。
它发生在我电脑上的不同浏览器上。
进一步的工作
在花费数小时调试并解决此问题后,这似乎是浏览器问题。我已经重命名了页面(一个页面被称为索引,而它没有在 .htaccess 中定义为目录列表页面,它可能可能导致浏览器打开它两次)。
我已经清除了所有相关数据:会话/数据库记录/浏览器历史记录,并且遇到了一些事情:
Firefox 现在按预期登录,计数器为 count+1 并且登录有效,但是在 Chrome 上,相同页面上的完全相同的登录不起作用,并且浏览器似乎加载了两次,counter = counter + 2。 Chrome 还会在每次加载时在数据库中留下两条记录,而不是预期的一条。
Chrome 版本 45.0.24 火狐42.0版
页面重复计数并在 Safari 和 Chrome 上运行两次脚本。在 Firefox、Opera 和 MSIE 上,它按预期工作。
知道为什么会发生这种情况?
我该如何解决这个问题?
【问题讨论】:
-
“加盐”...我总是看到每个人都说不要在标准
password_hash函数中使用自己的盐。 -
不是哈希盐,是字符串中的盐变成了哈希
-
所以让我确保我明白了这一点:您正在对用户代理和 IP 进行哈希处理,然后将它们放入表单的隐藏输入中?他们都会在请求中返回,因此您最好检查请求标头上的 ip 和 user-agent 是否与会话中的内容匹配。你这样做的方式(除非我误解了),如果有人截获了 html,他们可以通过在 post 参数中显示哈希来模仿另一个人的 ip。
-
这是一个令牌 CSRF 检查,@developerwjk -
-
将值与当前浏览器进行比较,但会话中的值也会与 POST 中的值进行比较。它们不是相互排斥的比较。 @developerwjk
标签: php google-chrome session