-
Cross-site Request Forgery (CSRF)concept/server 2020. 11. 1. 21:36
educative 를 번역, 요약한 자료입니다.
What is CSRF?
Cross-site Request Forgery의 약자로서, 유저가 브라우저에 로그인된 상태에서 원치 않은 액션을 실행시키도록 브라우저를 속이는 것이다.
해커가 로그인한 유저의 동의없이 실행시키도록 만들 수 있다.
CSRF 공격에서 해커는 응답에 접근할 수 없기 때문에 데이터에도 접근할 수가 없다.
또한 해커가 유저에게 은행 웹사이트에서 자금을 이전하거나 민감한 정보를 공유하도록 강요할 수 있기에 파괴적일 수 있다.
How does CSRF work?
CSRF 공격을 실시하기 위해서는 몇 가지 조건이 충족되어야 한다.
- Cookie-based session handling
: 유저는 이미 웹사이트에 로그인되어 있는 상태로 공격을 당하기 때문에 웹사이트는 유저를 식별하기 위해서 쿠키에 의존한다. - Request 파라미터를 예측할 수 없음
: Request가 악성 액션에 의해서 실행되기 때문에 해커가 예측할 수 없는 파라미터가 있으면 안된다.
예를 들어, 유저의 자금을 융통할 때 해커는 유저의 비밀번호를 알 필요가 없어야 한다.
Get 요청을 사용한 CSRF 공격
다음은 Get 요청을 이용한 CSRF 공격의 예시이다.
Bob이라는 사용자가 ABC은행의 고객이라고 가정했을 때, 그는 은행의 웹사이트에 로그인되어 있다.
이것은 현재 세션이 활성화되어 있고 쿠키에서 로그인 정보가 유지된다는 것을 의미한다.
그리고 자금 이체를 위한 Get 요청이 다음과 같이 실행된다고 가정해보자.GET http://abcbank.com/transfer.do?acct=Bob&amount=$500 HTTP/1.1해커는 해커의 계정 세부 정보가 제공될 요청을 생성한다.
GET http://abcbank.com/transfer.do?acct=attacker&amount=$500 HTTP/1.1무엇이 변했는가? Bob이 attacker로 바뀐 것을 알 수 있다.
해커가 이렇게 작성한 Get 요청으로 Bob이 자신의 브라우저에서 이 요청을 보내도록 속이는 것이다.
어떻게? 해커가 유저에게 보낼 프로모션 이메일을 만들어 다음 링크를 심어놓는다.<a href="http://abcbank.com/transfer.do?acct=attackerA&amount=$500">Get the offer!</a>유저가 이 링크를 클릭하면 거래가 이루어지고 해커의 계좌로 돈이 이체된다.
보다시피 이 공격이 성공하려면 유저가 이미 로그인되어 있어야 한다.
그렇지 않으면 유저는 링크를 클릭했을 때 로그인하라는 단계를 거치게 될 것이고 이 링크를 의심하게 될 것이다.POST 요청을 이용한 CSRF공격
그런데 GET 요청은 status 변경에 사용될 수 없다.
일반적으로 status 변경 작업은 POST 요청을 통해서 수행된다.
POST의 경우 GET 요청처럼 유저의 브라우저가 URL로 전송하는 것이 아니라, request body에 파라미터와 값을 전송한다.
그러므로 POST 요청으로 유저를 속이기는 어렵다. GET 요청으로 해커는 피해유저에게 필요한 모든 정보가 담긴 URL을 보내기만 하면 된다. 하지만 POST의 경우에는 request body에 내용을 첨부해야 한다.
해커는 웹사이트를 만들고 거기에 자바스크립트 코드를 추가할 수 있다. 그 다음 그들은 피싱 이메일을 통해서 이 웹사이트의 링크를 사용자에게 보낼 것이다.
유저가 이메일을 클릭하면 해커가 만든 악성 웹사이트가 은행 어플리케이션으로 POST요청을 보낼 것이다.
사용자가 만든 악성 웹사이트의 코드는 다음과 같다.
<body onload="document.csrf.submit()"> <form action="http://abcbank.com/transfer" method="POST" name="csrf"> <input type="hidden" name="amount" value="500"> <input type="hidden" name="account" value="attacker"> </form>이렇게 페이지가 로드되자마자, 즉시 숨겨진 위의 form이 제출되고 이 form 은 차례로 POST요청을 전송한다.
Methods to prevent CSRF attacks
1. Using CSRF tokens
anti-CSRF 토큰, synchronizer 토큰이라고도 불리는 것이다.
anti-CSRF 토큰은 서버 측 CSRF 보호의 일종이다. 그것은 사용자의 브라우저와 웹 애플리케이션에만 알려진 random string이다.
실행 방식은 다음과 같다.
-
요청이 서버로 보내지면, 토큰을 만들고 저장한다.
-
토큰은 양식의 숨겨진 필드로 정적으로 설정된다.
-
유저가 양식을 submit 할 때, 토큰은 POST 요청에 포함된다.
-
애플리케이션은 서버에서 생성, 저장되어 있는 토큰과 유저가 request 한 토큰을 비교한다.
-
이 토큰이 일치하면 request가 유효한 것이고 그렇지 않으면 해당 request는 거절된다.
이제 해커가 악의적인 POST 요청을 생성하더라도 해커가 그 토큰이 무엇인지 인지하지 못할 것이므로 토큰을 추가할 수 없다.
2. Same site cookies
쿠키의 same site flag는 CSRF 공격을 방지하고 웹 애플리케이션 보안을 향상시키는 비교적 새로운 방법이다.
위의 방법에서 알수있듯이 해커는 피싱 공격을 통해 사용자가 POST를 클릭할 때 POST요청을 보내는 다른 웹사이트를 만든다.만약, 세션 쿠키가 same site cookies로 표시된 경우, 동일한 도메인에서 발생한 요청과 함께 전송된다. 따라서 유저가 해커가 제공한 악성 웹사이트 링크를 클릭해도 도메인이 다르기 때문에 쿠키가 전송되지 않는다.
Best practices to avoid a CSRF-attack
CSRF 공격으로부터 유저가 방어할 수 있는 방법은 조금 있다.
-
작업이 끝나면 항상 웹사이트에서 로그아웃하라. 이렇게 하면 세션이 끊기고 쿠키가 삭제된다.
-
여러 웹사이트를 동시에 사용하지 않도록 하라. 한 브라우저 탭의 웹 사이트에 로그인한 상태에서 다른 탭의 악성 웹사이트를 사용하는 경우 CSRF 공격 가능성이 증가된다.
-
브라우저가 암호를 기억하도록 허용하지 말 것
'concept > server' 카테고리의 다른 글
OAuth - Authorization Code Grant Type (0) 2020.11.02 OAuth 2.0 Intro, 용어 (0) 2020.11.02 Cross-site Scripting Attack (XSS) (0) 2020.11.01 이 문제들을 다 풀면 session 이해 완료! (0) 2020.07.12 Server & Node 알고 넘어가야 할 요점 정리 (0) 2020.06.11 - Cookie-based session handling