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

例 1: 次の例では、isSecure パラメーターを true に設定せずに cookie が作成されています。

...
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, false, 'Strict');
...

HTTPS と HTTP の両方が使用されていても isSecure パラメーターが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はそれ以降の HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックをスニッフィングするのは攻撃者にとって簡単です。また、cookie (特にセッション ID が格納されている cookie) を HTTP 経由で送信すると、アプリケーションが危険にさらされる可能性があります。

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

例: 次の例では、Secure プロパティを設定せずにレスポンスに cookie が追加されています。

...
 HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);
...

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッションIDが格納されているcookie)をHTTP経由で送信すると、アプリケーションが危険にさらされる可能性があります。

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

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
http.SetCookie(response, &cookie)
...

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

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

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin', httpOnly: true, secure: false});

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッションIDが格納されているcookie)をHTTP経由で送信すると、アプリケーションが危険にさらされる可能性があります。

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

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッションIDが格納されているcookie)をHTTP経由で送信すると、アプリケーションが危険にさらされる可能性があります。

最近の 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: 次のコードでは、Secure フラグを設定せずに cookie がレスポンスに追加されています。

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

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

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

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, secure = false))

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッション ID が格納されている cookie) を HTTP 経由で送信すると、アプリケーションが危険にさらされる可能性があります。

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

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

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッション ID が格納されている cookie) を HTTP 経由で送信すると、アプリケーションが危険にさらされる可能性があります。

主要なブラウザーでサポートされている HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。 Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。 HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。
例 1: 次のコードでは、HttpOnly プロパティが設定されずに cookie が作成されています。

    HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);

ブラウザーで cookie プロパティ HttpOnly を設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie へアクセスします。HttpOnly を有効にしないと、攻撃者は容易にユーザーの cookie にアクセスできます。
例 1: 次のコードでは、HttpOnly プロパティが設定されずに cookie が作成されています。

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
...

主要なブラウザーでサポートされている HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。 Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。 HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。
例 1: 次のコードでは、httpOnly プロパティが設定されずに cookie が作成されています。

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin'});

主要なブラウザーでサポートされている HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。 Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。 HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。
例 1: 次のコードでは、HttpOnly プロパティが設定されずに cookie が作成されています。

setcookie("emailCookie", $email, 0, "/", "www.example.com", TRUE);  //Missing 7th parameter to set HttpOnly

ブラウザで HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。
例 1: 次のコードでは、HttpOnly プロパティが設定されずに cookie が作成されています。

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

主要なブラウザーでサポートされている HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。 Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。 HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。
例 1: 次のコードでは、HttpOnly プロパティが設定されずに cookie が作成されています。

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, httpOnly = false))

主要なブラウザーでサポートされている HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。 Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。 HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。
例 1: 次のコードでは、HttpOnly パラメーターを true に設定せずにセッション cookie を作成します。

session_set_cookie_params(0, "/", "www.example.com", true, false);

ブラウザで HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。

例 1: 次の設定構成では、HttpOnly プロパティを設定せず、セッション cookie を明示的に設定します。

...
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',
    ...
)
...
SESSION_COOKIE_HTTPONLY = False
...

ブラウザーは、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 タグを持つリクエストを含む) とともに送信されます。ユーザーがリンクをたどると、リクエストには cookie が含まれます。
- None: Cookie は、Cookie に設定されたパスやドメインの範囲内にあるサイトに対して行われたすべてのリクエストで送信されます。POST メソッドを使用したフォームの送信により生成されたリクエストも、リクエストとともに Cookie を送信することができます。

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

    ...
    CookieOptions opt = new CookieOptions()
    {
        SameSite = SameSiteMode.None;
    };
    context.Response.Cookies.Append("name", "Foo", opt);
    ...

ブラウザーは、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 属性を無効にしています。

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 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

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

開発者は ".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_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 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

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

例：

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

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

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

例：

session_set_cookie_params(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 が漏洩する可能性があります。

s開発者はセッション cookie を root コンテキストパス ("/") に設定する傾向にあります。この方法ではドメイン名を同じくするすべての Web アプリケーションにその cookie が漏えいしてしまいます。セッション cookie が漏えいすると、攻撃者はそのドメイン上の任意のアプリケーションに存在する脆弱性を利用してセッション cookie を盗むことができるため、アカウントが悪用される可能性があります。

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

例：

session_set_cookie_params(0, "/", "communitypages.example.com", true, true);

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

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 に設定しています。

    ...
    CookieOptions opt = new CookieOptions()
    {
        SameSite = SameSiteMode.Lax;
    };
    context.Response.Cookies.Append("name", "Foo", opt);
    ...

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 に設定しています。

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 が悪用される可能性があります。
例: 次のコードでは、cookie の有効期限が 10 年後に切れるように設定しています。

    HttpCookie cookie = new HttpCookie("emailCookie", email);
    cookie.Expires = DateTime.Now.AddYears(10);;