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. 파일 프로토콜을 허용하는 방법 file://?
그렇게 정의하려고하면 작동하지 않습니다. 대신, 당신은 filesystem매개 변수 와 함께 그것을 허용합니다
content="default-src filesystem"
7. 인라인 스크립트와 스타일 정의를 사용하는 방법?
명시 적으로 허용되지 않으면 인라인 스타일 정의, <script>태그 내부의 코드 또는와 같은 태그 속성을 사용할 수 없습니다 onclick. 당신은 그들을 이렇게 허용합니다 :
content="script-src 'unsafe-inline'; style-src 'unsafe-inline'"
또한 인라인 base64로 인코딩 된 이미지를 명시 적으로 허용해야합니다.
content="img-src data:"
8. 허용하는 방법 eval()?
나는 많은 사람들이 당신이 그렇지 않다고 말할 것이라고 확신합니다. 그 사람들은 틀렸을 것입니다. 물론 eval을 사용하여 사이트 보안에 큰 구멍을 뚫을 수는 있지만 유효한 유스 케이스가 있습니다. 당신은 그것을 사용하는 것에 대해 현명해야합니다. 당신은 그렇게 허용합니다 :
content="script-src 'unsafe-eval'"
9. 정확히 무엇을 'self'의미합니까?
'self'localhost, 로컬 파일 시스템 또는 같은 호스트에있는 것을 의미 할 수 있습니다 . 그것은 어떤 것도 의미하지 않습니다. 콘텐츠 정책이 정의 된 파일과 동일한 체계 (프로토콜), 동일한 호스트 및 동일한 포트를 가진 소스를 의미합니다. HTTP를 통해 사이트를 서비스 하시겠습니까? 명시 적으로 정의하지 않으면 https가 없습니다.
필자는 'self'일반적으로 포함시키는 것이 합리적이므로 대부분의 예에서 사용 했지만 결코 필수는 아닙니다. 필요하지 않은 경우 그대로 두십시오.
그러나 잠시만 요! 그냥 사용 content="default-src *"하고 끝낼 수 없습니까?
아니요. 명백한 보안 취약점 외에도 예상대로 작동하지 않습니다. 일부 문서 에서는 모든 것을 허용한다고 주장 하지만 사실이 아닙니다. 인라인이나 회피를 허용하지 않으므로 실제로 사이트를 더 취약하게 만들려면 다음을 사용하십시오.
content="default-src * 'unsafe-inline' 'unsafe-eval'"
...하지만 당신이하지 않을 것을 믿습니다.
더 읽을 거리 :
http://content-security-policy.com
http://en.wikipedia.org/wiki/Content_Security_Policy