ブラウザーは、cookie を設定しているサイトに対して行われたあらゆる HTTP リクエストに自動的に cookie を追加します。cookie は、セッション ID や認証トークン、またはセッション中に同じサイトに対して行われる別のリクエスト間で共有されるサイト データなどの機密データを保存する場合があります。攻撃者は、ブラウザが自動的にクッキーをリクエストに追加するため、クライアントマシンに読み込まれたサードパーティのサイト ページから認証サイトへのリクエストを生成することで、なりすまし攻撃を行うことができます。

SameSite パラメーターは、リクエストがファーストパーティまたは同じサイトのコンテキストから生成された場合にのみリクエストに追加するよう cookie の範囲を制限します。これは、Cross-Site Request Forgery (CSRF) 攻撃から cookie を保護するのに役立ちます。SameSite パラメーターの値は、次の 3 つのうちのいずれかになります。

- Strict: Strict に設定した場合、cookie はトップレベル ナビゲーションのリクエストとともにのみ送信されます。
- Lax: Lax に設定した場合、cookie は、同じホストからのトップレベル ナビゲーションだけでなく、サードパーティ サイトからホストへの GET リクエストとともに送信されます。たとえば、ホスト サイトにリンクする、iframe タグか href タグを持つサードパーティ サイトがあるとします。ユーザーがリンクをたどると、リクエストには cookie が含まれます。
- None: Cookie は、Cookie に設定されたパスやドメインの範囲内にあるサイトに対して行われたすべてのリクエストで送信されます。POST メソッドを使用したフォームの送信により生成されたリクエストも、リクエストとともに Cookie を送信することができます。

例 1: 次のコードは、セッション cookie の SameSite 属性を None に設定しています。

...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'None');
...

ブラウザーは、cookie を設定しているサイトに対して行われたあらゆる HTTP リクエストに自動的に cookie を追加します。cookie は、セッション ID や認証トークン、またはセッション中に同じサイトに対して行われる別のリクエスト間で共有されるサイト データなどの機密データを保存する場合があります。攻撃者は、ブラウザが自動的にクッキーをリクエストに追加するため、クライアントマシンに読み込まれたサードパーティのサイト ページから認証サイトへのリクエストを生成することで、なりすまし攻撃を行うことができます。

SameSite 属性は、リクエストがファーストパーティまたは同じサイトのコンテキストから生成された場合にのみリクエストに追加するよう Cookie の範囲を制限します。これは、Cross-Site Request Forgery (CSRF) 攻撃から cookie を保護するのに役立ちます。SameSite 属性の値は、次の 3 つのうちのいずれかになります。

- Strict: Strict に設定した場合、cookie はトップレベル ナビゲーションのリクエストとともにのみ送信されます。
- Lax: Lax に設定した場合、cookie は、同じホストからのトップレベル ナビゲーションだけでなく、サードパーティ サイトからホストへの GET リクエストとともに送信されます。たとえば、ホスト サイトにリンクする、iframe タグか href タグを持つサードパーティ サイトがあるとします。ユーザーがリンクをたどると、リクエストには cookie が含まれます。
- None: Cookie は、Cookie に設定されたパスやドメインの範囲内にあるサイトに対して行われたすべてのリクエストで送信されます。POST メソッドを使用したフォームの送信により生成されたリクエストも、リクエストとともに Cookie を送信することができます。

例 1: 次のコードでは、セッション cookie の SameSite 属性を無効にしています。

c := &http.Cookie{
  Name: "cookie",
  Value: "samesite-none",
  SameSite: http.SameSiteNoneMode,
}

ブラウザーは、cookie を設定しているサイトに対して行われたあらゆる HTTP リクエストに自動的に cookie を追加します。cookie は、セッション ID や認証トークン、またはセッション中に同じサイトに対して行われる別のリクエスト間で共有されるサイト データなどの機密データを保存する場合があります。攻撃者は、ブラウザーが自動的に Cookie をリクエストに追加するため、クライアント マシンに読み込まれたサードパーティのサイト ページから認証サイトへのリクエストを生成することで、なりすまし攻撃を行うことができます。

SameSite 属性は、リクエストがファーストパーティまたは同じサイトのコンテキストから生成された場合にのみリクエストに追加するよう Cookie の範囲を制限します。これは、Cross-Site Request Forgery (CSRF) 攻撃から cookie を保護するのに役立ちます。SameSite 属性の値は、次の 3 つのうちのいずれかになります。

- Strict: Strict に設定した場合、cookie はトップレベル ナビゲーションのリクエストとともにのみ送信されます。
- Lax: Lax に設定した場合、Cookie は、同じホストからのトップレベル ナビゲーションだけでなく、サードパーティ サイトからの GET リクエスト (ホスト サイトにリンクする iframe タグまたは href タグを持つリクエストを含む) とともに送信されます。たとえば、ホスト サイトにリンクする、iframe タグか href タグを持つサードパーティ サイトがあるとします。ユーザーがリンクをたどると、リクエストには cookie が含まれます。
- None: Cookie は、Cookie に設定されたパスやドメインの範囲内にあるサイトに対して行われたすべてのリクエストで送信されます。POST メソッドを使用したフォームの送信により生成されたリクエストも、リクエストとともに Cookie を送信することができます。

例 1: 次のコードでは、セッション cookie の SameSite 属性を無効にしています。

 ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue")
     ...
     .sameSite("None") 
     ...

ブラウザーは、cookie を設定しているサイトに対して行われたあらゆる HTTP リクエストに自動的に cookie を追加します。cookie は、セッション ID や認証トークン、またはセッション中に同じサイトに対して行われる別のリクエスト間で共有されるサイト データなどの機密データを保存する場合があります。攻撃者は、ブラウザーが自動的に Cookie をリクエストに追加するため、クライアント マシンに読み込まれたサードパーティのサイト ページから認証サイトへのリクエストを生成することで、なりすまし攻撃を行うことができます。

SameSite 属性は、リクエストがファーストパーティまたは同じサイトのコンテキストから生成された場合にのみリクエストに追加するよう Cookie の範囲を制限します。これは、Cross-Site Request Forgery (CSRF) 攻撃から cookie を保護するのに役立ちます。SameSite 属性の値は、次の 3 つのうちのいずれかになります。

- Strict: Strict に設定した場合、cookie はトップレベル ナビゲーションのリクエストとともにのみ送信されます。
- Lax: Lax に設定した場合、Cookie は、同じホストからのトップレベル ナビゲーションだけでなく、サードパーティ サイトからの GET リクエスト (ホスト サイトにリンクする iframe タグまたは href タグを持つリクエストを含む) とともに送信されます。たとえば、ホスト サイトにリンクする、iframe タグか href タグを持つサードパーティ サイトがあるとします。ユーザーがリンクをたどると、リクエストには cookie が含まれます。
- None: Cookie は、Cookie に設定されたパスやドメインの範囲内にあるサイトに対して行われたすべてのリクエストで送信されます。POST メソッドを使用したフォームの送信により生成されたリクエストも、リクエストとともに Cookie を送信することができます。

例 1: 次のコードでは、セッション cookie の SameSite 属性を無効にしています。

app.get('/', function (req, res) {
    ...
    res.cookie('name', 'Foo', { sameSite: false });
    ...
}

ブラウザーは、cookie を設定しているサイトに対して行われたあらゆる HTTP リクエストに自動的に cookie を追加します。cookie は、セッション ID や認証トークン、またはセッション中に同じサイトに対して行われる別のリクエスト間で共有されるサイト データなどの機密データを保存する場合があります。攻撃者は、ブラウザが自動的にクッキーをリクエストに追加するため、クライアントマシンに読み込まれたサードパーティのサイト ページから認証サイトへのリクエストを生成することで、なりすまし攻撃を行うことができます。

SameSite 属性は、リクエストがファーストパーティまたは同じサイトのコンテキストから生成された場合にのみリクエストに追加するよう cookie の範囲を制限します。これは、クロスサイト リクエスト フォージェリ (CSRF) 攻撃から cookie を保護するのに役立ちます。SameSite 属性の値は、次の 3 つのうちのいずれかになります。

- Strict: Strict に設定した場合、cookie はトップレベル ナビゲーションのリクエストとともにのみ送信されます。
- Lax: Lax に設定した場合、cookie は、同じホストからのトップレベル ナビゲーションだけでなく、サードパーティ サイトからホストへの GET リクエストとともに送信されます。たとえば、ホスト サイトにリンクする、iframe タグか href タグを持つサードパーティ サイトがあるとします。ユーザーがリンクをたどると、リクエストには cookie が含まれます。
- None: Cookie は、Cookie に設定されたパスやドメインの範囲内にあるサイトに対して行われたすべてのリクエストで送信されます。POST メソッドを使用したフォームの送信により生成されたリクエストも、リクエストとともに Cookie を送信することができます。

例 1: 次のコードでは、セッション cookie の SameSite 属性を無効にしています。

ini_set("session.cookie_samesite", "None");

ブラウザーは、cookie を設定しているサイトに対して行われたあらゆる HTTP リクエストに自動的に cookie を追加します。cookie は、セッション ID や認証トークン、またはセッション中に同じサイトに対して行われる別のリクエスト間で共有されるサイト データなどの機密データを保存する場合があります。攻撃者は、ブラウザが自動的にクッキーをリクエストに追加するため、クライアントマシンに読み込まれたサードパーティのサイト ページから認証サイトへのリクエストを生成することで、なりすまし攻撃を行うことができます。

samesite パラメーターは、リクエストがファーストパーティまたは同じサイトのコンテキストから生成された場合にのみリクエストに追加するよう Cookie の範囲を制限します。これは、Cross-Site Request Forgery (CSRF) 攻撃から cookie を保護するのに役立ちます。samesite パラメーターの値は、次の 3 つのうちのいずれかになります。

- Strict: Strict に設定した場合、cookie はトップレベル ナビゲーションのリクエストとともにのみ送信されます。
- Lax: Lax に設定した場合、cookie は、同じホストからのトップレベル ナビゲーションだけでなく、サードパーティ サイトからホストへの GET リクエストとともに送信されます。たとえば、ホスト サイトにリンクする、iframe タグか href タグを持つサードパーティ サイトがあるとします。ユーザーがリンクをたどると、リクエストには cookie が含まれます。
- None: Cookie は、Cookie に設定されたパスやドメインの範囲内にあるサイトに対して行われたすべてのリクエストで送信されます。POST メソッドを使用したフォームの送信により生成されたリクエストも、リクエストとともに Cookie を送信することができます。

例 1: 次のコードでは、セッション cookie の SameSite 属性を無効にしています。

  response.set_cookie("cookie", value="samesite-none", samesite=None)

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://secure.example.com/ に安全なアプリケーションを配置していると考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが「.example.com」であるセッション ID の cookie が設定されます。

例：

cookie := http.Cookie{
  Name:       "sessionID",
  Value:      getSessionID(),
  Domain:     ".example.com",
}
...

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションにクロスサイト スクリプティングの脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

攻撃者は、cookie の読み取りに加えて、「Cookie Poisoning 攻撃」を実行することもあります。その場合、攻撃者は insecure.example.com を使用して、パスがあまりに広範にわたっている cookie を独自に作成し、Secure.example.com からの cookie を上書きします。

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://secure.example.com/ に安全なアプリケーションを配置していると考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが「.example.com」であるセッション ID の cookie が設定されます。

例：

  Cookie cookie = new Cookie("sessionID", sessionID);
  cookie.setDomain(".example.com");

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://secure.example.com/ に安全なアプリケーションを配置していると考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが「.example.com」であるセッション ID の cookie が設定されます。

例：

  cookie_options = {};
  cookie_options.domain = '.example.com';
  ...
  res.cookie('important_cookie', info, cookie_options);

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://secure.example.com/ に安全なアプリケーションを配置していると考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが「.example.com」であるセッション ID の cookie が設定されます。

例：

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:@".example.com" forKey:NSHTTPCookieDomain];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://secure.example.com/ に安全なアプリケーションを配置していると考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが「.example.com」であるセッション ID の cookie が設定されます。

例：

setcookie("mySessionId", getSessionID(), 0, "/", ".example.com", true, true);

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://secure.example.com/ に安全なアプリケーションを配置していると考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが「.example.com」であるセッション ID の cookie が設定されます。

例：

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("mySessionId", getSessionID(), domain=".example.com")
  return res
...

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

cookie の読み取りに加えて、「Cookie Poisoning 攻撃」が実行される可能性もあります。その場合、攻撃者は insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://secure.example.com/ に安全なアプリケーションを配置していると考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが「.example.com」であるセッション ID の cookie が設定されます。

例：

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, domain = Some(".example.com")))

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションにCross-site Scriptingの脆弱性が存在するとします。 http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://secure.example.com/ に安全なアプリケーションを配置していると考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが「.example.com」であるセッション ID の cookie が設定されます。

例：

...
let properties = [
    NSHTTPCookieDomain: ".example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar",
    NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。

開発者は cookie を root コンテキストパス ("/") からアクセスできるように設定する傾向にあります。この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。例：

...
String path = '/';
Cookie cookie = new Cookie('sessionID', sessionID, path, maxAge, true, 'Strict');
...

攻撃者が http://communitypages.example.com/EvilSite に別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスしたフォーラム ユーザーのアカウントであれば、危険にさらされることがあります。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は /EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。

開発者は cookie を root コンテキストパス ("/") からアクセスできるように設定する傾向にあります。この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置していると考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、「/」というパスを持つセッション ID の cookie が設定されます。

例：

cookie := http.Cookie{
  Name:    "sessionID",
  Value:   sID,
  Expires: time.Now().AddDate(0, 0, 1),
  Path:    "/",
}
...

攻撃者が http://communitypages.example.com/EvilSite に別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。フォーラム ユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションへ送信します。攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスしたフォーラム ユーザーのアカウントであれば、危険にさらされることがあります。

攻撃者は、cookie の読み取りに加えて、「Cookie Poisoning 攻撃」を実行することもあります。その場合、攻撃者は /EvilSite を使用して、パスがあまりに広範にわたっている cookie を独自に作成し、/MyForum からの cookie を上書きします。

開発者は cookie を root コンテキストパス ("/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。

例：

  Cookie cookie = new Cookie("sessionID", sessionID);
  cookie.setPath("/");

攻撃者が http://communitypages.example.com/EvilSiteに別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は /EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。

開発者は cookie を root コンテキストパス ("/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。

例：

  cookie_options = {};
  cookie_options.path = '/';
  ...
  res.cookie('important_cookie', info, cookie_options);

攻撃者が http://communitypages.example.com/EvilSiteに別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は /EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。

開発者は cookie を root コンテキストパス ("/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。

例：

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:@"/" forKey:NSHTTPCookiePath];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

攻撃者が http://communitypages.example.com/EvilSiteに別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は /EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。

開発者は cookie を root コンテキストパス ("/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。

例：

  setcookie("mySessionId", getSessionID(), 0, "/", "communitypages.example.com", true, true);

攻撃者が http://communitypages.example.com/EvilSite に別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は /EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。

開発者は cookie を root コンテキストパス ("/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。

例：

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("sessionid", value)   # Path defaults to "/"
  return res
...

攻撃者が http://communitypages.example.com/EvilSiteに別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。

cookie の読み取りに加えて、「Cookie Poisoning 攻撃」が実行される可能性もあります。その場合、攻撃者は /EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。

開発者は cookie を root コンテキストパス ("/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。

例：

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, path = "/"))

攻撃者が http://communitypages.example.com/EvilSiteに別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は /EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。

開発者は cookie を root コンテキストパス ("/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。

例：

...
let properties = [
    NSHTTPCookieDomain: "www.example.com",
    NSHTTPCookiePath: "/",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar",
    NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

攻撃者が http://communitypages.example.com/EvilSiteに別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は /EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。

ブラウザーは、cookie を設定しているサイトに対して行われたあらゆる HTTP リクエストに自動的に cookie を追加します。cookie は、セッション ID や認証トークン、またはセッション中に同じサイトに対して行われる別のリクエスト間で共有されるサイト データなどの機密データを保存する場合があります。攻撃者は、ブラウザが自動的にクッキーをリクエストに追加するため、クライアントマシンに読み込まれたサードパーティのサイト ページから認証サイトへのリクエストを生成することで、なりすまし攻撃を行うことができます。

SameSite パラメーターは、リクエストがファーストパーティまたは同じサイトのコンテキストから生成された場合にのみリクエストに追加するよう cookie の範囲を制限します。これは、Cross-Site Request Forgery (CSRF) 攻撃から cookie を保護するのに役立ちます。SameSite パラメーターの値は、次の 3 つのうちのいずれかになります。

- Strict: Strict に設定した場合、cookie はトップレベル ナビゲーションのリクエストとともにのみ送信されます。
- Lax: Lax に設定した場合、cookie は、同じホストからのトップレベル ナビゲーションだけでなく、サードパーティ サイトからホストへの GET リクエストとともに送信されます。たとえば、ホスト サイトにリンクする、iframe タグか href タグを持つサードパーティ サイトがあるとします。ユーザーがリンクをたどると、リクエストには cookie が含まれます。
- None: Cookie は、Cookie に設定されたパスやドメインの範囲内にあるサイトに対して行われたすべてのリクエストで送信されます。POST メソッドを使用したフォームの送信により生成されたリクエストも、リクエストとともに Cookie を送信することができます。

例 1: 次のコードは、セッション cookie の SameSite パラメーターを Lax に設定します。

...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'Lax');
...

SameSite 属性は、クロスサイト リクエスト フォージェリ (CSRF) などの攻撃から Cookie を保護します。セッション Cookie はサイトに対してユーザーを表しているため、ユーザーは承認されたアクションを実行できるようになります。ただし、ブラウザーはリクエストとともに自動的に Cookie を送信するため、ユーザーと Web サイトは認証について暗黙的にブラウザーを信頼することになります。攻撃者はこの信頼を悪用して、攻撃者が制御するサードパーティ サイトのページにある link や iframe などのタグの href や src 属性内にリンクを埋め込むことで、ユーザーの代わりにサイトにリクエストを行うことができます。疑いを持たないユーザーを攻撃者が制御するサードパーティのサイトにおびき寄せることができれば、攻撃者はユーザーを認証するセッション Cookie を自動的に含めるリクエストを行うことができ、攻撃者がユーザーであるかのように効果的に認証されることになります。
SameSite 属性のセッション Cookie を SameSiteStrictMode に設定すると、トップレベル ナビゲーションまたは同じサイトからのリクエストにのみ Cookie を追加するよう、ブラウザーを制限できます。iframe, img, and form などのさまざまなタグにおけるリンク経由のサードパーティ サイトからのリクエストにはこれらの Cookie がないため、ユーザーが認証されていない可能性がある場合にサイトでの処理が回避されます。

例 1: 次のコードでは、セッション Cookie の SameSite 属性の SameSiteLaxMode を有効にしています。

c := &http.Cookie{
  Name: "cookie",
  Value: "samesite-lax",
  SameSite: http.SameSiteLaxMode,
}

SameSite 属性は、Cross-Site Request Forgery (CSRF) などの攻撃から Cookie を保護します。セッション Cookie はサイトに対してユーザーを表しているため、ユーザーは承認されたアクションを実行できるようになります。ただし、ブラウザーはリクエストとともに自動的に Cookie を送信するため、ユーザーと Web サイトは認証について暗黙的にブラウザーを信頼することになります。攻撃者はこの信頼を悪用して、攻撃者が制御するサードパーティ サイトのページにある link や iframe などのタグの href や src 属性内にリンクを埋め込むことで、ユーザーの代わりにサイトにリクエストを行うことができます。疑いを持たないユーザーを攻撃者が制御するサードパーティのサイトにおびき寄せることができれば、攻撃者はユーザーを認証するセッション Cookie を自動的に含めるリクエストを行うことができ、攻撃者がユーザーであるかのように効果的に認証されることになります。
セッション Cookie で、SameSite 属性の値を Strict に設定します。これにより、トップレベル ナビゲーションまたは同じサイトからのリクエストにのみ Cookie を追加するよう、ブラウザーが制限されます。iframe, img, and form などのさまざまなタグにおけるリンク経由のサードパーティ サイトからのリクエストにはこれらの Cookie がないため、ユーザーが認証されていない可能性がある場合にサイトでの処理が回避されます。

例 1: 次のコードでは、セッション cookie の SameSite 属性の値を Lax に設定しています。

 ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue") 
     ...
     .sameSite("Lax")  
     ...
}

SameSite 属性は、Cross-Site Request Forgery (CSRF) などの攻撃から Cookie を保護します。セッション Cookie はサイトに対してユーザーを表しているため、ユーザーは承認されたアクションを実行できるようになります。ただし、ブラウザーはリクエストとともに自動的に Cookie を送信するため、ユーザーと Web サイトは認証について暗黙的にブラウザーを信頼することになります。攻撃者はこの信頼を悪用して、攻撃者が制御するサードパーティ サイトのページにある link や iframe などのタグの href や src 属性内にリンクを埋め込むことで、ユーザーの代わりにサイトにリクエストを行うことができます。疑いを持たないユーザーを攻撃者が制御するサードパーティのサイトにおびき寄せることができれば、攻撃者はユーザーを認証するセッション Cookie を自動的に含めるリクエストを行うことができ、攻撃者がユーザーであるかのように効果的に認証されることになります。
セッション Cookie で、SameSite 属性の値を Strict に設定します。これにより、トップレベル ナビゲーションまたは同じサイトからのリクエストにのみ Cookie を追加するよう、ブラウザーが制限されます。iframe, img, and form などのさまざまなタグにおけるリンク経由のサードパーティ サイトからのリクエストにはこれらの Cookie がないため、ユーザーが認証されていない可能性がある場合にサイトでの処理が回避されます。

例 1: 次のコードでは、セッション cookie の SameSite 属性の値を Lax に設定しています。

app.get('/', function (req, res) {
    ...
    res.cookie('name', 'Foo', { sameSite: "Lax" });
    ...
}

SameSite 属性は、クロスサイト リクエスト フォージェリ (CSRF) などの攻撃から Cookie を保護します。セッション Cookie はサイトに対してユーザーを表しているため、ユーザーは承認されたアクションを実行できるようになります。ただし、ブラウザーはリクエストとともに自動的に Cookie を送信するため、ユーザーと Web サイトは認証について暗黙的にブラウザーを信頼することになります。攻撃者はこの信頼を悪用して、攻撃者が制御するサードパーティ サイトのページにある link や iframe などのタグの href や src 属性内にリンクを埋め込むことで、ユーザーの代わりにサイトにリクエストを行うことができます。疑いを持たないユーザーを攻撃者が制御するサードパーティのサイトにおびき寄せることができれば、攻撃者はユーザーを認証するセッション Cookie を自動的に含めるリクエストを行うことができ、攻撃者がユーザーであるかのように効果的に認証されることになります。
SameSite 属性のセッション Cookie を Strict に設定すると、トップレベル ナビゲーションまたは同じサイトからのリクエストにのみ Cookie を追加するよう、ブラウザーを制限できます。iframe, img, and form などのさまざまなタグにおけるリンク経由のサードパーティ サイトからのリクエストにはこれらの Cookie がないため、ユーザーが認証されていない可能性がある場合にサイトでの処理が回避されます。

例 1: 次のコードでは、セッション cookie の SameSite 属性の Lax モードを有効にしています。

ini_set("session.cookie_samesite", "Lax");

SameSite 属性は、Cross-Site Request Forgery (CSRF) などの攻撃から Cookie を保護します。セッション Cookie はサイトに対してユーザーを表しているため、ユーザーは承認されたアクションを実行できるようになります。ただし、ブラウザーはリクエストとともに自動的に Cookie を送信するため、ユーザーと Web サイトは認証について暗黙的にブラウザーを信頼することになります。攻撃者はこの信頼を悪用して、攻撃者が制御するサードパーティ サイトのページにある link や iframe などのタグの href や src 属性内にリンクを埋め込むことで、ユーザーの代わりにサイトにリクエストを行うことができます。疑いを持たないユーザーを攻撃者が制御するサードパーティのサイトにおびき寄せる場合、攻撃者は、ユーザー認証を使用してセッション Cookie を自動的に含めるリクエストを行うことができます。これにより、攻撃者はユーザーの承認を使用してアクセスできるようになります。
SameSite パラメーターのセッション Cookie を Strict に設定すると、トップレベル ナビゲーションまたは同じサイトからのリクエストにのみ Cookie を追加するよう、ブラウザーを制限できます。iframe, img, and form などのさまざまなタグにおけるリンク経由のサードパーティ サイトからのリクエストにはこれらの Cookie がないため、ユーザーが認証されていない可能性がある場合にサイトでの処理が回避されます。

例 1: 次のコードでは、セッション Cookie の samesite 属性の Lax を有効にしています。

  response.set_cookie("cookie", value="samesite-lax", samesite="Lax")

ほとんどの Web プログラミング環境では、デフォルトで非永続的な cookie が作成されます。これらの cookie はブラウザーのメモリにのみ存在し (ディスクには書き込まれません)、ブラウザーを閉じると失われます。プログラマーは、cookie が特定の将来の日付までブラウザー セッション間で保持されるように指定できます。このような cookie はディスクに書き込まれ、ブラウザー セッションやコンピューターの再起動後も存続します。

個人情報が永続的な cookie に保存されていると、攻撃者がこのデータを盗める期間が長くなります (特に、永続的な cookie では通常、有効期限がかなり先に設定されているため)。永続的な cookie は、ユーザーがサイトとやり取りする際のユーザーのプロファイリングによく使用されます。この追跡データの利用方法によっては、永続的な cookie を使用してユーザーのプライバシーを侵害することが可能になります。

例 1: 次のコードは、10 年後に期限切れになるように cookie を設定しています。

...
Integer maxAge = 60*60*24*365*10;
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, true, 'Strict');
...

Web プログラミング環境の大部分では、非永続的な cookie の作成がデフォルトになっています。非永続的 cookie はブラウザメモリにのみ存在し (ディスクに書き込まれない)、ブラウザが終了すると消滅します。プログラマは、近い将来までブラウザセッション間で cookie が永続的になるよう指定できます。そのような cookie はディスクに書き込まれ、すべてのブラウザセッションで使用されます。また、コンピュータを再起動しても使用されます。

永続的 cookie では有効期限がずっと先に設定されることが多いため、永続的 cookie に個人情報が保管されていると、攻撃者が情報を盗み出すことのできる時間が長くなります。多くの場合、永続的 cookie はサイトとやり取りする際のユーザープロファイルとして使用されます。この追跡データに対して実行される操作によっては、ユーザーの個人情報を盗み出すのに永続的 cookie が悪用される可能性があります。
例 1: 次のコードは、10 年後に期限切れになるように cookie を設定しています。

	Cookie cookie = new Cookie("emailCookie", email);
	cookie.setMaxAge(60*60*24*365*10);

Web プログラミング環境の大部分では、非永続的な cookie の作成がデフォルトになっています。非永続的 cookie はブラウザメモリにのみ存在し (ディスクに書き込まれない)、ブラウザが終了すると消滅します。プログラマは、近い将来までブラウザセッション間で cookie が永続的になるよう指定できます。そのような cookie はディスクに書き込まれ、すべてのブラウザー セッションで使用されます。また、デバイスを再起動しても使用されます。

永続的 cookie では有効期限がずっと先に設定されることが多いため、永続的 cookie に個人情報が保管されていると、攻撃者が情報を盗み出すことのできる時間が長くなります。多くの場合、永続的 cookie はサイトとやり取りする際のユーザープロファイルとして使用されます。この追跡データに対して実行される操作によっては、ユーザーの個人情報を盗み出すのに永続的 cookie が悪用される可能性があります。
例 1: 次のコードは、10 年後に期限切れになるように cookie を設定しています。

    ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:[[NSDate date] dateByAddingTimeInterval:(60*60*24*365*10)] forKey:NSHTTPCookieExpires];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

Web プログラミング環境の大部分では、非永続的な cookie の作成がデフォルトになっています。非永続的 cookie はブラウザメモリにのみ存在し (ディスクに書き込まれない)、ブラウザが終了すると消滅します。プログラマは、近い将来までブラウザセッション間で cookie が永続的になるよう指定できます。そのような cookie はディスクに書き込まれ、すべてのブラウザセッションで使用されます。また、コンピュータを再起動しても使用されます。

永続的 cookie では有効期限がずっと先に設定されることが多いため、永続的 cookie に個人情報が保管されていると、攻撃者が情報を盗み出すことのできる時間が長くなります。多くの場合、永続的 cookie はサイトとやり取りする際のユーザープロファイルとして使用されます。この追跡データに対して実行される操作によっては、ユーザーの個人情報を盗み出すのに永続的 cookie が悪用される可能性があります。
例 1: 次のコードは、10 年後に期限切れになるように cookie を設定しています。

setcookie("emailCookie", $email, time()+60*60*24*365*10);

Web プログラミング環境の大部分では、非永続的な cookie の作成がデフォルトになっています。非永続的 cookie はブラウザメモリにのみ存在し (ディスクに書き込まれない)、ブラウザが終了すると消滅します。プログラマは、近い将来までブラウザセッション間で cookie が永続的になるよう指定できます。そのような cookie はディスクに書き込まれ、すべてのブラウザセッションで使用されます。また、コンピュータを再起動しても使用されます。

永続的 cookie では有効期限がずっと先に設定されることが多いため、永続的 cookie に個人情報が保管されていると、攻撃者が情報を盗み出すことのできる時間が長くなります。多くの場合、永続的 cookie はサイトとやり取りする際のユーザープロファイルとして使用されます。この追跡データに対して実行される操作によっては、ユーザーの個人情報を盗み出すのに永続的 cookie が悪用される可能性があります。
例 1: 次のコードでは、cookie の有効期限が 10 年後に切れるように設定しています。

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email, expires=time()+60*60*24*365*10, secure=True, httponly=True)
  return res
...

Web プログラミング環境の大部分では、非永続的な cookie の作成がデフォルトになっています。 非永続的 cookie はブラウザーメモリにのみ存在し (ディスクに書き込まれない)、ブラウザーが終了すると消滅します。 プログラマは、近い将来までブラウザーセッション間で cookie が永続的になるよう指定できます。 そのような cookie はディスクに書き込まれ、すべてのブラウザーセッションで使用されます。また、コンピュータを再起動しても使用されます。

永続的 cookie では有効期限がずっと先に設定されることが多いため、永続的 cookie に個人情報が保管されていると、攻撃者が情報を盗み出すことのできる時間が長くなります。 多くの場合、永続的 cookie はサイトとやり取りする際のユーザープロファイルとして使用されます。 この追跡データに対して実行される操作によっては、ユーザーの個人情報を盗み出すのに永続的 cookie が悪用される可能性があります。
例 1: 次のコードは、10 年後に期限切れになるように cookie を設定しています。

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, maxAge = Some(60*60*24*365*10)))

Web プログラミング環境の大部分では、非永続的な cookie の作成がデフォルトになっています。非永続的 cookie はブラウザメモリにのみ存在し (ディスクに書き込まれない)、ブラウザが終了すると消滅します。プログラマは、近い将来までブラウザセッション間で cookie が永続的になるよう指定できます。そのような cookie はディスクに書き込まれ、すべてのブラウザー セッションで使用されます。また、デバイスを再起動しても使用されます。

永続的 cookie では有効期限がずっと先に設定されることが多いため、永続的 cookie に個人情報が保管されていると、攻撃者が情報を盗み出すことのできる時間が長くなります。多くの場合、永続的 cookie はサイトとやり取りする際のユーザープロファイルとして使用されます。この追跡データに対して実行される操作によっては、ユーザーの個人情報を盗み出すのに永続的 cookie が悪用される可能性があります。
例 1: 次のコードは、10 年後に期限切れになるように cookie を設定しています。

...
let properties = [
    NSHTTPCookieDomain: "www.example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar",
    NSHTTPCookieSecure: true,
    NSHTTPCookieExpires : NSDate(timeIntervalSinceNow: (60*60*24*365*10))
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

最近の Web ブラウザーでは、cookie ごとに Secure フラグがサポートされています。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合、特に重要になります。

例 1: 次の設定エントリでは、セッション cookie の Secure フラグを無効にします。

server.servlet.session.cookie.secure=false

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックをスニッフィングすることによって cookie を危険にさらすことがあります。特に無線ネットワークの場合、ネットワーク トラフィックのスニッフィングは非常に簡単です。

最近の Web ブラウザでは、cookie ごとに Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合に特に重要になります。
例 1: 次のコードでは、Secure フラグを設定せずに cookie がレスポンスに追加されています。

...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックをスニッフィングすることによって cookie を危険にさらすことがあります。特に無線ネットワークの場合、ネットワーク トラフィックのスニッフィングは非常に簡単です。

最近の Web ブラウザでは、cookie ごとに Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報またはセッション ID が保存されている場合や、cookie によって CSRF トークンが送信される場合に特に重要になります。
例 1: 次の設定エントリはセッション cookie に Secure ビットを明示的に設定しません。

...
MIDDLEWARE = (
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'csp.middleware.CSPMiddleware',
    'django.middleware.security.SecurityMiddleware',
    ...
)
...

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックをスニッフィングすることによって cookie を危険にさらすことがあります。特に無線ネットワークの場合、ネットワーク トラフィックのスニッフィングは非常に簡単です。

次の場合に、Cross-Site Scripting (XSS) の脆弱性が発生します。

1.信頼できないソース経由でデータが Web アプリケーションに入り込んだ場合。コンポーネント間通信 XSS の場合、信頼できないソースは、同じシステムに存在するその他のコンポーネントから受信するデータです。リフレクト XSS の場合、信頼できないソースは Web リクエストであることが多く、持続型 XSS (別名: ストアド XSS) の場合はデータベースなどのバックエンド データ ストアであるのが一般的です。

2.未検証で Web ユーザーへ送信される動的コンテンツにデータが含まれている場合。

Web ブラウザーへ送信される悪意あるコンテンツは多くの場合 JavaScript セグメントの形式になっていますが、HTML や Flash など、ブラウザーで実行される何らかのタイプのコードが含まれることもあります。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。


例 1: 次の Go コード セグメントはユーザー名 user を HTTP リクエストから読み取り、ユーザーに表示します。

func someHandler(w http.ResponseWriter, r *http.Request){
  r.parseForm()
  user := r.FormValue("user")
  ...
  fmt.Fprintln(w, "Username is: ", user)
}

この例のコードは、user に標準の英数字テキストだけが含まれている場合に正しく動作します。user の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。

最初は、たいした脆弱性ではないと思うかもしれません。自分のコンピューター上で悪意あるコードが実行される原因となる URL を自ら入力する人などいないと考えがちです。実際に危険なのは、攻撃者が悪意ある URL を作成し、電子メールやソーシャルエンジニアリングのトリックを利用してその URL へのリンクをクリックさせるよう誘い込むことです。リンクをクリックすると、脆弱性を持つ Web アプリケーションを通して悪意あるコンテンツが被害者のコンピュータに影響を与えますが、本人はそのことに気づきません。脆弱性のある Web アプリケーションを悪用するこの仕組みは、リフレクト XSS と呼ばれています。

例 2: 次の Go コード セグメントは特定の ID の従業員をデータベースでクエリし、対応する従業員の名前を出力します。

func someHandler(w http.ResponseWriter, r *http.Request){
  ...
  row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
  err := row.Scan(&name)
  ...
  fmt.Fprintln(w, "Username is: ", name)
}

Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザーで攻撃者が悪意あるコマンドを実行することがあります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターに「ゲストブック」を提供している Web サイトで、次のような形式で開始されます。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。

これらの例からわかるように、XSS の脆弱性は、HTTP レスポンスに未検証のデータを含めるコードによって発生します。被害を及ぼす可能性のある XSS 攻撃手段は 3 つあります。

- Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険なコンテンツを入力させられてしまい、それがユーザーに送り返されて Web ブラウザーにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。

- Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意あるコンテンツを実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりすることがあります。

- アプリケーション外のソースで危険なデータがデータベースなどのデータ ストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。

次の場合に、Cross-Site Scripting (XSS) の脆弱性が発生します。

1.信頼できないソース経由でデータが Web またはモバイルアプリケーションに入り込んだ場合。コンポーネント間通信 XSS の場合、信頼できないソースは、同じシステムに存在するその他のコンポーネントから受信するデータです。モバイルの場合、これらは、同じデバイス上で実行されているアプリケーションです。リフレクト XSS の場合、信頼できないソースは Web リクエストであるのが一般的です。一方、持続型 XSS (別名: ストアド XSS) の場合はデータベースなどのバックエンドデータストアであるのが一般的です。


2.未検証で Web ユーザーへ送信される動的コンテンツにデータが含まれている場合。

Web ブラウザーへ送信される悪意あるコンテンツは多くの場合 JavaScript セグメントの形式になっていますが、HTML や Flash など、ブラウザーで実行される何らかのタイプのコードが含まれることもあります。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。

一部には、モバイル環境では Cross-Site Scripting のような古典的な脆弱性は意味がなく、自分に降りかかる攻撃をするはずがない、という見方があります。しかし忘れてはならないモバイルプラットフォームの基本は、さまざまなソースからアプリケーションをダウンロードして同じデバイス上で一緒に実行することです。このため、たとえばバンキングアプリケーションのすぐ隣でマルウェアの一部を実行する可能性が高くなり、モバイルアプリケーションの攻撃面を拡張し、プロセス間通信なども含める必要があります。

例 1: 次のコードでは、Android の WebView で JavaScript を有効にして (デフォルトでは JavaScript は無効)、Android インテントから受け取った値に基づいてページをロードできます。

...
        WebView webview = (WebView) findViewById(R.id.webview);
        webview.getSettings().setJavaScriptEnabled(true);
        String url = this.getIntent().getExtras().getString("url");
        webview.loadUrl(url);
...

url の値が javascript: から始まる場合、それに続く JavaScript コードが WebView 内の Web ページのコンテキストから実行されます。

例 2: 次の JSP コード セグメントは従業員 ID eid を HTTP リクエストから読み取ってユーザーに表示します。

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

この例のコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。

最初は、たいした脆弱性ではないと思うかもしれません。自分のコンピューター上で悪意あるコードが実行される原因となる URL を自ら入力する人などいないと考えがちです。実際に危険なのは、攻撃者が悪意ある URL を作成し、電子メールやソーシャルエンジニアリングのトリックを利用してその URL へのリンクをクリックさせるよう誘い込むことです。リンクをクリックすると、脆弱性を持つ Web アプリケーションを通して悪意あるコンテンツが被害者のコンピュータに影響を与えますが、本人はそのことに気づきません。脆弱性のある Web アプリケーションを悪用するこの仕組みは、リフレクト XSS と呼ばれています。

例 3: 次の JSP コードセグメントは特定の ID の従業員をデータベースでクエリし、対応する従業員の名前を出力します。

<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
   rs.next();
   String name = rs.getString("name");
}
%>

Employee Name: <%= name %>

Example 2 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。

これらの例からわかるように、XSS の脆弱性は、HTTP レスポンスに未検証のデータを入れるコードにより引き起こされます。XSS 攻撃が被害をもたらす可能性のある手段は 3 つあります。

Example 1 に示したように、アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。

- Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。

- Example 3 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。

最新の Web フレームワークの多くが、ユーザー入力を検証するためのメカニズム (Struts および Struts 2 を含む) を提供しています。検証されていない入力ソースの問題を正確に反映させるために、Fortify セキュア コーディング ルールパックは、フレームワーク検証メカニズムが使用されている場合には、その証拠を示し、悪用の可能性を低く見積もり、Fortify Static Code Analyzer により報告される問題の優先度を動的に変更します。この機能は、状況依存ランキングと呼ばれます。Fortify ユーザーがさらに監査プロセスを効果的に進めることができるように、Fortify Software Security Research グループでは、入力ソースに適用される検証メカニズムを基準としたフォルダに問題をグループ化する Data Validation (データ検証) プロジェクト テンプレートのフォルダを用意しています。

次の場合に、Cross-Site Scripting (XSS) の脆弱性が発生します。

1.信頼できないソース経由でデータが Web アプリケーションに入り込んだ場合。コンポーネント間通信 XSS の場合、信頼できないソースは、同じシステムに存在するその他のコンポーネントから受信するデータです。モバイル環境の場合、これらは、同じデバイス上で実行されているアプリケーションです。リフレクト XSS の場合、信頼できないソースは Web リクエストであることが多く、持続型 XSS (別名: ストアド XSS) の場合はデータベースなどのバックエンド データ ストアであるのが一般的です。


2.未検証で Web ユーザーへ送信される動的コンテンツにデータが含まれている場合。

Web ブラウザーへ送信される悪意あるコンテンツは多くの場合 JavaScript セグメントの形式になっていますが、HTML や Flash など、ブラウザーで実行される何らかのタイプのコードが含まれることもあります。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。

一部には、モバイル環境では Cross-Site Scripting のような古典的な脆弱性は意味がなく、自分に降りかかる攻撃をするはずがない、という見方があります。しかし忘れてはならないモバイルプラットフォームの基本は、さまざまなソースからアプリケーションをダウンロードして同じデバイス上で一緒に実行することです。このため、たとえばバンキングアプリケーションのすぐ隣でマルウェアの一部を実行する可能性が高くなり、モバイルアプリケーションの攻撃面を拡張し、プロセス間通信なども含める必要があります。

例 1: 次のコードでは、Android の WebView で JavaScript を有効にして (デフォルトでは JavaScript は無効)、Android インテントから受け取った値に基づいてページをロードできます。

...
        val webview = findViewById<View>(R.id.webview) as WebView
        webview.settings.javaScriptEnabled = true
        val url = this.intent.extras!!.getString("url")
        webview.loadUrl(url)
...

url の値が javascript: から始まる場合、それに続く JavaScript コードが WebView 内の Web ページのコンテキストから実行されます。

例 2: 次のコードは従業員 ID eid を HTTP サーブレット リクエストから読み取ってから、サーブレットのレスポンスでユーザーに値を表示します。

val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...

この例のコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。

最初は、たいした脆弱性ではないと思うかもしれません。自分のコンピューター上で悪意あるコードが実行される原因となる URL を自ら入力する人などいないと考えがちです。実際に危険なのは、攻撃者が悪意ある URL を作成し、電子メールやソーシャルエンジニアリングのトリックを利用してその URL へのリンクをクリックさせるよう誘い込むことです。リンクをクリックすると、脆弱性を持つ Web アプリケーションを通して悪意あるコンテンツが被害者のコンピュータに影響を与えますが、本人はそのことに気づきません。脆弱性のある Web アプリケーションを悪用するこの仕組みは、リフレクト XSS と呼ばれています。

例 3: 次のコード セグメントは特定の ID の従業員をデータベースでクエリし、対応する従業員の名前をサーブレットのレスポンスに出力します。

val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...

Example 2 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。

これらの例からわかるように、XSS の脆弱性は、HTTP レスポンスに未検証のデータを含めるコードによって発生します。被害を及ぼす可能性のある XSS 攻撃手段は 3 つあります。

Example 1 に示すように、アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。

- Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。

- Example 3 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。


最新の Web フレームワークの多くが、ユーザー入力を検証するためのメカニズム (Struts や Spring MVC を含む) を提供しています。検証されていない入力ソースの問題を正確に反映させるために、Fortify セキュア コーディング ルールパックは、フレームワーク検証メカニズムが使用されている場合には、その証拠を示し、悪用の可能性を低く見積もり、Fortify Static Code Analyzer により報告される問題の優先度を動的に変更します。この機能は、状況依存ランキングと呼ばれます。Fortify ユーザーがさらに監査プロセスを効果的に進めることができるように、Fortify Software Security Research グループでは、入力ソースに適用される検証メカニズムを基準としたフォルダに問題をグループ化する Data Validation (データ検証) プロジェクト テンプレートのフォルダを用意しています。

次の場合に、Cross-Site Scripting (XSS) の脆弱性が発生します。

1.信頼できないソース経由でデータが Web またはモバイルアプリケーションに入り込んだ場合。コンポーネント間通信 XSS の場合、信頼できないソースは、同じシステムに存在するその他のコンポーネントから受信するデータです。モバイルの場合、これらは、同じデバイス上で実行されているアプリケーションです。リフレクト XSS の場合、信頼できないソースは Web リクエストであるのが一般的です。一方、持続型 XSS (別名: ストアド XSS) の場合はデータベースなどのバックエンドデータストアであるのが一般的です。


2.未検証で Web ユーザーへ送信される動的コンテンツにデータが含まれている場合。

Web ブラウザーへ送信される悪意あるコンテンツは多くの場合 JavaScript セグメントの形式になっていますが、HTML や Flash など、ブラウザーで実行される何らかのタイプのコードが含まれることもあります。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。

一部には、モバイル環境では Cross-Site Scripting のような古典的な脆弱性は意味がなく、自分に降りかかる攻撃をするはずがない、という見方があります。しかし忘れてはならないモバイルプラットフォームの基本は、さまざまなソースからアプリケーションをダウンロードして同じデバイス上で一緒に実行することです。このため、たとえばバンキングアプリケーションのすぐ隣でマルウェアの一部を実行する可能性が高くなり、モバイルアプリケーションの攻撃面を拡張し、プロセス間通信なども含める必要があります。

例 1: 次のコードによって、アプリケーションが WKWebView 内の HTML ページを、アプリケーションのカスタム URL スキームを使用する URL リクエストから、データとともにロードできるようになります。

AppDelegate.m:

...
@property (strong, nonatomic) NSString *webContentFromURL;
...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
  ...
  [self setWebContentFromURL:[url host]];
  ...
...

ViewController.m

...
@property (strong, nonatomic) WKWebView *webView;
...
AppDelegate *appDelegate = (AppDelegate *)[[UIApplication sharedApplication] delegate];
...
[_webView loadHTMLString:appDelegate.webContentFromURL] baseURL:nil];
...

loadHTMLString: に渡される文字列はユーザー制御可能で、JavaScript は既定で WKWebView 内で有効になるので、ユーザーは任意のコンテンツ (実行可能なスクリプトを含む) を、アプリのカスタム URL スキームを使用するリクエストによって WKWebView に書き込むことができます。

例 2: 次のコードは UITextField のコンテンツを読み込み、それを WKWebView でユーザーに表示します。

...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView loadHTMLString:_inputTextField.text baseURL:nil];
...

この例のコードは、inputTextField 内のテキストに標準の英数字テキストのみが含まれる場合は問題なく動作します。inputTextField 内のテキストにメタ文字またはソースコードが含まれる場合、入力は HTTP レスポンスを表示するときに Web ブラウザによってコードとして実行されます。

最初は、たいした脆弱性ではないと思うかもしれません。それでは、自分のデバイスで悪意あるコードを実行する可能性がある入力をなぜインプットしてしまうのでしょうか。本当の危険は、攻撃者が電子メールやソーシャル エンジニアリングのトリックを利用して、そのような行動を起こさせるように被害者を誘い込むことです。この企みが成功すると、脆弱性を持つ Web アプリケーションを通して悪意あるコンテンツが被害者のデバイスに影響を与えますが、本人はそのことに気づきません。脆弱性のある Web アプリケーションを悪用するこの仕組みは、リフレクト XSS と呼ばれています。

例 3: 次のコードセグメントは指定された ID の従業員をデータベースでクエリし、WKWebView の表示コンテンツに値を出力します。

...
@property (strong, nonatomic) WKWebView *webView;
...
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:@"Employee" inManagedObjectContext:context];
[fetchRequest setEntity:entity];

NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error];
for (NSManagedObject *info in fetchedObjects) {
  NSString msg = @"Hello, " + [info valueForKey:@"name"];
  [_webView loadHTMLString:msg baseURL:nil]
  ...
}
...

Example 2 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。

これらの例からわかるように、XSS の脆弱性は、HTTP レスポンスに未検証のデータを入れるコードにより引き起こされます。XSS 攻撃が被害をもたらす可能性のある手段は 3 つあります。

- Example 1 では、ターゲット アプリケーション外部のソースが、ターゲット アプリケーションのカスタム URL スキームを使用して URL リクエストを作成し、続いて URL リクエストによる未検証のデータが信頼されるデータとしてアプリケーションに再び読み込まれ、動的コンテンツに含まれます。

- Example 2 では、ユーザー制御可能な UI コンポーネントからデータを直接読み取り、HTTP レスポンスに反映します。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。

- Example 3 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。

次の場合に、Cross-Site Scripting (XSS) の脆弱性が発生します。

1.信頼できないソース経由でデータが Web またはモバイルアプリケーションに入り込んだ場合。コンポーネント間通信 XSS の場合、信頼できないソースは、同じシステムに存在するその他のコンポーネントから受信するデータです。モバイルの場合、これらは、同じデバイス上で実行されているアプリケーションです。リフレクト XSS の場合、信頼できないソースは Web リクエストであるのが一般的です。一方、持続型 XSS (別名: ストアド XSS) の場合はデータベースなどのバックエンドデータストアであるのが一般的です。


2.未検証で Web ユーザーへ送信される動的コンテンツにデータが含まれている場合。

Web ブラウザーへ送信される悪意あるコンテンツは多くの場合 JavaScript セグメントの形式になっていますが、HTML や Flash など、ブラウザーで実行される何らかのタイプのコードが含まれることもあります。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。

一部には、モバイル環境では Cross-Site Scripting のような古典的な脆弱性は意味がなく、自分に降りかかる攻撃をするはずがない、という見方があります。しかし忘れてはならないモバイルプラットフォームの基本は、さまざまなソースからアプリケーションをダウンロードして同じデバイス上で一緒に実行することです。このため、たとえばバンキングアプリケーションのすぐ隣でマルウェアの一部を実行する可能性が高くなり、モバイルアプリケーションの攻撃面を拡張し、プロセス間通信なども含める必要があります。

例 1: 次のコードによって、アプリケーションが WKWebView 内の HTML ページを、アプリケーションのカスタム URL スキームを使用する URL リクエストから、データとともにロードできるようになります。

...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
    ...
    let name = getQueryStringParameter(url.absoluteString, "name")
    let html = "Hi \(name)"
    let webView = WKWebView()
    webView.loadHTMLString(html, baseURL:nil)
    ...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
    if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
        return queryItems.filter({ (item) in item.name == param }).first?.value!
    }
    return nil
}
...

loadHTMLString: に渡される文字列はユーザー制御可能で、JavaScript は既定で WKWebView 内で有効になるので、ユーザーは任意のコンテンツ (実行可能なスクリプトを含む) を、アプリのカスタム URL スキームを使用するリクエストによって WKWebView に書き込むことができます。

例 2: 次のコードは UITextField のコンテンツを読み込み、それを WKWebView でユーザーに表示します。

...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...

この例のコードは、inputTextField 内のテキストに標準の英数字テキストのみが含まれる場合は問題なく動作します。inputTextField 内のテキストにメタ文字またはソースコードが含まれる場合、入力は HTTP レスポンスを表示するときに Web ブラウザによってコードとして実行されます。

最初は、たいした脆弱性ではないと思うかもしれません。それでは、自分のデバイスで悪意あるコードを実行する可能性がある入力をなぜインプットしてしまうのでしょうか。本当の危険は、攻撃者が電子メールやソーシャル エンジニアリングのトリックを利用して、そのような行動を起こさせるように被害者を誘い込むことです。この企みが成功すると、脆弱性を持つ Web アプリケーションを通して悪意あるコンテンツが被害者のデバイスに影響を与えますが、本人はそのことに気づきません。脆弱性のある Web アプリケーションを悪用するこの仕組みは、リフレクト XSS と呼ばれています。

例 3: 次のコードセグメントは指定された ID の従業員をデータベースでクエリし、WKWebView の表示コンテンツに値を出力します。

let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Employee", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
do {
    let results = try managedContext.executeFetchRequest(fetchRequest)
    let result : NSManagedObject = results.first!
    let name : String = result.valueForKey("name")
    let msg : String = "Hello, \(name)"
    let webView : UIWebView = UIWebView()
    webView.loadHTMLString(msg, baseURL:nil)
} catch let error as NSError {
    print("Error \(error)")
}

Example 2 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。

これらの例からわかるように、XSS の脆弱性は、HTTP レスポンスに未検証のデータを入れるコードにより引き起こされます。XSS 攻撃が被害をもたらす可能性のある手段は 3 つあります。

- Example 1 では、ターゲット アプリケーション外部のソースが、ターゲット アプリケーションのカスタム URL スキームを使用して URL リクエストを作成し、続いて URL リクエストによる未検証のデータが信頼されるデータとしてアプリケーションに再び読み込まれ、動的コンテンツに含まれます。

- Example 2 では、ユーザー制御可能な UI コンポーネントからデータを直接読み取り、HTTP レスポンスに反映します。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。

- Example 3 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。