如何保护 ASP.NET Core Web API 免受被盗 JWT 令牌的模拟攻击

vin*_*hvs 2 mobile angularjs asp.net-core asp.net-core-webapi asp.net-core-security

我在 IIS 后面的服务器中部署了 ASP.NET core 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();
Run Code Online (Sandbox Code Playgroud)

我希望每次从不同的机器请求时输出都会不同。但实际输出每次都是相同的IP,如15.11.101.25(尽管我在不同的机器上尝试过)。如果有更好的解决方案请与我分享。原谅我的英语。

Tse*_*eng 5

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

\n\n

您可以阅读Where to Store your JWTs \xe2\x80\x93 Cookies vs HTML5 Web Storage,其中涵盖了该主题并解释了本地存储与 JWT cookie 的优缺点。

\n\n

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

\n\n

因此,基于 XSS 的攻击不会具有基于 cookie 的令牌,并且基于 CSRF 的请求不会具有验证用户身份所需的 JWT 令牌。cookie 令牌可以在登录时生成,因此它与登录该计算机的用户绑定在一起。

\n\n

当然,您也可以扭转局面,将 JWT 放在安全的 cookies 中,并将反请求令牌作为标头。

\n\n

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

\n\n

或者,不要将 JWT 令牌存储在本地存储中。当您使用 OpenID 流程时,您的应用程序将在第一次加载时发现其未经授权,并将您重定向到 OpenID 提供程序,让用户输入其凭据并使用令牌(或授权代码的代码)将其重定向回来流动)。

\n\n

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

\n