| RFC 9116 | security.txt | 2022년 4월 |
| Foudil & Shafranovich | 정보 제공용 | [페이지] |
연구자들이 보안 취약점을 발견했을 때, 적절한 보고 채널이 부족한 경우가 많습니다. 그 결과, 취약점이 보고되지 않은 채 남을 수 있습니다. 이 문서는 기계 판독 가능 형식 ("security.txt")을 정의하여 조직이 취약점 공개 관행을 설명하도록 돕고, 연구자가 취약점을 더 쉽게 보고할 수 있게 합니다.¶
이 문서는 인터넷 표준 트랙 명세가 아니며, 정보 제공 목적으로 게시되었습니다.¶
이 문서는 인터넷 엔지니어링 태스크 포스 (IETF)의 산물입니다. 이는 IETF 커뮤니티의 합의를 나타냅니다. 이 문서는 공개 검토를 받았으며 인터넷 엔지니어링 운영 그룹 (IESG)에 의해 게시 승인을 받았습니다. IESG가 승인한 모든 문서가 인터넷 표준의 어떤 수준에 대한 후보가 되는 것은 아닙니다. RFC 7841의 2절을 참조하십시오.¶
이 문서의 현재 상태, 모든 정오표 및 이에 대한 피드백 제공 방법에 관한 정보는 https://www.rfc-editor.org/info/rfc9116에서 확인할 수 있습니다.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
많은 보안 연구자는 특정 리소스의 소유자에게 연락할 보고 채널이 없고, 해당 소유자의 취약점 공개 관행에 관한 정보도 제공되지 않기 때문에, 조직에 보안 취약점을 보고할 수 없는 상황을 마주합니다.¶
[RFC2142]의 4절에 따르면, 보안 문제에 관한 통신을 위해 <SECURITY@domain> 이메일 주소를 사용하는 기존 관례가 있습니다. 이 관례는 도메인당 하나의 이메일 기반 통신 채널만 제공하며, 도메인 소유자가 보안 공개 관행에 관한 정보를 게시할 방법을 제공하지 않습니다.¶
또한 [RFC3013]의 2절에는 인터넷 서비스 제공자 (ISP)를 위한 연락 관례가, [RFC2350]의 3.2절에는 컴퓨터 보안 사고 대응 팀(CSIRT)을 위한 연락 관례가, [RFC2196]의 5.2절에는 사이트 운영자를 위한 연락 관례가 규정되어 있습니다. [RFC7485]에 따르면, IP 주소, 자율 시스템 번호(ASN) 및 도메인 이름의 소유자에 대해 지역 인터넷 레지스트리(RIR)와 도메인 레지스트리가 제공하는 연락 정보도 있습니다. 그러나 이들 중 어느 것도 보안 연구자가 취약점을 보고하기 위해 조직의 연락 정보와 취약점 공개 관행을 찾는 방법이라는 문제를 다루지 않습니다.¶
이 문서에서는 조직이 보안 공개 관행과 연락 방법에 관한 정보를 전달하기 위한, 더 풍부하고 기계가 구문 분석할 수 있으며 더 확장 가능한 방법을 정의합니다. 취약점 공개의 다른 세부 사항은 이 문서의 범위를 벗어납니다. 독자는 [ISO.29147.2018] 또는 [CERT.CVD] 같은 다른 문서를 참고하는 것이 좋습니다.¶
[CERT.CVD]에 따르면, "vulnerability response"는 제품 취약점 보고를 의미하며, 이는 네트워크 침입 및 침해된 웹사이트에 대한 보고("incident response")와 관련은 있지만 구별됩니다. 이 문서에서 정의한 메커니즘은 전자 ("vulnerability response")에 사용되도록 의도되었습니다. 구현자가 이 메커니즘을 사고 대응에 활용하려는 경우, 5.1절에서 논의하는 추가 보안 고려 사항을 알고 있어야 합니다.¶
"security.txt" 파일은 조직이 보안 공개 관행과 관련하여 유지하는 다른 공개 리소스를 보완하기 위한 것이며, 이를 대체하거나 대신하기 위한 것이 아닙니다.¶
이 문서에서 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"은 여기에 표시된 것처럼 모두 대문자로 나타나는 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석됩니다.¶
"researcher"라는 용어는 [ISO.29147.2018] 및 [CERT.CVD]의 "finder" 및 "reporter"라는 용어에 해당합니다. "organization"이라는 용어는 [ISO.29147.2018] 및 [CERT.CVD]의 "vendor"라는 용어에 해당합니다.¶
"implementors"라는 용어에는 취약점 공개 프로세스에 관여하는 모든 당사자가 포함됩니다.¶
이 문서는 알려진 위치에 배치되는 텍스트 파일을 정의하며, 이 파일은 특정 조직의 취약점 공개 관행에 관한 정보를 제공합니다. 이 파일의 형식은 기계가 구문 분석할 수 있으며, 4절에 정의된 ABNF 문법을 MUST 따라야 합니다. 이 파일은 보안 연구자가 보안 취약점을 공개할 때 도움을 주기 위한 것입니다.¶
관례상 이 파일의 이름은 "security.txt"입니다. 위치와 범위는 3절에 설명되어 있습니다.¶
이 텍스트 파일에는 서로 다른 값을 가진 여러 필드가 포함됩니다. 필드에는 콜론까지의 필드 첫 부분인 "name"(예: "Contact:")이 포함되며, 이는 [RFC5322]의 3.6.8절에서 "field-name"에 대해 정의한 구문을 따릅니다. 필드 이름은 [RFC5234]의 2.3절에 따라 대소문자를 구분하지 않습니다. "value"는 필드 이름 뒤에 오며(예: "mailto:security@example.com"), [RFC5322]의 3.2.5절에서 "unstructured"에 대해 정의한 구문을 따릅니다. 파일은 빈 줄을 포함할 수도 MAY 있습니다.¶
필드는 항상 이름과 값으로 구성되어야 MUST 합니다 (예: "Contact: mailto:security@example.com"). "security.txt" 파일은 필드를 무제한으로 가질 수 있습니다. 각 필드는 자체 줄에 나타나야 MUST 합니다. 필드 정의에서 달리 지정하지 않는 한, 단일 필드에 대해 여러 값을 함께 연결해서는 MUST NOT 안 됩니다. 특정 필드의 정의에서 달리 표시하지 않는 한, 필드는 여러 번 나타날 수도 MAY 있습니다.¶
구현자는 일부 필드가 [RFC3986]의 2.1절에 따른 퍼센트 인코딩을 사용하는 URI를 포함할 수 있음을 알고 있어야 합니다.¶
"security.txt" 파일은 [RFC4880]의 7절에 설명된 OpenPGP 클리어텍스트 서명을 사용하여 디지털 서명하는 것이 RECOMMENDED됩니다. 디지털 서명이 사용되는 경우, 조직이 2.5.2절에 따른 "Canonical" 필드를 사용하여 디지털 서명이 파일의 위치를 인증할 수 있게 하는 것도 RECOMMENDED됩니다.¶
서명을 생성하는 데 사용된 키를 검증하는 경우, 사용 중인 키가 자신이 신뢰하는 키인지 확인하는 것은 항상 보안 연구자의 책임입니다.¶
다른 많은 형식과 프로토콜처럼, 이 형식은 시간이 지나며 계속 변화하는 인터넷 환경에 맞도록 변경될 필요가 있을 수 있습니다. 따라서 6.2절에 정의된 필드용 IANA 레지스트리를 통해 확장성이 제공됩니다. 해당 프로세스를 통해 등록된 모든 필드는 선택 사항으로 간주되어야 MUST 합니다. 확장성과 상호 운용성을 장려하기 위해, 연구자는 명시적으로 지원하지 않는 모든 필드를 무시해야 MUST 합니다.¶
일반적으로, 구현자는 "자신이 하는 일에는 보수적이고, 다른 이에게서 받아들이는 것에는 관대하라"([RFC0793]에 따름)는 원칙을 따라야 합니다.¶
달리 명시되지 않는 한, 모든 필드는 선택 사항으로 간주되어야 MUST 합니다.¶
"Acknowledgments" 필드는 보안 연구자가 자신의 보고에 대해 인정받는 페이지에 대한 링크를 나타냅니다. 참조된 페이지는 보안 취약점을 보고하고 이를 해결하기 위해 협력한 보안 연구자를 나열해야 합니다. 조직은 향후 공격을 방지하기 위해 게시되는 취약점 정보를 제한하는 데 주의해야 합니다.¶
이 필드가 웹 URI를 나타내는 경우, [RFC7230]의 2.7.2절에 따라 "https://"로 시작해야 MUST 합니다.¶
예:¶
Acknowledgments: https://example.com/hall-of-fame.html¶
보안 감사 페이지의 예:¶
We would like to thank the following researchers: (2017-04-15) Frank Denis - Reflected cross-site scripting (2017-01-02) Alice Quinn - SQL injection (2016-12-24) John Buchner - Stored cross-site scripting (2016-06-10) Anna Richmond - A server configuration issue¶
"Canonical" 필드는 "security.txt" 파일이 위치한 표준 URI를 나타내며, 이는 일반적으로 "https://example.com/.well-known/security.txt"와 같은 형식입니다. 이 필드가 웹 URI를 나타내는 경우, [RFC7230]의 2.7.2절에 따라 "https://"로 시작해야 MUST 합니다.¶
이 필드는 주어진 URI에서 가져온 "security.txt"가 해당 URI에 적용되도록 의도되었음을 나타내지만, 파일 안에 나열된 모든 표준 URI에 적용되는 것으로 해석되어서는 MUST NOT 안 됩니다. 연구자는 특정 표준 URI가 적용 가능한지 판단하기 위해 2.3절에 따른 디지털 서명 같은 추가 신뢰 메커니즘을 사용해야 SHOULD 합니다.¶
이 필드가 "security.txt" 파일 안에 나타나고, 해당 파일을 가져오는 데 사용된 URI가 어떤 canonical 필드에도 나열되어 있지 않다면, 파일 내용은 신뢰해서는 SHOULD NOT 안 됩니다.¶
Canonical: https://www.example.com/.well-known/security.txt Canonical: https://someserver.example.com/.well-known/security.txt¶
"Contact" 필드는 보안 취약점을 보고하기 위해 연구자가 사용해야 하는 방법을 나타내며, 여기에는 이메일 주소, 전화번호 및/또는 연락 정보가 있는 웹 페이지가 포함될 수 있습니다. 이 필드는 "security.txt" 파일에 항상 있어야 MUST 합니다. 이 필드가 웹 URI를 나타내는 경우, [RFC7230]의 2.7.2절에 따라 "https://"로 시작해야 MUST 합니다. 보안 이메일 주소는 [RFC2142]의 4절에 정의된 관례를 사용해야 합니다.¶
값은 [RFC3986]의 3절에 설명된 URI 구문을 따라야 MUST 합니다. 이는 이메일 주소와 전화번호를 지정할 때 [RFC6068] 및 [RFC3966]에 정의된 "mailto" 및 "tel" URI 스킴을 사용해야 함을 의미합니다. 이 필드의 값이 이메일 주소인 경우, 2.5.4절에 따라 암호화를 사용하는 것이 RECOMMENDED됩니다.¶
이들은 선호도 순으로 나열되어야 SHOULD 하며, 첫 번째 항목이 선호되는 연락 방법, 두 번째 항목이 두 번째로 선호되는 연락 방법 등이 됩니다. 아래 예에서 첫 번째 이메일 주소 ("security@example.com")가 선호되는 연락 방법입니다.¶
Contact: mailto:security@example.com Contact: mailto:security%2Buri%2Bencoded@example.com Contact: tel:+1-201-555-0123 Contact: https://example.com/security-contact.html¶
"Encryption" 필드는 보안 연구자가 암호화된 통신에 사용해야 하는 암호화 키를 나타냅니다. 키는 이 필드에 나타나서는 MUST NOT 안 됩니다. 대신 이 필드의 값은 키를 가져올 수 있는 위치를 가리키는 URI여야 MUST 합니다. 이 필드가 웹 URI를 나타내는 경우, [RFC7230]의 2.7.2절에 따라 "https://"로 시작해야 MUST 합니다.¶
키의 진위성을 검증하는 경우, 지정된 키가 자신이 신뢰하는 키인지 확인하는 것은 항상 보안 연구자의 책임입니다. 연구자는 이 키가 2.3절에서 참조된 디지털 서명을 생성하는 데 사용되었다고 가정해서는 안 됩니다.¶
웹 서버에서 제공되는 OpenPGP 키의 예:¶
Encryption: https://example.com/pgp-key.txt¶
OPENPGPKEY DNS 레코드에서 제공되는 OpenPGP 키의 예:¶
Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY¶
지문으로 참조되는 OpenPGP 키의 예:¶
Encryption: openpgp4fpr:5f2de5521c63a801ab59ccb603d49de44b29100f¶
"Expires" 필드는 "security.txt" 파일에 포함된 데이터가 오래되어 더 이상 사용해서는 안 되는 날짜와 시간을 나타냅니다(5.3절에 따름). 이 필드의 값은 [RFC3339]에 정의된 대로 [ISO.8601-1] 및 [ISO.8601-2]의 인터넷 프로파일에 따라 형식화됩니다. 오래된 정보가 되는 것을 피하기 위해, 이 필드의 값은 미래 1년 미만으로 설정하는 것이 RECOMMENDED됩니다.¶
이 필드는 항상 있어야 MUST 하며 한 번을 초과하여 나타나서는 MUST NOT 안 됩니다.¶
Expires: 2021-12-31T18:37:07z¶
"Hiring" 필드는 벤더의 보안 관련 채용 직무에 연결하는 데 사용됩니다. 이 필드가 웹 URI를 나타내는 경우, [RFC7230]의 2.7.2절에 따라 "https://"로 시작해야 MUST 합니다.¶
Hiring: https://example.com/jobs.html¶
"Policy" 필드는 취약점 공개 정책이 위치한 곳에 대한 링크를 나타냅니다. 이는 보안 연구자가 조직의 취약점 보고 관행을 이해하는 데 도움을 줄 수 있습니다. 이 필드가 웹 URI를 나타내는 경우, [RFC7230]의 2.7.2절에 따라 "https://"로 시작해야 MUST 합니다.¶
예:¶
Policy: https://example.com/disclosure-policy.html¶
"Preferred-Languages" 필드는 보안 보고서를 제출할 때 선호되는 자연어 집합을 나타내는 데 사용할 수 있습니다. 이 집합은 쉼표로 구분된 여러 값을 나열할 수도 MAY 있습니다. 이 필드가 포함되는 경우, 최소 하나의 값이 나열되어야 MUST 합니다. 이 집합 안의 값은 [RFC5646]에 정의된 언어 태그입니다. 이 필드가 없으면, 보안 연구자는 [RFC2277]의 4.5절에 따라 영어가 사용될 언어라고 가정할 수 있습니다.¶
이들이 나타나는 순서는 우선순위를 나타내지 않습니다. 나열된 언어는 동등한 우선순위를 갖도록 의도됩니다.¶
이 필드는 한 번을 초과하여 나타나서는 MUST NOT 안 됩니다.¶
예(영어, 스페인어 및 프랑스어):¶
Preferred-Languages: en, es, fr¶
# Our security address Contact: mailto:security@example.com # Our OpenPGP key Encryption: https://example.com/pgp-key.txt # Our security policy Policy: https://example.com/security-policy.html # Our security acknowledgments page Acknowledgments: https://example.com/hall-of-fame.html Expires: 2021-12-31T18:37:07z¶
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 # Canonical URI Canonical: https://example.com/.well-known/security.txt # Our security address Contact: mailto:security@example.com # Our OpenPGP key Encryption: https://example.com/pgp-key.txt # Our security policy Policy: https://example.com/security-policy.html # Our security acknowledgments page Acknowledgments: https://example.com/hall-of-fame.html Expires: 2021-12-31T18:37:07z -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2 [signature] -----END PGP SIGNATURE-----¶
웹 기반 서비스의 경우, 조직은 도메인 이름 또는 IP 주소에 대해 [RFC8615]에 따라 "security.txt" 파일을 "/.well-known/" 경로 아래에 배치해야 MUST 합니다. 예: https://example.com/.well-known/security.txt. 레거시 호환성을 위해 "security.txt" 파일은 최상위 경로에 배치되거나, "/.well-known/" 경로 아래의 "security.txt" 파일로 리디렉션될 수도 있습니다([RFC7231]의 6.4절에 따름). "security.txt" 파일이 두 위치 모두에 존재하는 경우, "/.well-known/" 경로에 있는 파일을 사용해야 MUST 합니다.¶
파일은 HTTP 1.0 또는 그 이상의 버전을 통해 접근되어야 MUST 하며, 파일 접근은 [RFC7230]의 2.7.2절에 따라 "https" 스킴을 사용해야 MUST 합니다. 이 파일은 [RFC2046]의 4.1.3절에 따라 기본 charset 매개변수가 "utf-8"로 설정된 "text/plain" Content-Type을 가져야 MUST 합니다.¶
"security.txt" 파일과 그러한 파일 안에 표시된 리소스를 가져오는 과정에서 리디렉션이 발생할 수 있습니다([RFC7231]의 6.4절에 따름). 연구자는 이러한 리디렉션이 악의적이지 않거나 공격자가 제어하는 리소스를 가리키지 않는지 확인하기 위해 추가 분석(5.2절에 따름)을 수행해야 합니다.¶
"security.txt" 파일은 이를 가져오는 데 사용된 URI의 도메인 또는 IP 주소에만 적용되어야 MUST 하며, 그 하위 도메인이나 상위 도메인에는 적용되지 않습니다. "security.txt" 파일은 해당 파일을 게시한 조직이 제공하는 제품과 서비스에도 적용될 수 MAY 있습니다.¶
1.1절에 따라, 이 명세는 취약점 대응을 위한 것입니다. 구현자가 이를 사고 대응에 사용하려는 경우, 5.1절에서 논의하는 추가 보안 고려 사항을 알고 있어야 합니다.¶
조직은 취약점 공개 프로세스의 범위와 세부 사항에 대한 추가 세부 정보를 제공하기 위해 2.5.7절에 따른 policy 지시자를 사용해야 SHOULD 합니다.¶
아래에 몇 가지 예가 나옵니다:¶
# The following only applies to example.com. https://example.com/.well-known/security.txt # This only applies to subdomain.example.com. https://subdomain.example.com/.well-known/security.txt # This security.txt file applies to IPv4 address of 192.0.2.0. https://192.0.2.0/.well-known/security.txt # This security.txt file applies to IPv6 address of 2001:db8:8:4::2. https://[2001:db8:8:4::2]/.well-known/security.txt¶
"security.txt" 파일의 파일 형식은 [RFC2046]의 4.1.3절에 정의된 일반 텍스트(MIME 유형 "text/plain")여야 MUST 하며, Net-Unicode 형식 [RFC5198]의 UTF-8 [RFC3629]을 사용하여 인코딩되어야 MUST 합니다.¶
이 파일의 형식은 아래 ABNF 정의를 따라야 MUST 합니다(이는 [RFC5234]의 핵심 ABNF 규칙을 통합하고 [RFC7405]의 대소문자 구분 문자열 지원을 사용합니다).¶
body = signed / unsigned
unsigned = *line (contact-field eol) ; one or more required
*line (expires-field eol) ; exactly one required
*line [lang-field eol] *line ; exactly one optional
; order of fields within the file is not important
; except that if contact-field appears more
; than once, the order of those indicates
; priority (see Section 3.5.3)
; signed is the production that should match the OpenPGP clearsigned
; document
signed = cleartext-header
1*(hash-header)
CRLF
cleartext
signature
cleartext-header = %s"-----BEGIN PGP SIGNED MESSAGE-----" CRLF
hash-header = %s"Hash: " hash-alg *("," hash-alg) CRLF
hash-alg = token
; imported from RFC 2045; see RFC 4880 Section
; 10.3.3 for a pointer to the registry of
; valid values
;cleartext = 1*( UTF8-octets [CR] LF)
; dash-escaped per RFC 4880 Section 7.1
cleartext = *((line-dash / line-from / line-nodash) [CR] LF)
line-dash = ("- ") "-" *UTF8-char-not-cr
; MUST include initial "- "
line-from = ["- "] "From " *UTF8-char-not-cr
; SHOULD include initial "- "
line-nodash = ["- "] *UTF8-char-not-cr
; MAY include initial "- "
UTF8-char-not-dash = UTF8-1-not-dash / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1-not-dash = %x00-2C / %x2E-7F
UTF8-char-not-cr = UTF8-1-not-cr / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1-not-cr = %x00-0C / %x0E-7F
; UTF8 rules from RFC 3629
UTF8-octets = *( UTF8-char )
UTF8-char = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1 = %x00-7F
UTF8-2 = %xC2-DF UTF8-tail
UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
%xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) /
%xF1-F3 3( UTF8-tail ) /
%xF4 %x80-8F 2( UTF8-tail )
UTF8-tail = %x80-BF
signature = armor-header
armor-keys
CRLF
signature-data
armor-tail
armor-header = %s"-----BEGIN PGP SIGNATURE-----" CRLF
armor-keys = *(token ": " *( VCHAR / WSP ) CRLF)
; Armor Header Keys from RFC 4880
armor-tail = %s"-----END PGP SIGNATURE-----" CRLF
signature-data = 1*(1*(ALPHA / DIGIT / "=" / "+" / "/") CRLF)
; base64; see RFC 4648
; includes RFC 4880 checksum
line = [ (field / comment) ] eol
eol = *WSP [CR] LF
field = ; optional fields
ack-field /
can-field /
contact-field / ; optional repeated instances
encryption-field /
hiring-field /
policy-field /
ext-field
fs = ":"
comment = "#" *(WSP / VCHAR / %x80-FFFFF)
ack-field = "Acknowledgments" fs SP uri
can-field = "Canonical" fs SP uri
contact-field = "Contact" fs SP uri
expires-field = "Expires" fs SP date-time
encryption-field = "Encryption" fs SP uri
hiring-field = "Hiring" fs SP uri
lang-field = "Preferred-Languages" fs SP lang-values
policy-field = "Policy" fs SP uri
date-time = < imported from Section 5.6 of [RFC3339] >
lang-tag = < Language-Tag from Section 2.1 of [RFC5646] >
lang-values = lang-tag *(*WSP "," *WSP lang-tag)
uri = < URI as per Section 3 of [RFC3986] >
ext-field = field-name fs SP unstructured
field-name = < imported from Section 3.6.8 of [RFC5322] >
unstructured = < imported from Section 3.2.5 of [RFC5322] >
token = < imported from Section 5.1 of [RFC2045] >
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
BIT = "0" / "1"
CHAR = %x01-7F
; any 7-bit US-ASCII character,
; excluding NUL
CR = %x0D
; carriage return
CRLF = CR LF
; Internet standard newline
CTL = %x00-1F / %x7F
; controls
DIGIT = %x30-39
; 0-9
DQUOTE = %x22
; " (Double Quote)
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
HTAB = %x09
; horizontal tab
LF = %x0A
; linefeed
LWSP = *(WSP / CRLF WSP)
; Use of this linear-white-space rule
; permits lines containing only white
; space that are no longer legal in
; mail headers and have caused
; interoperability problems in other
; contexts.
; Do not use when defining mail
; headers and use with caution in
; other contexts.
OCTET = %x00-FF
; 8 bits of data
SP = %x20
VCHAR = %x21-7E
; visible (printing) characters
WSP = SP / HTAB
; white space
¶
URI와 well-known 리소스의 사용으로 인해, 아래에 요약된 고려 사항에 더해 [RFC3986] 및 [RFC8615]의 보안 고려 사항이 여기에 적용됩니다.¶
웹사이트를 침해한 공격자는 "security.txt" 파일도 침해하거나 자신의 사이트로 리디렉션을 설정할 수 있습니다. 이로 인해 보안 보고서가 조직에 수신되지 않거나 공격자에게 전송될 수 있습니다.¶
이를 방지하기 위해, 조직은 "Canonical" 필드를 사용하여 파일의 위치를 나타내고(2.5.2절에 따름), "security.txt" 파일에 디지털 서명하며(2.3절에 따름), 변조를 탐지하기 위해 파일과 참조된 리소스를 정기적으로 모니터링해야 합니다.¶
보안 연구자는 "security.txt" 파일을 사용하기 전에 디지털 서명을 검증하고 이용 가능한 과거 기록을 확인하는 것을 포함하여 이를 검증해야 합니다. "security.txt" 파일이 의심스럽거나 침해된 것으로 보이면, 사용해서는 안 됩니다.¶
권장되지는 않지만, 구현자는 "security.txt" 파일에 게시된 정보를 사고 대응에 사용하도록 선택할 수 있습니다. 그러한 경우, 해당 정보가 공격자에 의해 침해되었을 수 있으므로 이를 신뢰하기 전에 극도의 주의를 기울여야 합니다. 연구자는 Pretty Good Privacy(PGP) 서명의 대역 외 검증, DNSSEC 기반 접근 방식 등을 포함하여 그러한 데이터를 검증하기 위한 추가 방법을 사용해야 합니다.¶
파일과 파일 안에서 참조된 리소스를 가져올 때, 연구자는 모든 리디렉션을 기록해야 합니다. 리디렉션은 공격자가 제어하는 다른 도메인 또는 IP 주소로 이어질 수 있기 때문입니다. 파일 안에 포함된 정보를 사용하기 전에 그러한 리디렉션을 추가로 검사하는 것이 권장됩니다.¶
"security.txt" 파일에서 참조된 정보와 리소스가 부정확하거나 최신 상태로 유지되지 않으면, 보안 보고서가 조직에 수신되지 않거나 잘못된 연락처로 전송되어, 가능한 보안 문제가 제3자에게 노출될 수 있습니다. 오래된 정보를 포함한 "security.txt" 파일을 갖는 것보다 "security.txt" 파일이 없는 것이 더 나을 수 있습니다. 조직은 2.5.5절을 참조하여 "Expires" 필드를 사용해 파일의 데이터가 더 이상 유효하지 않은 시점을 연구자에게 알려야 합니다.¶
조직은 이 파일과 웹 페이지, 이메일 주소, 전화번호 같은 참조된 모든 리소스의 정보가 최신 상태로 유지되고, 접근 가능하며, 조직이 제어하고, 안전하게 유지되도록 해야 합니다.¶
침해되었거나 악의적인 사이트가 구문 분석 코드의 약점을 발견하거나 악용하려는 시도로 비정상적으로 큰 파일 또는 그 밖에 잘못 구성된 파일을 만들 수 있습니다. 연구자는 그러한 코드가 크거나 잘못 구성된 파일과 필드에 대해 견고한지 확인해야 하며, 32KB보다 큰 파일, 2,048자보다 긴 필드를 가진 파일 또는 1,000줄을 초과하는 파일을 구문 분석하지 않도록 선택할 수 있습니다. 4절에 정의된 ABNF 문법도 이러한 파일을 검증하는 방법으로 사용할 수 있습니다.¶
동일한 우려 사항은 "security.txt" 파일 안에서 참조된 다른 모든 리소스와, 이 파일의 게시 결과로 수신되는 모든 보안 보고서에도 적용됩니다. 이러한 리소스와 보고서는 적대적이거나, 잘못 구성되었거나, 악의적일 수 있습니다.¶
"security.txt" 파일의 존재는 연구자에게 해당 파일이 게시된 도메인 또는 IP 주소, 또는 파일을 게시한 조직이 제공하는 제품 및 서비스에 대해 보안 테스트를 수행할 권한을 제공하는 것으로 해석될 수 있습니다. 이로 인해 연구자에 의한 조직 대상 테스트가 증가할 수 있습니다. 반대로 "security.txt" 파일을 게시하지 않기로 한 결정은 해당 웹사이트를 운영하는 조직이 연구자에게 특정 사이트 또는 프로젝트에 대한 테스트 권한이 거부되었음을 알리는 방법으로 해석될 수 있습니다. 이로 인해 해당 조직에 보안 문제를 보고하는 연구자에게 반발이 발생할 수 있습니다.¶
따라서 연구자는 "security.txt" 파일의 존재 또는 부재가 보안 테스트 권한을 부여하거나 거부한다고 가정해서는 안 됩니다. 그러한 권한은 회사의 취약점 공개 정책(2.5.7절에 따름) 또는 새 필드(2.4절에 따름)에 표시될 수 있습니다.¶
다중 사용자/다중 테넌트 환경에서는 사용자가 "security.txt" 파일의 위치를 장악할 수 있을 수 있습니다. 조직은 제3자가 "security.txt" 및 "/.well-known/security.txt" 이름으로 페이지를 만들 수 없도록 루트에서 "security.txt" 네임스페이스를 예약해야 합니다.¶
"security.txt" 파일이 전송 중 변조되는 것을 막기 위해, 구현자는 파일 자체를 제공할 때와 그 안에서 참조된 모든 웹 URI를 가져올 때 [RFC7230]의 2.7.2절에 따라 HTTPS를 사용해야 MUST 합니다(이 명세에서 달리 명시된 경우 제외). TLS 핸드셰이크의 일부로, 연구자는 [RFC6125] 및 다음 고려 사항에 따라 제공된 X.509 인증서를 검증해야 합니다:¶
인증서는 온라인 인증서 상태 프로토콜(OCSP) [RFC6960], 인증서 해지 목록(CRL) 또는 유사한 메커니즘을 통해 해지 여부도 확인될 수 있습니다.¶
"security.txt" 파일이 HTTPS를 통해 제공될 수 없는 경우(예: localhost) 또는 유효하지 않은 인증서로 제공되는 경우, 내용이 전송 중 수정되었을 수 있으므로 추가적인 사람의 검증이 권장됩니다.¶
추가 보호 계층으로, 조직이 OpenPGP로 "security.txt" 파일에 디지털 서명하는 것도 권장됩니다(2.3절에 따름). 또한 보안 보고서가 전송 중 변조되거나 관찰되는 것을 막기 위해, HTTPS가 보고서 제출에 사용되지 않는 한, 조직은 암호화 키를 지정해야 합니다(2.5.4절에 따름).¶
그러나 그러한 키의 유효성을 판단하는 것은 이 명세의 범위를 벗어납니다. 보안 연구자는 이를 검증하기 위한 다른 안전한 수단을 마련해야 합니다.¶
[RFC2142]의 우려 사항과 유사하게, 조직이 "security.txt" 파일을 게시하면 스팸 보고서를 통한 서비스 거부 공격이 더 쉬워질 수 있습니다. 또한 자동화된 방식으로 보고서가 전송되거나, 사람의 분석 없이 자동 스캔의 결과로 보고서가 전송될 가능성이 높아집니다. 공격자는 이 파일을 사용하여 관련 없는 제3자의 리소스 및/또는 연락 정보를 나열함으로써 이들을 스팸 대상으로 삼을 수도 있습니다.¶
조직은 이 파일을 게시할 때의 장점과, 보안 보고서를 분석하는 데 필요한 리소스 증가 및 가능한 단점을 비교 검토해야 합니다.¶
보안 연구자는 자동화된 방식으로 보고서를 제출하거나 자동 스캔으로 인한 보고서를 제출하기 전에 "security.txt" 파일 안의 모든 정보를 검토해야 합니다.¶
구현자는 "security.txt" 파일 안에서 참조된 모든 리소스가 IANA에 등록되어 있지 않는 한([RFC8615]에 따름) Well-Known URI 네임스페이스를 가리켜서는 MUST NOT 안 됨을 알고 있어야 합니다.¶
IANA는 [RFC8615]의 템플릿을 사용하여 다음 추가 값으로 "Well-Known URIs" 레지스트리를 업데이트했습니다:¶
IANA는 [RFC8126]에 따라 "security.txt Fields" 레지스트리를 만들었습니다. 이 레지스트리는 이 명세에서 정의한 "security.txt" 파일에서 사용할 필드를 포함합니다.¶
새 등록 또는 업데이트는 [RFC8126]의 4.5절 및 5절에 설명된 "Expert Review" 지침에 따라 게시되어야 MUST 합니다. 이렇게 등록된 모든 새 필드는 이 명세의 새 버전이 게시되지 않는 한 이 명세에서 선택 사항으로 간주됩니다.¶
지정 전문가들은 제안된 등록 또는 업데이트가 이 형식을 사용하는 조직과 연구자에게 가치를 제공하는지, 그리고 [ISO.29147.2018] 및 [CERT.CVD] 같은 업계에서 받아들여진 취약점 공개 프로세스의 맥락에서 타당한지 판단해야 합니다.¶
새 등록 및 업데이트는 다음 정보를 포함해야 MUST 합니다:¶
새 또는 업데이트된 상태. 이는 다음 중 하나여야 MUST 합니다:¶
기존 등록은 이 문서의 향후 업데이트에 의해 적절하게 historic 또는 deprecated로 표시될 수 있습니다.¶
초기 레지스트리에는 다음 값이 포함됩니다:¶
저자들은 이 문서의 개발 과정에서 Tom Hudson, Jobert Abma, Gerben Janssen van Doorn, Austin Heap, Stephane Bortzmeyer, Max Smith, Eduardo Vela, 및 Krzysztof Kotowicz가 제공한 도움에 감사를 표합니다.¶
저자들은 또한 IETF의 LAST CALL, SAAG 및 SECDISPATCH 목록의 여러 구성원이 제공한 피드백에 감사를 표합니다.¶
Yakov Shafranovich는 L.T.S.에게도 감사드립니다(모든 것에 대해).¶
2.1. 주석
"#"(%x23) 기호로 시작하는 모든 줄은 주석으로 해석되어야 MUST 합니다. 주석의 내용에는 %x21-7E 및 %x80-FFFFF 범위의 ASCII 또는 Unicode 문자와 탭(%x09) 및 공백(%x20) 문자가 포함될 수 있습니다.¶
예:¶