使用双提交 Cookie 在 ASP.NET MVC 中实现 XSRF 安全性的想法

发布于 2024-07-08 05:57:22 字数 673 浏览 7 评论 0原文

我决定尝试使用双重提交的cookie技术来尝试阻止对我正在工作的网站的 XSRF 攻击。 所以我在这里写下来的方式是,所有实际执行除获取信息之外的操作的操作都将是帖子。 获得将是……呃……获得。 其次,发布的每个表单都会有密钥/cookie 组合。

我的问题是,在 ASP.NET MVC Web 应用程序中实现此功能的最简单方法是什么?

不是回答我自己的问题,但这是我最初的想法:

现在我的控制器都继承自基本控制器,所以我的第一个想法是重写 OnActionExecuted 方法来检查所需表单字段是否存在,然后从那里开始它找到它,根据 cookie 验证它,然后允许帖子继续或将其踢到某个错误页面。

对于表单部分,我正在考虑生成自己的 html 扩展方法,例如... Html.BeginSecureForm() ,它重载与 BeginForm 相同的所有方法(以防万一我需要它们),但自动生成伪随机密钥和 cookie 并放置cookie 和表单内的表单字段(如果它是一个帖子!)自动。

抱歉,如果这有点混乱,我的笔记分散在这些页面中,我正在尝试组织它们。 其中一部分是弄清楚我对 XSRF 安全性的设计。

I've decided to attempt using the double submitted cookies technique to attempt to prevent XSRF attacks on the site I'm working on. So the way I have it written down here is, all actions that actually DO something other than GET information, will be posts. Gets will be...uh...GETs. Secondly, every form that posts will have the key/cookie combo.

My question is, what would be the easiest way to implement this in an ASP.NET MVC web application?

Not to answer my own question, but here are my initial thoughts:

Right now my controllers all inherit from a base controller, so my first thought was to override the OnActionExecuted method to check for the existence of the required form field, and from there if it finds it, verify it against the cookie and either allow the post to continue or kick it to some error page.

For the form portion I was thinking of generating my own html extension methods like... Html.BeginSecureForm() that overloads all of the same methods as BeginForm (In case I need them) but auto generates the Pseudorandom key and cookie and places the cookie and the form field inside the form (IF ITS A POST!) automagically.

Sorry, if this is kind of jumbled up, I have notes scattered throughout these pages and I'm trying to organize them. Part of that is to figure out my design for this XSRF security thing.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

随遇而安 2024-07-15 05:57:22

内置的 ASP.NET MVC XSRF 保护有一个缺点:它会向客户端发送另一个 cookie。

同时,Html.AntiForgeryToken()为访问者提供一个名为 __RequestVerificationToken 的 Cookie,其值与上面显示的随机隐藏值相同。

我不想向客户端发送大量 cookie,因此当您为每个用户拥有唯一的服务器端跟踪器(例如数据库中的会话表......)时,您可以使用它。 少一个 cookie —— 只需发送用户表中某些内容的唯一哈希值。

但也有一些匿名用户没有用户帐户,因此没有服务器端跟踪。 在这种情况下,我想知道您是否可以以某种方式获取已发送给每个用户的现有 ASP.NET_SessionId cookie(启用会话时)。而不是创建另一个 Cookie。

可能的? 还是我没有考虑清楚..?

The built in ASP.NET MVC XSRF protection has one downside: it sends down yet another cookie to the client.

At the same time, Html.AntiForgeryToken() will give the visitor a cookie called __RequestVerificationToken, with the same value as the random hidden value shown above.

I'd prefer not to send down a ton of cookies to the client, so when you have a unique server-side tracker for each user (like, say a session table in the database..) you can use that, instead. One less cookie -- just send down a unique hash of something in the user table.

But then there are anonymous users who do not hold a user account and thus have no server-side tracking. In that case, I'm wondering if you could somehow grab the existing ASP.NET_SessionId cookie (when sessions are enabled) that's being already sent to every user.. rather than creating Yet Another Cookie.

Possible? Or am I not thinking this through..?

分開簡單 2024-07-15 05:57:22

一种受到关注的方法是加密令牌模式,由名为 ARMOR 的框架实现。 这里的前提是你既不需要Session也不需要cookie来维持CSRF保护。 加密令牌模式利用 Rijndael 加密令牌,其完整性由 SHA256 哈希算法维护。

ARMOR 框架在 MVC 和 Web API 应用程序中都很容易实现。 完整演练此处

One method gaining traction is the Encrypted Token Pattern, implemented by a Framework called ARMOR. The premise here is that you need neither Session nor cookies in order to maintain CSRF protection. The Encrypted Token Pattern leverages a Rijndael-encrypted Token whose integrity is maintained by a SHA256 hashing algorithm.

The ARMOR Framework is simple to implement in both MVC and Web API applications. Full walkthrough here.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文