0

我们使用带有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"}

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

4

2 回答 2

1

这是一篇旧帖子，但它是在 Google 上出现的“WCF CSRC StackOverflow.com”的第一件事，所以这里是 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。

于 2015-04-23T22:46:40.363 回答
-1

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

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

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

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

于 2012-05-03T16:53:10.440 回答