Cookie Security: Overly Broad Domain

Um cookie com um domínio excessivamente amplo abre um aplicativo para ataques por meio de outros aplicativos.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

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

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Um cookie com um domínio excessivamente amplo abre um aplicativo a ataques por meio de outros aplicativos.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies carregam frequentemente informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro aplicativo.

Exemplo 1: Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz logon.

Por exemplo:

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

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de cross-site scripting. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de ler um cookie, os invasores podem executar um "ataque de envenenamento de cookie" usando insecure.example.com para criar seu próprio cookie excessivamente amplo que substitui o cookie em Secure.example.com.

Um cookie com um domínio excessivamente amplo abre um aplicativo para ataques por meio de outros aplicativos.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina um cookie de ID de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

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

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Um cookie com um domínio excessivamente amplo abre um aplicativo para ataques por meio de outros aplicativos.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

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

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Um cookie com um domínio excessivamente amplo abre um aplicativo para ataques por meio de outros aplicativos.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

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

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Um cookie com um domínio excessivamente amplo abre um aplicativo para ataques por meio de outros aplicativos.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1: Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

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

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de ler um cookie, pode ser possível aos invasores realizar um "ataque de envenenamento de cookie" usando insecure.example.com para criar o cookie próprio e excessivamente amplo que substitui o cookie secure.example.com.

Um cookie com um domínio excessivamente amplo abre um aplicativo para ataques por meio de outros aplicativos.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1: Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

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

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de cross-site scripting. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Um cookie com um domínio excessivamente amplo abre um aplicativo para ataques por meio de outros aplicativos.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

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

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.