Cross-Site Request Forgery

Visualforce 페이지 작업 메서드 또는 컨트롤러 생성자는 중요한 작업 수행 시 무단 요청으로부터 해당 작업을 보호하지 않습니다.

CSRF(Cross-Site Request Forgery) 취약점은 다음 경우에 발생합니다.
1. 웹 응용 프로그램이 세션 쿠키를 사용합니다.
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(cross-site request forgery) 취약점은 다음 경우에 발생합니다.
1. 웹 응용 프로그램이 세션 쿠키를 사용합니다.

2. 응용 프로그램이 해당 요청이 사용자의 동의 하에 이루어졌는지 확인하지 않고 HTTP 요청에 대해 작업합니다.



nonce는 재생 공격을 방지하기 위해 메시지와 함께 전송되는 암호화된 임의의 값입니다. 요청에 출처를 증명하는 nonce가 포함되어 있지 않으면 요청을 처리하는 코드가 CSRF 공격에 취약합니다(응용 프로그램 상태를 변경하지 않는 한). 즉, 세션 쿠키를 사용하는 웹 응용 프로그램은 공격자가 사용자를 속여 가짜 요청을 제출하지 못하도록 특별한 예방 조치를 취해야 합니다. 관리자가 다음과 같이 새 계정을 만들 수 있는 웹 응용 프로그램이 있다고 가정해 보십시오.

  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 공격입니다. 이는 응용 프로그램이 해당 요청의 출처를 확인하는 방법을 가지고 있지 않기 때문입니다. 모든 요청은 사용자가 선택한 적법한 작업이거나 공격자가 설정한 허위 작업일 가능성이 있습니다. 공격자는 허위 요청이 생성하는 웹 페이지를 보지 못하므로 이 공격 기법은 응용 프로그램의 상태를 변경하는 요청의 경우에만 유용합니다.

하지만 세션 ID를 쿠키가 아닌 URL에서 전달하는 응용 프로그램은 공격자가 세션 ID에 액세스하여 허위 요청의 일부로 포함시킬 방법이 없으므로 CSRF 문제가 발생하지 않습니다.
CSRF는 2007 OWASP Top 10 목록에서 제 5위입니다.

Django 응용 프로그램에서는 CSRF 미들웨어 보호가 활성화되지 않습니다.

CSRF(cross-site request forgery) 취약점은 다음 경우에 발생합니다.
1. 웹 응용 프로그램이 세션 쿠키를 사용합니다.

2. 응용 프로그램이 해당 요청이 사용자의 동의 하에 이루어졌는지 확인하지 않고 HTTP 요청에 대해 작업합니다.

Nonce는 재전송 공격을 막기 위해 메시지와 함께 전송된 암호화 무작위 값입니다. 요청에 출처를 증명하는 정보가 포함되어 있지 않은 경우, 해당 요청을 처리하는 코드는 CSRF 공격에 취약합니다(응용 프로그램의 상태를 변경하지 않는 경우 제외). 이는 공격자가 사용자로 하여금 허위 요청을 제출하도록 속이지 못하게 하려면 세션 쿠키를 사용하는 웹 응용 프로그램이 특별한 예방 조치를 취해야 한다는 의미입니다. 관리자가 다음과 같은 폼을 제출하여 새로운 계정을 생성하도록 허용하는 웹 응용 프로그램을 상상해 보십시오.

<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 공격입니다. 이는 응용 프로그램이 해당 요청의 출처를 확인하는 방법을 가지고 있지 않기 때문입니다. 모든 요청은 사용자가 선택한 적법한 작업이거나 공격자가 설정한 허위 작업일 가능성이 있습니다. 공격자는 허위 요청이 생성하는 웹 페이지를 보지 못하므로 이 공격 기법은 응용 프로그램의 상태를 변경하는 요청의 경우에만 유용합니다.

하지만 세션 ID를 쿠키가 아닌 URL에서 전달하는 응용 프로그램은 공격자가 세션 ID에 접근하여 허위 요청의 일부로 포함시킬 방법이 없으므로 CSRF 문제가 발생하지 않습니다.

HTTP 요청에는 공격자의 무단 요청을 막기 위한 사용자 특정 기밀이 포함되어 있어야 합니다.

CSRF(Cross-Site Request Forgery) 취약점은 다음 경우에 발생합니다.
1. 웹 응용 프로그램이 세션 쿠키를 사용합니다.

2. 응용 프로그램이 해당 요청이 사용자의 동의로 이루어졌는지 확인하지 않고 HTTP 요청에 대해 작업합니다.

Nonce는 재전송 공격을 막기 위해 메시지와 함께 전송된 암호화 무작위 값입니다. 요청에 출처를 증명하는 정보가 포함되어 있지 않은 경우, 해당 요청을 처리하는 코드는 CSRF 공격에 취약합니다(응용 프로그램의 상태를 변경하지 않는 경우 제외). 이는 공격자가 사용자로 하여금 허위 요청을 제출하도록 속이지 못하게 하려면 세션 쿠키를 사용하는 웹 응용 프로그램이 특별한 예방 조치를 취해야 한다는 의미입니다. 관리자가 다음과 같이 새로운 계정을 생성하도록 허용하는 웹 응용 프로그램을 상상해 보십시오.

기본적으로 Play Framework는 CSRF 차단을 추가하지만 전역으로 비활성화되거나 특정 경로에 대해 비활성화될 수 있습니다.

예제: 다음 경로 정의는 buyItem 컨트롤러 메서드에 대한 CSRF 차단을 비활성홥니다.

+ nocsrf
POST    /buyItem     controllers.ShopController.buyItem

사용자가 shop.com의 활성 세션에 있는 동안 악성 페이지를 방문하게 되면 의도치 않게 공격자의 물품을 구입하게 됩니다. 이것이 CSRF 공격입니다. 이 공격이 가능한 이유는 응용 프로그램에 해당 요청의 출처를 확인할 방법이 없기 때문입니다. 모든 요청은 사용자가 선택한 적법한 작업이거나 공격자가 설정한 허위 작업일 가능성이 있습니다. 공격자는 허위 요청이 생성하는 웹 페이지를 보지 못하므로 이 공격 기법은 응용 프로그램의 상태를 변경하는 요청의 경우에만 유용합니다.

하지만 세션 ID를 쿠키가 아닌 URL에서 전달하는 응용 프로그램은 공격자가 세션 ID에 액세스하여 허위 요청의 일부로 포함시킬 방법이 없으므로 CSRF 문제가 발생하지 않습니다.

폼 게시에는 공격자의 무단 요청을 막기 위한 사용자 특정 기밀이 포함되어 있어야 합니다.

CSRF(cross-site request forgery) 취약점은 다음 경우에 발생합니다.
1. 웹 응용 프로그램이 세션 쿠키를 사용합니다.

2. 응용 프로그램이 해당 요청이 사용자의 동의 하에 이루어졌는지 확인하지 않고 HTTP 요청에 대해 작업합니다.



Nonce는 재전송 공격을 막기 위해 메시지와 함께 전송된 암호화 무작위 값입니다. 요청에 출처를 증명하는 정보가 포함되어 있지 않은 경우, 해당 요청을 처리하는 코드는 CSRF 공격에 취약합니다(응용 프로그램의 상태를 변경하지 않는 경우 제외). 이는 공격자가 사용자로 하여금 허위 요청을 제출하도록 속이지 못하게 하려면 세션 쿠키를 사용하는 웹 응용 프로그램이 특별한 예방 조치를 취해야 한다는 의미입니다. 관리자가 다음과 같은 폼을 제출하여 새로운 계정을 생성하도록 허용하는 웹 응용 프로그램을 상상해 보십시오.

<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 공격입니다. 이는 응용 프로그램이 해당 요청의 출처를 확인하는 방법을 가지고 있지 않기 때문입니다. 모든 요청은 사용자가 선택한 적법한 작업이거나 공격자가 설정한 허위 작업일 가능성이 있습니다. 공격자는 허위 요청이 생성하는 웹 페이지를 보지 못하므로 이 공격 기법은 응용 프로그램의 상태를 변경하는 요청의 경우에만 유용합니다.

하지만 세션 ID를 쿠키가 아닌 URL에서 전달하는 응용 프로그램은 공격자가 세션 ID에 접근하여 허위 요청의 일부로 포함시킬 방법이 없으므로 CSRF 문제가 발생하지 않습니다.

CSRF는 2007 OWASP Top 10 목록에서 제 5위입니다.