2017-07-19 5 views
1

"Accept:application/json"ヘッダーを持つリクエストのみを受け付けるSPA用に構築されたJSON APIがあります。ブラウザに次のフォームを送信すると、「受け入れられません」というメッセージが表示されます。 HTTPエラーです。APIのCSRFからの保護方法としてカスタムの必須HTTPヘッダーを使用するのは安全ですか?

<form method="POST" action="https://api.example.domain/resource"> 
    <input type="password" name="password" value="CSRF"> 
    <input type="submit" value="Click!"> 
</form> 

これは、APIがCSRFタイプの攻撃から免除されていることを意味しているのですか、何か不足していますか?

答えて

3

非常に安全ですが、APIが脆弱である可能性があります。

攻撃者がウェブサイトでXSSの脆弱性を発見した場合、JavaScriptを使用してヘッダー:Accept: application/jsonを追加してからCSRF攻撃を実行できます。

これは、「禁止」ヘッダーリストにあるため、JavaScriptで設定できないヘッダーに依存することを推奨します。ブラウザでのみ変更できるため、XSSの脆弱性はここでは使用できません。

あなたはOWASPでより多くの情報を見つける:https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

+1

こんにちはホルヘ、あなたが共有してきた美しい記事をありがとう。したがって、REST APIが 'Access-Control-Allow-Origin:https:// domain.name'ヘッダーを各応答に設定する場合、' Origin'と 'Referer'ヘッダーもチェックする必要がありますか、それとも十分でしょうか? – tooleks

+0

私には十分だと思われる。 しかし、Webアプリケーションにセキュリティを追加するときに進む最善の方法は、OWASPのガイドラインに従うことです。あなたがすでに十分安全であると思っても、あなたは何かを見逃す可能性があります。だから、 'Origin'や' Referer'ヘッダーやシンクロナイザートークンを使用することをお勧めします。 –

1

私はあなたが一度にすべての予防法を実装することはできませんので、それは安全であるとは思いません。もちろん、CORSサポートを追加するだけで、HTTP Onlyフラグやその他の方法でハッキングされるのを防ぐことができますが、完全に安全ではありません。

すべての防止方法を実装してホイールを再発明する代わりに、既存の標準ラッパーまたはミドルウェアを使用して、アプリケーションに対するCSRF攻撃を防止する方がよいと思います。これらのコードは、入力よりもはるかに優れています。

CSRF攻撃を防ぐには、最高の(私のお気に入りのラッパー)、https://github.com/ring-clojure/ring-anti-forgeryのいずれかを使用できます。バックエンドの目的でノードを使用している場合は、別のベスト・ミドルウェア、https://github.com/expressjs/csurfがあります。

CSRFの攻撃を防ぐために、自分でコードを書くことは不可能だとは言いませんが、既存の標準コードを使い、機能を開発することに集中することは、 。

+0

こんにちはRewanth、あなたの答えに感謝します。フロントエンドアプリケーションは絶対的に別個のアプリケーションであるため、バックエンドはフロントエンドHTMLをレンダリングせず、REST APIのみを提供するので、このソリューション(バックエンドによるCSRFトークン隠蔽フィールドインジェクション)を使用できません。 – tooleks

関連する問題