HTTP 보안 헤더: CSP와 HSTS 점검 방법

애플리케이션을 배포했습니다. 페이지가 로드되고 양식이 작동하며 손상된 부분이 없습니다. 그런 다음 스캔을 실행하면 다음에 대한 결과 목록이 반환됩니다. 헤더 - 그리고 그 어느 것도 분명하지 않습니다.

그것은 정상적인 첫 번째 반응입니다. 헤더는 화면에 표시되지 않으므로 헤더가 중요한지 아니면 스캐너가 까다로워서인지 알기 어렵습니다. 이 가이드는 가장 자주 보게 될 헤더, 각 헤더가 실제로 일반 언어로 수행하는 작업, 추측 없이 헤더를 확인하는 방법을 안내합니다.

보안 헤더는 서버가 페이지와 함께 브라우저에 보내는 지침입니다. 브라우저는 이를 읽고 콘텐츠를 처리하는 방법(실행할 수 있는 스크립트, 일반 HTTP를 통해 페이지를 로드할 수 있는지 여부, 다른 사이트에서 해당 페이지를 프레임에 포함할 수 있는지 여부)을 조정합니다.

페이지에 아무것도 변경되지 않습니다. 이것이 바로 이러한 발견이 추상적으로 느껴지는 이유입니다. 사이트는 문제가 발생하는 날 중요한 보호 기능 세트를 놓친 채 완벽하게 보이고 작동할 수 있습니다.

정직한 구성은 다음과 같습니다. 헤더는 특정 종류의 위험을 줄입니다. 이는 자체적으로 사이트를 안전하게 만들지 않으며, 헤더를 깔끔하게 확인한다고 해서 사이트가 완전히 안전하다는 것을 증명할 수는 없습니다. 이를 여러 레이어 중 하나의 레이어로 생각하고 가장 저렴한 레이어 중 하나로 생각하세요.

브라우저가 페이지를 요청하면 서버는 해당 페이지로 응답합니다. 그리고 응답 헤더라고 불리는 메타데이터 블록입니다. 직접 볼 수 있습니다. 브라우저의 개발자 도구를 열고 네트워크 탭으로 이동하여 페이지를 다시 로드하고 상위 요청을 클릭하세요. 헤더가 바로 거기에 있습니다.

보안 헤더는 단순히 브라우저에 규칙을 적용하라고 지시하는 헤더입니다. 일부는 엄격하고 일부는 권고 사항이며 모두 HTML이 아닌 서버 구성, 프레임워크 또는 호스팅 플랫폼에 설정됩니다.

CSP는 페이지에 로드할 수 있는 콘텐츠 소스를 브라우저에 알려줍니다. 이것은 여기서 가장 강력한 헤더이며 사람들이 가장 위협적이라고 생각하는 헤더입니다.

실제로 CSP는 다음과 같은 내용을 설명합니다. 스크립트는 자신의 도메인과 신뢰할 수 있는 CDN에서만 나올 수 있습니다. 이미지는 HTTPS를 통해 어디에서나 나올 수 있습니다. 페이지가 다른 사이트에 의해 구성되지 않았을 수 있습니다. 허용하지 않은 소스에서 로드하려는 항목이 있으면 브라우저는 이를 차단하고 해당 시도를 콘솔에 기록합니다.

CSP는 안전한 출력 인코딩 및 삭제와 함께 스크립트 삽입에 대한 추가 방어입니다. 또한 너무 공격적으로 설정하면 무언가가 깨질 가능성이 가장 높은 헤더이기도 합니다. 초보자를 위한 실용적인 경로는 보고 전용 모드에서 시작하여 차단되었을 내용을 관찰하고 실제 문제를 수정한 다음 적용하는 것입니다.

HSTS는 정의된 기간 동안 HTTPS를 통해서만 사이트와 통신하도록 브라우저에 지시합니다. 브라우저가 이 헤더를 확인하면 사용자가 입력하더라도 도메인에 대한 안전하지 않은 HTTP 연결을 거부합니다. http:// 아니면 오래된 링크를 따라가세요.

브라우저가 HSTS 정책을 알게 되면 HTTP 요청을 보내기 전에 업그레이드합니다. 도메인이 이미 HSTS 사전 로드 항목에 포함되지 않는 한 첫 번째 방문에서는 여전히 HTTP를 사용할 수 있습니다.

여기서 존중해야 할 한 가지는 헌신입니다. HSTS는 지정한 기간 동안 브라우저에서 기억되므로 모든 하위 도메인이 HTTPS에서 작동하는지 확인하는 동안 짧은 기간부터 시작한 다음 확신이 들면 기간을 늘립니다.

X-Frame-Options는 다른 사이트가 프레임 안에 페이지를 로드할 수 있는지 여부를 제어합니다. <iframe> 다른 사람의 페이지에서.

왜 신경쓰나요? 프레이밍은 공격자가 실제 페이지에 보이지 않거나 위장된 요소를 오버레이하여 사용자가 의도하지 않은 항목을 클릭하도록 하는 클릭재킹의 메커니즘이기 때문입니다. 앱에 로그인된 작업(삭제 버튼, 결제, 설정 변경)이 있는 경우 다른 곳에 프레이밍하는 것은 원하지 않는 위험입니다.

일반적인 설정은 SAMEORIGIN, 자신의 페이지가 서로 프레임을 구성하도록 허용하지만 다른 페이지는 차단합니다. 액자에 넣을 의도가 전혀 없다면 일반적으로 이것이 올바른 기본값입니다.

Referrer-Policy는 사용자가 페이지에서 링크를 클릭할 때 다른 사이트와 공유되는 URL의 양을 결정합니다. 최신 브라우저는 일반적으로 strict-origin-when-cross-origin를 사용합니다. 전체 URL은 동일한 출처 요청에 대해 전송될 수 있지만 교차 출처 HTTPS 요청은 출처만 수신합니다. 명백히 약한 정책은 더 많은 정보를 공개할 수 있습니다.

전체 URL에는 때때로 토큰, ID, 이메일 주소, 검색어 등의 쿼리 문자열에 민감한 값이 포함되어 있기 때문에 이는 중요합니다. 제3자에게 유출하는 일은 조용하고 놓치기 쉽습니다.

합리적인 기준은 교차 사이트 요청에 대해 원본만 보내거나 전혀 보내지 않는 것입니다. 비용이 거의 들지 않으며 우발적인 데이터 유출을 제거합니다.

이름으로 알 수 있을 만큼 몇 가지 헤더가 더 자주 나타납니다.

• X-Content-Type-Options: nosniff 브라우저가 파일 형식을 추측하는 것을 중지합니다. 그렇지 않으면 업로드된 파일을 실행 가능한 스크립트로 바꿀 수 있습니다.

• Permissions-Policy 카메라, 마이크, 위치정보 등 사용하지 않는 브라우저 기능을 끕니다.

• Cross-Origin-Opener-Policy 및 관련 교차 출처 헤더는 귀하의 페이지를 다른 페이지와 격리시켜 특정 공격을 억제하는 데 도움이 됩니다.

첫날에는 모든 항목이 필요하지 않습니다. 그들이 무엇을 하는지 알면 당황하지 않고 스캔 보고서를 읽는 데 도움이 됩니다.

보는 방법에는 두 가지가 있습니다.

먼저 수동 경로: 개발자 도구, 네트워크 탭, 페이지 요청을 클릭하고 응답 헤더를 읽습니다. 이는 단일 헤더가 있는지 확인하고 예상한 대로 설정하는 데 유용합니다.

둘째, 두 페이지 이상에 대한 실제 경로: 스캔을 실행합니다. 스캐너는 브라우저와 같은 방식으로 사이트를 가져와서 어떤 보안 헤더가 있는지, 어떤 것이 누락되었는지, 그리고 각 공백이 무엇을 노출하는지 보고합니다. 이는 원시 텍스트 대신 우선 순위가 지정된 목록을 제공하며 수동으로 열 것이라고 생각하지 않은 페이지를 확인합니다.

VICE의 무료 경량 보안 스캔과 같은 범용 도구는 다른 문제와 함께 헤더 발견 사항을 플래그로 표시하고 각 문제 뒤에 있는 증거를 제공하므로 문제가 발생한 이유를 확인할 수 있습니다.

헤더는 구성에 있으므로 대부분의 수정 사항은 작습니다. 즉, 서버 구성에 한 줄을 추가하거나 프레임워크에 설정을 추가하거나 호스트 대시보드에 옵션을 추가합니다. 한 번에 하나의 헤더를 변경하고 사이트가 여전히 작동하는지 확인하세요.

그런 다음 다시 스캔하십시오. 사람들이 건너뛰는 단계가 바로 이것이다. 구성을 편집한다고 해서 이제 모든 페이지의 헤더가 정확하다는 의미는 아니며, 대시보드에서 수정된 것으로 표시하는 것은 이를 확인하는 것과는 다릅니다. 동일한 범위에 대한 새로 스캔을 통해서만 변경 사항이 실제로 적용되었음을 알 수 있습니다.

무료 검사로 시작하여 헤더가 실제로 수행하는 작업을 살펴보고 주요 결과를 한 번에 하나씩 수정하세요. 이는 합리적인 첫 번째 통과이며 기본값이 괜찮기를 바라는 것보다 훨씬 더 나은 위치입니다.