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.

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.
CSRF es la entrada situada en la posición cinco de la lista de las diez vulnerabilidades principales de OWASP 2007.

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.

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

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.

CSRF es la entrada situada en la posición cinco de la lista de las diez vulnerabilidades principales de OWASP 2007.

El secuestro WebSocket entre dominios tiene lugar cuando se engaña a un usuario para que visite un sitio malintencionado que establecerá una conexión WebSocket con un servidor de back-end legítimo. La solicitud HTTP inicial utilizada para preguntar al servidor acerca de la actualización al protocolo WebSocket es una solicitud HTTP normal, por lo que el explorador enviará cualquier cookie enlazada al dominio objetivo, incluidas las cookies de sesión. Si el servidor no puede verificar el encabezado Origin, permitirá que cualquier sitio malintencionado suplante al usuario y establezca una conexión WebSocket bidireccional sin que el usuario se dé cuenta.

Se produce scripting de zonas basado en archivos cuando se cumplen las siguientes condiciones:

1. Se carga un archivo que permite la ejecución de scripts en su aplicación.


2. Se asume que el script cargado tiene el mismo origen que la aplicación en ejecución (file://).

Cuando se cumplen estas dos condiciones, se posibilita una serie de ataques, especialmente si otras partes determinan la confianza basándose en si la información procede de su aplicación.

Ejemplo 1: el código siguiente utiliza el método UIWebView.loadRequest(_:) para cargar un archivo local:

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

En el Example 1, el motor WebView considera que todo aquello cargado con UIWebView.loadRequest(_:) con una dirección URL que empiece por file:// procede del mismo archivo local con privilegios.

Un usuario malintencionado dispone de varias formas típicas de aprovechar una vulnerabilidad de scripting de zonas basado en archivos al cargar desde un archivo:

- El archivo local puede estar controlado por el atacante. Por ejemplo, el atacante puede enviar el archivo a su víctima, que lo almacena en la aplicación vulnerable (por ejemplo: una aplicación de almacenamiento en la nube).
- El archivo local puede ser manipulado por un usuario malintencionado, que puede inyectar scripts en el archivo. Esto dependerá de los permisos del archivo, de dónde se encuentra el archivo o de las condiciones de carrera donde un archivo se puede guardar y luego cargar (podría haber un margen de tiempo para la modificación).
- El archivo puede llamar a un recurso externo. Esto puede ocurrir cuando el archivo cargado recupera scripts de un recurso externo.
- El archivo cargado puede contener vulnerabilidades de Cross-Site Scripting. Si el archivo que se está cargando incluye código inyectado, dicho código podría ejecutarse en el contexto de su aplicación. No es necesario que el código inyectado sea de tipo JavaScript; el HTML inyectado también podría habilitar las desfiguraciones o los ataques por denegación de servicio.

Si el archivo controlado por el atacante se carga localmente con una dirección URL file://, la política del mismo origen permitirá que los scripts de este archivo accedan a cualquier otro archivo del mismo origen, lo que puede permitir que un atacante acceda a cualquier archivo local que contenga información confidencial.

Se produce scripting de zonas basado en archivos cuando se cumplen las siguientes condiciones:

1. Se carga un archivo que permite la ejecución de scripts en su aplicación.


2. Se asume que el script cargado tiene el mismo origen que la aplicación en ejecución (file://).

Cuando se cumplen estas dos condiciones, se posibilita una serie de ataques, especialmente si otras partes determinan la confianza basándose en si la información procede de su aplicación.

Ejemplo 1: el código siguiente utiliza el método UIWebView.loadRequest(_:) para cargar un archivo local:

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

En el Example 1, el motor WebView considera que todo aquello cargado con UIWebView.loadRequest(_:) con una dirección URL que empiece por file:// procede del mismo archivo local con privilegios.

Un usuario malintencionado dispone de varias formas típicas de aprovechar una vulnerabilidad de scripting de zonas basado en archivos al cargar desde un archivo:

- El archivo local puede estar controlado por el atacante. Por ejemplo, el atacante puede enviar el archivo a su víctima, que lo almacena en la aplicación vulnerable (por ejemplo: una aplicación de almacenamiento en la nube).
- El archivo local puede ser manipulado por un usuario malintencionado, que puede inyectar scripts en el archivo. Esto dependerá de los permisos del archivo, de dónde se encuentra el archivo o de las condiciones de carrera donde un archivo se puede guardar y luego cargar (podría haber un margen de tiempo para la modificación).
- El archivo puede llamar a un recurso externo. Esto puede ocurrir cuando el archivo cargado recupera scripts de un recurso externo.
- El archivo cargado puede contener vulnerabilidades de Cross-Site Scripting. Si el archivo que se está cargando incluye código inyectado, dicho código podría ejecutarse en el contexto de su aplicación. No es necesario que el código inyectado sea de tipo JavaScript; el HTML inyectado también podría habilitar las desfiguraciones o los ataques por denegación de servicio.

Si el archivo controlado por el atacante se carga localmente con una dirección URL file://, la política del mismo origen permitirá que los scripts de este archivo accedan a cualquier otro archivo del mismo origen, lo que puede permitir que un atacante acceda a cualquier archivo local que contenga información confidencial.