Uma vulnerabilidade de CSRF (cross-site request forgery) ocorre quando:
1. Um aplicativo da Web usa cookies de sessão.

2. O aplicativo atua em uma solicitação HTTP sem verificar se ela foi feita com o consentimento do usuário.

Por padrão, as páginas do Visualforce são renderizadas com campos de formulário ocultos que servem como tokens anti-CSRF. Esses tokens são incluídos nas solicitações enviadas da página e o servidor verifica a validade dos tokens antes de executar os métodos de ação ou comandos correspondentes. No entanto, essa defesa integrada não se aplica a métodos de ação de página e construtores de controlador de página personalizados porque eles são executados antes que os tokens anti-CSRF sejam gerados durante o carregamento da página.

Exemplo 1: A página a seguir do Visualforce declara um controlador personalizado MyAccountActions e um método de ação de página pageAction(). O método pageAction() é executado quando o URL da página é visitado e o servidor não verifica se há tokens anti-CSRF.

<apex:page controller="MyAccountActions" action="{!pageAction}">
    ...
</apex:page>

public class MyAccountActions {

    ...
    public void pageAction() {
        Map<String,String> reqParams = ApexPages.currentPage().getParameters();
        if (params.containsKey('id')) {
            Id id = reqParams.get('id');
            Account acct = [SELECT Id,Name FROM Account WHERE Id = :id];
            delete acct;
        }
    }
    ...
}

Um invasor pode configurar um site mal-intencionado que contém o seguinte código:

<img src="http://my-org.my.salesforce.com/apex/mypage?id=YellowSubmarine" height=1 width=1/>

Se um administrador da página do Visualforce visitar a página mal-intencionada durante uma sessão ativa no site, ele excluirá involuntariamente as contas do invasor.

Uma vulnerabilidade de CSRF (falsificação de solicitações entre sites) ocorre quando:
1. Um aplicativo da Web usa cookies de sessão.

2. O aplicativo atua em uma solicitação HTTP sem verificar se ela foi feita com o consentimento do usuário.



Um nonce é um valor criptográfico aleatório enviado com uma mensagem para evitar ataques de repetição. Se a solicitação não contiver um nonce que comprove sua proveniência, o código que trata a solicitação ficará vulnerável a um ataque CSRF (a menos que não altere o estado da aplicativo). Isso significa que um aplicativo da Web que usa cookies de sessão precisa tomar precauções especiais para garantir que um invasor não consiga enganar os usuários para que enviem solicitações falsas. Imagine um aplicativo da Web que permite que os administradores criem novas contas da seguinte forma:

  var req = new XMLHttpRequest();
  req.open("POST", "/new_user", true);
  body = addToPost(body, new_username);
  body = addToPost(body, new_passwd);
  req.send(body);

Um invasor pode configurar um site mal-intencionado que contém o seguinte código.

  var req = new XMLHttpRequest();
  req.open("POST", "http://www.example.com/new_user", true);
  body = addToPost(body, "attacker");
  body = addToPost(body, "haha");
  req.send(body);

Se uma administradora do example.com visitar a página maliciosa enquanto tiver uma sessão ativa no site, ela involuntariamente criará uma conta para o invasor. Isto é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.

Aplicativos que transmitem o identificador de sessão na URL em vez de como um cookie não têm problemas de CSRF, pois não há como o invasor acessar o identificador de sessão e incluí-lo como parte da solicitação falsa.
A CSRF está em quinto lugar na lista dos 10 principais ataques do OWASP em 2007.

Uma vulnerabilidade de CSRF (falsificação de solicitações entre sites) ocorre quando:
1. Um aplicativo da Web usa cookies de sessão.

2. O aplicativo atua em uma solicitação HTTP sem verificar se ela foi feita com o consentimento do usuário.

Um nonce é um valor aleatório criptográfico que é enviado com uma mensagem para impedir ataques de reprodução. Se a solicitação não contiver um nonce que comprove sua procedência, o código que a manipula será vulnerável a um ataque de CSRF (a menos que isso não altere o estado do aplicativo). Isso significa que um aplicativo Web que usa cookies de sessão precisa tomar precauções especiais para assegurar que um invasor não consiga enganar os usuários a ponto de que estes enviem solicitações falsas. Imagine um aplicativo Web que permite aos administradores criar novas contas enviando este formulário:

<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>

Um invasor pode configurar um site com o seguinte:

<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>

Se uma administradora do example.com visitar a página maliciosa enquanto tiver uma sessão ativa no site, ela involuntariamente criará uma conta para o invasor. Isto é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.

Aplicativos que transmitem o identificador de sessão na URL em vez de como um cookie não têm problemas de CSRF, pois não há como o invasor acessar o identificador de sessão e incluí-lo como parte da solicitação falsa.

Uma vulnerabilidade de CSRF (cross-site request forgery) ocorre quando:
1. Um aplicativo da Web usa cookies de sessão.

2. O aplicativo atua em uma solicitação HTTP sem verificar se ela foi feita com o consentimento do usuário.

Um nonce é um valor aleatório criptográfico que é enviado com uma mensagem para impedir ataques de reprodução. Se a solicitação não contiver um nonce que comprove sua procedência, o código que a manipula será vulnerável a um ataque de CSRF (a menos que isso não altere o estado do aplicativo). Isso significa que um aplicativo Web que usa cookies de sessão precisa tomar precauções especiais para assegurar que um invasor não consiga enganar os usuários a ponto de que estes enviem solicitações falsas. Imagine um aplicativo Web que permite aos administradores criar novas contas, da seguinte maneira:

Por padrão, o Play Framework adiciona proteção contra CSRF, mas ela pode ser desabilitada globalmente ou em determinadas rotas.

Exemplo: A definição de rota a seguir desabilita a proteção CSRF para o método de controlador buyItem.

+ nocsrf
POST    /buyItem     controllers.ShopController.buyItem

Se uma usuária for enganada para visitar uma página mal-intencionada enquanto tiver uma sessão ativa no shop.com, ela comprará itens involuntariamente para o invasor. Isso é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.

Aplicativos que transmitem o identificador de sessão na URL em vez de como um cookie não têm problemas de CSRF, pois não há como o invasor acessar o identificador de sessão e incluí-lo como parte da solicitação falsa.

Uma vulnerabilidade de CSRF (falsificação de solicitações entre sites) ocorre quando:
1. Um aplicativo da Web usa cookies de sessão.

2. O aplicativo atua em uma solicitação HTTP sem verificar se ela foi feita com o consentimento do usuário.



Um nonce é um valor aleatório criptográfico que é enviado com uma mensagem para impedir ataques de reprodução. Se a solicitação não contiver um nonce que comprove sua procedência, o código que a manipula será vulnerável a um ataque de CSRF (a menos que isso não altere o estado do aplicativo). Isso significa que um aplicativo Web que usa cookies de sessão precisa tomar precauções especiais para assegurar que um invasor não consiga enganar os usuários a ponto de que estes enviem solicitações falsas. Imagine um aplicativo Web que permite aos administradores criar novas contas enviando este formulário:

<form method="POST" action="/new_user" >
  Name of new user: <input type="text" name="username">
  Password for new user: <input type="password" name="user_passwd">
    <input type="submit" name="action" value="Create User">
</form>

Um invasor pode configurar um site com o seguinte:

<form method="POST" action="http://www.example.com/new_user">
  <input type="hidden" name="username" value="hacker">
  <input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
  document.usr_form.submit();
</script>

Se uma administradora do example.com visitar a página maliciosa enquanto tiver uma sessão ativa no site, ela involuntariamente criará uma conta para o invasor. Isto é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.

Aplicativos que transmitem o identificador de sessão na URL em vez de como um cookie não têm problemas de CSRF, pois não há como o invasor acessar o identificador de sessão e incluí-lo como parte da solicitação falsa.

A CSRF está em quinto lugar na lista dos 10 principais ataques do OWASP em 2007.

O sequestro de WebSocket entre sites ocorre quando um usuário é levado a visitar um site mal-intencionado que estabelecerá uma conexão WebSocket com um servidor de back-end legítimo. A solicitação HTTP inicial usada para solicitar ao servidor a atualização para o protocolo WebSocket é uma solicitação HTTP regular e, portanto, o navegador enviará todos os cookies associados ao domínio de destino, incluindo cookies de sessão. Se o servidor não conseguir verificar o cabeçalho Origin, ele permitirá que qualquer site mal-intencionado represente o usuário e estabeleça uma conexão WebSocket bidirecional sem o usuário sequer perceber.

A execução de scripts entre zonas com base em arquivo ocorre quando as seguintes condições são atendidas:

1. É carregado um arquivo capaz de permitir que scripts sejam executados dentro do seu aplicativo.


2. O script carregado é considerado como tendo a mesma origem que o aplicativo em execução (file://).

Quando essas duas condições são atendidas, uma série de ataques pode ser habilitada, especialmente se outras partes determinarem a confiança com base em se as informações são provenientes dos limites do seu aplicativo.

Exemplo 1: O seguinte código usa o método UIWebView.loadRequest(_:) para carregar um arquivo local:

...
NSURL *url = [[NSBundle mainBundle] URLForResource: filename withExtension:extension]; 
[webView loadRequest:[[NSURLRequest alloc] initWithURL:url]];
...

No Example 1, o mecanismo WebView trata todo o conteúdo carregado com UIWebView.loadRequest(_:), com uma URL que começa com file://, como estando na origem de arquivo local privilegiada.

Existem algumas maneiras típicas de um invasor se aproveitar de uma vulnerabilidade de execução de script entre zonas com base em arquivo ao carregar a partir de um arquivo:

- O arquivo local pode ser controlado pelo invasor. Por exemplo, o invasor pode enviar o arquivo para a sua vítima, que então o armazena no aplicativo vulnerável (por exemplo: um aplicativo de armazenamento na nuvem)
- O arquivo local pode ser manipulado por um invasor, que pode injetar script nesse arquivo. Isso dependerá de permissões de arquivo, na localização do arquivo ou em condições de corrida, nas quais um arquivo pode ser salvo e então carregado (pode haver uma janela de tempo para modificação).
- O arquivo pode ser chamado para um recurso externo. Isso pode ocorrer quando o arquivo carregado recupera scripts de um recurso externo.
- O arquivo carregado pode conter vulnerabilidades de execução de scripts entre sites. Se o arquivo que está sendo carregado contiver código injetado, talvez esse código possa ser executado no contexto do seu aplicativo. O código injetado não precisa ser o código JavaScript - um HTML injetado também pode permitir desfigurações ou ataques de negação de serviço.

Se o arquivo controlado pelo invasor for carregado localmente com uma URL file://, a Política de mesma origem permitirá que os scripts nesse arquivo acessem qualquer outro arquivo da mesma origem, o que pode permitir que um invasor acesse qualquer arquivo local que contenha informações confidenciais.

A execução de scripts entre zonas com base em arquivo ocorre quando as seguintes condições são atendidas:

1. É carregado um arquivo capaz de permitir que scripts sejam executados dentro do seu aplicativo.


2. O script carregado é considerado como tendo a mesma origem que o aplicativo em execução (file://).

Quando essas duas condições são atendidas, uma série de ataques pode ser habilitada, especialmente se outras partes determinarem a confiança com base em se as informações são provenientes dos limites do seu aplicativo.

Exemplo 1: O seguinte código usa o método UIWebView.loadRequest(_:) para carregar um arquivo local:

...
let url = Bundle.main.url(forResource: filename, withExtension: extension)
self.webView!.load(URLRequest(url:url!))
...

No Example 1, o mecanismo WebView trata todo o conteúdo carregado com UIWebView.loadRequest(_:), com uma URL que começa com file://, como estando na origem de arquivo local privilegiada.

Existem algumas maneiras típicas de um invasor se aproveitar de uma vulnerabilidade de execução de script entre zonas com base em arquivo ao carregar a partir de um arquivo:

- O arquivo local pode ser controlado pelo invasor. Por exemplo, o invasor pode enviar o arquivo para a sua vítima, que então o armazena no aplicativo vulnerável (por exemplo: um aplicativo de armazenamento na nuvem)
- O arquivo local pode ser manipulado por um invasor, que pode injetar script nesse arquivo. Isso dependerá de permissões de arquivo, na localização do arquivo ou em condições de corrida, nas quais um arquivo pode ser salvo e então carregado (pode haver uma janela de tempo para modificação).
- O arquivo pode ser chamado para um recurso externo. Isso pode ocorrer quando o arquivo carregado recupera scripts de um recurso externo.
- O arquivo carregado pode conter vulnerabilidades de execução de scripts entre sites. Se o arquivo que está sendo carregado contiver código injetado, talvez esse código possa ser executado no contexto do seu aplicativo. O código injetado não precisa ser o código JavaScript - um HTML injetado também pode permitir desfigurações ou ataques de negação de serviço.

Se o arquivo controlado pelo invasor for carregado localmente com uma URL file://, a Política de mesma origem permitirá que os scripts nesse arquivo acessem qualquer outro arquivo da mesma origem, o que pode permitir que um invasor acesse qualquer arquivo local que contenha informações confidenciais.