Cookie Security: Overly Broad Domain

지나치게 광범위한 도메인을 가진 쿠키는 다른 응용 프로그램을 통해 공격할 수 있도록 응용 프로그램을 열어 줍니다.

개발자는 쿠키를 ".example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.

예제:http://secure.example.com/에서 배포한 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.

예를 들어 다음과 같습니다.

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.Domain = ".example.com";

http://insecure.example.com/에 안전성이 낮은 다른 응용 프로그램이 있으며 여기에 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.

쿠키 읽기 외에도 공격자는 insecure.example.com을 사용한 Cookie Poisoning 공격을 수행하여 secure.example.com의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다.

Overly Broad Domain을 가진 쿠키는 다른 응용 프로그램을 통해 공격할 수 있도록 응용 프로그램을 열어 줍니다.

개발자는 쿠키를 ".example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.

예제 1:http://secure.example.com/에서 배포된 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.

예를 들어, 다음과 같습니다.

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

http://insecure.example.com/에 덜 안전한 다른 응용 프로그램이 있으며 여기에는 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.

공격자는 쿠키를 읽는 것은 물론, insecure.example.com를 사용한 "쿠키 감염(Cookie Poisoning) 공격"을 수행하여 Secure.example.com의 쿠키를 덮어쓰는, 지나치게 광범위한 자체 쿠키를 생성할 수 있습니다.

지나치게 광범위한 도메인을 가진 쿠키는 다른 응용 프로그램을 통해 공격할 수 있도록 응용 프로그램을 열어 줍니다.

개발자는 쿠키를 ".example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.

예제 1:http://secure.example.com/에서 배포한 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.

예:

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

http://insecure.example.com/에 덜 안전한 다른 응용 프로그램이 있으며 여기에는 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.

쿠키 읽기 외에도 공격자는 insecure.example.com을 사용한 Cookie Poisoning 공격을 수행하여 secure.example.com의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다.

지나치게 광범위한 도메인을 가진 쿠키는 다른 응용 프로그램을 통해 공격할 수 있도록 응용 프로그램을 열어 줍니다.

개발자는 쿠키를 ".example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.

예제 1:http://secure.example.com/에서 배포한 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.

예:

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

http://insecure.example.com/에 덜 안전한 다른 응용 프로그램이 있으며 여기에는 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.

쿠키 읽기 외에도 공격자는 insecure.example.com을 사용한 Cookie Poisoning 공격을 수행하여 secure.example.com의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다.

지나치게 광범위한 도메인을 가진 쿠키는 다른 응용 프로그램을 통해 공격할 수 있도록 응용 프로그램을 열어 줍니다.

개발자는 쿠키를 ".example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.

예제 1:http://secure.example.com/에서 배포한 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.

예:

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

http://insecure.example.com/에 덜 안전한 다른 응용 프로그램이 있으며 여기에는 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.

쿠키 읽기 외에도 공격자는 insecure.example.com을 사용한 Cookie Poisoning 공격을 수행하여 secure.example.com의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다.

지나치게 광범위한 도메인을 가진 쿠키는 다른 응용 프로그램을 통해 공격할 수 있도록 응용 프로그램을 열어 줍니다.

개발자는 쿠키를 ".example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.

예제 1:http://secure.example.com/에서 배포된 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.

예:

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://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.

공격자는 쿠키를 읽는 것은 물론, insecure.example.com를 사용한 "쿠키 감염(Cookie Poisoning) 공격"을 수행하여 secure.example.com의 쿠키를 덮어쓰는, 지나치게 광범위한 자체 쿠키를 생성할 수도 있습니다.

지나치게 광범위한 도메인을 가진 쿠키는 다른 응용 프로그램을 통해 공격할 수 있도록 응용 프로그램을 열어 줍니다.

개발자는 쿠키를 ".example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.

예제 1:http://secure.example.com/에서 배포한 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.

예를 들어 다음과 같습니다.

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

http://insecure.example.com/에 덜 안전한 다른 응용 프로그램이 있으며 여기에는 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.

쿠키 읽기 외에도 공격자는 insecure.example.com을 사용한 Cookie Poisoning 공격을 수행하여 secure.example.com의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다.

지나치게 광범위한 도메인을 가진 쿠키는 다른 응용 프로그램을 통해 공격할 수 있도록 응용 프로그램을 열어 줍니다.

개발자는 쿠키를 ".example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.

예제 1:http://secure.example.com/에서 배포한 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.

예:

...
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://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.

쿠키 읽기 외에도 공격자는 insecure.example.com을 사용한 Cookie Poisoning 공격을 수행하여 secure.example.com의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다.