CSP란?
Content Security Policy (CSP, 컨텐츠 보안 정책)는 웹 사이트 관리자가 웹 페이지에서 사용할 수 있는 콘텐츠 유형을 브라우저에게 지시하는 방식이다. CSP는 주로 XSS 공격을 방지하는 데 사용되며, 이 정책은 웹 페이지에서 실행할 수 있는 스크립트와 스타일, 이미지, 폰트 등의 자원을 제한함으로써 웹 사이트의 보안을 강화한다.
CSP의 주요 기능
- 출처 제한: CSP를 통해 웹 사이트는 스크립트, 스타일시트, 이미지, 폰트, AJAX 요청 등의 리소스가 로드될 수 있는 출처를 지정할 수있다. 이를 통해 불신할 수 있는 출처로부터의 콘텐츠를 차단한다.
- 인라인 스크립트 및 스타일의 제한: XSS 공격은 종종 인라인 스크립트를 통해 수행된다. CSP는 인라인 스크립트와 CSS의 사용을 제한하거나 금지하여 공격을 방지할 수 있다.
- 보고 기능: CSP는 보안 위반 사항을 서버에 보고할 수 있는 메커니즘을 제공한다. 이를 통해 웹 사이트 관리자는 보안 정책 위반 사항을 모니터링하고 적절한 조치를 취할 수 있다.
CSP 구현 방법
- HTTP 헤더: CSP는 주로 HTTP 헤더 'Content-Security-Policy'를 통해 구현된다. 웹 서버는 이 헤더를 웹 페이지와 함께 보내며, 브라우저는 지정된 정책에 따라 페이지를 처리한다.
- 메타 태그: 일부 경우에는 HTML 문서 내의 '<meta>' 태그를 사용하여 CSP를 구현할 수 있다.
Content-Security-Policy: default-src 'self'; img-src https://*; child-src 'none';
위 예시에서 default-src 'self' 는 모든 콘텐츠가 현재 출처에서만 로드되어야 함으로 지시하고, img-src https://*은 이미지가 HTTPS 프로토콜을 사용하는 모든 출처에서 로드될 수 있음을 허용한다. child-src 'none'은 iframe이나 프레임을 통한 콘텐츠의 로드를 금지한다.
CSP - Inline Code
CSP는 인라인 코드를 유해하다고 간주한다. 따라서 CSP를 사용할 때에는 기본적으로 인라인 코드를 사용할 수 없다. 인라인 코드는 태그의 src 속성으로 코드를 로드하지 안혹 태그 내에 직접 코드를 삽입하는 것을 의미한다.
CSP는 <script> 태그 내에 코드를 삽입하는 것을 포함하여 on 이벤트 핸들러 속성, javascript: 인 URL 스킴, CSS 스타일 시트 또한 인라인 코드로 간주하고 허용하지 않는다.
CSP - Eval
CSP는 기본적으로 문자열 텍스트를 실행 가능한 자바스크립트 코드 형태로 변환하는 메커니즘 또한 유해하다고 간주한다. 대표적인 예로 eval 함수가 있다.
eval, new Funtion(), setTimeout(), setInterval()과 같이 문자열 형태로 입력을 받는 함수의 실행은 모두 차단된다. 다만 해당 함수에 문자열 입력이 아닌 인라인 함수 형태로 파라미터가 전달될 때에는 차단되지 않는다.
Policy Directive
<Policy-directive>는 <directive> <value> 형태로 구성된다. <directive>는 지시문이라고 부르며, <value>는 directive에서 정의한 리소스의 출처를 정의한다.
자주 사용되는 지시문의 종류
지시문 | 설명 |
default-src | -src로 끝나는 모든 지시문의 기본 동작을 제어한다. 만약 CSP 구문 내에서 지정하지 않은 지시문이 존재한다면 default-src의 정의를 따라간다. |
img-src | 이미지를 로드할 수 있는 출처를 제어한다. |
sript-src | 스크립트 태그 관련 권한과 출처를 제어한다. |
style-src | 스타일시트 관련 권한과 출처를 제어한다. |
child -src | 페이지 내에 삽입된 프레임 컨텐츠에 대한 출처를 제어한다. |
base-uri | 페이지의 <base> 태그에 나타날 수 있는 URL을 제어한다. |
출처 종류
출처 | 설명 |
*://example.com | 출처의 scheme은 와일드카드를 이용해 표현할 수 있다. |
https://*.example.com | 출처의 호스트 서브도메인은 와일드카드를 이용해 표현할 수 있다. (단, 와일드카드는 호스트의 중간에 들어갈 수 없다. i.e) https://www.*.com, https://*.example.* |
https://example.com:* | 출처의 포트는 와일드카드를 이용해 표현할 수 있다. |
none | 모든 출처를 허용하지 않는다. |
self | 페이지의 현재 출처 내에서 로드하는 리소스만 허용한다. |
unsafe-inline | 예외적으로 인라인 코드의 사용을 허용한다. |
unsafe-eval | 예외적으로 eval과 같은 텍스트-자바스크립트 변환 메커니즘의 사용을 허용한다. |
nonce-<base64-value> | nonce 속성을 설정하여 예외적으로 인라인 코드를 사용한다. <base64-value>는 반드시 요청마다 다른 난수 값으로 설정해야 한다. 해당 출처를 설정하면 unsafe-inline 은 무시된다. |
<hash-algorithm>-<base64-value> | script 혹은 style 태그 내 코드의 해시를 표현한다. 해당 출처를 설정하면 unsafe-inline은 무시된다. |
'Web Hacking > Study' 카테고리의 다른 글
UNION Based SQL Injection 정리 (0) | 2024.01.13 |
---|---|
Relative Path Overwrite (RPO) 취약점이란 (0) | 2024.01.02 |
XSS 필터링 우회 (2) | 2023.12.21 |
Error & Time based SQL Injection (0) | 2023.07.01 |
ExploitTech: Blind SQL Injection Advanced (0) | 2023.07.01 |