Cross-Site Request Forgery

El método o el constructor del controlador de la acción de página de Visualforce realiza tareas confidenciales sin protección contra solicitudes no autorizadas.

Se genera una vulnerabilidad de Cross-site Request Forgery (CSRF) cuando:
1. Una aplicación web utiliza cookies de sesión.

2. La aplicación actúa en una solicitud de HTTP sin verificar si la solicitud se realizó con el consentimiento del usuario.

De forma predeterminada, las páginas de Visualforce se representan con campos de formulario ocultos que sirven como tokens anti-CSRF. Estos tokens se incluyen en las solicitudes que se envían desde dentro de la página y el servidor verifica la validez de los tokens antes de ejecutar los métodos o comandos de acción correspondientes. Sin embargo, esta defensa integrada no se aplica a los métodos de acción de página ni a los constructores de controladores de página personalizados porque se ejecutan antes de que se generen los tokens anti-CSRF durante la carga de la página.

Ejemplo 1: La siguiente página de Visualforce declara un controlador personalizado MyAccountActions y un método de acción de página pageAction(). El método pageAction() se ejecuta al visitar la URL de la página y el servidor no comprueba los 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;
        }
    }
    ...
}

Un atacante podría configurar un sitio web malintencionado que contuviese el siguiente código:

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

Si un administrador de la página de Visualforce visita la página malintencionada mientras tiene una sesión activa en el sitio, borrará involuntariamente cuentas para el atacante.

Las solicitudes HTTP deben contener un secreto específico de usuario para evitar que un atacante realice solicitudes no autorizadas.

Una vulnerabilidad de falsificación de solicitud entre sitios (CSRF) ocurre cuando:
1. Una aplicación web utiliza cookies de la sesión.

2. La aplicación actúa con una solicitud de HTTP sin verificar si la solicitud se realizó con el consentimiento del usuario.



Un nonce es un valor aleatorio criptográfico que se envía con un mensaje para evitar ataques de reproducción. Si la solicitud no contiene un nonce que demuestre su procedencia, el código que maneja la solicitud es vulnerable a un ataque CSRF (a menos que no cambie el estado de la aplicación). Esto significa que una aplicación web que utiliza cookies de sesión debe tomar precauciones especiales para garantizar que un atacante no pueda engañar a los usuarios para que envíen solicitudes falsas. Imagine una aplicación web que permita a los administradores crear nuevas cuentas de la siguiente manera:

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

Un atacante podría configurar un sitio web malicioso que contuviese el siguiente 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);

Si un administrador de example.com visita la página malintencionada mientras tiene una sesión activa en el sitio, creará sin quererlo una cuenta para el usuario malintencionado. Esto es lo que se denomina un ataque CSRF. Este ataque es posible porque la aplicación no tiene forma de determinar la procedencia de la solicitud. Todas las solicitudes podrían ser acciones válidas elegidas por el usuario o acciones engañosas llevadas a cabo por un atacante. El atacante no ve la página web que la solicitud falsa genera, por lo que esta técnica de ataque solo es útil para las solicitudes que alteran el estado de la aplicación.

Las aplicaciones que pasan el identificador de sesión en la URL en lugar de hacerlo en una cookie no tienen problemas de CSRF, ya que no hay forma de que el usuario malintencionado acceda al identificador de sesión y lo incluya como parte de la solicitud falsa.

La aplicación de Django no permite la protección del software intermedio de CSRF.

Una vulnerabilidad de falsificación de solicitud entre sitios (CSRF) ocurre cuando:
1. Una aplicación web utiliza cookies de la sesión.

2. La aplicación actúa con una solicitud de HTTP sin verificar si la solicitud se realizó con el consentimiento del usuario.

Un nonce es un valor criptográfico aleatorio que se envía con un mensaje para prevenir ataques de reproducción. Si la solicitud no contiene un nonce que demuestre su procedencia, el código que administra la solicitud será vulnerable a un ataque de CSRF (a menos que no modifique el estado de la aplicación). Esto implica que una aplicación web que utilice cookies de sesión debe tomar precauciones especiales para garantizar que un atacante no pueda engañar a los usuarios para que envíen solicitudes falsas. Imagine una aplicación web que permite a los administradores crear cuentas nuevas enviando este formulario:

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

Un atacante podría establecer un sitio web con lo siguiente:

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

Si un administrador de example.com visita la página malintencionada mientras tiene una sesión activa en el sitio, creará sin quererlo una cuenta para el usuario malintencionado. Esto es lo que se denomina un ataque CSRF. Este ataque es posible porque la aplicación no tiene forma de determinar la procedencia de la solicitud. Todas las solicitudes podrían ser acciones válidas elegidas por el usuario o acciones engañosas llevadas a cabo por un atacante. El atacante no ve la página web que la solicitud falsa genera, por lo que esta técnica de ataque solo es útil para las solicitudes que alteran el estado de la aplicación.

Las aplicaciones que pasan el identificador de sesión en la URL en lugar de hacerlo en una cookie no tienen problemas de CSRF, ya que no hay forma de que el usuario malintencionado acceda al identificador de sesión y lo incluya como parte de la solicitud falsa.

Las solicitudes HTTP deben contener un secreto específico de usuario para evitar que un atacante realice solicitudes no autorizadas.

Una vulnerabilidad Cross-Site Request Forgery (CSRF) ocurre cuando:
1. Una aplicación web utiliza cookies de sesión.

2. La aplicación actúa en una solicitud de HTTP sin verificar si la solicitud se realizó con el consentimiento del usuario.

Un nonce es un valor criptográfico aleatorio que se envía con un mensaje para prevenir ataques de reproducción. Si la solicitud no contiene un nonce que demuestre su procedencia, el código que administra la solicitud será vulnerable a un ataque de CSRF (a menos que no modifique el estado de la aplicación). Esto implica que una aplicación web que utilice cookies de sesión debe tomar precauciones especiales para garantizar que un atacante no pueda engañar a los usuarios para que envíen solicitudes falsas. Imaginemos una aplicación web que permite a los administradores crear cuentas nuevas de la siguiente forma:

De forma predeterminada, Play Framework agrega protección frente a CSRF, pero se puede deshabilitar de forma global o para determinadas rutas.

Ejemplo 1: La definición de ruta siguiente deshabilita la protección CSRF para el método de controlador buyItem.

+ nocsrf
POST    /buyItem     controllers.ShopController.buyItem

Si un usuario engañado visita una página malintencionada mientras tiene una sesión activa en shop.com, comprará sin quererlo artículos para el atacante. Esto es lo que se denomina un ataque CSRF. Este ataque es posible porque la aplicación no tiene forma de determinar la procedencia de la solicitud. Todas las solicitudes podrían ser acciones válidas elegidas por el usuario o acciones engañosas determinadas por un atacante. El atacante no ve la página web que la solicitud falsa genera, por lo que esta técnica de ataque solo es útil para las solicitudes que alteran el estado de la aplicación.

Las aplicaciones que pasan el identificador de sesión en la URL en lugar de hacerlo en una cookie no tienen problemas de CSRF, ya que no hay forma de que el atacante acceda al identificador de sesión y lo incluya como parte de la solicitud falsa.

Los envíos de formularios deben contener un secreto específico del usuario para impedir que los atacantes realicen solicitudes no autorizadas.

Una vulnerabilidad de falsificación de solicitud entre sitios (CSRF) ocurre cuando:
1. Una aplicación web utiliza cookies de la sesión.

2. La aplicación actúa con una solicitud de HTTP sin verificar si la solicitud se realizó con el consentimiento del usuario.



Un nonce es un valor criptográfico aleatorio que se envía con un mensaje para prevenir ataques de reproducción. Si la solicitud no contiene un nonce que demuestre su procedencia, el código que administra la solicitud será vulnerable a un ataque de CSRF (a menos que no modifique el estado de la aplicación). Esto implica que una aplicación web que utilice cookies de sesión debe tomar precauciones especiales para garantizar que un atacante no pueda engañar a los usuarios para que envíen solicitudes falsas. Imagine una aplicación web que permite a los administradores crear cuentas nuevas enviando este formulario:

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

Un atacante podría establecer un sitio web con lo siguiente:

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

Si un administrador de example.com visita la página malintencionada mientras tiene una sesión activa en el sitio, creará sin quererlo una cuenta para el usuario malintencionado. Esto es lo que se denomina un ataque CSRF. Este ataque es posible porque la aplicación no tiene forma de determinar la procedencia de la solicitud. Todas las solicitudes podrían ser acciones válidas elegidas por el usuario o acciones engañosas llevadas a cabo por un atacante. El atacante no ve la página web que la solicitud falsa genera, por lo que esta técnica de ataque solo es útil para las solicitudes que alteran el estado de la aplicación.

Las aplicaciones que pasan el identificador de sesión en la URL en lugar de hacerlo en una cookie no tienen problemas de CSRF, ya que no hay forma de que el usuario malintencionado acceda al identificador de sesión y lo incluya como parte de la solicitud falsa.