ウェブアプリケーションセキュリティ 第2版

第29章. CSRF攻撃から身を守る

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

第 2 部では、ユーザに代わってリクエストを行うために、ユーザの認証されたセッションを利点とする クロスサイトリクエストフォージェリ(CSRF)攻撃を構築した。CSRF 攻撃は、<a></a> のリンク、<img></img> のタグ、さらにはウェブ・フォームを使った HTTP POST 経由で行われた。CSRF スタイルの攻撃は、高い特権レベルで機能し、多くの場合、認証されたユーザには検出できないので、アプリケーションに対し ていかに効果的で危険であるかを見た。

この章では、そのような攻撃からコードベースを防御する方法を学び、ユーザが認証セッションを標的にするあらゆるタイプの攻撃に対してリスクにさらされる確率を軽減する。

ヘッダ検証

<a></a> リンクを使って構築したCSRF攻撃を覚えているだろうか？その議論では、リンクは電子メールまたはターゲットとは全く別のWebサイト経由で配布された。

多くの CSRF リクエストの原点はウェブ・アプリケーションとは別なので、リクエストの原点をチェックすることで CSRF 攻撃のリスクを軽減することができる。HTTP の世界では、リクエストの元をチェックする際に注目するヘッダが 2 つある：referer とorigin 。これらのヘッダが重要なのは、主要なブラウザーではJavaScriptでプログラ ム的に変更できないからである。そのため、適切に実装されたブラウザのreferrer またはorigin ヘッダは、なりすまされる可能性が低い：

オリジン・ヘッダ

origin ヘッダはHTTPのPOSTリクエストでのみ送られる。それはリクエストがどこから発信されたかを示す単純なヘッダである。(HTTPやHTTPSに関係なく)すべてのリクエストに現れるreferer とは異なる。origin ヘッダは以下のようになる：Origin: https://www.mega-bank.com:80.

リファラーヘッダ

referer 、 のヘッダはすべてのリクエストにセットされ、リクエストがどこから来たか も示す。このヘッダが存在しないのは、参照元リンクにrel=noreferer 属性がセットされているときだけである。referer ヘッダは以下のようになる：Referer: https://www.mega-bank.com:80.

POSTリクエストがウェブサーバに行われたとき、例えば、https://www.mega-bank.com/transfer にパラメーamount=1000 とto_user=123を付けたとき、これらのヘッダの場所が、ウェブサーバを実行している信頼できるオリジンと同じであることを確認できる。このようなチェックのノード実装を以下に示す：

const transferFunds = require('../operations/transferFunds');
const session = require('../util/session');

const validLocations = [
 'https://www.mega-bank.com',
 'https://api.mega-bank.com',
 'https://portal.mega-bank.com'
 ];

const validateHeadersAgainstCSRF ...