isSecure パラメーターを true に設定しないで作成されます。Secure フラグをサポートします。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークがスニッフィングされる可能性がありますが、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合、特に重要になります。isSecure パラメーターを true に設定せずに cookie が作成されています。
...
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, false, 'Strict');
...
isSecure パラメーターが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はそれ以降の HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックをスニッフィングするのは攻撃者にとって簡単です。また、cookie (特にセッション ID が格納されている cookie) を HTTP 経由で送信すると、アプリケーションが危険にさらされる可能性があります。Secure フラグが true に設定されていない cookie が作成されます。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合に特に重要になります。Secure プロパティを設定せずにレスポンスに cookie が追加されています。
...
HttpCookie cookie = new HttpCookie("emailCookie", email);
Response.AppendCookie(cookie);
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッションIDが格納されているcookie)をHTTP経由で送信すると、アプリケーションが危険にさらされる可能性があります。Secure フラグを true に設定せずに cookie を作成します。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報またはセッション ID が保存されている場合や、cookie によって CSRF トークンが送信される場合、特に重要です。Secure フラグを設定せずに cookie がレスポンスに追加されています。
cookie := http.Cookie{
Name: "emailCookie",
Value: email,
}
http.SetCookie(response, &cookie)
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックをスニッフィングすることによって cookie を危険にさらすことがあります。特に無線ネットワークの場合、ネットワーク トラフィックのスニッフィングは非常に簡単です。Secure フラグが true に設定されていない cookie が作成されます。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合、特に重要になります。use-secure-cookie 属性によって remember-me cookie が有効化され、暗号化されていない転送によって送信されます。
<http auto-config="true">
...
<remember-me use-secure-cookie="false"/>
</http>
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッション ID が格納されている cookie) を HTTP 経由で送信すると、アプリケーションが危険にさらされる可能性があります。Secure フラグが true に設定されていない cookie が作成されます。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合に特に重要になります。Secure プロパティを true に設定せずにレスポンスに cookie が追加されています。
res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin', httpOnly: true, secure: false});
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッションIDが格納されているcookie)をHTTP経由で送信すると、アプリケーションが危険にさらされる可能性があります。NSHTTPCookieSecure フラグが TRUE に設定されていない cookie が作成されます。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合に特に重要になります。Secure フラグを設定せずにレスポンスに cookie が追加されています。
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッションIDが格納されているcookie)をHTTP経由で送信すると、アプリケーションが危険にさらされる可能性があります。Secure フラグを true に設定せずに cookie を作成します。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合に特に重要になります。Secure フラグを設定せずに cookie がレスポンスに追加されています。
...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックをスニッフィングすることによって cookie を危険にさらすことがあります。特に無線ネットワークの場合、ネットワーク トラフィックのスニッフィングは非常に簡単です。Secure フラグを True に設定せずに cookie を作成します。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報またはセッション ID が保存されている場合や、cookie によって CSRF トークンが送信される場合に特に重要になります。Secure フラグを設定せずに cookie がレスポンスに追加されています。
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("emailCookie", email)
return res
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックをスニッフィングすることによって cookie を危険にさらすことがあります。特に無線ネットワークの場合、ネットワーク トラフィックのスニッフィングは非常に簡単です。Secure フラグが true に設定されていない cookie が作成されます。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合、特に重要になります。Secure フラグを設定せずにレスポンスに cookie が追加されています。
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, secure = false))
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッション ID が格納されている cookie) を HTTP 経由で送信すると、アプリケーションが危険にさらされる可能性があります。NSHTTPCookieSecure フラグが TRUE に設定されていない cookie が作成されます。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合、特に重要になります。Secure フラグを設定せずにレスポンスに cookie が追加されています。
...
let properties = [
NSHTTPCookieDomain: "www.example.com",
NSHTTPCookiePath: "/service",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar"
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッション ID が格納されている cookie) を HTTP 経由で送信すると、アプリケーションが危険にさらされる可能性があります。CSRF_COOKIE_SECURE プロパティを明示的に True に設定しないか、または False に設定します。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報またはセッション ID が保存されている場合や、cookie によって CSRF トークンが送信される場合に特に重要になります。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',
...
)
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックをスニッフィングすることによって cookie を危険にさらすことがあります。特に無線ネットワークの場合、ネットワーク トラフィックのスニッフィングは非常に簡単です。HttpOnly フラグを true に設定していません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie へアクセスします。HttpOnly フラグを有効にしないと、攻撃者は容易にユーザーの cookie にアクセスできます。HttpOnly プロパティが設定されずに cookie が作成されています。
HttpCookie cookie = new HttpCookie("emailCookie", email);
Response.AppendCookie(cookie);
HttpOnly フラグを true に設定していません。HttpOnly を設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie へアクセスします。HttpOnly を有効にしないと、攻撃者は容易にユーザーの cookie にアクセスできます。HttpOnly プロパティが設定されずに cookie が作成されています。
cookie := http.Cookie{
Name: "emailCookie",
Value: email,
}
...
HttpOnly フラグを true に設定していません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie へアクセスします。HttpOnly フラグを有効にしないと、攻撃者は容易にユーザーの cookie にアクセスできます。HttpOnly プロパティが設定されずに cookie が作成されています。
javax.servlet.http.Cookie cookie = new javax.servlet.http.Cookie("emailCookie", email);
// Missing a call to: cookie.setHttpOnly(true);
HttpOnly フラグを true に設定していません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie へアクセスします。HttpOnly フラグを有効にしないと、攻撃者は容易にユーザーの cookie にアクセスできます。httpOnly プロパティが設定されずに cookie が作成されています。
res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin'});
HttpOnly フラグを true に設定していません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie へアクセスします。HttpOnly フラグを有効にしないと、攻撃者は容易にユーザーの cookie にアクセスできます。HttpOnly プロパティが設定されずに cookie が作成されています。
setcookie("emailCookie", $email, 0, "/", "www.example.com", TRUE); //Missing 7th parameter to set HttpOnly
HttpOnly フラグを True に設定していません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。HttpOnly プロパティが設定されずに cookie が作成されています。
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("emailCookie", email)
return res
...
HttpOnly フラグを true に設定していません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie へアクセスします。HttpOnly フラグを有効にしないと、攻撃者は容易にユーザーの cookie にアクセスできます。HttpOnly プロパティが設定されずに cookie が作成されています。
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, httpOnly = false))
HttpCookie.HttpOnly プロパティを true に設定しません。httpOnlyCookies 属性のデフォルト値は false です。これは、クライアント側のスクリプトを介して cookie にアクセスできることを意味します。これは Cross-Site Scripting の脅威となり、cookie が盗まれる可能性があります。盗まれた cookie には、ASP.NET セッション ID やフォーム認証チケットなど、サイトに対してユーザーを識別する機密情報が含まれている可能性があり、攻撃者がユーザーになりすましたり、機密情報を取得したりするために、再生される可能性があります。
<configuration>
<system.web>
<httpCookies httpOnlyCookies="false">
HttpOnly フラグを true に設定できません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。django.middleware.csrf.CsrfViewMiddleware Django ミドルウェアを使用するとき、CSRF cookie は HttpOnly プロパティを設定せずに送信されます。
...
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',
...
)
...
HttpOnly フラグを true に設定していません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie へアクセスします。HttpOnly フラグを有効にしないと、攻撃者は容易にユーザーの cookie にアクセスできます。HttpOnly フラグを true に設定せずにセッション cookie を作成します。
server.servlet.session.cookie.http-only=false
HttpOnly フラグを true に設定していません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie へアクセスします。HttpOnly フラグを有効にしないと、攻撃者は容易にユーザーの cookie にアクセスできます。HttpOnly フラグを true に設定せずにセッション cookie を作成します。
session_set_cookie_params(0, "/", "www.example.com", true, false);
HttpOnly フラグを true に設定できません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。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
...
SameSite 属性を設定できません。SameSite パラメーターは、リクエストがファーストパーティまたは同じサイトのコンテキストから生成された場合にのみリクエストに追加するよう cookie の範囲を制限します。これは、Cross-Site Request Forgery (CSRF) 攻撃から cookie を保護するのに役立ちます。SameSite パラメーターの値は、次の 3 つのうちのいずれかになります。Strict に設定した場合、cookie はトップレベル ナビゲーションのリクエストとともにのみ送信されます。Lax に設定した場合、cookie は、同じホストからのトップレベル ナビゲーションだけでなく、サードパーティ サイトからホストへの GET リクエストとともに送信されます。たとえば、ホスト サイトにリンクする、iframe タグか href タグを持つサードパーティ サイトがあるとします。ユーザーがリンクをたどると、リクエストには cookie が含まれます。SameSite 属性を None に設定しています。
...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'None');
...
SameSite 属性の設定に失敗します。SameSite 属性は、リクエストがファーストパーティまたは同じサイトのコンテキストから生成された場合にのみリクエストに追加するよう cookie の範囲を制限します。これは、Cross-Site Request Forgery (CSRF) 攻撃から cookie を保護するのに役立ちます。SameSite 属性の値は、次の 3 つのうちのいずれかになります。Strict に設定した場合、cookie はトップレベル ナビゲーションのリクエストとともにのみ送信されます。Lax に設定した場合、Cookie は、同じホストからのトップレベル ナビゲーションだけでなく、サードパーティ サイトからの GET リクエスト (ホスト サイトにリンクする iframe タグまたは href タグを持つリクエストを含む) とともに送信されます。ユーザーがリンクをたどると、リクエストには cookie が含まれます。SameSite 属性を無効にしています。
...
CookieOptions opt = new CookieOptions()
{
SameSite = SameSiteMode.None;
};
context.Response.Cookies.Append("name", "Foo", opt);
...
SameSite 属性の設定に失敗します。SameSite 属性は、リクエストがファーストパーティまたは同じサイトのコンテキストから生成された場合にのみリクエストに追加するよう Cookie の範囲を制限します。これは、Cross-Site Request Forgery (CSRF) 攻撃から cookie を保護するのに役立ちます。SameSite 属性の値は、次の 3 つのうちのいずれかになります。Strict に設定した場合、cookie はトップレベル ナビゲーションのリクエストとともにのみ送信されます。Lax に設定した場合、cookie は、同じホストからのトップレベル ナビゲーションだけでなく、サードパーティ サイトからホストへの GET リクエストとともに送信されます。たとえば、ホスト サイトにリンクする、iframe タグか href タグを持つサードパーティ サイトがあるとします。ユーザーがリンクをたどると、リクエストには cookie が含まれます。SameSite 属性を無効にしています。
c := &http.Cookie{
Name: "cookie",
Value: "samesite-none",
SameSite: http.SameSiteNoneMode,
}
SameSite 属性の設定に失敗します。SameSite 属性は、リクエストがファーストパーティまたは同じサイトのコンテキストから生成された場合にのみリクエストに追加するよう Cookie の範囲を制限します。これは、Cross-Site Request Forgery (CSRF) 攻撃から cookie を保護するのに役立ちます。SameSite 属性の値は、次の 3 つのうちのいずれかになります。Strict に設定した場合、cookie はトップレベル ナビゲーションのリクエストとともにのみ送信されます。Lax に設定した場合、Cookie は、同じホストからのトップレベル ナビゲーションだけでなく、サードパーティ サイトからの GET リクエスト (ホスト サイトにリンクする iframe タグまたは href タグを持つリクエストを含む) とともに送信されます。たとえば、ホスト サイトにリンクする、iframe タグか href タグを持つサードパーティ サイトがあるとします。ユーザーがリンクをたどると、リクエストには cookie が含まれます。SameSite 属性を無効にしています。
ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue")
...
.sameSite("None")
...
SameSite 属性の設定に失敗します。SameSite 属性は、リクエストがファーストパーティまたは同じサイトのコンテキストから生成された場合にのみリクエストに追加するよう Cookie の範囲を制限します。これは、Cross-Site Request Forgery (CSRF) 攻撃から cookie を保護するのに役立ちます。SameSite 属性の値は、次の 3 つのうちのいずれかになります。Strict に設定した場合、cookie はトップレベル ナビゲーションのリクエストとともにのみ送信されます。Lax に設定した場合、Cookie は、同じホストからのトップレベル ナビゲーションだけでなく、サードパーティ サイトからの GET リクエスト (ホスト サイトにリンクする iframe タグまたは href タグを持つリクエストを含む) とともに送信されます。たとえば、ホスト サイトにリンクする、iframe タグか href タグを持つサードパーティ サイトがあるとします。ユーザーがリンクをたどると、リクエストには cookie が含まれます。SameSite 属性を無効にしています。
app.get('/', function (req, res) {
...
res.cookie('name', 'Foo', { sameSite: false });
...
}
SameSite 属性の設定に失敗します。SameSite 属性は、リクエストがファーストパーティまたは同じサイトのコンテキストから生成された場合にのみリクエストに追加するよう cookie の範囲を制限します。これは、クロスサイト リクエスト フォージェリ (CSRF) 攻撃から cookie を保護するのに役立ちます。SameSite 属性の値は、次の 3 つのうちのいずれかになります。Strict に設定した場合、cookie はトップレベル ナビゲーションのリクエストとともにのみ送信されます。Lax に設定した場合、cookie は、同じホストからのトップレベル ナビゲーションだけでなく、サードパーティ サイトからホストへの GET リクエストとともに送信されます。たとえば、ホスト サイトにリンクする、iframe タグか href タグを持つサードパーティ サイトがあるとします。ユーザーがリンクをたどると、リクエストには cookie が含まれます。SameSite 属性を無効にしています。
ini_set("session.cookie_samesite", "None");
SameSite 属性の設定に失敗します。samesite パラメーターは、リクエストがファーストパーティまたは同じサイトのコンテキストから生成された場合にのみリクエストに追加するよう Cookie の範囲を制限します。これは、Cross-Site Request Forgery (CSRF) 攻撃から cookie を保護するのに役立ちます。samesite パラメーターの値は、次の 3 つのうちのいずれかになります。Strict に設定した場合、cookie はトップレベル ナビゲーションのリクエストとともにのみ送信されます。Lax に設定した場合、cookie は、同じホストからのトップレベル ナビゲーションだけでなく、サードパーティ サイトからホストへの GET リクエストとともに送信されます。たとえば、ホスト サイトにリンクする、iframe タグか href タグを持つサードパーティ サイトがあるとします。ユーザーがリンクをたどると、リクエストには 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 が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 が漏洩する可能性があります。insecure.example.com を使用して、パスがあまりに広範にわたっている cookie を独自に作成し、Secure.example.com からの cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 にアクセスしたフォーラム ユーザーのアカウントであれば、危険にさらされることがあります。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/」に設定する傾向にありますが、この方法では同じドメイン上のすべての 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 にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 にアクセスしたフォーラム ユーザーのアカウントであれば、危険にさらされることがあります。/EvilSite を使用して、パスがあまりに広範にわたっている cookie を独自に作成し、/MyForum からの cookie を上書きします。/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、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 にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。.example.com」などのセッション cookie を設定する傾向にあります。しかし、この方法では同じベースドメイン名およびサブドメイン上にあるすべての Web アプリケーションがそのセッション cookie にアクセスできてしまいます。セッション cookie が漏洩すると、アカウントが悪用される可能性があります。http://secure.example.com/ に安全なアプリケーションを配置していると考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが「.example.com」であるセッションの cookie が設定されます。
server.servlet.session.cookie.domain=.example.com
http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting 脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。.example.com」などのセッション cookie を設定する傾向にあります。この方法では同じベース ドメインおよびサブドメイン上にあるすべての Web アプリケーションがそのセッション cookie にアクセスできてしまいます。アプリケーション間でセッション cookie を共有すると、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 が漏洩する可能性があります。/」) に設定する傾向にあります。この方法では同じドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。セッション cookie が漏えいすると、攻撃者はそのドメイン上の任意のアプリケーションに存在する脆弱性を利用してセッション cookie を盗むことができるため、アカウントが悪用される可能性があります。http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、「/」というパスを持つセッションの cookie が設定されます。例：
server.servlet.session.cookie.path=/
http://communitypages.example.com/EvilSite に別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。フォーラム ユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定されたセッション cookie を /EvilSite で実行されているアプリケーションに送信します。攻撃者は、ユーザーによって /MyForum に設定されるセッション cookie を使用することにより、/EvilSite にアクセスするフォーラム ユーザーのアカウントを危険にさらすことがあります。/」) に設定する傾向にあります。この方法では同じドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。セッション cookie が漏えいすると、攻撃者はそのドメイン上の任意のアプリケーションに存在する脆弱性を利用してセッション cookie を盗むことができるため、アカウントが悪用される可能性があります。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 パラメーターが Strict に設定されていません。SameSite パラメーターは、リクエストがファーストパーティまたは同じサイトのコンテキストから生成された場合にのみリクエストに追加するよう cookie の範囲を制限します。これは、Cross-Site Request Forgery (CSRF) 攻撃から cookie を保護するのに役立ちます。SameSite パラメーターの値は、次の 3 つのうちのいずれかになります。Strict に設定した場合、cookie はトップレベル ナビゲーションのリクエストとともにのみ送信されます。Lax に設定した場合、cookie は、同じホストからのトップレベル ナビゲーションだけでなく、サードパーティ サイトからホストへの GET リクエストとともに送信されます。たとえば、ホスト サイトにリンクする、iframe タグか href タグを持つサードパーティ サイトがあるとします。ユーザーがリンクをたどると、リクエストには cookie が含まれます。SameSite パラメーターを Lax に設定します。
...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'Lax');
...
SameSite 属性は Strict に設定されていません。SameSite 属性は、Cross-Site Request Forgery (CSRF) などの攻撃から Cookie を保護します。セッション Cookie はサイトに対してユーザーを表しているため、ユーザーは承認されたアクションを実行できるようになります。ただし、ブラウザーはリクエストとともに自動的に Cookie を送信するため、ユーザーと Web サイトは認証について暗黙的にブラウザーを信頼することになります。攻撃者はこの信頼を悪用して、攻撃者が制御するサードパーティ サイトのページにある link や iframe などのタグの href や src 属性内にリンクを埋め込むことで、ユーザーの代わりにサイトにリクエストを行うことができます。疑いを持たないユーザーを攻撃者が制御するサードパーティのサイトにおびき寄せることができれば、攻撃者はユーザーを認証するセッション Cookie を自動的に含めるリクエストを行うことができ、攻撃者がユーザーであるかのように効果的に認証されることになります。SameSite 属性の値を Strict に設定します。これにより、トップレベル ナビゲーションまたは同じサイトからのリクエストにのみ Cookie を追加するよう、ブラウザーが制限されます。iframe, img, and form などのさまざまなタグにおけるリンク経由のサードパーティ サイトからのリクエストにはこれらの Cookie がないため、ユーザーが認証されていない可能性がある場合にサイトでの処理が回避されます。SameSite 属性の値を Lax に設定しています。
...
CookieOptions opt = new CookieOptions()
{
SameSite = SameSiteMode.Lax;
};
context.Response.Cookies.Append("name", "Foo", opt);
...
SameSite 属性は SameSiteStrictMode に設定されていません。SameSite 属性は、クロスサイト リクエスト フォージェリ (CSRF) などの攻撃から Cookie を保護します。セッション Cookie はサイトに対してユーザーを表しているため、ユーザーは承認されたアクションを実行できるようになります。ただし、ブラウザーはリクエストとともに自動的に Cookie を送信するため、ユーザーと Web サイトは認証について暗黙的にブラウザーを信頼することになります。攻撃者はこの信頼を悪用して、攻撃者が制御するサードパーティ サイトのページにある link や iframe などのタグの href や src 属性内にリンクを埋め込むことで、ユーザーの代わりにサイトにリクエストを行うことができます。疑いを持たないユーザーを攻撃者が制御するサードパーティのサイトにおびき寄せることができれば、攻撃者はユーザーを認証するセッション Cookie を自動的に含めるリクエストを行うことができ、攻撃者がユーザーであるかのように効果的に認証されることになります。SameSite 属性のセッション Cookie を SameSiteStrictMode に設定すると、トップレベル ナビゲーションまたは同じサイトからのリクエストにのみ Cookie を追加するよう、ブラウザーを制限できます。iframe, img, and form などのさまざまなタグにおけるリンク経由のサードパーティ サイトからのリクエストにはこれらの Cookie がないため、ユーザーが認証されていない可能性がある場合にサイトでの処理が回避されます。SameSite 属性の SameSiteLaxMode を有効にしています。
c := &http.Cookie{
Name: "cookie",
Value: "samesite-lax",
SameSite: http.SameSiteLaxMode,
}
SameSite 属性は Strict に設定されていません。SameSite 属性は、Cross-Site Request Forgery (CSRF) などの攻撃から Cookie を保護します。セッション Cookie はサイトに対してユーザーを表しているため、ユーザーは承認されたアクションを実行できるようになります。ただし、ブラウザーはリクエストとともに自動的に Cookie を送信するため、ユーザーと Web サイトは認証について暗黙的にブラウザーを信頼することになります。攻撃者はこの信頼を悪用して、攻撃者が制御するサードパーティ サイトのページにある link や iframe などのタグの href や src 属性内にリンクを埋め込むことで、ユーザーの代わりにサイトにリクエストを行うことができます。疑いを持たないユーザーを攻撃者が制御するサードパーティのサイトにおびき寄せることができれば、攻撃者はユーザーを認証するセッション Cookie を自動的に含めるリクエストを行うことができ、攻撃者がユーザーであるかのように効果的に認証されることになります。SameSite 属性の値を Strict に設定します。これにより、トップレベル ナビゲーションまたは同じサイトからのリクエストにのみ Cookie を追加するよう、ブラウザーが制限されます。iframe, img, and form などのさまざまなタグにおけるリンク経由のサードパーティ サイトからのリクエストにはこれらの Cookie がないため、ユーザーが認証されていない可能性がある場合にサイトでの処理が回避されます。SameSite 属性の値を Lax に設定しています。
ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue")
...
.sameSite("Lax")
...
}
SameSite 属性は Strict に設定されていません。SameSite 属性は、Cross-Site Request Forgery (CSRF) などの攻撃から Cookie を保護します。セッション Cookie はサイトに対してユーザーを表しているため、ユーザーは承認されたアクションを実行できるようになります。ただし、ブラウザーはリクエストとともに自動的に Cookie を送信するため、ユーザーと Web サイトは認証について暗黙的にブラウザーを信頼することになります。攻撃者はこの信頼を悪用して、攻撃者が制御するサードパーティ サイトのページにある link や iframe などのタグの href や src 属性内にリンクを埋め込むことで、ユーザーの代わりにサイトにリクエストを行うことができます。疑いを持たないユーザーを攻撃者が制御するサードパーティのサイトにおびき寄せることができれば、攻撃者はユーザーを認証するセッション Cookie を自動的に含めるリクエストを行うことができ、攻撃者がユーザーであるかのように効果的に認証されることになります。SameSite 属性の値を Strict に設定します。これにより、トップレベル ナビゲーションまたは同じサイトからのリクエストにのみ Cookie を追加するよう、ブラウザーが制限されます。iframe, img, and form などのさまざまなタグにおけるリンク経由のサードパーティ サイトからのリクエストにはこれらの Cookie がないため、ユーザーが認証されていない可能性がある場合にサイトでの処理が回避されます。SameSite 属性の値を Lax に設定しています。
app.get('/', function (req, res) {
...
res.cookie('name', 'Foo', { sameSite: "Lax" });
...
}
SameSite 属性は Strict に設定されていません。SameSite 属性は、クロスサイト リクエスト フォージェリ (CSRF) などの攻撃から Cookie を保護します。セッション Cookie はサイトに対してユーザーを表しているため、ユーザーは承認されたアクションを実行できるようになります。ただし、ブラウザーはリクエストとともに自動的に Cookie を送信するため、ユーザーと Web サイトは認証について暗黙的にブラウザーを信頼することになります。攻撃者はこの信頼を悪用して、攻撃者が制御するサードパーティ サイトのページにある link や iframe などのタグの href や src 属性内にリンクを埋め込むことで、ユーザーの代わりにサイトにリクエストを行うことができます。疑いを持たないユーザーを攻撃者が制御するサードパーティのサイトにおびき寄せることができれば、攻撃者はユーザーを認証するセッション Cookie を自動的に含めるリクエストを行うことができ、攻撃者がユーザーであるかのように効果的に認証されることになります。SameSite 属性のセッション Cookie を Strict に設定すると、トップレベル ナビゲーションまたは同じサイトからのリクエストにのみ Cookie を追加するよう、ブラウザーを制限できます。iframe, img, and form などのさまざまなタグにおけるリンク経由のサードパーティ サイトからのリクエストにはこれらの Cookie がないため、ユーザーが認証されていない可能性がある場合にサイトでの処理が回避されます。SameSite 属性の Lax モードを有効にしています。
ini_set("session.cookie_samesite", "Lax");
SameSite 属性は Strict に設定されていません。SameSite 属性は、Cross-Site Request Forgery (CSRF) などの攻撃から Cookie を保護します。セッション Cookie はサイトに対してユーザーを表しているため、ユーザーは承認されたアクションを実行できるようになります。ただし、ブラウザーはリクエストとともに自動的に Cookie を送信するため、ユーザーと Web サイトは認証について暗黙的にブラウザーを信頼することになります。攻撃者はこの信頼を悪用して、攻撃者が制御するサードパーティ サイトのページにある link や iframe などのタグの href や src 属性内にリンクを埋め込むことで、ユーザーの代わりにサイトにリクエストを行うことができます。疑いを持たないユーザーを攻撃者が制御するサードパーティのサイトにおびき寄せる場合、攻撃者は、ユーザー認証を使用してセッション Cookie を自動的に含めるリクエストを行うことができます。これにより、攻撃者はユーザーの承認を使用してアクセスできるようになります。SameSite パラメーターのセッション Cookie を Strict に設定すると、トップレベル ナビゲーションまたは同じサイトからのリクエストにのみ Cookie を追加するよう、ブラウザーを制限できます。iframe, img, and form などのさまざまなタグにおけるリンク経由のサードパーティ サイトからのリクエストにはこれらの Cookie がないため、ユーザーが認証されていない可能性がある場合にサイトでの処理が回避されます。samesite 属性の Lax を有効にしています。
response.set_cookie("cookie", value="samesite-lax", samesite="Lax")
...
Integer maxAge = 60*60*24*365*10;
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, true, 'Strict');
...
HttpCookie cookie = new HttpCookie("emailCookie", email);
cookie.Expires = DateTime.Now.AddYears(10);;
Cookie cookie = new Cookie("emailCookie", email);
cookie.setMaxAge(60*60*24*365*10);
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
[cookieProperties setValue:[[NSDate date] dateByAddingTimeInterval:(60*60*24*365*10)] forKey:NSHTTPCookieExpires];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
setcookie("emailCookie", $email, time()+60*60*24*365*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
...
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, maxAge = Some(60*60*24*365*10)))
...
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)
...
server.servlet.session.cookie.persistent=true
session_set_cookie_params(time()+60*60*24*365*10, "/", "www.example.com", false, true);
Secure フラグを true に設定せずに、アプリケーション セッション cookie が作成されます。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合、特に重要になります。Secure フラグを設定せずにレスポンスにセッション cookie が追加されるようにする設定です。
...
<configuration>
<system.web>
<authentication mode="Forms">
<forms requireSSL="false" loginUrl="login.aspx">
</forms>
</authentication>
</system.web>
</configuration>
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッション ID が格納されている cookie) を HTTP 経由で送信すると、アプリケーションが危険にさらされる可能性があります。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合、特に重要になります。Secure フラグを無効にします。
server.servlet.session.cookie.secure=false
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックをスニッフィングすることによって cookie を危険にさらすことがあります。特に無線ネットワークの場合、ネットワーク トラフィックのスニッフィングは非常に簡単です。Secure フラグを true に設定せずにセッション cookie を作成します。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合に特に重要になります。Secure フラグを設定せずに cookie がレスポンスに追加されています。
...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックをスニッフィングすることによって cookie を危険にさらすことがあります。特に無線ネットワークの場合、ネットワーク トラフィックのスニッフィングは非常に簡単です。SESSION_COOKIE_SECURE プロパティを明示的に True に設定しないか、または False に設定します。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報またはセッション ID が保存されている場合や、cookie によって CSRF トークンが送信される場合に特に重要になります。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',
...
)
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックをスニッフィングすることによって cookie を危険にさらすことがあります。特に無線ネットワークの場合、ネットワーク トラフィックのスニッフィングは非常に簡単です。java.io パッケージを使用しているので、Enterprise JavaBeans 仕様に違反しています。