사이트 간 요청 위조
사이트 간 요청 위조(CSRF, Cross-Site Request Forgery)는 웹사이트 취약점 공격의 하나로, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위를 특정 웹사이트에 요청하게 하는 해킹 공격을 말한다. 크로스 사이트 요청 위조라고도 한다.
개요[편집]
사이트 간 요청 위조는 특정 웹사이트가 사용자의 웹 브라우저를 신용하는 상태를 노린 것이다. 일단 사용자가 웹사이트에 로그인한 상태에서 사이트 간 요청 위조 공격 코드가 삽입된 페이지를 열면, 공격 대상이 되는 웹사이트는 위조된 공격 명령이 믿을 수 있는 사용자로부터 발송된 것으로 판단하게 되어 공격에 노출된다. 사이트 간 요청 위조는 개별 링크와 폼이 사용자 별로 예측 가능한 토큰을 사용할 때 발생하는데, 예측 불가능한 토큰이 있다면 공격자는 요청 메시지를 변조할 수 없지만 예측 가능한 토큰이 있다면 공격자는 요청 메시지를 변조할 수 있다. 인증이나 세션, 쿠키 등 모든 웹사이트에서 인증된 사용자가 보내는 데이터는 정상적인 경로를 통한 파라미터 요청으로 판단한다. 즉, 정상적인 요청과 비 정상적인 요청을 구분하지 못한다.[1]
사이트 간 요청 위조는 일단 사용자가 웹사이트에 로그인한 상태에서 사이트 간 요청 위조 공격 코드가 삽입된 페이지를 열면 이후에는 사용자의 행동과 관계없이 사용자의 웹 브라우저와 공격 대상 웹사이트 간의 상호작용이 이루어져 다양한 공격이 가능하게 된다. 따라서 해당 공격 가능성이 존재한다는 것은 위험한 상태로 신속한 보안 조치가 필요한 상황이다.[2]
특징[편집]
공격방법[편집]
- 공격자는 게시판에 관리자가 관심을 가질 수 있는 제목으로 사이트 간 요청 위조 스크립트가 포함된 게시물을 등록한다.
- 관리자는 확인이 필요한 게시물로 파악하여, 사이트 간 요청 위조 스크립트가 포함된 게시물을 확인한다.
- 게시물을 읽은 관리자는 사이트 간 요청 위조 스크립트가 포함된 것을 알지 못한 채 게시물을 확인한다. 하지만 관리자의 권한으로 공격자가 원하는 사이트 간 요청 위조 스크립트 요청이 발생한다.
- 공격자가 원하는 사이트 간 요청 위조 스크립트 결과가 발생하여, 관리자와 사용자의 피해가 발생한다.[2]
사이트 간 스크립팅[편집]
사이트 간 스크립팅(XSS, Cross site Script)은 웹 애플리케이션에서 나타나는 취약점 중 하나로, 웹사이트 관리자가 아닌 이가 페이지에 악성 스크립트를 삽입할 수 있는 취약점이다. 주로 여러 사용자가 보게 되는 전자 게시판에 악성 스크립트가 담긴 글을 올리는 형태로 이루어진다. 이 취약점은 웹 애플리케이션이 사용자로부터 입력받은 값을 제대로 검사하지 않고 사용할 경우 나타난다. 이 취약점으로 해커가 사용자의 쿠키, 세션 등의 정보를 탈취하거나, 자동으로 비정상적인 기능을 수행하게 할 수 있다. 주로 다른 웹사이트와 정보를 교환하는 식으로 작동하므로 사이트 간 스크립팅이라고 한다.[3]
사이트 간 스크립팅은 공격 대상이 클라이언트(Client)인 반면, 사이트 간 요청 위조의 공격 대상은 사용자라는 점에서 차이가 있다.[4] 더 자세히 보면 사이트 간 요청 위조는 스크립트 언어가 포함된 게시물을 올려서 서버가 원하지 않는 행동을 하게 하는 기술이고, 사이트 간 요청 위조는 해커가 열어 놓은 웹사이트에 오게 URL을 숨겨놓고 그 URL 안에 오기 전 웹사이트에 쿠키값을 유지한 채 오게 하면 해커는 열어놓은 서버에서 그 쿠키값을 얻는 기술이다. 이렇게 사이트 간 스크립팅의 공격목적은 쿠키값 탈취, 사이트 간 요청 위조의 공격목적은 서버의 권한도용이라는 점에서도 차이점이 있다.[5]
대안[편집]
- 리퍼러(Referer) 체크 : 리퍼러는 체크는 백-엔드(Back-end) 단에서 해당 요청의 리퍼러를 확인하여 도메인이 일치하는지 검증하는 방법으로, 해당 정보는 파로스(Paros), 잡(Zap), 피들러(fiddler) 같은 프로그램으로 조작이 가능하지만 방법이 간단하여 소규모 웹사이트에 주로 이용된다. 일반적으로 리퍼러 체크만으로 대부분의 사이트 간 요청 위조 공격을 방어할 수 있다. 하지만 같은 도메인 내의 페이지에 사이트 간 스크립팅 취약점이 있는 경우 사이트 간 요청 위조 공격에 취약해질 수 있다. 도메인 단위 검증에서 좀 더 세밀하게 페이지 단위까지 일치하는지 검증하면 도메인 내의 타 페이지에서 사이트 간 스크립팅 취약점에 의한 사이트 간 요청 위조 공격을 방어 할 수 있다.[6]
- 시큐리티 토큰(Security Token) 사용
- 리퍼러 검증이 불가능한 환경이라면 시큐리티 토큰을 사용할 수 있다. 우선 사용자의 세션에 임의의 난수 값을 저장하고 사용자의 요청마다 해당 난수 값을 포함해 전송한다. 이후 백-엔드 단에서 요청을 받을 때마다 세션에 저장된 토큰 값과 요청 파라미터에 전달되는 토큰 값이 일치하는지 검증하는 방법이다. 이 방법도 결국 같은 도메인 내 사이트 간 스크립팅 취약점이 있다면 사이트 간 요청 위조 공격에 취약하다.
- 더블 서밋 쿠키(Double Submit Cookie) 검증
- 더블 서밋 쿠키 검증은 시큐리티 토큰 검증의 한 종류로 세션을 사용할 수 없는 환경에서 사용할 수 있는 방법입니다. 웹 브라우저의 동일 출처 정책(Same Origin Policy)으로 인해 자바스크립트에서 타 도메인의 쿠키 값을 확인 및 수정하지 못한다는 것을 이용한 방어기법이다. 스크립트 단에서 요청 시 난수 값을 생성하여 쿠키에 저장하고 동일한 난수 값을 요청하여 파라미터에 저장하여 서버로 전송한다. 서버 단에서는 쿠키의 토큰값과 파라미터의 토큰 값이 일치하는지 검사하면 된다. 서버에 따로 토큰값을 저장할 필요가 없어 위에서 살펴본 세션을 이용한 검증보다 개발 공수가 적은 편이다. 피싱 사이트에서는 도메인이 달라 쿠키에 값을 저장하지 못하므로 가능한 방어 기법이다.[6]
사례[편집]
- 옥션 개인정보 유출 사건
- 2008년 2월 국내 유명 경매 사이트인 옥션이 중국인 해커로부터 수만 명 회원들의 이름, 주민등록번호, 주소, 전화번호, 아이디, 계좌번호 등 개인정보를 해킹당했다. 당초 1,081만 명으로 파악되었던 피해자는 2010년 조사를 통해 당시 전체 회원인 1,864만 명의 개인정보가 유출된 사실을 파악했다. 옥션은 사건 이후 해킹 사실을 자진 신고하고 회원들에게 이를 알려 2차 피해 예방에 나선 바 있고 특히 개인정보침해센터 운영 및 안철수연구소 안티바이러스 프로그램 무상 배포 등으로 회원 정보 침해에 적극적으로 대응했다.[7]
각주[편집]
- ↑ nhojimin, 〈(Web) CSRF 공격 가능 여부〉, 《블로그스팟》, 2016-09-05
- ↑ 2.0 2.1 손우규, 〈CSRF(Cross Site Request Forgery) 공격 기법〉, 《티스토리》, 2018-08-12
- ↑ 위키백과 - https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9D%B4%ED%8A%B8_%EA%B0%84_%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8C%85
- ↑ 글쓰는 공학도 You Jing, 〈XSS와 CSRF의 차이점〉, 《티스토리》, 2017-07-25
- ↑ 혀비혀비, 〈XSS와 CSRF의 차이〉, 《네이버 블로그》, 2018-03-24
- ↑ 6.0 6.1 kkd927, 〈CSRF 공격이란? 그리고 CSRF 방어 방법〉, 《네이버 블로그》, 2018-03-30
- ↑ 김철현 기자, 〈옥션, 개인정보 유출 회원 총 1863만명〉, 《아시아경제》, 2010-03-25
참고자료[편집]
- 〈사이트 간 스크립팅〉, 《위키백과》
- 김철현 기자, 〈옥션, 개인정보 유출 회원 총 1863만명〉, 《아시아경제》, 2010-03-25
- 글쓰는 공학도 You Jing, 〈XSS와 CSRF의 차이점〉, 《티스토리》, 2017-07-25
- 혀비혀비, 〈XSS와 CSRF의 차이〉, 《네이버 블로그》, 2018-03-24
- kkd927, 〈CSRF 공격이란? 그리고 CSRF 방어 방법〉, 《네이버 블로그》, 2018-03-30
- 손우규, 〈CSRF(Cross Site Request Forgery) 공격 기법〉, 《티스토리》, 2018-08-12
같이 보기[편집]
