지난 강의에서
CSRF 공격에 대해 다뤘습니다
잘 이해되셨기를 바랍니다
이번 강의에서는 웹 애플리케이션으로
CSRF를 대처할 만한
해결방안에 대해 보겠습니다
CSRF 공격을 대처하기 위해서는
백엔드 애플리케이션이
들어오는 HTTP 요청이 정당한 유저에게 오고 있는지
혹은 해커에서 오는 건 아닌지
잘 구분할 줄 알아야 합니다
현재 백엔드 웹 애플리케이션은
이를 구분을 할 수 없습니다 왜냐하면 두 요청 모두
유효한 쿠키와 인증을 갖고 있기 때문입니다
그럴 수 있습니다
정당한 유저와 해커를 구분하기 위해서는
또 다른 토큰을 가져와
CSRF로 이름을 짓겠습니다
CSRF 토큰은 안전한 랜덤 토큰으로
많은 기업들이 CSRF 공격을 예방하기 위해
웹 애플리케이션에서 사용 중입니다
이 토큰은 엔드 유저의 세션마다 고유하게 할당되며
랜덤으로 큰 값을 지정합니다
그러니 알아맞추기 매우 어렵습니다
CSRF 토큰이 있으면
백엔드 서버는
정당한 유저와 해커를 구분하지만
CSRF 토큰이 어떻게 CSRF 공격을 예방하는지
알아보도록 하겠습니다
같은 상황을 떠올려 보겠습니다
이번에는 내 백엔드 웹 애플리케이션에
CSRF 토큰 해결책을 적용해놓은 상황입니다
마찬가지로 금요일 밤에
netflix.com를 열고
자격증명를 입력했습니다
하지만 이번에는 netflix.com이
인증 정보와 관련된 쿠키와 함께
백엔드에서 CSRF 토큰을 랜덤으로 생성하고
동일하게 UI 애플리케이션 보내졌습니다
CSRF 토큰 또한 쿠키로써 함께 보내졌습니다
하지만 백엔드에서 UI 애플케이션으로
CSRF 토큰을 갖고 소통을 하는 데에는
수많은 방법들이 있고
가장 흔한 방법은
CSRF 토큰을 쿠키 자체에 넣어서 전송하는 것입니다
그럼 브라우저는 넷플릭스 백엔드에서
두 개의 쿠키를 받습니다
하나는 인증 정보 관련 쿠키
하나는 CSRF 관련 쿠키
그리고 두 번째 단계로 가봅시다
두 번째 단계에서 제 엔드 유저가 evil.com에 접속했습니다
같은 브라우저의 창으로 말입니다
이번에도 evil.com이 같은 웹 페이지를 보냅니다
넷플릭스 계정의 이메일을 바꾸게 하는 코드가
잠복된 악성 링크가 담겨있습니다
이 잠복 링크 역시 유혹적입니다
아이폰 90% 할인 문구를 지나칠 수 없습니다
그리고 세 번째 단계에서 예상했듯이
제 엔드 유저가 악성 코드를 클릭합니다
그리고 코드 뒤에서 해커가
html이든 Java든 뭐든 사용해서
netflix.com에 요청을 보내려고 할 것입니다
엔드 유저의 이메일을 바꿔야 하기 때문입니다
요청이 netflix.com로 들어왔고
브라우저는 2개의 쿠키를 보냅니다
하나는 인증 쿠키
하나는 CSRF 토큰 쿠키
이번에는 netflix.com 백엔드 서버가
403 에러와 함께 요청을 거부합니다
그리고 해커는 CSRF 공격을 실행하지 못합니다
그럼 여기서 드는 의문은
브라우저가 두 개의 쿠키를 보내는데
어떻게 netflix.com 백엔드 서버는
이를 알아보고
정당한 유저인지 해커인지 구분을 하지? 입니다
여기에는 속임수가 있습니다
웹 애플케이션과 UI 애플리케이션 모두에 말입니다
로그인 동작에서
언제든 CSRF 토큰을 받으면
그 토큰을 쿠키 안에 저장합니다
하지만 브라우저의 도움을 받아
기본 형식으로 백엔드에서
쿠키를 보내는 게 아니라
UI 애플리케이션 안에 작은 코드를 써서
쿠키를 보내려면 수동으로 코드 읽어서
헤더나
내용(Body/Payload)에 보내야하고
아니면 백엔드 서버의 동의가 있어야 합니다
그리고 쿠키를 같은 도메인 netflix.com에서 읽기 때문에
JavaScript로 쿠키를 읽을 수 있어야 하고
HTML 코드를 통해서는
해커가 evil.com에서 하던 것을 할 수 없습니다
왜냐하면 evil.com에서
JavaScript 작업을 하려면
그는 evil.com의 JavaScript로 접속해야 하기 때문에
그러면 도메인이 CSRF 토큰의 쿠키에
접근하지 못합니다
제한이 생기면 해커는 헤더나
내용(payload)안에 토큰을 넣어 전송할 수 없습니다
해커는 쿠키가 브라우저의 백엔드에
자동으로만 전송되는 것에 의존했기 때문입니다
이번에는 내 백엔드 웹 애플리케이션이 똑똑해졌습니다
CSRF 토큰이 들어오지 않는 이상
브라우저는 요청을 수락하지 않을 것이며
UI 애플리케이션과의 동의가 된
내용(payload)이라도 있어야 합니다
이는 가장 흔하게 쓰이는 방법으로써
CSRF 토큰의 도움으로 CSRF 공격에 대처합니다
물론 다른 방법도 많겠지만
제가 추천해드리는 것은
어떻게 CSRF 토큰을 다루는지
앞선 예시 상황을 통해 잘 이해해보는 것입니다
그리고 방법을 웹 애플리케이션에
Spring Security를 통해 적용해보겠습니다
전에 말했듯이 CSRF를 완전히 비활성화하는
옵션도 있습니다
Spring Security 설정에서
csrf().disable()를 불러오는 방법입니다
하지만 그 옵션은 사용해서는 안 됩니다
더 낮은 환경의 애플리케이션이나
위험하지 않은 애플리케이션에서는 가능할지도 모릅니다
하지만 배포 수준의 웹 애플리케이션을 만들려고 한다면
절대 절대 시도하지 마십시오
여러분의 웹 애플리케이션 안에
수많은 CSRF 공격을 유인할 것입니다
그리고 그 CSRF 공격들 때문에
엔드 유저들이 많은 어려움을 겪게 될 것입니다
자 이제 CSRF 공격이 무엇인지
이에 대처하기 위해
고려해볼 수 있는 방법들은 무엇인지
확실히 이해하셨기를 바랍니다
다음 강의에서는
CSRF 공격에 대처하기 위한
방법들을 직접 웹 애플리케이션에 적용해보록 하겠습니다
감사합니다 다음 강의 때 뵙겠습니다
수고하셨습니다