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 是與訊息一起傳送的加密隨機值，用於防止重複進行的攻擊。如果要求不包含其來源的證明，則負責處理要求的程式碼將容易受到 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 攻擊。這樣是有可能的，因為應用程式無法確定要求的來源。因此不論是使用者建立的或是由攻擊者建立的偽造操作，都會被視為合法的操作。攻擊者不會看到假造的要求所產生的網頁，所以這種攻擊技術只有對修改應用程式狀態的要求有用。

在 URL 中傳送階段作業識別碼而非當作 Cookie 的應用程式不會有 CSRF 問題，因為攻擊者沒有辦法存取階段作業識別碼做為假造的要求。

Django 應用程式不會啟用 CSRF 中介軟體保護

防禦跨網站偽造要求 (CSRF) 弱點會在以下情況中出現：
1. Web 應用程式使用了階段作業 Cookie。

2. 應用程式在回應 HTTP 要求時，沒有驗證該要求是否經使用者同意產生。

nonce 是與訊息一起傳送的加密隨機值，用於防止重複進行的攻擊。如果 HTTP 要求目前沒有包含其來源的證明，則負責處理 HTTP 要求的程式碼會容易受到 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 攻擊。這樣是有可能的，因為應用程式無法確定要求的來源。因此不論是使用者建立的或是由攻擊者建立的偽造操作，都會被視為合法的操作。攻擊者不會看到假造的要求所產生的網頁，所以這種攻擊技術只有對修改應用程式狀態的要求有用。

在 URL 中傳送階段作業識別碼而非當作 Cookie 的應用程式不會有 CSRF 問題，因為攻擊者沒有辦法存取階段作業識別碼做為假造的要求。

HTTP 要求必須包含特定使用者機密，以避免攻擊者作出未經授權的要求。

Cross-site request forgery (CSRF) 弱點會在以下情況中出現：
1. Web 應用程式使用了階段作業 Cookie。

2. 應用程式在回應 HTTP 要求時，沒有驗證該要求是否經使用者同意產生。

nonce 是與訊息一起傳送的加密隨機值，用於防止重複進行的攻擊。 如果要求不包含其來源的證明，則負責處理要求的程式碼將容易受到 CSRF 的攻擊 (除非它不改變應用程式的狀態)。 這代表使用階段作業 Cookie 的 Web 應用程式必須特別留意，以確保攻擊者沒辦法傳遞假造的要求去欺騙使用者。 想像若 Web 應用程式允許管理人員按如下方式建立新帳戶：

依預設，Play Framework 會新增保護來防範 CSRF，但也可全域或針對特定路徑予以停用。

範例 1：以下路徑定義停用 buyItem 控制項方法的 CSRF 保護。

+ nocsrf
POST    /buyItem     controllers.ShopController.buyItem

如果使用者在其 shop.com 的階段作業處於作用中狀態期間受騙而造訪惡意頁面，則該使用者會不知不覺地為攻擊者購買項目。 這就是 CSRF 攻擊。 這樣是有可能的，因為應用程式無法確定要求的來源。 因此任何要求可能是使用者選擇的合法操作，也可能是由攻擊者建立的偽造操作。 攻擊者不會看到假造的要求所產生的網頁，所以這種攻擊技術只有對修改應用程式狀態的要求有用。

在 URL 中傳送階段作業識別碼而非當作 Cookie 的應用程式不會有 CSRF 問題，因為攻擊者沒有辦法存取階段作業識別碼來將其作為假造的要求。

表單發佈必須包含特定使用者機密，以避免攻擊者作出未經授權的要求。

防禦跨網站偽造要求 (CSRF) 弱點會在以下情況中出現：
1. Web 應用程式使用了階段作業 Cookie。

2. 應用程式在回應 HTTP 要求時，沒有驗證該要求是否經使用者同意產生。



nonce 是與訊息一起傳送的加密隨機值，用於防止重複進行的攻擊。如果 HTTP 要求目前沒有包含其來源的證明，則負責處理 HTTP 要求的程式碼會容易受到 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 攻擊。這樣是有可能的，因為應用程式無法確定要求的來源。因此不論是使用者建立的或是由攻擊者建立的偽造操作，都會被視為合法的操作。攻擊者不會看到假造的要求所產生的網頁，所以這種攻擊技術只有對修改應用程式狀態的要求有用。

在 URL 中傳送階段作業識別碼而非當作 Cookie 的應用程式不會有 CSRF 問題，因為攻擊者沒有辦法存取階段作業識別碼做為假造的要求。