Cross-Site Request Forgery

Visualforce 页面操作方法或控制器构造函数在未提供针对未经授权的请求的防护的情况下执行敏感任务。

Cross-Site Request Forgery (CSRF) 漏洞会在以下情况下发生：
1.Web 应用程序使用会话 Cookie。

2.应用程序未验证请求是否经过用户同意便处理 HTTP 请求。

默认情况下，Visualforce 页面以隐藏的表单字段呈现，这些字段用作反 CSRF 令牌。这些令牌包含在从页面内发送的请求中，服务器会在执行相应的操作方法或命令之前检查令牌的有效性。但是，此内置防御不适用于页面操作方法和自定义页面控制器构造函数，因为它们是在页面加载期间生成反 CSRF 令牌之前执行的。

示例 1：以下 Visualforce 页面声明了一个自定义控制器 MyAccountActions 和一个页面操作方法 pageAction()。该 pageAction() 方法在访问页面 URL 时执行，且服务器不会检查是否存在反 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;
        }
    }
    ...
}

攻击者可以设置一个包含以下代码的恶意网站：

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

如果 Visualforce 页面的管理员在网站上具有活动会话时访问了恶意页面，则他们会在毫不知情的情况下为攻击者删除帐户。

HTTP 请求必须包含用户特定的密码，以防止攻击者发出未经授权的请求。

跨站点伪装请求 (CSRF) 漏洞会在以下情况下发生：
1. Web 应用程序使用会话 cookie。

2. 应用程序未验证请求是否经过用户同意便处理 HTTP 请求。



nonce 是加密随机值，随消息发送，以防止转发攻击。如果请求中不包含证明其来源的 nonce，则用来处理该请求的代码容易受到 CSRF 攻击（除非请求不改变应用程序的状态）。这意味着使用会话 Cookie 的 Web 应用程序必须采取特殊的预防措施，以确保攻击者无法诱骗用户提交虚假请求。假设某个 Web 应用程序允许管理员新建帐户，如下所示：

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

攻击者可以设置一个包含以下代码的恶意网站。

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

如果 example.com 的管理员在网站上具有活动会话时访问了恶意页面，则会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。

如果应用程序通过 URL 传递会话标识符（而不是 cookie），则不会出现 CSRF 问题，因为攻击者无法访问会话标识符，也无法在伪请求中包含会话标识符。

Django 应用程序不启用 CSRF 中间件保护

跨站点伪装请求 (CSRF) 漏洞会在以下情况下发生：
1. Web 应用程序使用会话 cookie。

2. 应用程序未验证请求是否经过用户同意便处理 HTTP 请求。

Nonce 是随消息一起发送的加密随机值，可防止 replay 攻击。如果该请求未包含证明其来源的 nonce，则处理该请求的代码将易受到 CSRF 攻击（除非它并未更改应用程序的状态）。这意味着使用会话 cookie 的 Web 应用程序必须采取特殊的预防措施，确保攻击者无法诱骗用户提交伪请求。假设有一个 Web 应用程序，它允许管理员通过提交此表单来创建新帐户：

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

攻击者可能会使用以下内容来建立一个网站：

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

如果 example.com 的管理员在网站上具有活动会话时访问了恶意页面，则会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。

如果应用程序通过 URL 传递会话标识符（而不是 cookie），则不会出现 CSRF 问题，因为攻击者无法访问会话标识符，也无法在伪请求中包含会话标识符。

HTTP 请求必须包含用户特定的密码，以防止攻击者发出未经授权的请求。

Cross-Site Request Forgery (CSRF) 漏洞会在以下情况下发生：
1. Web 应用程序使用会话 Cookie。

2. 应用程序未验证请求是否经过用户同意便处理 HTTP 请求。

随机数是随消息一起发送的加密随机值，可防止 Replay 攻击。 如果该请求不包含可证明其来源的随机数，则处理该请求的代码将易受到 CSRF 攻击（除非它并未更改应用程序的状态）。 这意味着使用会话 Cookie 的 Web 应用程序必须采取特殊的预防措施，确保攻击者无法诱骗用户提交伪请求。 假设有一个 Web 应用程序，它允许管理员创建新帐户，如下所示：

默认情况下，Play Framework 可抵御 CSRF 攻击，但是也可以全局或针对某些路由禁用。

示例 1：以下路由定义将禁用 buyItem 控制器方法的 CSRF 保护。

+ nocsrf
POST    /buyItem     controllers.ShopController.buyItem

如果用户在 shop.com 上具有活动会话时被诱骗访问了恶意网页，她会在毫不知情的情况下为攻击者购买物品。 这就是 CSRF 攻击。 正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。 任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。 攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。

如果应用程序通过 URL 传递会话标识符（而不是 Cookie），则不会出现 CSRF 问题，因为攻击者无法访问会话标识符，也无法在伪请求中包含会话标识符。

表单发布必须包含用户特有的机密，防止攻击者发出未经授权的请求。

跨站点伪装请求 (CSRF) 漏洞会在以下情况下发生：
1. Web 应用程序使用会话 cookie。

2. 应用程序未验证请求是否经过用户同意便处理 HTTP 请求。



Nonce 是随消息一起发送的加密随机值，可防止 replay 攻击。如果该请求未包含证明其来源的 nonce，则处理该请求的代码将易受到 CSRF 攻击（除非它并未更改应用程序的状态）。这意味着使用会话 cookie 的 Web 应用程序必须采取特殊的预防措施，确保攻击者无法诱骗用户提交伪请求。假设有一个 Web 应用程序，它允许管理员通过提交此表单来创建新帐户：

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

攻击者可能会使用以下内容来建立一个网站：

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

如果 example.com 的管理员在网站上具有活动会话时访问了恶意页面，则会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。

如果应用程序通过 URL 传递会话标识符（而不是 cookie），则不会出现 CSRF 问题，因为攻击者无法访问会话标识符，也无法在伪请求中包含会话标识符。