アングルアプリからの各リクエストでの偽造トークン

Question

ほとんどのアクティビティが金融取引であるため、私は非常に安全と思われるウェブサイトを持っています。このサイトには多くのセキュリティ機構があり、そのうちの1つでは不十分だとは思っていません。

このWebアプリケーションは、AngularJS 1.4とASP.NET MVC 4をベースにしています。角度を使用してシステムにログインした後、コントローラアクションを呼び出して偽造トークンを設定します。以降の要求はすべて同じトークンを持ち、サーバーは各要求に対して同じトークンを検証します。

今問題です。

各リクエストでトークンを変更していないため、ログインしたユーザーはFiddlerまたはChromeの[ネットワーク]タブを探してリクエストを変更するリソースをリクエストするだけでリクエストからのトークンを使用できます。

各リクエストでトークンをリセットする必要がありますか？この種の攻撃を防ぐのに役立つでしょうか？

Answer 1

トークンは、許可されたユーザーが手動で要求を作成することを防ぐものではありません。トークンは、それらのユーザー以外の誰かが、csrf要求を使用してユーザーからの要求を偽造できないことを保証します。

同じトークンを再利用することができます。これは、適切に実装されている場合、潜在的なCSRF攻撃者が値を読み取るべきではないからです。これは、サードパーティのサイトが同じ値を読み取ったり送信したりすることができないようにするために、ブラウザの同じ発信元ポリシーに依存しています。

トークンを返したjson GETなどのような穴があった場合は、JSON返信データが投稿付きで提出されるべきです）トークンが侵害される可能性があります。あなたは、彼は彼だけが権限を持つアカウントを編集する掲示されていることを確認し、サーバ側のチェックを必要とする認証されたユーザ

から詐欺の可能性の要求に関しては

https://docs.microsoft.com/en-us/aspnet/web-api/overview/security/preventing-cross-site-request-forgery-csrf-attacks

認証 編集する。たとえば、私がアカウントAを所有していて、アカウントBに送金したい場合、サーバー側の小切手は私がアカウントAを所有していることを保証し、その資金をどこか別の場所に送る権限を持っています。私がBからAに資金を送付する要求を作成した場合、サーバー側のチェックでは、アカウントと所有者のデータベース関係を調べることによって、Bの所有者ではないことがわかります。これは承認と呼ばれます。許可は、ユーザーがアクションを実行する権限を持つことを保証します。これは通常、誰が何にアクセスできるかを言うテーブル間の関係を定義するビジネスルールによって規定されます。

認証 唯一の他の問題は、私は私がちょうど要求にユーザーIDを掲示した場合、私は簡単にブラウザでそれを変更する可能性があるため、私は、午前言う人だということを保証することです。

ユーザーが彼が誰かであると証明した場合、通常はユーザーID /パスワードを指定して、認証トークンを生成します。 ASP.NETでは、このトークンは、トークンを生成して検証するのに必要なキー情報をサーバーだけが持つように、暗号的に安全です。通常、このトークンはクッキーとして保持されます。

認証と認可の組み合わせにより、ユーザーが誰であるかがわかります。また、各要求に対して、承認を定義するビジネスルールを使用して、アクションが有効であることを確認します。リクエストがサーバー側の承認に失敗するため、無効なリクエストを作成することはできません。

この簡略化されたサーバー側のコードを想像してみて：

public void TransferFunds(TransferFundsRequest request) 
{ 
    var account = Database.GetAccount(request.SourceAccountId); 
    if(account.OwnerUserId != session.UserId) 
    { 
    throw UnauthorizedException("This user is not the owner of the source account in the transfer funds request."); 
    } 

    // continue with logic to transfer funds 
} 

CSRF クロスサイトリクエストフォージェリは全く別の問題です。これは、許可されたユーザーのブラウザに読み込まれた別のサイトが、ユーザーのブラウザから要求を送信しようとしたときです。私が訪問した悪意のある第三者サイトは、javascriptや他の方法を使って、アカウントAからアカウントCへの私のブラウザのTransferFundsリクエストを行います。今、私がアカウントAの所有者であり、有効なリクエストであるサーバーの観点から。 CSRFトークンは、ユーザーがサーバーが生成したフォームからリクエストを送信したのではなく、サードパーティのサイトのフォームまたはURLからリクエストを送信したことを検出できることを保証します。

たとえば、リクエストのすべてのパラメータをクエリ文字列に記述できる場合は、TransferFundsリクエストのURLを作成してアカウントAの所有者に電子メールで送信し、そのリンクをクリックするように試みることができます。ユーザーがサイトにログインした場合、当社のサーバーはユーザーがリクエストを送信したと考えます。ただし、HTML入力フォームを生成する際にanti-CSRFトークンを含めると、トークンがないため、リクエストは第三者が作成したフォームまたはURLからのものであることがわかります。