デフォルトでは、SNS トピックは保存時に暗号化されません。そのため、許可されていない閲覧者にデータが公開される可能性があります。

例 1: 次の例は、AWS KMS キー識別子の定義を怠ったために SNS トピックの暗号化に失敗するテンプレートを示しています。

AWSTemplateFormatVersion: 2010-09-09
Description: My SNS Topic
Resources:
  MySNSTopic:
    Type: AWS::SNS::Topic
    Properties:
      Subscription:
        - Endpoint: "MySNSEndpoint"
      Protocol: "sqs"
      TopicName: "SampleTopic"

キーチェーン サービスを使用して、タッチ ID ベースの認証を実装できます。それには、キーチェーンにアイテムを格納して、後からアイテムを取得するにはフィンガープリントを使用することをユーザーに要求するアクセス制御を設定します。次のポリシーを使用して、フィンガープリントを使用してユーザーを認証する方法を定義できます。

- kSecAccessControlUserPresence: タッチ ID またはパスコードでのアクセスへの制約。タッチ ID が使用可能である、または登録されている必要はありません。フィンガープリントが追加または削除された場合でも、引き続きタッチ ID でアイテムにアクセスできます。
- kSecAccessControlTouchIDAny: 登録されている任意のフィンガープリントのタッチ ID でのアクセスへの制約。フィンガープリントが追加または削除された場合、アイテムは無効化されません。
- kSecAccessControlTouchIDCurrentSet: 現在登録されているフィンガープリントのタッチ ID でのアクセスへの制約。フィンガープリントが追加または削除された場合、アイテムは無効化されます。

タッチ ID を使用する場合、kSecAccessControlTouchIDCurrentSet 属性を使用して、フィンガープリントが今後追加または削除されるのを防ぐ必要があります。

例 1: 次のコードは、今後登録されるフィンガープリントでキーチェーンのアイテムをロック解除できる kSecAccessControlTouchIDAny 制約を使用しています。

    ...
    let flags = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
        kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
        .TouchIDAny, 
        nil)

    var query = [String : AnyObject]()
    query[kSecClass as String] = kSecClassGenericPassword
    query[kSecAttrService as String] = service as AnyObject?
    query[kSecAttrAccount as String] = account as AnyObject?
    query[kSecValueData as String] = secret as AnyObject?
    ...
    query[kSecAttrAccessControl as String] = sacRef
    query[kSecUseOperationPrompt as String] = "Please authenticate using the Touch ID sensor."

    SecItemAdd(query as CFDictionary, nil)
    ...

アプリケーションが次の場合に Cross-Frame Scripting に対して脆弱になります。

1. iframe 内への追加をアプリケーション自体に許可する場合。
2. X-Frame-Options ヘッダーを介してフレーミング ポリシーを指定できない場合。
3. JavaScript ベースのフレーム バースティング ロジックなど、低品質の防御機能を使用する場合。

クロスフレーム スクリプトに対する脆弱性は、多くの場合、クリックジャッキング攻撃の土台となり、攻撃者はこれを利用し、クロスサイト リクエスト フォージェリ攻撃やフィッシング攻撃を実行できます。

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

次の場合に、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 を偽のリクエストの一部に追加することは不可能であるためです。

次の場合に、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 を偽のリクエストの一部に追加することは不可能であるためです。

次の場合に、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 を偽のリクエストの一部に追加することは不可能であるためです。

次の場合に、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 を偽のリクエストの一部に追加することは不可能であるためです。

クロスサイト WebSocket 乗っ取りは、正規のバックエンドサーバーとの WebSocket 接続を確立する悪意あるサイトにアクセスするようにユーザーが仕向けられた場合に発生します。WebSocket プロトコルへのアップグレードをサーバーに要求するために使用される最初の HTTP リクエストは、通常の HTTP リクエストです。そのため、ブラウザは、すべてのセッション cookie を含む、ターゲットドメインを指す任意の cookie を送信します。Origin ヘッダーの検証に失敗した場合、サーバーは、悪意あるサイトがユーザーに気づかれずにユーザーを偽装し、双方向 WebSocket 接続を確立することを許可します。

File Based Cross Zone Scripting が発生するのは、次の条件に一致した場合です。

1. アプリケーション内でスクリプトの実行を許可する可能性があるファイルがロードされた場合。


2. ロードされたスクリプトが、実行中のアプリケーションと生成元が同じであると表示されている場合 (file://)。

この両方の条件に一致すると、特に、第三者が情報の発生元がアプリケーションの境界内かどうかに基づいて信頼性を判定している場合、一連の攻撃が可能になります。

例 1: 次のコードは、UIWebView.loadRequest(_:) メソッドを使用してローカル ファイルをロードしています。

...
NSURL *url = [[NSBundle mainBundle] URLForResource: filename withExtension:extension]; 
[webView loadRequest:[[NSURLRequest alloc] initWithURL:url]];
...

Example 1 の WebView エンジンは、file:// で開始する URL を使用する UIWebView.loadRequest(_:) でロードされたものはすべて、権限のあるローカル ファイルで発生したとして扱います。

攻撃者がファイルからのロード時に File Based Cross-Zone Scripting の脆弱性を利用する場合、いくつかの典型的な方法があります。

- ローカル ファイルが攻撃者によって制御される。たとえば、攻撃者はファイルを攻撃対象者に送信し、攻撃対象者はそのファイルを脆弱なアプリケーション (クラウド ストレージ アプリケーションなど) に保存することがあります。
- ローカル ファイルが攻撃者によって操作され、スクリプトがファイル内に挿入される。これは、ファイルが存在する場所のファイル権限、またはファイルが保存されてロードされた場所の Race Condition に依存します。
- ファイルが外部リソースをコールアウトする。これは、ロードされたファイルが外部リソースからスクリプトを取得する場合に発生する可能性があります。
- ロードされるファイルに Cross-Site Scripting の脆弱性が含まれている場合がある。ロードされているファイルに挿入されたコードが含まれている場合、このコードはアプリケーションのコンテキスト内で実行される可能性があります。挿入されるコードを JavaScript コードにする必要はなく、挿入された HTML コードによって改ざんや DoS (サービス妨害) 攻撃も実行できるようになります。

攻撃者が制御するファイルが file:// URL によってローカルにロードされると、同一生成元ポリシーによって、このファイル内のスクリプトは同じ生成元から生成された他のファイルにアクセスできるようになるため、攻撃者は機密情報を含むすべてのローカル ファイルにアクセスできるようになる可能性があります。

File Based Cross Zone Scripting が発生するのは、次の条件に一致した場合です。

1. アプリケーション内でスクリプトの実行を許可する可能性があるファイルがロードされた場合。


2. ロードされたスクリプトが、実行中のアプリケーションと生成元が同じであると表示されている場合 (file://)。

この両方の条件に一致すると、特に、第三者が情報の発生元がアプリケーションの境界内かどうかに基づいて信頼性を判定している場合、一連の攻撃が可能になります。

例 1: 次のコードは、UIWebView.loadRequest(_:) メソッドを使用してローカル ファイルをロードしています。

...
let url = Bundle.main.url(forResource: filename, withExtension: extension)
self.webView!.load(URLRequest(url:url!))
...

Example 1 の WebView エンジンは、file:// で開始する URL を使用する UIWebView.loadRequest(_:) でロードされたものはすべて、権限のあるローカル ファイルで発生したとして扱います。

攻撃者がファイルからのロード時に File Based Cross-Zone Scripting の脆弱性を利用する場合、いくつかの典型的な方法があります。

- ローカル ファイルが攻撃者によって制御される。たとえば、攻撃者はファイルを攻撃対象者に送信し、攻撃対象者はそのファイルを脆弱なアプリケーション (クラウド ストレージ アプリケーションなど) に保存することがあります。
- ローカル ファイルが攻撃者によって操作され、スクリプトがファイル内に挿入される。これは、ファイルが存在する場所のファイル権限、またはファイルが保存されてロードされた場所の Race Condition に依存します。
- ファイルが外部リソースをコールアウトする。これは、ロードされたファイルが外部リソースからスクリプトを取得する場合に発生する可能性があります。
- ロードされるファイルに Cross-Site Scripting の脆弱性が含まれている場合がある。ロードされているファイルに挿入されたコードが含まれている場合、このコードはアプリケーションのコンテキスト内で実行される可能性があります。挿入されるコードを JavaScript コードにする必要はなく、挿入された HTML コードによって改ざんや DoS (サービス妨害) 攻撃も実行できるようになります。

攻撃者が制御するファイルが file:// URL によってローカルにロードされると、同一生成元ポリシーによって、このファイル内のスクリプトは同じ生成元から生成された他のファイルにアクセスできるようになるため、攻撃者は機密情報を含むすべてのローカル ファイルにアクセスできるようになる可能性があります。

GraphiQL は、GraphQL スキーマ イントロスペクション メカニズムを活用して、GraphQL API の開発とテスト用のグラフィカル インターフェイスを提供するブラウザー内ツールです。GraphiQL は、ユーザーが GraphQL スキーマを調べたり、GraphQL クエリを作成および実行したりするのに役立ちます。

GraphiQL を介して GraphQL スキーマのイントロスペクションを有効にすると、全体的なセキュリティにリスクが生じる可能性があるため、本番環境で GraphiQL へのアクセスを許可することはお勧めしません。攻撃者は GraphiQL とイントロスペクションを使用して、GraphQL スキーマから実装の詳細を取得し、より的を絞った攻撃を実行できます。GraphQL スキーマは、内部で使用されるフィールド、説明、非推奨のメモなど、一般の使用を目的としていない可能性のある情報をリークする可能性があります。

例 1: 次のコードは、デフォルトで有効になっている GraphiQL を使用して GraphQL.js エンドポイントを初期化します。

app.use('/graphql', graphqlHTTP({
    schema
}));

GraphiQL は、GraphQL スキーマ イントロスペクション メカニズムを活用して、GraphQL API の開発とテスト用のグラフィカル インターフェイスを提供するブラウザー内ツールです。GraphiQL は、ユーザーが GraphQL スキーマを調べたり、GraphQL クエリを作成および実行したりするのに役立ちます。

GraphiQL を介して GraphQL スキーマのイントロスペクションを有効にすると、全体的なセキュリティにリスクが生じる可能性があるため、本番環境で GraphiQL へのアクセスを許可することはお勧めしません。攻撃者は GraphiQL とイントロスペクションを使用して、GraphQL スキーマから実装の詳細を取得し、より的を絞った攻撃を実行できます。GraphQL スキーマは、内部で使用されるフィールド、説明、非推奨のメモなど、一般の使用を目的としていない情報をリークする可能性があります。

例 1: 次のコードでは、GraphiQL を有効にして GraphQL エンドポイントを初期化します。

app.add_url_rule('/graphql', view_func=GraphQLView.as_view(
  'graphql',
  schema = schema,
  graphiql = True
))

GraphQL イントロスペクション機能を使用すると、誰でも GraphQL サーバーに現在のスキーマに関する情報を照会できます。利害関係者は、GraphQL イントロスペクション クエリを発行して、スキーマで使用可能な操作、データ型、フィールド、およびドキュメントの全体像を把握できます。

GraphQL イントロスペクションは、GraphQL API に関する情報の開発と共有のコンテキストで重要なユーティリティを提供します。イントロスペクションは、さまざまなツールとの統合を容易にする強力な GraphQL 機能です。たとえば、IDE はスキーマ イントロスペクションを活用して、GraphQL API を開発およびテストするための拡張機能を提供できます。

しかし、本番環境で誰でも GraphQL スキーマを照会できるようにすると、全体的なセキュリティにリスクが生じる可能性があります。攻撃者がイントロスペクションを使用して、GraphQL スキーマから実装の詳細を取得し、より的を絞った攻撃を実行できます。GraphQL スキーマは、内部で使用されるフィールド、説明、非推奨のメモなど、一般の使用を目的としていない可能性のある情報をリークする可能性があります。

例 1: 次のコードは、スキーマ イントロスペクションがデフォルトで有効になっている Hot Chocolate GraphQL エンドポイントを初期化します。

    services
        .AddGraphQLServer()
        .AddQueryType<Query>()
        .AddMutationType<Mutation>();
    

GraphQL イントロスペクション機能を使用すると、誰でも GraphQL サーバーに現在のスキーマに関する情報を照会できます。利害関係者は、GraphQL イントロスペクション クエリを発行して、スキーマで使用可能な操作、データ型、フィールド、およびドキュメントの全体像を把握できます。

GraphQL イントロスペクションは、GraphQL API に関する情報の開発と共有のコンテキストで重要なユーティリティを提供します。イントロスペクションは、さまざまなツールとの統合を容易にする強力な GraphQL 機能です。たとえば、IDE はスキーマ イントロスペクションを活用して、GraphQL API を開発およびテストするための拡張機能を提供できます。

しかし、本番環境で誰でも GraphQL スキーマを照会できるようにすると、全体的なセキュリティにリスクが生じる可能性があります。攻撃者がイントロスペクションを使用して、GraphQL スキーマから実装の詳細を取得し、より的を絞った攻撃を実行できます。GraphQL スキーマは、内部で使用されるフィールド、説明、非推奨のメモなど、一般の使用を目的としていない可能性のある情報をリークする可能性があります。

例 1: 次のコードでは、スキーマ イントロスペクションがデフォルトで有効になっている GraphQL エンドポイントを初期化します。

app.use('/graphql', graphqlHTTP({
    schema
}));

GraphQL イントロスペクション機能を使用すると、誰でも GraphQL サーバーに現在のスキーマに関する情報を照会できます。利害関係者は、GraphQL イントロスペクション クエリを発行して、スキーマで使用可能な操作、データ型、フィールド、およびドキュメントの全体像を把握できます。

GraphQL イントロスペクションは、GraphQL API に関する情報の開発と共有のコンテキストで重要なユーティリティを提供します。イントロスペクションは、さまざまなツールとの統合を容易にする強力な GraphQL 機能です。たとえば、IDE はスキーマ イントロスペクションを活用して、GraphQL API を開発およびテストするための拡張機能を提供できます。

しかし、本番環境で誰でも GraphQL スキーマを照会できるようにすると、全体的なセキュリティにリスクが生じる可能性があります。攻撃者がイントロスペクションを使用して、GraphQL スキーマから実装の詳細を取得し、より的を絞った攻撃を実行できます。GraphQL スキーマは、内部で使用されるフィールド、説明、非推奨のメモなど、一般の使用を目的としていない情報をリークする可能性があります。

例 1: 次のコードでは、スキーマ イントロスペクションがデフォルトで有効になっている GraphQL エンドポイントを初期化します。

app.add_url_rule('/graphql', view_func=GraphQLView.as_view(
  'graphql',
  schema = schema
))

プログラマは、「ユーザーは非表示フィールドを見ることも、その内容を操作することもできない」という前提から、非表示フィールドの内容を信頼する傾向にあります。攻撃者はそのような想定に反して、非表示フィールドに書き込まれた値を調べ、その値を改ざんしたり不正なデータに置き換えたりします。

例 1:

  HtmlInputHidden hidden = new HtmlInputHidden();

重要な情報が非表示フィールドに保管されている場合、そのページ上の他の情報がキャッシュされるのと同じ方法で重要な情報がキャッシュされてしまいます。すると、ユーザーの知らない間に重要な情報がブラウザキャッシュに保存される可能性があります。

プログラマは、「ユーザーは非表示フィールドを見ることも、その内容を操作することもできない」という前提から、非表示フィールドの内容を信頼する傾向にあります。攻撃者はそのような想定に反して、非表示フィールドに書き込まれた値を調べ、その値を改ざんしたり不正なデータに置き換えたりします。

例 1:hidden タイプの <input> タグは、非表示フィールドが使用されていることを示します。

<input type="hidden">

重要な情報が非表示フィールドに保管されている場合、そのページ上の他の情報がキャッシュされるのと同じ方法で重要な情報がキャッシュされてしまいます。すると、ユーザーの知らない間に重要な情報がブラウザキャッシュに保存される可能性があります。