02. SOP 원칙 및 Client Side Attack

SOP(Same Origin Policy)

브라우저는 웹 리소스를 통해 간접적으로 타 사이트에 접근할 때도 인증 정보인 쿠키를 함께 전송하는 특징을 가지고 있다. 따라서, 클라이언트 입장에서는 가져온 데이터를 악의적인 페이지에서 읽을 수 없도록 해야 한다. 따라서 타 사이트에 접근해 읽어 올 때, 해당 사이트가 같은 출처 (Same Origin)인지 검사한다. 이것이 바로 브라우저의 보안 메커니즘인 동일 출처 정책 (Same Origin Policy, SOP) 이다. 악성 데이터를 읽어오는 것이 문제 이므로 다른 출처의 사이트를 쓰는 행위는 규제하지 않는다.

Same Origin은 URL의 프로토콜, 포트, 호스트가 모두 같을 때 Same Origin이라 한다.

프로토콜은 앞서 말한 http / https 를 말하며 호스트는 사이트의 주소를 말한다. (https://naver.com의 naver.com) 포트는 호스트 뒤에 붙는 포트 번호를 말한다. 이들이 모두 같을 때 데이터를 읽어 올 수 있도록 규제한다.

하지만 이 규제가 완화된 경우가 두 가지가 있는데, 첫 번째는 <img>, <style>, <script>의 태그이다. 해당 태그들의 src 혹은 onerror와 같은 조건에 동일 출처가 아닌 URL을 넣어도 규제하지 않는다. 따라서 해당 취약점을 이용하는 방법이 뒤에 설명할 XSS, CSRF이다.

두 번째는 교차 출처 리소스 공유(CORS)이다. 다른 출처의 데이터를 사용해야 하는 경우도 있기 때문에 CORS와 관련된 HTTP 헤더를 추가해 전송하거나 JSONP방법을 사용한다. 헤더에 추가하는 방식은 발신측에서 CORS 헤더를 설정해 요청하면, 수신측에서 헤더를 구분해 정해진 규칙에 맞게 데이터를 가져갈 수 있도록 설정한다. 맨 처음 요청할 때 preflight으로 수신측에 웹리소스를 요청해도 되는지 질의 후 응답 결과를 보고 이후 데이터를 요청한다. (해킹 문제에 나올 순 없는데 웹개발 관련 정보로 알고 있으면 좋겠다.) 

JSONP는 script태그로 cross origin을 callback 함수로 불러온다. (현재는 거의 사용하지 않음)

Header	설명
Access-Control-Allow-Origin	헤더 값에 해당하는 Origin에서 들어오는 요청만 처리합니다.
Access-Control-Allow-Methods	헤더 값에 해당하는 메소드의 요청만 처리합니다.
Access-Control-Allow-Credentials	쿠키 사용 여부를 판단합니다.
Access-Control-Allow-Headers	헤더 값에 해당하는 헤더의 사용 가능 여부를 나타냅니다.

Cross Site Scripting (XSS)

XSS 공격은 이용자가 입력한 내용을 웹서비스에서 받아들이고 출력 혹은 저장하는 기능에서 발생한다.

XSS는 발생 형태에 따라 4가지 종류로 구분된다.

종류	설명
Stored XSS	XSS에 사용되는 악성 스크립트가 서버에 저장되고 서버의 응답에 담겨오는 XSS
Reflected XSS	XSS에 사용되는 악성 스크립트가 URL에 삽입되고 서버의 응답에 담겨오는 XSS
DOM-based XSS	XSS에 사용되는 악성 스크립트가 URL Fragment에 삽입되는 XSS (Fragment는 서버 요청 / 응답에 포함되지 않는다.)
Universal XSS	클라이언트의 브라우저 혹은 브라우저의 플러그인에서 발생하는 취약점으로 SOP정책을 우회하는 XSS

1. Stored XSS서버의 데이터베이스 또는 파일 등의 형태로 저장된 악성 스크립트를 조회할 때 발생하는 XSS이다. 대표적으로 게시물과 댓글에 악성스크립트를 포함해 업로드하는 방식이 있다. 게시판에 게시물, 댓글을 업로드 할 때 <script> 태그를 사용해 이용자가 조회할 때 작동하도록 작성한다.
2. Reflected XSS서버가 악성스크립트가 담긴 요청을 할 때 발생한다. 게시판에서 게시물을 검색하기 위해 사용자가 입력한 검색어를 그대로 쿼리로 넣는 페이지가 있다고 하자. ex)제목이 hello인 글을 찾는 url이 http://xxxx.com/?search="hello" 이때 검색창에 악성 스크립트를 넣는다면 그대로 실행할 것이다.

Cross Site Request Forgery (CSRF)

CSRF는 임의로 탈취한 이용자의 권한으로 임의의 주소에 HTTP 요청을 보낼 수 있는 취약점이다.URL로 들어오는 argument로 GET 혹은 POST와 같은 HTTP method 를 사용한다면 해당 URL에 원하는 값을 넣어 요청 할 수 있다. Same origin에서 유저가 HTTP method를 수행하는 url을 open하도록 촉발시키는 방법으로는 몇 가지가 있다. 앞서 말한 img의 tag를 사용하고 src를 HTTP method를 수행하는 target url로 지정한다. 그리고 width, height를 0px로 지정한다면 사용자가 눈치채지 못하게 CSRF를 수행할 수 있다. JS script를 넣을 수 있다면 window.open을 활용해 target url을 새 창으로 열거나 현재 창의 주소를 location.href로 target url을 할당시키거나 location.replace함수를 사용해 변경할 수 있다.

 

XSS와 CSRF의 차이

공통점
두 개의 취약점은 모두 클라이언트를 대상으로 하는 공격이며, 이용자가 악성 스크립트가 포함된 페이지에 접속하도록 유도해야 한다.

차이점
XSS는 인증 정보인 세션 및 쿠키 탈취를 목적으로 하는 공격이며, 공격할 사이트의 오리진에서 스크립트를 실행시킨다.

CSRF는 이용자가 임의 페이지에 HTTP 요청을 보내는 것을 목적으로 하는 공격이다. 또한, 공격자는 악성 스크립트가 포함된 페이지에 접근한 이용자의 권한으로 웹 서비스의 임의 기능을 실행할 수 있다.