Javascript ASP.NET核心WebAPI安全注意事项

我的WebAPI就是我的UI使用的API后端。事实上，我的UI可能会使用10个WebAPI服务

我很难理解我需要考虑的安全问题。

我的API使用承载令牌进行保护，并且只允许https。我已经设置了COR，它们只允许原始

https://my-front.end

这一切都非常有效

然而。。如何防止对WebAPI的C/XSRF和重播攻击？我需要吗

在ASP.NET MVC项目中设置反CSRF是相当轻松的，但如何在WebAPI项目上实现这一点，据我所知，它依赖于将服务器上生成的信息发送到客户端，以便在请求正文中并通过另一个通道（例如cookie或标头）发送。我了解到，您可以通过使用nonce（例如时间戳和随机数）来防止重播攻击——有些方法——但找不到任何实现示例

还有什么我需要考虑的吗？< /P>

---

编辑：前端使用vue.js，但我们有一个非常有能力的js程序员，所以任何前端实现都不会有问题。这只是找出需要做什么的问题

---

可能还值得注意的是，为了显而易见，WebAPI和前端在不同的服务器上运行，因此这些都是有效的跨源调用。

好吧。首先，您需要在头中发送XSRF令牌。为此，您需要转到ConfigureServices方法，并将AntiForgery服务设置为预期此标头

public void ConfigureServices(IServiceCollection services)
{
    services.AddAntiforgery(x => x.HeaderName = "X-XSRF-TOKEN");
    services.AddMvc();
}

接下来，您需要生成令牌。因为前端和API是不同的服务，所以在执行此操作时需要进行计算。例如，您可以在登录时执行此操作，也可以让专用端点执行此操作，但最终结果是相同的

您可以在标头或cookie中返回令牌值，这取决于您自己。在我的示例中，我使用了一个Cookie，稍后我将对此进行解释，但如果您愿意，可以使用一个标题

public class HomeController : Controller
{
    private readonly IAntiforgery _antiForgeryService;

    public HomeController(IAntiforgery antiForgeryService)
    {
        _antiForgeryService = antiForgeryService;
    }

    public IActionResult GetToken()
    {
        var token = _antiForgeryService.GetTokens(HttpContext).RequestToken;
        HttpContext.Response.Cookies.Append("XSRF-TOKEN", token, new CookieOptions { HttpOnly = false });
        return new StatusCodeResult(StatusCodes.Status200OK);
    }
}

IAntiforgery服务应该已经可以使用了（它是您将在.net核心服务中使用的“AddMVC”调用的一部分）

好的，现在我们返回了一个带有令牌值的cookie。现在我们只需要把它送回去

下面是一些jQuery正在做的腿部工作

<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/js-cookie/2.1.4/js.cookie.min.js"></script>
<script type="text/javascript">
    var token = Cookies.get("XSRF-TOKEN");

    $.ajax({
        url: "/",
        contentType: "application/json",
        type: "POST",
        headers: {
            "X-XSRF-TOKEN": token
        }
    });
</script>

总之，它基本上归结为：

• 安装程序.net Core AntiForgery希望为CSRF令牌使用头值
• 拥有一个端点，该端点将手动生成令牌供您使用，并将其作为cookie/头返回
• 让前端读取此值，并将其存储以备后续请求
• 在后续请求中，将令牌值作为标头（而不是cookie）发送

---

主要取材于此：

您是否在前端使用了类似Angular的功能？您可以将此添加到您的问题中，因为Angular具有CSRF令牌等的默认设置。不，它是vue.js，我已经对问题进行了适当的编辑@请稍等。只是为你解决：）太棒了，非常感谢！我将在未来几天内对此进行一次尝试。我需要了解CSRF攻击是如何进行的，以便更好地理解这一点，我觉得奇怪的是手动请求令牌，而不是让服务器将其烘焙到表单中。在问无聊的问题之前，我最好先读一读：）事实上，如果你不使用水疗，在表格中烘焙是正常的方式（）。但是在构建表单时，您需要使用Razor HTML帮助程序。你仍然可以把它作为一个隐藏的字段放在表单上，但是如果你正在使用SPA的话，这是没有意义的。是的，这是有意义的！如果我的所有端点都使用承载身份验证（oidc）进行保护，那么我需要担心这一点吗？在我们的js应用程序中，令牌被附加到请求中-因此，如果用户被发送到一个试图调用

our.api/protected/endpoint

的可疑站点，它将不会做任何事情，因为不会附加身份验证令牌？这是正确的。CSRF基于浏览器“存储”的内容，并随每个请求一起发送。e、 每一个请求都会发送一个cookie到该站点。请注意，虽然上面的教程很棒，但有一件事让我失望，那就是获取XSRF令牌并将其保存为cookie。而不是使用_antiForgeryService.GetTokens（HttpContext.RequestToken）；最好改用_antiForgeryService.GetAndStoreTokens（HttpContext），因为它也会返回&自动创建并存储AspNet.antiforgerytoke cookie，这样即使在将XSRF令牌正确地放入请求头时，您也需要避免始终返回400。

[AutoValidateAntiforgeryToken]
public class HomeController : Controller
{