Wagtail Documentation
보안 문제 보고¶
경고
최신 보안 정책을 보고 있는지 확인하세요.
참고
보안 문제는 security@wagtail.org로만 보고해주세요.
Wagtail의 대부분의 일반적인 버그는 GitHub 이슈로 보고되지만, 보안 문제의 민감한 특성으로 인해 이러한 방식으로 공개적으로 보고하지 않도록 요청합니다.
대신, Wagtail에서 보안에 영향을 미치는 것을 발견했다고 생각되면, security@wagtail.org로 문제에 대한 설명을 이메일로 보내주세요. 해당 주소로 보낸 메일은 핵심 팀의 일부에게 전달되며, 필요한 경우 더 넓은 논의를 위해 다른 핵심 팀 구성원에게 보안 문제를 전달할 수 있습니다.
이메일로 문제를 제출하면, 48시간 이내에 보안팀 구성원으로부터 확인 이메일을 받게 되며, 취해질 조치에 따라 추가 후속 이메일을 받을 수 있습니다.
암호화된 이메일(선택 사항)을 보내려면, security@wagtail.org의 공개 키 ID는 0xbed227b4daf93ff9 이며, 이 공개 키는 대부분의 일반적으로 사용되는 키 서버에서 사용할 수 있습니다.
이 정보는 security.txt에서도 찾을 수 있습니다.
Django 보안 문제는 Django의 보안 정책에 따라 Django 프로젝트에 직접 보고해야 합니다(Wagtail의 자체 정책은 이를 기반으로 합니다).
지원 버전¶
언제든지 Wagtail 팀은 여러 버전의 Wagtail에 대해 공식적인 보안 지원을 제공합니다:
GitHub에서 호스팅되는
main개발 브랜치는 다음 Wagtail 릴리스가 될 것이며 보안 지원을 받습니다.가장 최근의 두 Wagtail 릴리스 시리즈는 보안 지원을 받습니다. 예를 들어, Wagtail 2.6 릴리스로 이어지는 개발 주기 동안 Wagtail 2.5 및 Wagtail 2.4에 대한 지원이 제공됩니다. Wagtail 2.6이 릴리스되면 Wagtail 2.4의 보안 지원이 종료됩니다.
최신 장기 지원 릴리스는 보안 업데이트를 받습니다.
보안상의 이유로 새 릴리스가 발행될 때, 함께 제공되는 공지에는 영향을 받는 버전 목록이 포함됩니다. 이 목록은 지원되는 Wagtail 버전으로만 구성됩니다: 이전 버전도 영향을 받을 수 있지만, 이를 확인하기 위해 조사하지 않으며 해당 버전에 대한 패치나 새 릴리스를 발행하지 않습니다.
버그 바운티¶
Wagtail에는 “버그 바운티” 프로그램이 없습니다. 저희는 모든 사람의 보고를 감사히 받고 수락하며, 귀하 및/또는 귀하의 조직에 기꺼이 크레딧을 제공하지만, 취약점 보고에 대해 “보상”할 수는 없습니다.
“구걸 바운티(Beg Bounties)”는 보안 연구원들 사이에서 계속 증가하고 있으며, 이는 우리가 용납하거나 지원하지 않는 것입니다.
CVE ID¶
게시될 때, Wagtail의 취약점에는 CVE(Common Vulnerability and Exposures) ID(예: CVE-2020-15118)가 부여됩니다. Wagtail 프로젝트는 GitHub의 보안 권고를 사용하여 취약점을 기록하고, CVE ID를 요청하며, 예정된 및 과거의 취약점을 모두 추적합니다. 따라서 GitHub는 Wagtail의 CNA(CVE Numbering Authority) 역할을 합니다.
Wagtail에서 취약점을 발견한 경우, 위 정보를 사용하여 보고해주세요 - CVE ID를 요청하지 마세요. CVE는 해결 과정의 일부로 보안팀에서 요청하며 필요한 경우 세부 정보와 크레딧으로 올바르게 채워지며, 그렇지 않으면 요청해서는 안 됩니다.
Wagtail 보안팀과 논의되지 않은 취약점에 대해 발급되거나, 또는 잘못 발급되거나 요청된 모든 CVE는 이의가 제기될 것이며 나중에 거부될 수 있습니다.
Wagtail이 보안 문제를 공개하는 방법¶
보안 문제를 비공개 토론에서 공개로 전환하는 과정에는 여러 단계가 포함됩니다.
확인된 보안 문제가 해결될 때까지 정해진 기간은 없습니다. 이는 문제에 따라 다르지만, 가능한 한 빨리 보안 릴리스를 발행하는 것이 Wagtail 팀의 우선순위가 될 것입니다.
문제 제보자는 문제를 공개할 계획인 날짜에 대한 알림을 받게 됩니다. 공개 당일, 저희는 다음 단계를 따를 것입니다:
Wagtail의 코드베이스에 관련 패치를 적용합니다. 이 패치의 커밋 메시지는 보안 문제를 위한 것임을 나타내지만, 문제에 대해 자세히 설명하지는 않습니다. 대신, 다가오는 공개에 대해 경고할 것입니다.
Python 패키지 인덱스에 새 패키지를 배치하고, Wagtail의 GitHub 저장소에 새 릴리스를 태그하고, Wagtail의 릴리스 노트를 업데이트하여 관련 릴리스를 발행합니다.
Wagtail의 GitHub 저장소에 보안 권고를 게시합니다. 이는 문제와 해결책을 자세히 설명하고, 관련 패치와 새 릴리스를 가리키며, 문제 제보자에게 크레딧을 제공합니다(제보자가 공개적으로 신원을 밝히기를 원하는 경우).
Wagtail 토론 게시판, Slack 워크스페이스 및 X 피드(@WagtailCMS)에 보안 권고로 연결되는 공지를 게시합니다.
보고된 문제가 특히 시간에 민감하다고 판단되는 경우(예: 알려진 익스플로잇이 있는 경우), 사전 통지와 공개 사이의 시간이 상당히 단축될 수 있습니다.
자주 보고되는 이슈¶
다음 우려 사항은 이전에 여러 연구원에 의해 제기되었지만, Wagtail 보안팀의 전체 조사 결과 Wagtail에서 보안 문제를 제기하지 않는 것으로 판단되었습니다. 연구원들은 이러한 보고서의 직접적인 중복을 제출하지 않도록 요청하지만, 간과되었을 수 있는 측면에 대한 추가 피드백은 환영합니다.
CSV 내보내기 내 수식/매크로 주입¶
Wagtail은 다양한 곳에서 데이터를 CSV 형식으로 내보내는 옵션을 제공하며, 여러 제보자들이 악의적인 사용자가 Microsoft Excel과 같은 스프레드시트 패키지로 로드될 때 수식으로 해석될 데이터를 삽입할 가능성을 제기했습니다. 저희는 이것을 Wagtail의 보안 취약점으로 간주하지 않습니다. RFC 4180에 정의된 CSV는 순수한 데이터 형식이며 해당 데이터가 어떻게 해석되어야 하는지에 대해 어떠한 주장도 하지 않습니다. 특정 소프트웨어가 일부 문자열을 실행 가능한 코드로 처리하기로 한 결정은 사양에 근거가 없습니다. 따라서 Wagtail은 생성한 데이터가 미사일 제어 시스템에 로드되는 것에 대해 책임이 없는 것처럼, 안전하지 않게 해석하는 소프트웨어 패키지에 로드되는 것에 대해 책임질 수 없습니다. 이는 Google 보안팀의 입장과 일치합니다.
CSV 형식에는 수식이나 매크로 개념이 없으므로, 데이터가 그런 식으로 해석되는 것을 방지하기 위해 데이터를 이스케이프하는 것에 대한 합의된 규칙도 없습니다. 필드 앞에 따옴표 문자를 붙이는 것과 같이 일반적으로 제안되는 접근 방식은 CSV 사양을 올바르게 따르는 소프트웨어에 의해 해석될 때 합법적인 데이터(예: ‘+’로 시작하는 전화번호)를 손상시킬 수 있습니다.
Wagtail의 데이터 내보내기는 기본적으로 XLSX로 설정되어 있으며, 이는 이러한 문제 없이 스프레드시트 소프트웨어로 로드할 수 있습니다. 이는 사용자가 더 친숙한 XLSX 형식 대신 명시적으로 CSV를 선택해야 하므로 CSV 파일을 안전하지 않게 처리할 위험을 최소화합니다.
문서 업로드를 통한 사이트 간 스크립팅¶
사용자 업로드 파일을 허용하는 모든 시스템은 잠재적인 보안 위험입니다. 여러 과거 보고서에서 업로드가 제대로 보호되지 않으면 사이트 간 스크립팅(XSS)을 통해 임의의 코드가 실행될 수 있다는 문제를 제기했습니다.
Wagtail이 이러한 파일을 직접 제공할 때(즉, 콘텐츠가 응답에서 직접 반환될 때), 필요한 보호 조치는 이미 마련되어 있습니다. 이것은 이미지의 경우 동적 이미지 제공 뷰를 사용하고 WAGTAILDOCS_SERVE_METHOD를 serve_view 로 설정하여 수행할 수 있습니다. 그러나 파일이 저장된 위치에서 직접 제공될 때(예: AWS S3 버킷에서 직접), Wagtail은 파일이 제공되는 방식에 대해 거의 또는 전혀 제어할 수 없습니다. 대신, 개발자는 파일 저장을 구성하여 파일을 제공할 때 주의를 기울여야 합니다. 원격 저장소에서 직접 파일을 제공하기 전에 이미지 및 문서에 대한 관련 문서를 읽어야 합니다.
원격 저장소에 필요한 고려 사항이 이미 문서화되어 있으므로, 특히 미디어 소스에서 직접 제공될 때 저장소의 잘못된 구성을 Wagtail의 보안 취약점으로 간주하지 않습니다. 여기에는 MEDIA_URL 을 통해 Django의 내장 미디어 제공 기능을 사용할 때도 포함됩니다. Wagtail의 내장 제공 뷰의 취약점은 여전히 고려됩니다.
Wagtail은 PDF 문서 내에서 JavaScript 실행을 차단하기 위한 조치를 취하지 않습니다. 브라우저가 이를 허용하는 범위 내에서, 그들은 원본 사이트나 네트워크에 접근할 수 없는 잠긴 샌드박스 환경에서 그렇게 합니다. PDF에서 경고 상자를 열 수 있는 능력 자체가 실행 가능한 사이트 간 스크립팅 공격을 입증하는 것은 아니며, 저희는 이것을 보안 취약점으로 간주하지 않습니다. 그러나 PDF 문서를 통해 실제 사용자 데이터 유출을 입증하는 보고서는 기꺼이 고려할 것입니다.