0

我在 IIS 后面的服务器中部署了一个 ASP.NET 核心 REST API。REST API 由 Angular JS Web 应用程序和移动（Android/IOS）应用程序使用。对于授权，我使用的是 JWT token()。最近通过安全审计，他们发现存储在本地存储中的 JWT 可以被同一组织的其他攻击者窃取并用于冒充（例如，员工利用经理的功能）。

我想将这个人或那台机器标记到那个 JWT 上，这样当 JWT 被盗时，攻击者就不能滥用它，或者不会使用那个被盗的令牌。我尝试使用 JWT 令牌标记 IP 并将这些查找存储在服务器中（在内存缓存中）。下面是我试过的代码，没有用。

private readonly IHttpContextAccessor _httpContextAccessor;
public TestController(IHttpContextAccessor httpContextAccessor)
{
    _httpContextAccessor = httpContextAccessor;
}
var ipAddress = _httpContextAccessor.HttpContext.Connection.RemoteIpAddress.ToString();

每次我从不同的机器请求时，我都希望输出不同。但是每次像 15.11.101.25 这样的实际输出都是相同的 IP（尽管我从不同的机器上尝试过）。如果有的话，请与我分享一些更好的解决方案。原谅我的英语。

4

1 回答 1

4

如果您确实需要这种安全性，您可以将 JWT 令牌与安全（=cookies 只允许通过 https 发送）http-only cookie 结合起来，并在其中存储一种请求令牌，在每个请求中发送。

您可以阅读JWT 的存储位置 – Cookie 与 HTML5 Web 存储，其中涵盖了该主题并解释了 JWT 本地存储与 cookie 的优缺点。

仅 Http cookie 无法通过 JavaScript 读取（因此不会被盗），因此可以抵御 XSS 攻击。基于 CSRF 的攻击无法获取 JWT 令牌（因为它是通过标头发送的）。

所以基于 XSS 的攻击不会有基于 cookie 的令牌，基于 CSRF 的请求不会有验证用户所需的 JWT 令牌。cookie 令牌可以在登录时生成，因此它与登录该机器的用户相关联。

当然，您也可以将它转过来，将 JWT 放在安全的库克中，并将反请求令牌作为标头。

当然，您仍然可以通过物理访问机器来窃取防伪 cookie，但这既不是 XSS 也不是 CSRF，并且不能仅由应用程序保护，机器本身需要保护免受物理类型的攻击。

或者，不要将 JWT 令牌存储在本地存储中。当您使用 OpenID 流程时，您的应用程序将在第一次加载时看到它未授权，会将您重定向到 OpenID 提供程序，让用户输入他的凭据并使用令牌（或身份验证代码的代码）将其重定向回流动）。

当用户关闭浏览器并再次打开站点时，不再有令牌，用户将被重定向到 OpenID 提供程序。由于用户仍处于登录状态，因此不会询问任何凭据，并且他将被重定向回他来自的页面，包括一组新的令牌。您只需要为当前应用程序会话将令牌存储在内存中（并在过期时刷新）。

于 2019-01-02T17:42:22.247 回答