webHttpBindingを使用してWCFサービスに対してCSRF攻撃を実行することは可能ですか？

webHttpBindingバインディングでWCFサービスを使用して、クライアントにエンドポイントを公開しています。サービスはIIS（.svc）によってホストされます。クライアントはenableWebScriptビヘイビアを使用して自動的にJavaScriptを生成します。すべてのメソッドがPOSTを使用しています。webHttpBindingを使用してWCFサービスに対してCSRF攻撃を実行することは可能ですか？

このサービスにCSRF攻撃を加えることは可能ですか？

私は、次のオプションと見なさ：

AJAX -
クロスサイトリクエストが許可されていないので、（私は、私たちのサイトにはXSSの傾向がないと仮定しています）

その他のオプションはありますか？フラッシュ、Silverlight、Webソケットなど何か？

有効な要求は、次のようになります

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を防ぐにはReferrerヘッダーをチェックするだけで十分です（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

リファラーチェックのもう1つの問題は、それが偽造できることです。リファラーヘッダーを使用することは事実上役に立たない。 CSRFから保護する唯一の意味のある方法は、サーバー側と所定の形式で格納されたランダムトークンを使用することです。 – TheMonarch

@TheMonarchそれは偽造することは間違いありませんが、CSRFコントロールの目的はサービスではなくエンドユーザーを保護することです。したがって、あなた自身がCSRFの被害者にならないようにしない限り、リファラーヘッダを偽造することは無意味です。 –

これは古い記事ですが、それはので、ここで紹介ヘッダーにOWASPの意見だ、「WCF CSRC StackOverflow.com」をGoogleに現れる最初のものです：

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

こちらの回答は多少誤解を招きます。リファラーヘッダーはCSRFをチェックするのに便利な方法ですが、完全に信頼できるわけではありません。より信頼性の高い方法は、サーバー側でチェックされる各フォームに埋め込まれたランダムトークン（フォームの各インスタンスごとにランダムに生成されることが好ましい）を使用することです。例えば

：MVCコードで

<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>

：CSRF攻撃は、まだあなたのサイトにログインすることができる被害者のブラウザを使用しているため、これが必要である

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

    //Do actual work 
}

理由があります。これは、ユーザーが複数のタブを開いている場合、またはセッションの有効期限が切れるまでに時間がかかる場合に発生します。攻撃者は、通常、悪質なデータを含むフォーム提出ページにユーザーをリダイレクトします。

また、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攻撃を実行することは可能ですか？

答えて

関連する問題