비밀을 노출하지 않고 이메일 테스트 증거를 저장하는 방법
Once Email 편집팀검토 Once Email 한국어 편집 검토
글 안내
이 글을 읽을 가치
- 독창적 분석
- 우리는 수집된 증거를 최소화하기 위해 결함 질문부터 거꾸로 작업하여 비밀 및 관련 없는 개인 데이터로부터 재생산에 필요한 증거를 분리합니다.
- 동향 설명
- 클라우드 문제 추적기와 분산된 팀은 증거를 더 쉽게 공유하고 철회하기 어렵게 만들어 취소, 자르기 및 합성 샘플의 가치를 높입니다.
- 실용적 가치
- 독자는 진단을 지원하지 않는 라이브 자격 증명, 식별자 및 컨텍스트를 제거하면서 유용한 스크린샷, 헤더 및 버그 보고서를 생성할 수 있습니다.
이 페이지의 내용
스크린샷을 통해 이메일이 잘못 렌더링되었음을 입증할 수 있을 뿐만 아니라 작동하는 재설정 링크를 게시할 수도 있습니다. 복사된 헤더는 주소, 메시지 ID, 내부 호스트 또는 테스트 상관관계 값을 노출하면서 전달 경로를 설명할 수 있습니다. 좋은 증거는 결함을 재현하는 데 필요한 사실을 보존하고 해당 사실을 뒷받침하지 않는 모든 것을 제거합니다.
유효한 동안 인증 코드, 매직 링크, 비밀번호 재설정 URL을 자격 증명으로 취급하십시오. 수정은 만료 또는 취소를 대체하지 않습니다. 실제 비밀이 이미 공유된 경우 먼저 무효화하거나 교체하세요. 저장소에서 민감한 데이터 제거에 대한 GitHub의 공식 지침에서는 마찬가지로 저장소 정리를 시도하기 전에 노출된 비밀번호, 토큰 또는 자격 증명을 취소하거나 순환할 것을 권장합니다.
증거가 대답해야 하는 질문부터 시작하세요.
무엇이든 수집하기 전에 한 문장을 작성하십시오. "이 증거는 다음을 보여주어야 합니다..." 예에는 "모바일 제목 줄이 타임스탬프와 겹칩니다.", "명시된 유효 기간 이후에 재설정 메시지가 도착했습니다." 또는 "링크가 스테이징 호스트를 가리킵니다." 등이 있습니다.
그 문장은 수집을 제한합니다. 레이아웃 결함에는 원시 메시지가 아닌 잘린 스크린샷과 뷰포트 너비가 필요할 수 있습니다. 지연된 배달 결함에는 메시지 본문이 아닌 UTC 타임스탬프와 익명화된 상관 관계 값이 필요할 수 있습니다. 헤더 구문 분석 결함에는 고객의 원본 메시지가 아닌 작은 합성 헤더 샘플이 필요할 수 있습니다.
전용 테스트 계정과 허구 데이터로 생성된 증거를 선호합니다. 단지 문제가 이미 입증되었다는 이유만으로 실제 고객의 받은 편지함을 사용하지 마십시오.
무엇을 제거할지 알아두세요
보이는 데이터와 숨겨진 데이터를 모두 검토합니다. 일반적인 민감한 요소는 다음과 같습니다.
- 전체 보낸 사람 및 받는 사람 주소
- 인증 코드, 일회용 비밀번호 및 매직 링크
- 쿼리 문자열 및 조각을 포함한 모든 재설정 URL
- 비밀번호, API 키, 쿠키, 인증 필드 및 세션 식별자
Message-ID, 제공자 대기열 ID 및 애플리케이션 상관 ID;- 내부 호스트 이름, 개인 IP 주소 및 비공개 환경 URL
- 이름, 전화번호, 위치, 주문 세부정보 및 관련 없는 메시지 내용
- 스크린샷 주변에 캡처된 브라우저 탭, 북마크, 알림 및 데스크톱 파일 이름
- 수집 도구가 이미지를 보존하는 경우 이미지 메타데이터입니다.
RFC 5322는 Message-ID를 메시지의 특정 버전에 대해 기계가 읽을 수 있는 고유 식별자로 정의합니다. 이는 제어된 로그 상관 관계에 유용하지만 고유성은 공개 보고서에 일반적으로 원래 값이 아닌 안정적인 자리 표시자가 필요한 이유이기도 합니다.
버튼 뒤의 URL을 잊지 마세요. 스크린샷은 대상을 숨길 수 있지만, 복사된 HTML이나 마우스 오버 도구 설명은 전체 토큰을 표시합니다. 반대로, 이미지에 보이는 텍스트 위에 페인팅해도 기본 HTML, PDF 레이어, 문제 설명 또는 첨부 파일 이름에서 비밀이 제거되지는 않습니다.
가장 작고 안전한 증거 형식을 선택하세요
시각적 위치, 줄 바꿈, 대비 또는 반응형 레이아웃을 위해 잘린 스크린샷을 사용하세요. 정확한 문자나 구문 분석을 위해 짧은 텍스트 발췌문을 사용하세요. 배송 지연에 대해 구조화된 타임라인을 사용하세요. 반복 가능한 파서 테스트를 위해 합성 메시지를 사용합니다.
세 줄이 결함을 증명하는 경우 전체 메일함 내보내기를 첨부하지 마십시오. 기본적으로 원시 .eml 파일을 광범위하게 표시되는 이슈 추적기에 업로드하지 마십시오. 전체 본문, 모든 헤더 필드, 원격 리소스 URL 및 첨부 파일이 포함될 수 있습니다.
Once Email는 수신된 메시지를 표시하지만 증거 내보내기 또는 수정 보장을 제공하지 않습니다. 이메일 헤더 분석기는 붙여넣은 헤더 텍스트를 브라우저에서 로컬로 처리하고 필드를 식별하는 데 도움을 줄 수 있지만 공유할 수 있는 항목을 결정하는 책임은 여전히 사용자에게 있습니다.
안전하게 스크린샷 수정
승인되고 접근이 통제되는 장소에만 사본을 만들고 수정되지 않은 원본을 보관하십시오. 먼저 관련 구성요소를 자릅니다. 그런 다음 민감한 영역을 불투명 블록으로 교체합니다. 흐림, 픽셀화, 반투명 강조 표시 또는 편집 가능한 콘텐츠 위에 이동 가능한 모양 배치에 의존하지 마십시오.
수정된 결과를 병합된 이미지로 내보냅니다. 내보낸 파일을 다시 열고 확대하여 레이어를 숨기거나 텍스트를 복사하거나 대비를 높이는 방법으로 비밀을 복구할 수 없는지 확인합니다. 이미지 가장자리와 주변 브라우저 크롬에서 주소, 탭 및 알림을 확인하세요.
상황이 중요한 경우 의미 있는 자리 표시자를 사용하세요.
[TEST_RECIPIENT]
[VERIFICATION_CODE_REMOVED]
https://staging.example/reset?[TOKEN_REMOVED]
Message-ID: <[MESSAGE_ID_REMOVED]>
두 값이 일치해야 함을 표시하는 경우에만 반복 발생에 대해 동일한 자리 표시자를 유지하십시오. 그렇지 않으면 독자가 관련 없는 보고서를 연관시킬 수 있는 안정적인 가명을 만들지 마십시오.
버그를 파괴하지 않고 헤더와 링크를 수정합니다.
최소한의 관련 필드를 새 텍스트 파일에 복사합니다. 민감한 값을 바꾸십시오. 유일한 원본 증거를 편집하지 마십시오. 결함이 구문 분석과 관련된 경우 필드 이름, 접기 및 구분 기호를 유지하십시오.
배송 주문 문제의 경우 익명 처리된 샘플은 호스트, 주소 및 대기열 ID를 교체하는 동안 Received 타임스탬프를 유지할 수 있습니다. 인증 표시 문제의 경우 spf=pass와 같은 결과 키워드를 유지하면서 도메인을 sender.example와 같은 예약된 예로 바꾸세요. 보고서의 모든 대체 사항을 설명하십시오.
재설정 URL이 잘못된 호스트 이름을 나타내는 경우 구성표와 정리된 호스트만 유지한 다음 해당 구성 요소에 결함이 없는 한 전체 경로, 쿼리 및 조각을 교체합니다. 부분적인 실제 토큰을 보존하지 마십시오. 비밀 형식은 계정 식별자를 포함하거나 몇 개의 문자만 숨겨진 후에도 계속 사용할 수 있습니다.
제한된 증거와 공개 보고서를 분리하세요
주요 이슈에는 재현 가능한 단계, 예상 결과, 실제 결과, 환경, 구축 및 정리된 증거가 포함되어야 합니다. 승인된 보안 또는 개인정보 검토자가 원본을 정말로 필요로 하는 경우 소유자 및 삭제 날짜와 함께 조직의 승인된 제한된 채널에 원본을 배치하십시오. 채팅에 함부로 첨부하지 마세요.
제한된 사본에 접근할 수 있는 사람과 그 이유를 기록하십시오. 조사가 종료되거나 보존기간이 만료되면 삭제하세요. 임시 확인 메시지를 장기간 보관하면 종결된 결함을 개선하지 않고도 위험을 초래할 수 있습니다.
업로드 전 검토
2단계 검토를 사용하세요. 먼저 보고자는 표시되는 모든 값, 링크 대상, 파일 이름 및 메타데이터 필드를 확인합니다. 둘째, 다른 승인된 사람이 내보낸 아티팩트를 수신자가 보는 것처럼 확인합니다. 편집 가능한 소스가 아닌 업로드할 정확한 파일을 엽니다.
다음 사항을 확인하세요.
- 유효한 코드, 링크, 쿠키 또는 자격 증명이 남아 있지 않습니다.
- 주소와 개인 데이터는 엄격하게 필요하고 승인되지 않는 한 제거됩니다.
- 식별자는 자리 표시자이거나 제한된 채널에만 저장됩니다.
- 증거는 명시된 실제 결과를 여전히 입증합니다.
- 재현 단계에서는 테스트 데이터와 승인된 환경을 사용합니다.
- 문제의 가시성이 나머지 민감도와 일치합니다.
- 제한된 원본에 대해 보존 또는 삭제 결정이 존재합니다.
비밀이 이미 게시된 경우
링크 공유를 중지하고 시스템 소유자에게 문의하세요. 자격 증명을 만료 또는 교체하고, 해당하는 경우 영향을 받는 세션을 무효화하고, 보고서를 제한하고, 리포지토리 또는 문제 시스템의 정리 절차를 따르십시오. 최신 스크린샷이나 커밋을 삭제해도 캐시된 복사본, 알림, 포크 또는 기록은 제거되지 않을 수 있습니다.
격리 후에는 아티팩트를 검증된 편집 버전으로 교체하고 조직의 사건 프로세스를 통해 노출을 문서화합니다. 목표는 역사를 깨끗하게 보이게 만드는 것이 아닙니다. 비밀을 사용할 수 없게 만들고, 접근을 제한하고, 근본적인 결함을 수정하기에 충분한 안전한 증거를 보존하는 것입니다.
이 증거를 생성하는 완전한 기능적 작업 흐름을 보려면 개발자 이메일 테스트 체크리스트. 두 가지 방법을 함께 사용하면 보고서를 두 번째 보안 사고로 전환하지 않고도 메일 흐름 결함을 재현 가능하게 유지할 수 있습니다.