[Web Hacking] CSRF(Cross-Site Request Forgery) 취약점

 

 

CSRF(Cross-Site Request Forgery) 개념

 

CSRF(Cross-Site Request Forgery)는 XSRF 또는 사이트 간 요청 위조로 불린다.

이는 웹사이트 취약점 공격 기법이며, 사용자가 자신의 의지와는 무관하게 수정, 삭제, 등록 등 공격자가 의도한 행위를 특정 웹사이트에 요청하게 하는 공격이다.

 

CSRF와 XSS(Cross-Site Scripting)의 개념이 상당부분 비슷해 보이지만 각각 공격이 실행되는 위치에 차이를 두고 있다.

일반적으로 XSS는 클라이언트(PC)에서, CSRF는 서버 단에서 공격이 발생한다.

즉, XSS는 사용자의 정보를 탈취하는 것, CSRF는 위조한 요청을 서버에 보내 공격하는 것이 목적이다.

 

대표적으로 2008년에 유명 경매 사이트인 옥션에서 발생한 개인정보 유출 사건에서 CSRF 공격 기법이 포함되어 있었다.

 

...
<img src="http://auction.com/changeUserAcoount?id=admin&password=admin" width="0" height="0">
...

 

해커가 옥션 운영자에게 위와 같은 CSRF 공격 코드가 포함된 이메일을 전송하여 옥션 관리자 권한을 획득한 사건이다.

 

대표적으로 다음과 같은 시나리오로 CSRF 공격 기법을 사용할 수 있다.

 

CSRF(Cross-Site Request Forgery)

 

1. 공격자는 관리자 및 사용자가 관심을 가질 수 있는 제목으로 게시판에 CSRF 스크립트가 포함된 게시물을 업로드한다.

2. 관리자 및 사용자는 CSRF 스크립트가 포함된 게시물을 열람하지만, CSRF 스크립트가 포함되어 있다는 것을 알지 못한다.

3. 관리자 및 사용자 고유 권한으로 공격자가 원하는 CSRF 스크립트 요청이 발생한다.

4. 공격자가 원하는 CSRF 스크립트 결과가 발생하여, 관리자 및 사용자의 피해가 발생한다

 

---

 

CSRF 대응방안

 

[Referrer 검증]

Referrer은 HTTP Request header에 있는 정보로 요청한 페이지의 정보를 가지고 있는데, Back-end 단에서 Request의 Referrer을 확인하여 도메인이 일치하는지 검증하는 방법이다. 일반적으로 이 방법으로 대부분의 CSRF 공격을 방어할 수 있다.

 

그러나 같은 도메인 내 웹페이지에 XSS 취약점이 있는 경우에는 CSRF 공격에 취약해질 수 있다. 도메인 단위 검증에서 좀 더 세밀하게 페이지 단위까지 일치하는지 검증하면 도메인 내의 타 페이지에서의 XSS 취약점에 의한 CSRF 공격을 방어할 수 있다.

 

 

[CSRF Token(Security Token) 사용] [세션]

Referrer 검증이 불가한 환경이라면, 랜덤한 수인 Token을 사용자의 세션에 저장하여 사용자의 모든 요청(Request)에 해당 Token을 포함시켜 전송한다. 이후 Back-end 단에서 요청을 받을 때마다 세션에 저장된 토큰 값과 요청 파라미터에 전달되는 토큰 값이 일치하는지 검증하는 방법이다.

 

그러나 이 방법도 Referrer 검증 방법과 마찬가지로 같은 도메인 내에 XSS 취약점이 존재하면 CSRF 공격에 취약해진다.

 

아래는 샘플코드이다.

 

// 로그인시, 또는 작업화면 요청시 CSRF 토큰을 생성하여 세션에 저장한다.
session.setAttribute("CSRF_TOKEN",UUID.randomUUID().toString());

// 요청 페이지에 CSRF 토큰을 셋팅하여 전송한다
<input type="hidden" name="_csrf" value="${CSRF_TOKEN}" />

// 파라미터로 전달된 csrf 토큰 값
String param = request.getParameter("_csrf");
 
// 세션에 저장된 토큰 값과 일치 여부 검증
if (request.getSession().getAttribute("CSRF_TOKEN").equals(param)) { 
     return true;
} else {
     response.sendRedirect("/");
     return false;
}

 

 

[Double-Submit Cookie Pattern] [쿠키]

CSRF Token(Security Token)을 사용하는 방어 기법의 한 종류로 세션을 사용할 수 없는 환경에서 사용할 수 있는 방법이다. 웹브라우저의 Same Origin Policy로 인해 자바스크립트에서 공격자가 타 도메인의 Cookie 값을 확인 또는 수정하지 못한다는 것을 이용한 방어 기법이다.

 

1. 스크립트 단에서 요청 시 난수 값인 Token을 생성하여 Cookie에 저장하고 동일한 Token을 요청 파라미터(또는 헤더)에도 저장하여 서버로 전송한다.

2. 서버 단에서 Cookie의 Token 값과 파라미터(또는 헤더)의 Token 값이 일치하는지 검사한다.

 

서버에 따로 Token 값을 저장할 필요가 없다.

 

다만, Same Origin Policy로 인해 다른 도메인으로부터 Cookie 값에 접근할 수는 없지만 이는 완전하다고 할 수는 없다.

서브도메인을 이용한 XSS 공격이나 http-equiv="set-cookie"와 같은 메타태그를 이용한 Cookie 값 조작에는 취약할 수 있다.

 

이를 예방하기 위해 https로 웹사이트를 구축하고 HSTS헤더값을 설정하여 모든 서브도메인에 적용시켜야 한다.

 

HSTS헤더란? [RFC 6797]
HTTP Strict Transport Security의 약자로 웹사이트 접속 시 https만 사용하도록 강제하는 기술이다.
HSTS가 적용된 웹사이트의 웹 서버는 클라이언트에게 HTTPS만을 사용할 수 있음을 알려주고, HSTS를 지원하는 브라우저는 이를 해석하고 적용한다. 최신 버전의 브라우저들은 대부분 HSTS를 지원한다.

 

 

[CAPTCHA 인증]

CAPTCHA 이미지 상의 문자, 숫자를 인증하지 못하면 해당 요청을 거부한다.

 

 

 

[참고]

https://itstory.tk/entry/CSRF-공격이란-그리고-CSRF-방어-방법

https://swk3169.tistory.com/24?category=712648

https://velog.io/@jeong3320/CSRF-공격

https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html