Cross-Site Request Forgery

Visualforce のページ アクション メソッドまたはコントローラー コンストラクターは、不正なリクエストに対する保護なしで、機密性の高いタスクを実行します。

次の場合に、Cross-Site Request Forgery (CSRF) の脆弱性が発生します。
1.Web アプリケーションがセッションの cookie を使用する。
2.ユーザーの承諾を得てリクエストが作成されているかをどうかを検証せずに、この Web アプリケーションは HTTP リクエストを処理する。
デフォルトでは、Visualforce ページは CSRF 防止トークンとして機能する非表示のフォーム フィールドとともにレンダリングされます。これらのトークンはページ内から送信されるリクエストに含まれ、サーバーは対応するアクション メソッドまたはコマンドを実行する前にトークンの有効性をチェックします。ただし、この組み込みの防御は、ページ アクション メソッドやカスタム ページ コントローラー コンストラクターには適用されません。これらは、ページのロード中、CSRF 防止トークンが生成される前に実行されるためです。
例 1: 次の Visualforce ページは、カスタム コントローラー MyAccountActions とページ アクション メソッド pageAction() を宣言しています。ページの URL にアクセスすると、pageAction() メソッドが実行され、サーバーは CSRF 防止トークンをチェックしません。

<apex:page controller="MyAccountActions" action="{!pageAction}">
    ...
</apex:page>
public class MyAccountActions {
    ...
    public void pageAction() {
        Map<String,String> reqParams = ApexPages.currentPage().getParameters();
        if (params.containsKey('id')) {
            Id id = reqParams.get('id');
            Account acct = [SELECT Id,Name FROM Account WHERE Id = :id];
            delete acct;
        }
    }
    ...
}

攻撃者は次のコードを含んだ悪意ある Web サイトをセットアップする可能性があります。

<img src="http://my-org.my.salesforce.com/apex/mypage?id=YellowSubmarine" height=1 width=1/>

Visualforce ページの管理者が、サイトでセッションを行っているときに、悪意あるページにアクセスすると、攻撃者のアカウントを削除してしまいますが、本人はそのことに気づきません。

承認していないリクエストを攻撃者が送信できないようにするため、HTTP リクエストにはユーザー固有のシークレットが含まれている必要があります。

次の場合に、Cross-Site Request Forgery (CSRF) の脆弱性が発生します。
1. Web アプリケーションがセッションの cookie を使用する。

2. ユーザの承諾を得てリクエストが作成されているかをどうかを検証せずに、この Web アプリケーションは HTTP リクエストを処理する。



ナンスは、リプレイ攻撃を防ぐためにメッセージと一緒に送信される、暗号のランダム値です。リクエストにその出所を証明するナンスが含まれていない場合、リクエストを処理するコードは (アプリケーションの状態を変更しない限り) CSRF 攻撃に対して脆弱です。つまり、セッション Cookie を使用する Web アプリケーションは、攻撃者がユーザーをだまして偽のリクエストを送信させないように、特別な予防措置を講じる必要があります。管理者が新しいアカウントを作成できる次のような Web アプリケーションを考えてみます。

  var req = new XMLHttpRequest();
  req.open("POST", "/new_user", true);
  body = addToPost(body, new_username);
  body = addToPost(body, new_passwd);
  req.send(body);

攻撃者は次のコードを含んだ悪意ある Web サイトを準備する可能性があります。

  var req = new XMLHttpRequest();
  req.open("POST", "http://www.example.com/new_user", true);
  body = addToPost(body, "attacker");
  body = addToPost(body, "haha");
  req.send(body);

example.com の管理者が、サイトでセッションを行っているときに、悪意あるページにアクセスすると、攻撃者にアカウントを作成してしまいますが、本人はそのことに気づきません。これが CSRF 攻撃です。アプリケーションには、リクエストの生成元を検証する方法がないために、この攻撃が可能となっています。リクエストはユーザによって選択された正当なアクションにも、攻撃者が準備した不正なアクションにもなりえます。攻撃者は偽のリクエストを生成する Web ページを見ることができません。そのため、この攻撃方法は、アプリケーションの状態を変更するリクエストにのみ有効です。

cookie ではなく URL でセッション ID を渡すアプリケーションには CSRF の問題は存在しません。これは、攻撃者にとってセッション ID にアクセスすることやセッション ID を偽のリクエストの一部に追加することは不可能であるためです。

Django アプリケーションは CSRF ミドルウェア保護を有効にしません。

次の場合に、Cross-Site Request Forgery (CSRF) の脆弱性が発生します。
1. Web アプリケーションがセッションの cookie を使用する。

2. ユーザの承諾を得てリクエストが作成されているかをどうかを検証せずに、この Web アプリケーションは HTTP リクエストを処理する。

ナンス (ワンタイムパスワード) は、反射攻撃を防止するためにメッセージと共に送信される暗号的な乱数値です。生成元を証明するナンス (ワンタイム パスワード) がリクエストに含まれていない場合、このリクエストを処理するコードは CSRF 攻撃に対して脆弱になる可能性があります （アプリケーションの状態が変更される場合は脆弱になりません）。つまり、セッション cookie を使用する Web アプリケーションでは、攻撃者によってユーザが偽のリクエストを送信するように仕向けられることないように、特殊な予防措置を講じる必要があります。管理者が次のフォームを送信して新しいアカウントを作成できる Web アプリケーションを例としてみましょう。

<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>

攻撃者は次のフォームを使用した Web サイトを準備する可能性があります。

<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>

example.com の管理者が、サイトでセッションを行っているときに、悪意あるページにアクセスすると、攻撃者にアカウントを作成してしまいますが、本人はそのことに気づきません。これが CSRF 攻撃です。アプリケーションには、リクエストの生成元を検証する方法がないために、この攻撃が可能となっています。リクエストはユーザによって選択された正当なアクションにも、攻撃者が準備した不正なアクションにもなりえます。攻撃者は偽のリクエストを生成する Web ページを見ることができません。そのため、この攻撃方法は、アプリケーションの状態を変更するリクエストにのみ有効です。

cookie ではなく URL でセッション ID を渡すアプリケーションには CSRF の問題は存在しません。これは、攻撃者にとってセッション ID にアクセスすることやセッション ID を偽のリクエストの一部に追加することは不可能であるためです。

承認していないリクエストを攻撃者が送信できないようにするため、HTTP リクエストにはユーザー固有のシークレットが含まれている必要があります。

次の場合に、Cross-Site Request Forgery (CSRF) の脆弱性が発生します。
1. Web アプリケーションがセッションの cookie を使用する。

2. ユーザーの承諾を得てリクエストが作成されているかをどうかを検証せずに、この Web アプリケーションは HTTP リクエストを処理する。

ナンス (ワンタイムパスワード) は、反射攻撃を防止するためにメッセージと共に送信される暗号的な乱数値です。 生成元を証明するナンス (ワンタイム パスワード) がリクエストに含まれていない場合、このリクエストを処理するコードは CSRF 攻撃に対して脆弱になる可能性があります （アプリケーションの状態が変更される場合は脆弱になりません）。 つまり、セッション cookie を使用する Web アプリケーションでは、攻撃者によってユーザーが偽のリクエストを送信するように仕向けられることないように、特殊な予防措置を講じる必要があります。 管理者が新しいアカウントを作成できる Web アプリケーションを例としてみましょう。

デフォルトでは、Play Framework は CSRF に対する防御を追加しますが、グローバルに、または特定のルートに対して無効にすることができます。

例 1: 次のルート定義は、buyItem コントローラー メソッドの CSRF 保護を無効にします。

+ nocsrf
POST    /buyItem     controllers.ShopController.buyItem

shop.com のアクティブ セッション実行時に、ユーザーは意図せずに悪意あるページに誘導され、気づかないうちに攻撃者にアイテムを購入してしまいます。 これが CSRF 攻撃です。 アプリケーションには、リクエストの生成元を検証する方法がないために、この攻撃が可能となっています。 リクエストはユーザーによって選択された正当なアクションにも、攻撃者が準備した不正なアクションにもなりえます。 攻撃者は偽のリクエストを生成する Web ページを見ることができません。そのため、この攻撃方法は、アプリケーションの状態を変更するリクエストにのみ有効です。

cookie ではなく URL でセッション ID を渡すアプリケーションには CSRF の問題は存在しません。これは、攻撃者にとってセッション ID にアクセスすることやセッション ID を偽のリクエストの一部に追加することは不可能であるためです。

承認していない要求を攻撃者が実行できないように、フォームの post には、ユーザー指定のシークレットを追加する必要があります。

次の場合に、Cross-Site Request Forgery (CSRF) の脆弱性が発生します。
1. Web アプリケーションがセッションの cookie を使用する。

2. ユーザの承諾を得てリクエストが作成されているかをどうかを検証せずに、この Web アプリケーションは HTTP リクエストを処理する。



ナンス (ワンタイムパスワード) は、反射攻撃を防止するためにメッセージと共に送信される暗号的な乱数値です。生成元を証明するナンス (ワンタイム パスワード) がリクエストに含まれていない場合、このリクエストを処理するコードは CSRF 攻撃に対して脆弱になる可能性があります （アプリケーションの状態が変更される場合は脆弱になりません）。つまり、セッション cookie を使用する Web アプリケーションでは、攻撃者によってユーザが偽のリクエストを送信するように仕向けられることないように、特殊な予防措置を講じる必要があります。管理者が次のフォームを送信して新しいアカウントを作成できる Web アプリケーションを例としてみましょう。

<form method="POST" action="/new_user" >
  Name of new user: <input type="text" name="username">
  Password for new user: <input type="password" name="user_passwd">
    <input type="submit" name="action" value="Create User">
</form>

攻撃者は次のフォームを使用した Web サイトを準備する可能性があります。

<form method="POST" action="http://www.example.com/new_user">
  <input type="hidden" name="username" value="hacker">
  <input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
  document.usr_form.submit();
</script>

example.com の管理者が、サイトでセッションを行っているときに、悪意あるページにアクセスすると、攻撃者にアカウントを作成してしまいますが、本人はそのことに気づきません。これが CSRF 攻撃です。アプリケーションには、リクエストの生成元を検証する方法がないために、この攻撃が可能となっています。リクエストはユーザによって選択された正当なアクションにも、攻撃者が準備した不正なアクションにもなりえます。攻撃者は偽のリクエストを生成する Web ページを見ることができません。そのため、この攻撃方法は、アプリケーションの状態を変更するリクエストにのみ有効です。

cookie ではなく URL でセッション ID を渡すアプリケーションには CSRF の問題は存在しません。これは、攻撃者にとってセッション ID にアクセスすることやセッション ID を偽のリクエストの一部に追加することは不可能であるためです。