콘텐츠 보안 정책은 어떻게 작동합니까?

콘텐츠 보안 정책은 어떻게 작동합니까?

---

개발자 콘솔에 많은 오류가 있습니다.

문자열을 평가하기 위해 거부

다음 콘텐츠 보안 정책 지침을 위반하여 인라인 스크립트 실행을 거부했습니다.

스크립트를로드하기 위해 거부

스타일 시트를로드하도록 거부

이게 다 뭐야? 콘텐츠 보안 정책은 어떻게 작동합니까? Content-Security-PolicyHTTP 헤더 는 어떻게 사용 합니까?

구체적으로 ...

1. ... 여러 소스를 허용합니까?
2. ... 다른 지시어를 사용합니까?
3. ... 여러 지시문을 사용합니까?
4. ... 핸들 포트?
5. ... 다른 프로토콜을 처리합니까?
6. ... file://프로토콜 허용 ?
7. ... 인라인 스타일, 스크립트 및 태그를 사용 <style>하고 <script>?
8. ... 허용 eval()?

그리고 마지막으로:

9. 정확히 무엇을 'self'의미합니까?

---

Content-Security-Policy메타 태그를 사용하면 위험 줄일 수 있습니다 XSS의 자원이 다른 위치에서 데이터를로드에서 브라우저를 방지에서로드 할 수있는 사용자가 정의 할 수 있도록하여 공격을. 이로 인해 공격자가 사이트에 악성 코드를 삽입하기가 더 어려워집니다.

나는 왜 CSP 오류가 발생했는지 알아 내려고 벽돌 벽에 머리를 부딪쳤다. 어떻게 작동하는지에 대한 간결하고 명확한 지시는 없었습니다. 여기 CSP의 몇 가지 요점을 간단히 설명하려고했는데 , 주로 해결하기 어려운 것에 집중했습니다.

간결성을 위해 각 샘플에 전체 태그를 쓰지 않습니다. 대신 content속성 만 표시 하므로 샘플은 다음을 content="default-src 'self'"의미합니다.

<meta http-equiv="Content-Security-Policy" content="default-src 'self'">

1. 여러 소스를 허용하는 방법?

지시문 뒤에 소스를 공백으로 구분 된 목록으로 간단히 나열 할 수 있습니다.

content="default-src 'self' https://example.com/js/"

와 같은 특수 매개 변수 이외의 매개 변수에는 따옴표가 없습니다 'self'. 또한 :지시문 뒤에 콜론 ( ) 이 없습니다 . 지시어와 공백으로 구분 된 매개 변수 목록 만 있습니다.

지정된 매개 변수 아래의 모든 것은 암시 적으로 허용됩니다. 즉, 위 예에서 유효한 소스가됩니다.

https://example.com/js/file.js
https://example.com/js/subdir/anotherfile.js

그러나 이들은 유효하지 않습니다.

http://example.com/js/file.js
^^^^ wrong protocol

https://example.com/file.js
                   ^^ above the specified path

2. 다른 지시어를 사용하는 방법은 무엇입니까?

가장 일반적인 지시문은 다음과 같습니다.

• default-src 자바 스크립트, 이미지, CSS, 글꼴, AJAX 요청 등을로드하기위한 기본 정책
• script-src 자바 스크립트 파일의 유효한 소스를 정의합니다
• style-src CSS 파일의 유효한 소스를 정의합니다
• img-src 이미지의 유효한 소스를 정의합니다
• connect-srcAJAX (XMLHttpRequest), WebSockets 또는 EventSource에 대한 유효한 대상을 정의합니다. 여기에서 허용되지 않는 호스트에 연결을 시도하면 브라우저가 400오류 를 에뮬레이트합니다

다른 것들도 있지만 이것들은 가장 필요할 것입니다.

3. 여러 지시문을 사용하는 방법?

세미콜론 ( ;) 으로 종료하여 하나의 메타 태그 안에 모든 지시문을 정의합니다 .

content="default-src 'self' https://example.com/js/; style-src 'self'"

4. 포트를 처리하는 방법?

허용 된 도메인 뒤에 포트 번호 나 별표를 추가하여 기본 포트를 제외한 모든 것을 명시 적으로 허용해야합니다.

content="default-src 'self' https://ajax.googleapis.com http://example.com:123/free/stuff/"

위의 결과는 다음과 같습니다.

https://ajax.googleapis.com:123
                           ^^^^ Not ok, wrong port

https://ajax.googleapis.com - OK

http://example.com/free/stuff/file.js
                 ^^ Not ok, only the port 123 is allowed

http://example.com:123/free/stuff/file.js - OK

앞에서 언급했듯이 별표를 사용하여 모든 포트를 명시 적으로 허용 할 수도 있습니다.

content="default-src example.com:*"

5. 다른 프로토콜을 처리하는 방법?

기본적으로 표준 프로토콜 만 허용됩니다. 예를 들어 WebSocket을 허용 ws://하려면 명시 적으로 허용해야합니다.

content="default-src 'self'; connect-src ws:; style-src 'self'"
                                         ^^^ web sockets are now allowed on all domains and ports

6. How to allow the file protocol file://?

If you'll try to define it as such it won’t work. Instead, you'll allow it with the filesystem parameter:

content="default-src filesystem"

7. How to use inline scripts and style definitions?

Unless explicitly allowed, you can't use inline style definitions, code inside <script> tags or in tag properties like onclick. You allow them like so:

content="script-src 'unsafe-inline'; style-src 'unsafe-inline'"

You'll also have to explicitly allow inline, base64 encoded images:

content="img-src data:"

8. How to allow eval()?

I'm sure many people would say that you don't, since 'eval is evil' and the most likely cause for the impending end of the world. Those people would be wrong. Sure, you can definitely punch major holes into your site's security with eval, but it has perfectly valid use cases. You just have to be smart about using it. You allow it like so:

content="script-src 'unsafe-eval'"

9. What exactly does 'self' mean?

You might take 'self' to mean localhost, local filesystem, or anything on the same host. It doesn't mean any of those. It means sources that have the same scheme (protocol), same host, and same port as the file the content policy is defined in. Serving your site over HTTP? No https for you then, unless you define it explicitly.

I've used 'self' in most examples as it usually makes sense to include it, but it's by no means mandatory. Leave it out if you don't need it.

But hang on a minute! Can't I just use content="default-src *" and be done with it?

No. In addition to the obvious security vulnerabilities, this would leave it also won’t work as you'd expect. Even though some docs claim it allows anything, that's not true. It doesn't allow inlining or evals, so to really, really make your site extra vulnerable, you would use this:

content="default-src * 'unsafe-inline' 'unsafe-eval'"

... but I trust you won’t.

Further reading:

http://content-security-policy.com

http://en.wikipedia.org/wiki/Content_Security_Policy

---

APACHE2 MOD_HEADERS

You could also enable Apache2 mod_headers, on Fedora it's already enabled by default, if you use Ubuntu/Debian enable it like this:

# First enable headers module for Apache2, 
# then restart the Apache2 service   
a2enmod headers
apache2 -k graceful

On Ubuntu/Debian you can configure headers in the file /etc/apache2/conf-enabled/security.conf

#
# Setting this header will prevent MSIE from interpreting files as something
# else than declared by the content type in the HTTP headers.
# Requires mod_headers to be enabled.
# 
#Header set X-Content-Type-Options: "nosniff"

#
# Setting this header will prevent other sites from embedding pages from this
# site as frames. This defends against clickjacking attacks.
# Requires mod_headers to be enabled.
#
Header always set X-Frame-Options: "sameorigin"
Header always set X-Content-Type-Options nosniff
Header always set X-XSS-Protection "1; mode=block"
Header always set X-Permitted-Cross-Domain-Policies "master-only"
Header always set Cache-Control "no-cache, no-store, must-revalidate"
Header always set Pragma "no-cache"
Header always set Expires "-1"
Header always set Content-Security-Policy: "default-src 'none';"
Header always set Content-Security-Policy: "script-src 'self' www.google-analytics.com adserver.example.com www.example.com;"
Header always set Content-Security-Policy: "style-src 'self' www.example.com;"

Note: This is the bottom part of the file, only the last 3 entries are CSP settings.

The first parameter is the directive, the 2nd are the sources to be white-listed. I've added Google analytics and an adserver, which you might have. Furthermore I found that if you have aliases, e.g, www.example.com and example.com configured in Apache2 you should add them to the white-list as well.

Inline code is considered harmful, you should avoid it. Copy all the javascripts and css to separate files and add them to the white-list.

While you're at it you could take a look at the other header settings and install mod_security

Further reading:

https://developers.google.com/web/fundamentals/security/csp/

https://www.w3.org/TR/CSP/

참고URL : https://stackoverflow.com/questions/30280370/how-does-content-security-policy-work