CSP 우회

1. CSP

 

CSP (콘텐츠 보안 정책Content Security Policy)는 XSS, clickjacking이나 데이터 주입과 같은 특정 웹사이트 관련 공격을 탐지 하거나 완화 하기 위해 사용된다.

 

CSP를 활성화하려면 Content-Security-Policy HTTP 헤더를 반환하도록 웹 서버를 구성해야 한다. 

Content-Security-Policy-Report-Only: policy

 

+) Content-Security-Policy-Report-Only 헤더와 Content-Security-Policy 헤더가 모두 동일한 응답에 있으면, 두 정책은 모두 적용됨. 즉, 둘다 설정하면 허용되지 않은 요청이 보내지지도 않고 보고서도 보내짐. (보안 강화의 효과)

 

<meta> 태그를 통해 활성화하는 방법도 있다. 

<meta
  http-equiv="Content-Security-Policy"
  content="default-src 'self'; img-src https://*; child-src 'none';" />

 

CSP의 주요 목표는 XSS 공격을 방어하는 것이다.

XSS 공격은 서버에서 받은 콘텐츠를 브라우저가 신뢰한다는 점을 악용한다. 브라우저는 콘텐츠의 출처를 신뢰하기 때문에 콘텐츠가 이상한 곳에서 오더라도 악성 스크립트를 피해자의 브라우저에서 실행하는 것이다. 

 

CSP를 사용하면 서버 관리자가 브라우저에서 실행 가능한 스크립트의 유효한 소스로 간주해야 하는 도메인을 지정하여 XSS가 발생할 수 있는 벡터를 줄이거나 제거할 수 있다.

즉, 허용된 도메인에서 받은 소스 파일에서 로드된 스크립트만 실행하거나 HTML 속성을 포함한 인라인 스크립트 및 이벤트 처리 등의 다른 모든 스크립트는 무시할 수 있다. 

 

CSP 설정과 관련된 정보는 아래 링크에서 더 자세하게 확인해볼 수 있다. 

https://content-security-policy.com/

Content-Security-Policy (CSP) Header Quick Reference

https://book.hacktricks.xyz/pentesting-web/content-security-policy-csp-bypass

Content Security Policy (CSP) Bypass | HackTricks | HackTricks

2. CSP 정책 

(1) 웹 사이트 관리자는 모든 콘텐츠가 사이트 자체의 출처(하위 도메인 제외)에서 오도록 함.

Content-Security-Policy: default-src 'self'

(2) 신뢰할 수 있는 도메인 및 모든 하위 도메인의 콘텐츠를 허용 (CSP가 설정된 도메인과 동일할 필요는 없음).

Content-Security-Policy: default-src 'self' example.com *.example.com

(3) 웹 애플리케이션 사용자의 모든 원본의 이미지를 포함할 수 있도록 허용하지만 오디오 또는 비디오 미디어는 신뢰할 수 있는 공급자로 제한하고 모든 스크립트는 신뢰할 수 있는 코드를 호스팅하는 특정 서버로만 제한

• 이미지는 출처에 상관없이 로드할 수 있음
• 미디어는 example.org 및 example.net에서만 허용되며 해당 사이트의 하위 도메인에서는 허용되지 않음 
• 실행 가능한 스크립트는 userscripts.example.com에서 온 것만 허용

Content-Security-Policy: default-src 'self'; img-src *; media-src example.org example.net; script-src userscripts.example.com

(4) 온라인 뱅킹 사이트의 웹 사이트 관리자는 공격자가 요청을 도청하는 것을 방지하기 위해 모든 콘텐츠가 TLS를 사용하여 로드되었는지 확인

• 서버는 단일 출처인 onlinebanking.example.com에서 특별히 HTTPS를 통해 로드되는 문서에 대한 액세스만 허용

Content-Security-Policy: default-src https://onlinebanking.example.com

(5) 웹 메일 사이트의 웹 사이트 관리자는 전자 메일에 HTML을 허용하고 어디에서나 로드된 이미지를 허용하려고 하지만 JavaScript 또는 기타 잠재적으로 위험한 콘텐츠는 허용하지 않음

• script-src를 지정하지 않고, default-src 지시문을 사용
• 즉, 원본 서버에서만 스크립트를 로드할 수 있음

Content-Security-Policy: default-src 'self' *.example.com; img-src *

 

정책 목록 

default-src	-src로 끝나는 모든 리소스의 기본 동작을 설정
img-src	이미지를 로드할 수 있는 출처 설정
script-src	Javascript 태그 관련 권한과 출처 설정
style-src	스타일시트 관련 권한과 출처 설정
child-src	페이지 내에 삽입된 프레임 컨텐츠에 대한 출처 설정
base-uri	페이지의 <base> 태그에 나타날 수 있는 URL을 설정
object-src	Flash와 같은 위험한 플러그인 비활성화

 

+ script-src directive

script-src-elem	<script> 요소를 지정하지만 인라인 스크립트 이벤트 핸들러는 지정x
script-src-attr	인라인 스크립트 이벤트 핸들러는 지정 하지만 <script>요소에 직접 로드된 URL은 포함x

value

none	모든 출처를 허용하지 않음
self	Origin 내에서 로드하는 리소스만 허용
unsafe-inline	인라인 코드의 사용을 허용
unsafe-eval	eval과 같은 텍스트-자바스크립트 변환 메커니즘의 사용을 허용
nonce-<base64-value>	nonce 속성을 설정하여 예외적으로 인라인 코드를 사용합니다. <base64-value>는 반드시 요청마다 다른 난수 값으로 설정해야 합니다. 해당 출처를 설정하면 unsafe-inline 은 무시됩니다. 안전하지 않은 인라인 지시어를 사용하지 않도록 할 수 있습니다

- 모든 리소스 출처를 origin으로 제한   

Content-Security-Policy: default-src 'self'

 

- base태그의 모든 값을 허용하지 않음

Content-Security-Policy: base-uri 'none'

 

- 인라인 코드의 사용을 허가

Content-Security-Policy: script-src 'unsafe-inline'

3. CSP 우회

(1) 신뢰하는 도메인에 업로드

만약 신뢰하는 출처(도메인)에서 파일 업로드 및 다운로드 기능을 제공한다면, 공격자는 출처에 스크립트와 같은 자원을 업로드한 뒤 다운로드 경로로 웹 페이지에 자원을 포함시킬 수 있다.

<!--외부 자원 업로드 예시-->
<meta http-equiv="Content-Security-Policy" content="script-src 'self'">
...
<h1>검색 결과: <script src="/download_file.php?id=177742"></script></h1>

 

(2) JSONP API

JSONP란?

JSONP(JSON with Padding)은 웹 애플리케이션에서 서로 다른 도메인(Cross-Origin) 간에 데이터를 주고받을 때 사용되는 기술이다. JSONP보다 CORS가 권장되는 이유는 JSONP의 경우는 GET 파라미터를 통해서만 전달이 되는데 그렇게 되면 공격자에 의해서 쉽게 조작이 가능하다. 따라서 허용하는 교차 출처만을 지정할 수 있는 CORS를 사용하는 것이 안전하다.

+) https://blog.kingbbode.com/26

+) https://en.wikipedia.org/wiki/JSONP

만약 CSP에서 허용한 도메인에서 JSONP API를 지원한다면, callback 파라미터에 원하는 스크립트를 삽입하여 공격이 가능하다.

웹 페이지에서 *.google.com에서 온 출처만 허용한다고 가정해보면, 공격자는 구글에서 JSONP API를 지원하는 서버를 찾아 callback에 원하는 스크립트를 삽입할 수 있다.

 

JSONP API의 예로 아래와 같은 Google Accounts 서비스를 들 수 있다.

https://accounts.google.com/o/oauth2/revoke?callback=alert(1);

 

이때 JSONP API를 제공하는 서비스는 콜백 이름에 식별자를 제외한 문자를 거부함으로써 이를 추가적으로 방어할 수 있다.

즉, Google의 서버는 콜백 이름으로 alert(1);이 유효하지 않다고 판단하고 오류 메시지를 반환하는 것이다. 

그러나 보안적으로 가능한 경우 JSONP보다는 CORS를 지원하는 API를 사용하는 것이 좋다.

<!--CSP 설정 (구글)-->
<meta http-equiv="Content-Security-Policy" content="script-src 'https://*.google.com/'">
...
<script src="https://accounts.google.com/o/oauth2/revoke?callback=alert(1);"></script>
<!-- JSONP API 결과:
// API callback
alert(1);({
  "error": {
    "code": 400,
    "message": "Invalid JSONP callback name: 'alert(1)'; only alphabet, number, '_', '$', '.', '[' and ']' are allowed.",
    "status": "INVALID_ARGUMENT"
  }
}
);
-->

 

(3) nonce 예측 가능

CSP의 nonce를 이용하면 따로 도메인이나 해시 등을 지정하지 않아도 공격자가 예측할 수 없는 nonce 값이 태그 속성에 존재할 것을 요구함으로써 XSS 공격을 방어할 수 있다.

이 방어를 효과적으로 사용하기 위해서는 nonce  가 공격자가 취득하거나 예측할 수 없는 값이어야 한다.

Content-Security-Policy: script-src 'nonce-2726c7f26c'
....
<script nonce="2726c7f26c">
  var inline = 1;
</script>

 

nonce 값은 보통 요청마다 새로 생성되는데, 만일 이를 생성하는 알고리즘이 취약하여 값을 예측할 수 있다면 공격자는 이를 유추해 자신의 스크립트를 웹 사이트에 삽입할 수 있다.

nonce를 사용할 때에는 nonce 값을 담고 있는 HTTP 헤더 또는 <meta> 태그가 캐싱되지 않는지 주의해야 한다.

PHP나 CGI 계열 스크립팅을 사용할 때에는 특히 주의해야 하는데, 이는 스크립트들이 /index.php/style.css처럼 뒤에 추가적인 경로를 붙여 접근될 수 있기 때문이다.

 

웹 사이트에서는 종종 특정 파일들을 캐시(즉, 임시 저장)하여 웹 페이지를 더 빠르게 로드할 수 있도록 한다. 이때, 파일 확장자(예: .css)를 기반으로 어떤 파일을 캐시할지 결정하는 경우가 있다. css 파일 같은 정적 파일은 내용이 자주 변경되지 않기 때문에, 이런 파일은 보통 캐시에 저장된다.

캐싱 : https://learn.microsoft.com/ko-kr/azure/cdn/cdn-how-caching-works

이 경우 캐시가 만료될 때까지 요청시마다 같은 nonce가 돌아오기 때문에 공격자는 이를 바탕으로 nonce를 획득할 수 있다. 콘텐츠가 캐시되어 서버 측 XSS가 일어나지는 않으나, DOM XSS 등 클라이언트 측에서 일어날 수 있는 공격에 취약해지게 된다.

또한, nonce 값은 공격자가 예측할 수 없는 난수값이여야 하기 때문에 보안 상 안전한 의사 난수 생성기(CSPRNG)를 사용하는 것이 좋다. 만일 현재 시각(srand() / rand()) 등 공격자가 알 수 있는 정보를 바탕으로 nonce를 생성하면 의미가 없다. 이는 CSP 이외에도 난수를 사용하는 응용에서 일반적으로 적용되는 사항이다. 

 

 - Nginx와 PHP FastCGI SAPI(php-fpm) 사용 예시

location ~ \.php {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php7.2-fpm.sock;
}

 

- snippets/fastcgi-php.conf

# regex to split $uri to $fastcgi_script_name and $fastcgi_path
fastcgi_split_path_info ^(.+\.php)(/.+)$;

# Check that the PHP script exists before passing it
try_files $fastcgi_script_name =404;

# Bypass the fact that try_files resets $fastcgi_path_info
# see: http://trac.nginx.org/nginx/ticket/321
set $path_info $fastcgi_path_info;
fastcgi_param PATH_INFO $path_info;

fastcgi_index index.php;
include fastcgi.conf;

 

• fastcgi_split_path_info ^(.+\.php)(/.+)$;는 요청된 URI를 PHP 파일 이름과 추가 경로 정보로 분할하여 캡처(저장)한다. 이는 PHP 파일 뒤에 추가적인 경로 정보가 있을 때 사용된다.
• try_files $fastcgi_script_name =404;는 요청된 PHP 스크립트 파일이 실제로 존재하는지 확인하고, 파일이 없으면 404 오류를 반환한다.
• set $path_info $fastcgi_path_info;와 fastcgi_param PATH_INFO $path_info;는 PATH_INFO 환경 변수를 설정하여 추가 경로 정보를 PHP 스크립트로 전달한다. 

이 설정 때문에 Nginx는 요청된 URL이 PHP 파일로 끝나지 않더라도 URL 내에 .php 파일이 포함되어 있으면 해당 파일을 실행하려고 한다. dom_xss_vulnerable.php 파일명이 .php로 끝나기 때문에, Nginx는 이 파일을 실행 대상으로 판단하고 PHP-FPM에 실행을 요청한다. 

 

이때,  dom_xss_vulnerable.php 파일이 실행되어 nonce 가 <meta http-equiv="Content-Security-Policy" content="... nonce ..."> 태그로 출력된다.

CDN은 보통 CSS 또는 스크립트 등 정적 파일을 캐싱하기 때문에 meta 태그로 출력된 nonce 또한 같이 캐싱된다.

따라서 DOM XSS에 취약한 페이지의 nonce 값이 고정되어 공격자는 아래와 같은 마크업을 이용할 수 있다.

<script nonce="{고정된 nonce 값}">alert(1);</script>

 

PATH_INFO  기능을 사용하지 않는 경우 해당 설정은 location ~ \.php$처럼 URL의 끝 부분이 .php일때만 FastCGI로 넘어가게 수정되어야 한다. 또한 URL에 a/b.php/c/d.php와 같이 .php가 중복 사용될 때를 대비하여 fastcgi-php.conf 스니펫을 사용하지 않고 다음과 같이 변경되어야 합니다.

location ~ \.php$ {
    try_files $uri =404;
    fastcgi_index index.php;
    include fastcgi.conf;
    fastcgi_pass unix:/run/php/php7.2-fpm.sock;
}

• location ~ \.php$: 이 정규 표현식은 URL이 .php로 끝나는 경우에만 해당 블록의 설정을 적용하도록 한다. 즉, URL 끝부분에 .php가 정확히 위치할 때만 처리하도록 제한을 둔다. 이렇게 함으로써, 중간에 .php가 여러 번 등장하는 URL을 올바르게 처리할 수 있다.
• try_files $uri =404: 이 지시어는 요청된 URI가 실제로 서버에 존재하는지를 확인합니다. 파일이 존재하지 않으면 404 오류를 반환한다. 이는 서버가 잘못된 파일 경로에 대해 PHP 처리를 시도하는 것을 방지한다.
• fastcgi_index index.php;: 이 설정은 요청이 디렉토리로 들어왔을 때 기본적으로 실행할 PHP 파일을 index.php로 지정한다. 

 

(4) base-uri 미지정

HTML 하이퍼링크에서 호스트 주소 없이 경로를 지정하면 브라우저는 현재 문서를 기준으로 주소를 해석한다.

 HTML <base> 태그는 경로가 해석되는 기준점을 변경할 수 있도록 하며, <a>, <form> 등의 target 속성의 기본 값을 지정하도록 한다.

 

만일 공격자가 <base href="https://attack/xss-proxy/">와 같은 마크업을 삽입하게 된다면, 추후 상대 경로를 사용하는 URL들은 본래 의도한 위치가 아닌 공격자의 서버에 자원을 가리키게 되어 공격자는 이를 통해 임의의 스크립트 등을 삽입할 수 있게 된다.

base-uri은 임의로 지정하지 않는 이상 default 초기 값이 존재하지 않는다.

 

만약 페이지에 임의 마크업을 삽입할 수 있는 취약점이 있지만, nonce CSP 구문으로 인해 스크립트를 삽입할 수 없다고 가정할 때, base-uri CSP 구문을 지정하지 않은 경우 아래와 같이 base 태그를 이용하여 임의 자원을 로드할 수 있다.

이와 같은 형태의 공격을 Nonce Retargeting 이라고 한다. 

<base href="https://malice.test">
<script src="/jquery.js" nonce=NONCE> 
<!-- jquery.js는 base 태그에 의해 https://malice.test/jquery.js를 가리킵니다. -->

 

<base> 태그의 href 속성을 사용하지 않는 페이지라면 이를 방어하기 위해 csp를 통해 아래와 같은 정책을 설정할 수 있다.

- base 태그의 URL 제한

Content-Security-Policy: base-uri 'none'

 

앞서 언급했듯이, base-uri은 임의로 지정하지 않으면 default 초기 값이 존재하지 않는다. 

따라서 웹 서비스를 개발할 때에는 반드시 base-uri 지시문을 정의해야 한다. 

 

[참고]

드림핵 CSP 강의

https://developer.mozilla.org/ko/docs/Glossary/CSP

https://developer.mozilla.org/ko/docs/Web/HTTP/CSP

https://lovflag.tistory.com/19