web-dev-qa-db-ja.com

JSONを使用したCSRF POST

JSONリクエストを受け入れ、レスポンスもJSONであるテストアプリケーションで遊んでいます。 POSTメソッドでリクエストのJSONデータのみを受け入れるトランザクションに対してCSRFを実行しようとしています。getメソッドを使用してURLがリクエストされると、アプリケーションがエラーをスローします（例：<script src=）。

また、攻撃が意味のあるものになるように、つまりトランザクションが通過するためには、リクエストでデータを送信する必要があります。自分のページを作成してJSONリクエストを送信すると、Cookieが移動しないため、サーバーが未認証のエラーメッセージを返します。

サーバーによる元のリクエストにはランダムなトークンはありません。

このシナリオでCSRF攻撃を成功させる方法はあるのでしょうか。

httpcsrfjson
32
Sachin Kumar

少なくともリクエストでContent-Type: application/jsonを確認する必要があります。

POSTされた<form>を取得してContent-Type: application/jsonでリクエストを送信することはできません。ただし、本文にenctype="text/plain"として有効なJSON構造を含むフォームを送信できます。

クロスオリジンを実行することはできません（ [〜＃〜] cors [〜＃〜] ）XMLHttpRequest POST with Content-Type: application/json with a non-クロスオリジン対応サーバー。これにより、「プリフライト」HTTP OPTIONSリクエストが最初にそれを承認します。ただし、クロスオリジンXMLHttpRequest POST withCredentials を送信できます。 = text/plainの場合。

したがって、application/jsonチェックを使用しても、XSRFに完全に到達していなくても、かなり近づくことができます。そして、それを安全にするために依存している動作はややあいまいであり、まだ草案段階にあります。 Webの将来を保証するものではありません。

たとえば、将来のHTMLバージョンで新しいJSON enctypeがフォームに追加された場合、これらは壊れる可能性があります。 （WHATWGはtext/plain enctypeをHTML5に追加し、元々はtext/xmlも追加しようとしたため、これが発生する可能性があることは疑いの余地がありません。 CORS実装におけるプラグインのバグ。

したがって、おそらく今はそれを回避できますが、適切なXSRFトークンシステムなしで先に進むことは絶対にお勧めしません。

37
bobince

https://code.google.com/p/browsersec/wiki/Part2#Same-Origin_policy_for_Flash によると、これはFlashを使用して悪用可能です。

Cookieを含むクロスドメインHTTP GETおよびPOSTリクエストをブラウザースタック経由で作成する機能。ブラウザーの他の場所で一般的に見られるよりも制約が少なくなります。これはURLRequest APIによって実現されます。特に、任意のContent-Type値を指定したり、バイナリペイロードを送信したりする機能が含まれます。

私自身はテストしていませんが、もっともらしいようです。

更新：最新のFlashリリースでは、デフォルトでクロスドメインリクエストが許可されなくなったため、これを悪用不可能にしています。

更新＃2：ただし、フラッシュの307リダイレクトの処理には長年の脆弱性があり、これはまだ悪用可能であることを意味します

7
albinowax