Cookie Security: Overly Broad Domain

cookie のドメインがあまりに広範にわたっていると、別のアプリケーションを介し攻撃を受ける可能性があります。

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

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

例：

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.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 を上書きします。

cookie のドメインがあまりに広範にわたっていると、別のアプリケーションを介し攻撃を受ける可能性があります。

開発者は ".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 を上書きします。

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 を上書きします。

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 を上書きします。

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 を上書きします。

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 を上書きします。

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 を上書きします。

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 を上書きします。