반응형

0.개요

브라우저는 어플리케이션에 속한 스크립트와 제3자가 악의적으로 주입한 스크립트를 구분하지 못한다. 그래서 이것을 이용한 공격이 있는데, 그것은 바로 XSS(Cross Site Scripting) 취약점이다. 


해당 취약점에 대한 공격의 위험과 영향을 줄여주기 위해 브라우저에게 신뢰할 수 있는 데이터에 대한 허용 목록을 클라이언트에게 알려주는 CSP(Content Security Policy)에 대해 알아보도록 하겠다.




1. 소스 허용 목록

Content-Security-Policy HTTP 헤더를 통해 신뢰할 수 있는 데이터의 허용 목록을 클라이언트에 알려준다.

예를 들어 자기 자신과 rootable.tistory.com에서는 신뢰할 수 있는 컨텐츠가 제공될 것이라 믿을 경우, 다음과 같은 csp를 통해 코드의 출처가 다음 두 가지 소스 중 하나일 때만 스크립트 실행을 허용할 수 있다.

Content-Security-Policy: script-src 'self' https://rootable.tistory.com




2. 다양한 리소스 정책

csp가 스크립트 리소스에 대해 허용 목록을 제공하기 위해 만들어진 것이지만, 스크립트 뿐만 아니라 다양한 리소스에 대한 제어 정책 지시문도 제공하고 있다.


대표적으로 default-src 지시문을 통해 -src로 끝나는 모든 지시문에 대해 정책을 정의할 수 있다.

예를 들어 다음과 같은 정책이 있다고 가정해보자.

Content-Security-Policy: default-src https://rootable.tistory.com


만약 위와 같이 정책이 설정되어 있을 때 img-src, media-src를 따로 지정하지 않는다면 https://rootable.tistory.com에서만 이미지 로드, 미디어 로드가 가능하다.


이외에도 다음과 같은 지시문들이 더 존재한다.

 child-src

 삽입된 프레임 콘텐츠에 대한 URL 나열

 ex) child-src https://youtube.com → 다른 출처가 아닌 YouTube에서 가져온 동영상만 삽입 가능

 connect-src

 (XHR, WebSockets 및 EventSource를 통해) 연결할 수 있는 출처 제한

 form-action

 <form> 태그에서의 제출을 위해 유효한 End-Point 나열

 img-src

 이미지를 로드할 수 있는 출처 정의 

 media-src

 동영상과 오디오를 제공하도록 허용되는 출처 정의

 object-src

 플래시와 기타 플러그인에 대한 출처 정의


위 표는 많이 사용되는 것들 몇개만 나열한 것이므로, 자세한 것은 다음 사이트를 참고하길 바란다.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy




3. 소스 목록

3.1 직관적인 소스 목록

지시문에서 정의하는 소스는 단순히 나열할 수 있고, 각 지시문은 세미콜론( ; )을 통해 구분을 한다.


1) 스크립트 지시문 소스 나열

Content-Security-Policy: script-src https://rootable.tistory.com https://google.com


2) 지시문 나열

Content-Security-Policy: script-src https://rootable.tistory.com; child-src 'none'; object-src 'none'


3.2 소스 목록의 유연함

각 지시문의 소스 목록은 유연하게 작성할 수 있다.

data: , http: 와 같은 프로토콜 기준으로 소스 지정이 가능하며, 호스트 이름만으로도 가능하고, 포트까지 정의도 가능하다.

게다가 와일드 카드가 허용되지만, 프로토콜이나 포트, 호스트 이름의 맨 왼쪽 위치에서만 허용된다.


허용되는 부분에 와일드 카드를 적용한 것은 다음과 같은 형태이다.

*://*.tistory.com:*


3.3 키워드

소스 목록에서는 다음 4개의 키워드도 허용된다.


◎ 'none' : 아무것과도 일치하지 않음

◎ 'self' : 현재 출처와 일치, 하위 도메인은 일치하지 않음

◎ 'unsafe-inline' : 인라인 자바스크립트 및 CSS 허용

◎ 'unsafe-eval' :  eval과 같은 텍스트-자바스크립트 메커니즘 허용


이 때, 각 키워드는 작은 따옴표가 필요하다.

만약 script-src self로 작성할 경우, self가 키워드로써 작동하는 것이 아니라 self라는 이름의 서버에 존재하는 자바스크립트를 허용하도록 설정된다.




4. 활용 예시

1) 소셜 미디어 위젯

구글의 +1 버튼, Facebook의 Like 버튼, Twitter의 Tweet 버튼을 허용하기 위해서는 다음과 같은 CSP가 적용된다.

script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com


2) SSL 전용

모든 리소스를 보안 채널을 통해서만 로드하고 싶을 경우 다음과 같은 CSP로 가능하다.

default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'



(참고)

https://developers.google.com/web/fundamentals/security/csp?hl=ko#구현_세부정보

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web

반응형

'Hacking > Web' 카테고리의 다른 글

Liferay Portal RCE ( CVE-2020–7961 )  (0) 2020.08.14
XSS In event handler  (0) 2020.08.06
python deserialize vulnerability in pickle module  (1) 2020.07.26
Filter bypass Using Multipart form data  (0) 2020.05.08
SQL Injection where filter bypass  (2) 2020.04.23
블로그 이미지

rootable

,