Cross-Site Request Forgery

O método de ação de página do Visualforce ou o construtor do controlador executa tarefas confidenciais sem proteção contra solicitações não autorizadas.

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.

As solicitações HTTP devem conter um segredo específico do usuário para impedir que um invasor faça solicitações não autorizadas.

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.

O aplicativo Django não permite a proteção de middleware CSRF

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.

As solicitações HTTP devem conter um segredo específico do usuário para impedir que um invasor faça solicitações não autorizadas.

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

Publicações de formulário devem conter um segredo específico do usuário para impedir que um invasor faça solicitações não autorizadas.

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.