Content Security Policy를 완화하는 방법

개발
1

안녕하세요

설정된 공용 도메인 이름을 거치지 않고 Discourse를 테스트해 보고 싶습니다. 예를 들어, Discourse가 https://uat.mysite.com으로 설치 및 구성되었다면, 브라우저에서 https://uat.mysite.com으로 이동할 수 있습니다. 이렇게 하면 브라우저가 내부 네트워크를 벗어나 공용 인터넷으로 나가 도메인 이름을 공용 IP 주소로 해석하고, 해당 공용 IP 주소를 통해 페이지를 로드하게 됩니다.

방금 서버의 내부 IP 주소(아래에 표시된 192.168.1.2 등)를 통해 Discourse에 접속을 시도해 보았지만, Content Security Policy(CSP) 때문에 당연히 로드가 되지 않습니다. 발생하는 오류는 다음과 같은 형태입니다.

Refused to load the script 'http://192.168.1.2:12000/assets/locales/en-a9c88e45eb548bd7c807aecfd37d218891e213b5c1fd254857e0f16c72d73996.js' because it violates the following Content Security Policy directive: "script-src http://uat.mysite.com/logs/ http://uat.mysite.com/sidekiq/ http://uat.mysite.com/mini-profiler-resources/ http://uat.mysite.com/assets/ http://uat.mysite.com/brotli_asset/ http://uat.mysite.com/extra-locales/ http://uat.mysite.com/highlight-js/ http://uat.mysite.com/javascripts/ http://uat.mysite.com/plugins/ http://uat.mysite.com/theme-javascripts/ http://uat.mysite.com/svg-sprite/ 'sha256-rwfDVOTzygQmkOwFNAeX564B66beHoel4+gRLgQUgHg='". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

                                           ---------------------------------------------
                                          |                                             |
                                           ------------
uat.mysite.com resolves to 98.1.2.3 -->   |  Public IP |  Server running Discourse.     |
                                          |  96.1.2.3. |
                                           ------------                                 |
                                          |                                             |
                                          |                  ----------------           |
                                          |                  |  Private IP  |           |
                                          |                  | 192.168.1.2  |           |
                                           ---------------------------------------------
                                                                         ^
                                                                         |
192.168.1.2   ------------------------------------------------------------

서버의 내부 IP를 통해 Discourse에 접근하고 싶은 이유는 테스트를 수행하기 위해서입니다. 예를 들어, 부하 테스트를 수행할 때 인터넷을 서비스하는 네트워크에 불필요한 부하를 걸고 싶지 않을 수 있습니다. 또는 DNS를 설정하지 않고 노트북이나 빌드 서버에 테스트 인스턴스를 설치하고 싶을 수도 있습니다.

항상 /etc/hosts에 사용자 지정 항목을 설정하여 이 문제를 우회할 수 있다고 생각합니다만, CSP를 비활성화하거나 테스트를 허용하기 위해 다른 소스를 신뢰하도록 설정하는 방법이 있을까요?

2

그 다음, 해당 주소를 Discourse 서버의 로컬 IP로 해석하도록 컴퓨터를 구성하세요. 이를 수행하는 방법은 다양하지만 운영체제에 따라 다르므로, Google 검색 시 운영체제 정보를 포함하는 것이 좋습니다. (Linux와 Mac의 경우 /etc/hosts 파일을 편집하면 됩니다.)

3

사실 /etc/hosts를 시도해 보았지만 CSP로 인해 동일한 오류가 계속 발생합니다. 개발자가 DNS 솔루션을 구축하지 않고 노트북 내에서 모든 작업을 수행할 수 있도록 이 기능을 전환할 수 있는 플래그나 설정이 있을 것이라 생각했습니다. macOS에서 개발용 Discourse 설치 - 문서 / 개발자 - Discourse Meta를 살펴보면, IP 주소가 아닌 http://localhost:3000으로 작동하도록 부트스트랩되는 것으로 보입니다.

제가 직면한 문제는 Discourse 설치를 자동화하는 도구를 가지고 있으며, 개발, UAT, 프로덕션 환경 모두를 동일한 프로세스로 구축하고 싶다는 것입니다. 현재 적절한 FQDN을 해석해야 하므로 공개 인터넷에서 접근 가능해야 한다는 것이 요구 사항인 것으로 보이며, 개발 환경을 공개 인터넷에서 접근 가능하게 하고 싶지는 않습니다. 여기에는 여러 사용 사례가 있으며, 그중 하나는 개발 환경에서 매주 Discourse 업그레이드를 자동화하고 여러 테스트를 실행하여 문제가 발생하는지 확인하는 것입니다.

어쨌든 IP를 통한 직접 액세스를 허용하도록 요구 사항을 완화할 방법이 있다면 알려주시면 좋겠습니다. 그렇지 않다면 유일한 대안은 작은 DNS 서비스를 실행한 후 노트북을 해당 커스텀 DNS 서비스를 사용하도록 설정하는 것일 텐데, 이는 다소 번거로워 보입니다.

4

content security policy라는 이름의 사이트 설정이 있습니다. 이 항목의 체크를 해제하고 저장하면 CSP를 비활성화할 수 있습니다.

프로덕션 인스턴스에서 이렇게 하지 않는 한 괜찮습니다.

5

그것은 좋은 아이디어가 아닙니다. 절대 작동하지 않을 것입니다. 개발 환경은 자산이 사전 컴파일되어 있고 개발을 불가능하게 만드는 기타 여러 요소가 있어 필연적으로 다릅니다. 플러그인을 개발하는 것이 아니라면 개발 환경 자체가 전혀 필요하지 않습니다. 따라서 그런 상황이라면 개발 환경을 Docker 설치로 설정할 수 있지만, 여기에서 말하는 개발 환경과는 다릅니다.

표준 설치에 설명된 대로 Docker를 사용하여 스테이징 및 프로덕션 환경을 시작해야 합니다.

6

안녕하세요! 저는 Docker 설치 환경에서 이 작업을 정기적으로 수행합니다. 프로덕션 환경에서 표준 Docker 설치를 사용한다고 가정하면, 인수 테스트(Acceptance Testing)에도 동일한 환경을 사용하는 것이 좋습니다. 개발 환경과 Docker 설치 환경 간에는 설정, gem 및 JS 패키지 버전 등에서 상당한 차이가 있을 수 있으며, 이는 배포 시 큰 문제를 일으킬 수 있습니다.

Docker 설치 환경은 기본적으로 HTTPS를 사용하며 이를 강제합니다. 컨테이너 템플릿을 사용자 정의하지 않는 한(제가 경험해 보니 여기에는 몇 가지 숨겨진 복잡성이 있습니다), 다른 사이트 설정을 통해 HTTPS 강제 기능을 간단히 비활성화할 수 있습니다.

다음은 로컬 Docker 설치 환경에서 "보안을 완화"하기 위한 제 스니펫입니다. 프로덕션으로 전환하기 전에도 쉽게 되돌릴 수 있습니다:

SiteSetting.content_security_policy = false
SiteSetting.force_https = false

이제 브라우저가 http://uat.mysite.com에서 Docker 컨테이너의 포트 80을 찾을 수 있도록 하면 됩니다. https 대신 http를 사용하게 된다는 점에 유의하세요.

이를 위해 @pfaffman의 /etc/hosts 트릭이 적합합니다. 각 운영 체제에 대한 자세한 내용은 여기에서 확인하세요.