3

我正在尝试使用 Omniauth 从头开始​​进行身份验证。

我关注了 Ryan Bate 的截屏视频。但在我推出一个实现之前，我想了解一些事情。

helper_method在他的截屏视频中，他有一个application_controller：

helper_method :current_user

private

def current_user
  @current_user ||= User.find(session[:user_id]) if session[:user_id]
end

上面的代码，检查user_id.

我知道会话是加密的（并存储在 cookie 中）。但是，它们是可读的，但不能修改。有人用假的劫持会话有多难user_id？是什么阻止了任何人从头开始或通过某种“cookie 注入器”方法（如果存在这种情况）创建 cookie。

我试图了解这些 cookie 是如何受到保护的。

4

2 回答 2

3

会话通常保存在服务器端，唯一通过 cookie 传入/传出客户端的是会话标识符。在该 cookie 中存储实际会话数据将是一个主要的安全漏洞，无论它的加密程度如何。例如，如果您很便宜并使用 rot-13 “加密”，那么用户对数据和 set 进行摆弄将是微不足道的superuser=1。

但是对于会话 ID，这是不可能的 - cookie 中没有任何内容可用于摆弄服务器端数据。充其量他们可以发回随机会话 ID 值，并尝试劫持其他人的会话。使用足够大的 ID 哈希，找到另一个会话劫持的机会非常小。

于 2013-02-14T15:07:03.983 回答
1

我认为您提供的链接给出了最好的答案。并且涵盖了许多更隐蔽的攻击，我更关心敏感应用程序。

在 Rails 中，提交包含会话数据的伪造或篡改的 cookie 是非常困难的，因为 cookie 由服务器签名，并检查提交的 cookie 以确保签名正确。更改 cookie 值需要知道服务器签署 cookie 所用的密钥。

最好的做法是在会话中只存储非常小的位（最好是 ID），如果您担心有人能够从头开始创建包含用户 ID 的会话 cookie，简单的答案是：不要把用户.id 在 cookie 中。而是为每个用户生成一个 GUID，作为 cookie 中的 id。这样您就可以在 URL 中公开 user.id，而不必担心知道某些用户的 id 会允许攻击者伪造一个有用的 cookie。

于 2013-02-15T12:41:13.263 回答