Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O parâmetro SameSite limita o escopo do cookie para que ele seja anexado apenas a uma solicitação se a solicitação for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O parâmetro SameSite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definido como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com a solicitação.

Exemplo 1: O código a seguir habilita o atributo SameSite como None para cookies de sessão.

...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'None');
...

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O atributo SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definido como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com a solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

c := &http.Cookie{
  Name: "cookie",
  Value: "samesite-none",
  SameSite: http.SameSiteNoneMode,
}

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O atributo SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definidos como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas de sites de terceiros, incluindo aqueles que têm as tags iframe ou href vinculadas ao site host. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com a solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

 ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue")
     ...
     .sameSite("None") 
     ...

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O atributo SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definidos como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas de sites de terceiros, incluindo aqueles que têm as tags iframe ou href vinculadas ao site host. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com a solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

app.get('/', function (req, res) {
    ...
    res.cookie('name', 'Foo', { sameSite: false });
    ...
}

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O atributo SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definido como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

ini_set("session.cookie_samesite", "None");

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O parâmetro samesite limita o escopo do cookie para que ele seja anexado apenas a uma solicitação se a solicitação for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O parâmetro samesite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definido como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com a solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

  response.set_cookie("cookie", value="samesite-none", samesite=None)

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: Suponha 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.

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:
Suponha 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 cookie = new Cookie("sessionID", sessionID);
  cookie.setDomain(".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.

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:
Suponha 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_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.

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:
Suponha 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:

  ...
  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.

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:
Suponha 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:

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.

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: Suponha 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:

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.

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: Suponha 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:

    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.

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:
Suponha 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:

...
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.

Os desenvolvedores muitas vezes definem cookies para serem acessíveis no caminho do contexto raiz ("/"). Fazer isso expõe o cookie a todos os aplicativos Web no domínio. 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 de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum. Por exemplo:

...
String path = '/';
Cookie cookie = new Cookie('sessionID', sessionID, path, maxAge, true, 'Strict');
...

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando a ID de sessão, o invasor pode comprometer a conta de qualquer usuário do fórum que tenha navegado até /EvilSite.

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

Os desenvolvedores muitas vezes definem cookies para serem acessíveis no caminho do contexto raiz ("/"). Fazer isso expõe o cookie a todos os aplicativos Web no domínio. 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:
Suponha que você tenha um aplicativo de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.

Por exemplo:

cookie := http.Cookie{
  Name:    "sessionID",
  Value:   sID,
  Expires: time.Now().AddDate(0, 0, 1),
  Path:    "/",
}
...

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clica nesse link, o navegador envia o cookie definido por /MyForum para o aplicativo em execução em /EvilSite. Roubando a ID de sessão, o invasor pode comprometer a conta de qualquer usuário do fórum que tenha navegado até /EvilSite.

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

Os desenvolvedores muitas vezes definem que os cookies sejam acessíveis a partir do caminho do contexto raiz ("/"). Isso expõe o cookie a todos os aplicativos Web no domínio. 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 de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.

Por exemplo:

  Cookie cookie = new Cookie("sessionID", sessionID);
  cookie.setPath("/");

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

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

Os desenvolvedores muitas vezes definem que os cookies sejam acessíveis a partir do caminho do contexto raiz ("/"). Isso expõe o cookie a todos os aplicativos Web no domínio. 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 de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.

Por exemplo:

  cookie_options = {};
  cookie_options.path = '/';
  ...
  res.cookie('important_cookie', info, cookie_options);

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

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

Os desenvolvedores muitas vezes definem que os cookies sejam acessíveis a partir do caminho do contexto raiz ("/"). Isso expõe o cookie a todos os aplicativos Web no domínio. 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 de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.

Por exemplo:

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:@"/" forKey:NSHTTPCookiePath];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

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

Os desenvolvedores muitas vezes definem que os cookies sejam acessíveis a partir do caminho do contexto raiz ("/"). Isso expõe o cookie a todos os aplicativos Web no domínio. 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 de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.

Por exemplo:

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

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

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

Os desenvolvedores muitas vezes definem que os cookies sejam acessíveis a partir do caminho do contexto raiz ("/"). Isso expõe o cookie a todos os aplicativos Web no domínio. 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 de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.

Por exemplo:

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("sessionid", value)   # Path defaults to "/"
  return res
...

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

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

Os desenvolvedores muitas vezes definem que os cookies sejam acessíveis a partir do caminho do contexto raiz ("/"). Isso expõe o cookie a todos os aplicativos Web no domínio. 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 de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.

Por exemplo:

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, path = "/"))

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

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

Os desenvolvedores muitas vezes definem que os cookies sejam acessíveis a partir do caminho do contexto raiz ("/"). Isso expõe o cookie a todos os aplicativos Web no domínio. 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 de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.

Por exemplo:

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

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

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

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O parâmetro SameSite limita o escopo do cookie para que ele seja anexado apenas a uma solicitação se a solicitação for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O parâmetro SameSite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definido como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com a solicitação.

Exemplo 1: O código a seguir habilita o parâmetro SameSite como Lax para cookies de sessão.

...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'Lax');
...

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.
Defina cookies de sessão com o atributo SameSiteStrictMode para SameSite, o que restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir habilita SameSiteLaxMode no atributo SameSite para cookies de sessão.

c := &http.Cookie{
  Name: "cookie",
  Value: "samesite-lax",
  SameSite: http.SameSiteLaxMode,
}

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.
Defina o valor do atributo SameSite como Strict nos cookies de sessão. Isso restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir define o valor do atributo SameSite como Lax para cookies de sessão.

 ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue") 
     ...
     .sameSite("Lax")  
     ...
}

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.
Defina o valor do atributo SameSite como Strict nos cookies de sessão. Isso restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir define o valor do atributo SameSite como Lax para cookies de sessão.

app.get('/', function (req, res) {
    ...
    res.cookie('name', 'Foo', { sameSite: "Lax" });
    ...
}

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.
Defina cookies de sessão com o atributo Strict para SameSite, o que restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir habilita o modo Lax no atributo SameSite para cookies de sessão.

ini_set("session.cookie_samesite", "Lax");

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor atrair um usuário desavisado para o site de terceiros que ele controla, o invasor poderá fazer solicitações que incluam automaticamente o cookie de sessão com autorização do usuário. Isso efetivamente dá ao invasor acesso com a autorização do usuário.
Defina cookies de sessão como Strict para o parâmetro SameSite, o que restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir habilita Lax no atributo samesite para cookies de sessão.

  response.set_cookie("cookie", value="samesite-lax", samesite="Lax")

A maioria dos ambientes de programação da Web adota como padrão a criação de cookies não persistentes. Esses cookies residem apenas na memória do navegador (não são gravados no disco) e são perdidos quando o navegador é fechado. Os programadores podem especificar que os cookies persistam nas sessões do navegador até uma data futura. Esses cookies são gravados no disco e sobrevivem às sessões do navegador e reinicializações do computador.

Se as informações privadas forem armazenadas em cookies persistentes, os invasores terão uma janela de tempo maior para roubar esses dados, especialmente porque os cookies persistentes costumam expirar em um futuro distante. Os cookies persistentes costumam ser usados para traçar o perfil dos usuários conforme eles interagem com um site. Dependendo do que for feito com esses dados de rastreamento, será possível usar cookies persistentes para violar a privacidade dos usuários.

Exemplo 1: O código a seguir define um cookie para expirar em 10 anos.

...
Integer maxAge = 60*60*24*365*10;
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, true, 'Strict');
...

A maioria dos ambientes de programação da Web assumem como padrão a criação de cookies não persistentes. Esses cookies residem apenas na memória do navegador (não são gravados em disco) e se perdem quando o navegador é fechado. Os programadores podem especificar que os cookies se mantenham persistentes entre sessões do navegador até uma determinada data no futuro. Esses cookies são gravados no disco e sobrevivem entre sessões de navegador e reinicializações do computador.

Se informações privadas forem armazenadas em cookies persistentes, os invasores terão uma janela de tempo maior para roubar esses dados, especialmente porque cookies persistentes são muitas vezes definidos para expirarem em um futuro distante. Cookies persistentes costumam ser usados para definir perfis de usuários à medida que estes interagem com um site. Dependendo do que é feito com esses dados de rastreamento, é possível utilizar cookies persistentes para violar a privacidade dos usuários.
Exemplo 1: O código a seguir define um cookie para expirar em 10 anos.

	Cookie cookie = new Cookie("emailCookie", email);
	cookie.setMaxAge(60*60*24*365*10);

A maioria dos ambientes de programação da Web assumem como padrão a criação de cookies não persistentes. Esses cookies residem apenas na memória do navegador (não são gravados em disco) e se perdem quando o navegador é fechado. Os programadores podem especificar que os cookies se mantenham persistentes entre sessões do navegador até uma determinada data no futuro. Esses cookies são gravados em disco e sobrevivem em todas as sessões do navegador e as reinicializações do dispositivo.

Se informações privadas forem armazenadas em cookies persistentes, os invasores terão uma janela de tempo maior para roubar esses dados, especialmente porque cookies persistentes são muitas vezes definidos para expirarem em um futuro distante. Cookies persistentes costumam ser usados para definir perfis de usuários à medida que estes interagem com um site. Dependendo do que é feito com esses dados de rastreamento, é possível utilizar cookies persistentes para violar a privacidade dos usuários.
Exemplo 1: O código a seguir define um cookie para expirar em 10 anos.

    ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:[[NSDate date] dateByAddingTimeInterval:(60*60*24*365*10)] forKey:NSHTTPCookieExpires];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

A maioria dos ambientes de programação da Web assumem como padrão a criação de cookies não persistentes. Esses cookies residem apenas na memória do navegador (não são gravados em disco) e se perdem quando o navegador é fechado. Os programadores podem especificar que os cookies se mantenham persistentes entre sessões do navegador até uma determinada data no futuro. Esses cookies são gravados no disco e sobrevivem entre sessões de navegador e reinicializações do computador.

Se informações privadas forem armazenadas em cookies persistentes, os invasores terão uma janela de tempo maior para roubar esses dados, especialmente porque cookies persistentes são muitas vezes definidos para expirarem em um futuro distante. Cookies persistentes costumam ser usados para definir perfis de usuários à medida que estes interagem com um site. Dependendo do que é feito com esses dados de rastreamento, é possível utilizar cookies persistentes para violar a privacidade dos usuários.
Exemplo 1: O código a seguir define um cookie para expirar em 10 anos.

setcookie("emailCookie", $email, time()+60*60*24*365*10);

A maioria dos ambientes de programação da Web assumem como padrão a criação de cookies não persistentes. Esses cookies residem apenas na memória do navegador (não são gravados em disco) e se perdem quando o navegador é fechado. Os programadores podem especificar que os cookies se mantenham persistentes entre sessões do navegador até uma determinada data no futuro. Esses cookies são gravados no disco e sobrevivem entre sessões de navegador e reinicializações do computador.

Se informações privadas forem armazenadas em cookies persistentes, os invasores terão uma janela de tempo maior para roubar esses dados, especialmente porque cookies persistentes são muitas vezes definidos para expirarem em um futuro distante. Cookies persistentes costumam ser usados para definir perfis de usuários à medida que estes interagem com um site. Dependendo do que é feito com esses dados de rastreamento, é possível utilizar cookies persistentes para violar a privacidade dos usuários.
Exemplo 1: O código a seguir define um cookie para expirar em 10 anos.

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
...

A maioria dos ambientes de programação da Web assumem como padrão a criação de cookies não persistentes. Esses cookies residem apenas na memória do navegador (não são gravados em disco) e se perdem quando o navegador é fechado. Os programadores podem especificar que os cookies se mantenham persistentes entre sessões do navegador até uma determinada data no futuro. Esses cookies são gravados no disco e sobrevivem entre sessões de navegador e reinicializações do computador.

Se informações privadas forem armazenadas em cookies persistentes, os invasores terão uma janela de tempo maior para roubar esses dados, especialmente porque cookies persistentes são muitas vezes definidos para expirarem em um futuro distante. Cookies persistentes costumam ser usados para definir perfis de usuários à medida que estes interagem com um site. Dependendo do que é feito com esses dados de rastreamento, é possível utilizar cookies persistentes para violar a privacidade dos usuários.
Exemplo 1: O código a seguir define um cookie para expirar em 10 anos.

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, maxAge = Some(60*60*24*365*10)))

A maioria dos ambientes de programação da Web assumem como padrão a criação de cookies não persistentes. Esses cookies residem apenas na memória do navegador (não são gravados em disco) e se perdem quando o navegador é fechado. Os programadores podem especificar que os cookies se mantenham persistentes entre sessões do navegador até uma determinada data no futuro. Esses cookies são gravados em disco e sobrevivem em todas as sessões do navegador e as reinicializações do dispositivo.

Se informações privadas forem armazenadas em cookies persistentes, os invasores terão uma janela de tempo maior para roubar esses dados, especialmente porque cookies persistentes são muitas vezes definidos para expirarem em um futuro distante. Cookies persistentes costumam ser usados para definir perfis de usuários à medida que estes interagem com um site. Dependendo do que é feito com esses dados de rastreamento, é possível utilizar cookies persistentes para violar a privacidade dos usuários.
Exemplo 1: O código a seguir define um cookie para expirar em 10 anos.

...
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)
...

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.

Exemplo 1: A seguinte entrada de configuração desativa o sinalizador Secure para cookies de sessão.

server.servlet.session.cookie.secure=false

Se um aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.
Exemplo 1: O seguinte código adiciona um cookie à resposta sem definir o sinalizador Secure.

...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...

Se um aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante se o cookie contém dados privados, identificadores de sessão, ou carrega um token CSRF.
Exemplo 1: Esta entrada de configuração não define explicitamente o bit Secure para os cookies de sessão.

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

Se um aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.

Vulnerabilidades de XSS (criação de script entre sites) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso de um XSS de Comunicação entre Componentes, a fonte não confiável consiste em dados recebidos de outros componentes que residem no mesmo sistema. No caso de XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso de XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.

2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador da Web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo da Web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.


Exemplo 1: O seguinte segmento de código Go lê um nome de usuário, user, de uma solicitação HTTP e o exibe para o usuário.

func someHandler(w http.ResponseWriter, r *http.Request){
  r.parseForm()
  user := r.FormValue("user")
  ...
  fmt.Fprintln(w, "Username is: ", user)
}

O código nesse exemplo funcionará corretamente se user contiver apenas texto alfanumérico padrão. Se user tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 2: O segmento de código Go a seguir consulta um banco de dados em busca de um funcionário com determinada ID e imprime o nome do funcionário correspondente.

func someHandler(w http.ResponseWriter, r *http.Request){
  ...
  row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
  err := row.Scan(&name)
  ...
  fmt.Fprintln(w, "Username is: ", name)
}

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque a indireção causada pelo armazenamento de dados dificulta a identificação da ameaça e aumenta a possibilidade de o ataque afetar vários usuários. O XSS começou dessa forma, com sites que ofereciam um "livro de visitas" aos visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como mostrado no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações XSS refletidas ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como mostrado no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor poderá executar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais pertencentes ao usuário.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Dados entram em um aplicativo Web ou móvel por meio de uma fonte não confiável. No caso de um XSS de Comunicação entre Componentes, a fonte não confiável consiste em dados recebidos de outros componentes que residem no mesmo sistema. No mundo móvel, esses são os aplicativos em execução no mesmo dispositivo. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Algumas pessoas acham que, no ambiente móvel, vulnerabilidades clássicas de aplicativos Web, como criação de scripts entre sites, não fazem sentido — por que um usuário atacaria a si mesmo? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 1: O código a seguir habilita o JavaScript no WebView do Android (o JavaScript está desabilitado por padrão) e carrega uma página com base no valor recebido de uma intenção do Android.

...
        WebView webview = (WebView) findViewById(R.id.webview);
        webview.getSettings().setJavaScriptEnabled(true);
        String url = this.getIntent().getExtras().getString("url");
        webview.loadUrl(url);
...

Se o valor de url começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.

Exemplo 2: O seguinte segmento de código JSP lê uma ID de funcionário, eid, de uma solicitação HTTP e a exibe para o usuário.

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 3: O seguinte segmento de código JSP consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
   rs.next();
   String name = rs.getString("name");
}
%>

Employee Name: <%= name %>

Como no Example 2, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 3, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

Várias estruturas modernas da Web fornecem mecanismos para realizar a validação de entradas do usuário (como o Struts e o Struts 2). Para destacar as fontes não validadas de entradas, os pacotes seguros de regras de codificação do Fortify estabelecem dinamicamente uma nova prioridade para os problemas que o Fortify Static Code Analyzer relata, diminuindo sua probabilidade de exploração e fornecendo ponteiros para as evidências sempre que o mecanismo de validação de estrutura estiver em uso. Chamamos esse recurso de Classificação Sensível ao Contexto. Para ajudar ainda mais o usuário do Fortify com o processo de auditoria, o Fortify Software Security Research Group disponibiliza o modelo de projeto de Validação de Dados, que agrupa os problemas em pastas com base no mecanismo de validação aplicado à respectiva fonte de entrada.

Vulnerabilidades de XSS (criação de script entre sites) ocorrem quando:

1. Dados entram em um aplicativo Web por meio de uma fonte não confiável. No caso de um XSS de Comunicação entre Componentes, a fonte não confiável consiste em dados recebidos de outros componentes que residem no mesmo sistema. No ambiente móvel, esses aplicativos estão em execução no mesmo dispositivo. No caso de XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso de XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Algumas pessoas acham que, no ambiente móvel, vulnerabilidades clássicas de aplicativos Web, como criação de scripts entre sites, não fazem sentido — por que um usuário atacaria a si mesmo? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 1: O código a seguir habilita o JavaScript no WebView do Android (o JavaScript está desabilitado por padrão) e carrega uma página com base no valor recebido de uma intenção do Android.

...
        val webview = findViewById<View>(R.id.webview) as WebView
        webview.settings.javaScriptEnabled = true
        val url = this.intent.extras!!.getString("url")
        webview.loadUrl(url)
...

Se o valor de url começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.

Exemplo 2: O código a seguir lê uma ID de funcionário, eid, de uma solicitação de servlet HTTP e, em seguida, exibe o valor de volta para o usuário na resposta do servlet.

val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...

O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 3: O seguinte segmento de código consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente na resposta do servlet.

val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...

Como no Example 2, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 3, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.


Várias estruturas da Web modernas fornecem mecanismos para realizar a validação de entradas do usuário (como o Struts e o Spring MVC). Para destacar as fontes não validadas de entradas, os pacotes seguros de regras de codificação do Fortify estabelecem dinamicamente uma nova prioridade para os problemas que o Fortify Static Code Analyzer relata, diminuindo sua probabilidade de exploração e fornecendo ponteiros para as evidências sempre que o mecanismo de validação de estrutura estiver em uso. Chamamos esse recurso de Classificação Sensível ao Contexto. Para ajudar ainda mais o usuário do Fortify com o processo de auditoria, o Fortify Software Security Research Group disponibiliza o modelo de projeto de Validação de Dados, que agrupa os problemas em pastas com base no mecanismo de validação aplicado à respectiva fonte de entrada.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web ou móvel por meio de uma fonte não confiável. No caso de um XSS de Comunicação entre Componentes, a fonte não confiável consiste em dados recebidos de outros componentes que residem no mesmo sistema. No mundo móvel, esses são os aplicativos em execução no mesmo dispositivo. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Algumas pessoas acham que, no ambiente móvel, vulnerabilidades clássicas de aplicativos Web, como criação de scripts entre sites, não fazem sentido — por que um usuário atacaria a si mesmo? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 1: Este código permite a um aplicativo carregar uma página html dentro de um WKWebView com dados de uma solicitação de URL que usa o esquema de URL personalizado do aplicativo:

AppDelegate.m:

...
@property (strong, nonatomic) NSString *webContentFromURL;
...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
  ...
  [self setWebContentFromURL:[url host]];
  ...
...

ViewController.m

...
@property (strong, nonatomic) WKWebView *webView;
...
AppDelegate *appDelegate = (AppDelegate *)[[UIApplication sharedApplication] delegate];
...
[_webView loadHTMLString:appDelegate.webContentFromURL] baseURL:nil];
...

Uma vez que a cadeia tenha passado para loadHTMLString: será controlável pelo usuário e o JavaScript será ativado por padrão dentro de um WKWebView, o usuário poderá gravar conteúdo arbitrário (incluindo scripts executáveis) no WKWebView via solicitações que usem o esquema de URL personalizado do aplicativo.

Exemplo 2: Este código lê o conteúdo de um UITextField e o exibe ao usuário dentro de um WKWebView:

...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView loadHTMLString:_inputTextField.text baseURL:nil];
...

O código neste exemplo operará sem problemas caso o texto noinputTextField contiver apenas um texto alfanumérico padrão. Se o texto no inputTextField incluir metacaracteres ou código-fonte, a entrada poderá ser executada como código pelo navegador da Web conforme exibe a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém forneceria uma entrada a qual pode permitir que um código malicioso seja executado em seu próprio dispositivo? O perigo real é que um invasor pode usar email ou truques de engenharia social para atrair as vítimas a realizar tais ações. Caso isso tenha êxito, as vítimas refletem o conteúdo malicioso sem querer por meio do aplicativo web vulnerável de volta para seus próprios dispositivos. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 3: Este segmento de código consulta um banco de dados para um funcionário com uma determinada ID e emite o valor no conteúdo de exibição de uma WKWebView.

...
@property (strong, nonatomic) WKWebView *webView;
...
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:@"Employee" inManagedObjectContext:context];
[fetchRequest setEntity:entity];

NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error];
for (NSManagedObject *info in fetchedObjects) {
  NSString msg = @"Hello, " + [info valueForKey:@"name"];
  [_webView loadHTMLString:msg baseURL:nil]
  ...
}
...

Como no Example 2, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, uma fonte fora do aplicativo de destino faz uma solicitação de URL usando o esquema de URL personalizado do aplicativo de destino, e os dados não validados a partir da solicitação de URL subsequentemente são lidos pelo aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

- Como no Example 2, os dados são lidos diretamente de um componente de IU controlado pelo usuário e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 3, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web ou móvel por meio de uma fonte não confiável. No caso de um XSS de Comunicação entre Componentes, a fonte não confiável consiste em dados recebidos de outros componentes que residem no mesmo sistema. No mundo móvel, esses são os aplicativos em execução no mesmo dispositivo. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Algumas pessoas acham que, no ambiente móvel, vulnerabilidades clássicas de aplicativos Web, como criação de scripts entre sites, não fazem sentido — por que um usuário atacaria a si mesmo? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 1: Este código permite a um aplicativo carregar uma página html dentro de um WKWebView com dados de uma solicitação de URL que usa o esquema de URL personalizado do aplicativo:

...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
    ...
    let name = getQueryStringParameter(url.absoluteString, "name")
    let html = "Hi \(name)"
    let webView = WKWebView()
    webView.loadHTMLString(html, baseURL:nil)
    ...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
    if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
        return queryItems.filter({ (item) in item.name == param }).first?.value!
    }
    return nil
}
...

Como a cadeia de caracteres transmitida para loadHTMLString: é controlável pelo usuário e JavaScript é habilitado por padrão em um WKWebView, o usuário pode escrever conteúdo arbitrário (incluindo scripts executáveis) para o WKWebView por meio de solicitações que usam o esquema de URL personalizado do aplicativo.

Exemplo 2: Este código lê o conteúdo de um UITextField e o exibe ao usuário dentro de um WKWebView:

...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...

O código neste exemplo operará sem problemas caso o texto noinputTextField contiver apenas um texto alfanumérico padrão. Se o texto no inputTextField incluir metacaracteres ou código-fonte, a entrada poderá ser executada como código pelo navegador da Web conforme exibe a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém forneceria uma entrada a qual pode permitir que um código malicioso seja executado em seu próprio dispositivo? O perigo real é que um invasor pode usar email ou truques de engenharia social para atrair as vítimas a realizar tais ações. Caso isso tenha êxito, as vítimas refletem o conteúdo malicioso sem querer por meio do aplicativo web vulnerável de volta para seus próprios dispositivos. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 3: Este segmento de código consulta um banco de dados para um funcionário com uma determinada ID e emite o valor no conteúdo de exibição de uma WKWebView.

let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Employee", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
do {
    let results = try managedContext.executeFetchRequest(fetchRequest)
    let result : NSManagedObject = results.first!
    let name : String = result.valueForKey("name")
    let msg : String = "Hello, \(name)"
    let webView : UIWebView = UIWebView()
    webView.loadHTMLString(msg, baseURL:nil)
} catch let error as NSError {
    print("Error \(error)")
}

Como no Example 2, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, uma fonte fora do aplicativo de destino faz uma solicitação de URL usando o esquema de URL personalizado do aplicativo de destino, e os dados não validados a partir da solicitação de URL subsequentemente são lidos pelo aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

- Como no Example 2, os dados são lidos diretamente de um componente de IU controlado pelo usuário e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 3, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.