是否可以使用 webHttpBinding 对 WCF 服务执行 CSRF 攻击？答案

【问题标题】：Is it possible to perform an CSRF attack on WCF service with webHttpBinding?是否可以使用 webHttpBinding 对 WCF 服务执行 CSRF 攻击？
【发布时间】：2012-05-12 21:52:45
【问题描述】：

我们使用带有webHttpBinding 绑定的WCF 服务来向客户端公开端点。服务由 IIS (.svc) 托管。客户端是使用 enableWebScript 行为自动生成的 JavaScript。所有方法都使用 POST。

是否可以对该服务进行 CSRF 攻击？

我考虑了以下选项：

AJAX - 不可能，因为不允许跨站点请求（我假设我们的站点不容易出现 XSS）
HTML 表单提交 - 不可能，因为服务需要某些无法使用 HTML 表单设置的 HTTP 标头

还有其他选择吗？ Flash、Silverlight、网络套接字或其他什么？

有效请求如下所示：

POST http://site/Service.svc/ServiceMethod HTTP/1.1
Host: site
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: cs,en-us;q=0.8,en;q=0.5,pl;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
X-Requested-With: XMLHttpRequest
Content-Type: application/json; charset=utf-8
Referer: http://site/
Content-Length: 33
Cookie: cookies, session id, etc.
Pragma: no-cache
Cache-Control: no-cache

{"param1":11,"param2":"123"}

明确一点：我正在努力保护我的服务。不进行攻击。我正在考虑为每次通话添加一个“身份验证令牌”，但首先我想知道这是否值得。

【问题讨论】：

标签： asp.net wcf web-services security

【解决方案1】：

这是一篇旧帖子，但它是“WCF CSRC StackOverflow.com”在 Google 上出现的第一件事，所以这里是 OWASP 对推荐标头的看法：

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Checking_The_Referer_Header

这里的另一个答案有些误导。推荐人标头是检查 CSRF 的有用方法，但并不完全可靠。一种更可靠的方法是使用嵌入在每个表单中的随机令牌（最好为每个表单实例随机生成），该令牌将在服务器端进行检查。

例如：

<html>
<body>
    <form>
        <input type='text' name='securityfield' /><input type='submit' value='submit' />
    <input type='hidden' value='<some random token>' name='CSRF-token' />
    </form
</body>
</html>

在 MVC 代码中：

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult SomeAction(Dictionary<string, string> parameters){
    if(parameters["CSRF-token"] != UserContext.csrfToken){
        return View();
    }

    //Do actual work
}

之所以需要这样做是因为 CSRF 攻击使用了受害者的浏览器，而该浏览器可能仍会登录到您的站点。如果用户打开了多个选项卡，或者您的会话只是需要一段时间才能过期，则可能会发生这种情况。攻击者通常会使用恶意数据将用户重定向到您的表单提交页面。

我还应该说 AJAX 不是跨域的。此外，XSS 不需要实现 AJAX。

【讨论】：

你链接的文章明确说“虽然在你自己的浏览器上欺骗referer header很简单，但在CSRF攻击中是不可能的”
针对推荐标头的错误进行了编辑。我发布了 OWASP 链接，但没有删除我对推荐标题的仇恨。
AJAX 允许跨域，因为 CORS 使这成为可能。请注意，缺少 CORS 标头并不能减轻 CSRF 的影响，因为 requests can still me made cross-domain, if not read

【解决方案2】：

一般来说，检查Referrer header就足以防止CSRF，因为浏览器会设置referrer header（即使是javascript设置的）。

我认为没有人能够保证您的服务不受 CSRF 影响，因为您总是有可能（不小心）打开一些攻击向量。例如，如果您有以下网站：

http://mycompanysite.com/MyService/Service.svc (hosting the service)
http://mycompanysite.com/MyWebApp/ (hosting a web app)

然后，Web 应用程序中的漏洞可能允许攻击，因为“跨域”规则不再适用。此外，客户端应用程序（即浏览器）中始终存在漏洞的可能性，因此从托管的角度来看，您实际上只能在用户使用众所周知的最新浏览器的基础上工作没有插件等。

【讨论】：

Referrer 检查的问题是仍有大量用户禁用设置 Referrer 标头。我不想把它们删掉。您对此有何看法？
referrer 检查的另一个问题是它可以被伪造。使用referrer 标头实际上是没有用的。防止 CSRF 的唯一有意义的方法是使用以给定形式存储在服务器端的随机令牌。
@TheMonarch 你说得对，它可以被伪造，但是 CSRF 控制的目的是保护最终用户而不是服务，所以伪造一个引用标题是没有意义的，除非你想让自己成为 CSRF 的受害者。