Web APIとangljsを持つ秘密トークン

Question

xss攻撃を避けるために、MVCはいくつかの偽造防止トークンを生成します。

しかし、私たちのプロジェクトでは、ウェブAPIを使ってAngularjsを持っています。

私の必要性が

• である私たちは、ウェブAPIでAngularjsプロジェクトにおけるXSS攻撃を防ぐためにantiforgeryトークンが必要ですか？
• もし必要なら、実装する方法は？

Answer 1

偽造防止トークンは、サイト間要求偽造（CSRF）に対するものです。非常に短くてやや簡略化して、攻撃者は自分のウェブサイトを立ち上げ、ユーザーをそのウェブサイトに誘導してから、そのユーザーのブラウザがアプリケーションに有効なリクエストを投稿するようにするWebページを作成することができます。あなたのユーザーはしたくなかった。これに対して標準的な防御策は、攻撃者が知らずに送信できないランダムなトークンをアプリケーションで生成することです。 OWASPには、description of CSRFとprotection cheat sheetという素晴らしいものがあります。この問題は、認証情報（セッションIDまたはアクセストークン）がリクエストによってブラウザによって自動的に送信される場合にのみ発生します。それがクッキーに入っているとき。さもなければ攻撃は不可能です。

これは、cross-site scripting (xss)とは関係ありません。攻撃者は、他のユーザーが閲覧したときにJavascriptをページに挿入して、犠牲者のユーザーがクライアントに表示または保存したデータにアクセスできるようにしたい場合があります。これを解決するには、すべての出力をコンテキストに従ってエンコードする必要があります。またAngular（およびJavascript一般）では、ページノード内にスクリプトノードを作成せず、テキストとしてのみバインドできるバインディングを使用する必要があります。 OWASPにはcheat sheet for XSSもあります。

Angular talk to Web APIの場合、Cookieベースの認証/セッションを使用する場合にのみ、Web APIコードのCSRFを処理する必要があります。アクセストークンが他の場所に格納されていて、そのコードを各リクエストに挿入する必要がある場合（たとえば、トークンがJavascriptオブジェクトに格納され、各リクエストにjQueryのリクエストヘッダとして追加された場合など） CSRFに対するさらなる保護が必要です。

Web APIがJSONコンテンツに対応している場合、JSONレスポンスにエンコードされていないデータを格納しても問題ありません（JSON自体のデータをエンコードする必要があることは明らかですが、そのレベルでのプレゼンテーション）。このようなデータをAngularで受け取った場合、セーフバインディングのみを使用して実際にそのデータをUIにバインドして、Javascriptを挿入できないようにする必要があります。角度は合理的には良いですが、コードは依然として脆弱です。また、DOM XSS（XSSの形式）は、Javascript重のアプリケーションでは非常に一般的な脆弱性です。

これを正確に実装する方法は、残念なことにここの答えの範囲を超えています。それはすべて詳細に依存します。