티스토리 뷰
발생일: 2014.12.12
키워드: XSS, XSRF, CSRF
문제:
JSON WebToken 에 관련된 아티클을 읽다가 토큰이 쿠키보다 나은 이유에 다음과 같은 항목이 있었다.
"It's easier to deal with XSS than XSRF"
가만...
XSS는 크로스 사이트 스크립팅인데, XSRF는 뭐였더라.
크로스 사이트 리… 포… 뭐였는데...
이 두 개는 봐도봐도 헷갈린다.
이 참에 까먹지 않게 잘 정리해두자.
해결책:
XSRF: Cross-Site Request Forgery
XSRF 라고도 하고, CSRF 라고도 한다.
쿠키만으로 인증하는 서비스의 취약점을 이용해, 사용자가 모르게 해당 서비스에 특정 명령을 요청하는 공격
예:
- 사용자가 쿠키만으로 인증하고 있는 A 사이트에 로그인한다.
- 사용자가 B 사이트에서 XSRF 공격 코드를 만난다. (예: A 사이트의 API를 호출하는 이미지 태그)
- 쿠키는 페이지가 다르더라도 요청 URL이 같다면 요청되기 때문에 해당 요청은 유효하게 처리된다.
취약점 시나리오 예:
- A 사이트의 주소를 http://site-a.com 이라고 해보자. A 사이트는 쿠키로 인증한다고 가정한다.
- A 사이트의 출석체크 API인, `/api/attendance` 는 GET 요청을 허용한다고 가정해보자.
- 사용자가 A 사이트에서 로그인 후, A 사이트와 전혀 관계 없는 B 사이트로 이동했다.
- 만약 사용자가 B 사이트에서 `<img src="http://site-a.com/api/attendance">`와 같은 이미지 태그를 만났다면, A 사이트에 출석체크가 된다.
방어:
- GET 요청에 쓰기 작업을 할당하지 않는다.
- 유효한 API 콜인지 확인한다. 요청 헤더를 활용하면 쉽게 해결할 수 있다. (예를 들면, 레퍼러를 체크거나, X-Requested-With 헤더가 있는지 확인)
- 인증 정보를 쿠키 대신 헤더로 보낸다. (인증 쿠키를 읽어서 자바스크립트 헤더로 보내는 방식)
XSS: Cross-Site Scripting
특정 사용자의 페이지에 스크립트를 추가하는 방식
예:
- 게시판 댓글에 `<script>alert(1);</script>`와 같이 스크립트 태그를 작성한다.
- 스크립트가 실행되면, 자바스크립트로 접근 가능한 정보를 취약 사이트로 전송할 수 있다.
- document.cookie 와 같은 쿠키 정보 뿐 아니라, 서비스에서 사용하는 자바스크립트 객체에 저장된 데이터도 전송할 수 있다.
방어:
- 페이지를 렌더링할 때 불필요한 태그를 이스케이프하는 것으로 방어할 수 있다.
참고:
반응형
댓글
공지사항