是否可以使用webHttpBinding對WCF服務執行CSRF攻擊？

我們使用WCF服務與webHttpBinding綁定將端點暴露給客戶端。服務由IIS（.svc）託管。客戶端使用enableWebScript行爲自動生成JavaScript。所有的方法都使用POST。是否可以使用webHttpBinding對WCF服務執行CSRF攻擊？

是否可以對此服務進行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"}

要明確：我想保護我的服務。不執行攻擊。我正在考慮爲每個呼叫添加一個「身份驗證令牌」，但首先我想知道它是否值得付出努力。

來源

2012-05-03 jakubka

-1

通常，檢查引用標頭足以阻止CSRF，因爲瀏覽器將設置引用標頭（即使它是由javascript設置的）。

我認爲任何人都不能保證你的服務對於CSRF是安全的，因爲你總是可能（意外）打開一些攻擊媒介。舉例來說，如果你有下列網站：

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

然後在Web應用程序中的漏洞可能允許攻擊，因爲「跨域」規則不再適用。此外，客戶端應用程序（即瀏覽器）中存在漏洞的可能性始終存在，因此從託管角度來看，您實際上只能從用戶使用衆所周知的最新瀏覽器的基礎開始工作無插件等

來源

2012-05-03 16:53:10

推薦人檢查的問題是仍然有大量的用戶無法設置推薦人標題。我不想把它們剪掉。你怎麼看待這件事？ – jakubka

引用程序檢查的另一個問題是它可能是僞造的。使用引用標頭實際上是無用的。防止CSRF的唯一有意義的方法是使用隨機令牌存儲服務器端和給定的形式。 – TheMonarch

@TheMonarch你說的是僞造的，但是CSRF控制的目的是爲了保護最終用戶而不是服務，所以僞造引用標頭是毫無意義的，除非你想讓自己成爲CSRF的受害者。 –

這是舊的文章，但它顯示了在谷歌「WCF證監會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-23 22:46:40 TheMonarch

您明確鏈接的文章說：「儘管在您自己的瀏覽器中欺騙引用標題是微不足道的，但在CSRF攻擊中這樣做是不可能的」 –

編輯了有關引用標題的錯誤。我發佈了OWASP鏈接，但沒有刪除我的推薦標題討厭。 – TheMonarch

自[CORS]（https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS）使這成爲可能，允許AJAX跨域。請注意，缺少CORS頭文件並不能減輕CSRF的負擔[請求仍然可以通過跨域進行，如果沒有閱讀]（http://security.stackexchange.com/a/58811/8340） – SilverlightFox

是否可以使用webHttpBinding對WCF服務執行CSRF攻擊？

回答

相關問題