재현 조건 고정

재현은 실행 조건을 전달하는 일입니다

동료가 같은 결함을 확인하지 못하면 수정 완료 여부도 합의하기 어렵습니다. 화면 사진 하나만 있으면 어떤 계정으로 어떤 자료를 요청했는지 알 수 없습니다. 재현 카드는 결함이 드러나는 상태를 작은 절차로 고정하는 문서입니다. 이번에는 앞 모듈의 자료 보관 앱을 대상으로 버전·계정·자료·설정·검증 위치를 기록합니다. 재현 성공과 실제 유출 사고 발생은 서로 다른 주장입니다.

이 모듈의 공통 실행 환경

Node.js와 Python 3를 사용하며 외부 패키지를 설치하지 않습니다. 각 ZIP을 별도 폴더에 풀고 ZIP 루트에서 bash check.sh를 실행합니다. 합성 계정 alice·bob과 더미 비밀만 사용합니다. 앱 함수를 직접 부르므로 네트워크 요청은 발생하지 않습니다. 누적 미션 starter는 m07 solution을 이어받았습니다. 실습 fixture는 본인 환경에서만 사용하며 실제 사용자 자료와 운영 설정을 복사하지 않습니다.

과거 허가를 현재 허가로 오해하지 않습니다

기존 scope-001은 생성과 조회에 한정된 고정 시각 자료입니다. 업데이트·삭제·부정 테스트까지 수행하려면 행동 범위가 맞는지 다시 확인해야 합니다. 미션의 scope-008은 그 차이를 표현하는 별도 교재 승인 fixture입니다. parent로 scope-001을 연결하지만 과거 문서를 덮어쓰지 않습니다. 파일을 작성했다고 실제 소유자 승인이 생기는 것은 아니며 실제 점검은 승인자·대상·기간·행동을 별도로 확인합니다.

대상과 중단 조건을 먼저 씁니다

이번 대상은 in-process synthetic vault입니다. 127.0.0.1 주소가 코드에 있어도 실제 리스닝 서버에 연결한 검사는 아닙니다. 테스트가 실제 개인정보를 발견하거나 대상이 바뀌거나 예상하지 못한 오류를 내면 실행을 멈추고 원인을 확인합니다. 오류를 결함 재현 성공으로 바꾸어 쓰지 않습니다. 실행 범위가 불명확할 때는 확인할 소유자와 제외할 행동을 카드에 남깁니다.

비교할 코드를 식별합니다

secure-app.cjs는 현재 수정 앱이고 vulnerable-fixture.cjs는 소유자 확인 누락을 좁게 되살리는 비교 전용 파일입니다. 취약 코드 전체를 현재 서버로 되돌리지 않습니다. 앱 진입 파일만 적으면 의존하는 app.cjs·auth.cjs·security.cjs·store.py 변경을 놓칠 수 있습니다. 실제 실행 Node와 Python 버전, 검사 파일 경로와 관련 소스의 해시를 적습니다. 다른 버전에서 다시 실행했다면 별도 실행 기록을 만듭니다.

계정과 자료 상태를 고정합니다

Alice와 Bob은 서로 다른 합성 회원이며 자료 소유자는 서버 세션에서 결정합니다. Alice가 제목 synthetic인 자료를 하나 생성한 뒤 그 반환 id를 Bob 조회에 사용합니다. id가 언제나 1이라고 가정하지 않고 생성 응답에서 가져옵니다. 새 임시 SQLite 폴더를 매 실행 만들기 때문에 이전 실습의 삭제나 변경이 결과에 섞이지 않습니다. 테스트 후 폴더를 지워 자료 잔존도 줄입니다.

시간과 설정을 제어합니다

세션 시간이 우연히 지나면 타인 조회가 404 대신 401이 되어 소유자 검사를 통과한 것처럼 보일 수 있습니다. 이번 probe는 now가 0을 반환하고 ttl이 1000인 고정 시계를 사용합니다. Origin은 지정된 루프백 문자열이며 생성에 정상 CSRF를 붙입니다. 실제 만료 정책을 시험하는 것은 앞 모듈의 별도 회귀입니다. 재현 카드에는 고정 시계가 시간 경과 시험을 대체하지 않는다는 제한을 적습니다.

요청과 기대값을 분리합니다

관찰 전부터 정책 기대값을 정합니다. 타인 기존 자료 조회는 404, 소유자 조회는 200, 무인증 조회는 401, 없는 자료는 404입니다. 취약 fixture에서 타인이 200을 받는 것은 관찰값이며 올바른 기대값으로 바꾸지 않습니다. 응답 본문에 합성 자료가 있는지도 확인합니다. 상태 코드 하나만으로 자료 노출을 주장하면 성공 응답이지만 빈 본문인 경우를 구분하지 못합니다.

재현 불가를 조사합니다

401이면 세션 발급·만료와 전달 위치를 먼저 봅니다. 생성이 403이면 Origin이나 CSRF가 잘못되어 자료 준비가 끝나지 않았을 수 있습니다. storage_failure이면 SQLite 실행 환경과 자료 입력을 확인합니다. SyntaxError나 모듈 경로 오류는 앱 조건을 비교하기 전에 해결할 환경 문제입니다. 카드에 최초 실패 단계와 실제 값, 기대 값을 적으면 다른 담당자가 같은 부분부터 조사할 수 있습니다.

제출물의 완성 기준

재현 카드 한 장에 허가 참조, 코드 식별, 계정 관계, 초기 자료, 설정, 고정 시각, 요청 순서, 기대와 관찰, 정리 절차, 미검증 범위를 넣습니다. 팀원이 카드만 보고 재현 준비와 중단 여부를 판단할 수 있어야 합니다. 본문 전체나 세션 원문을 넣는 대신 합성 계정 역할과 검사 경로를 씁니다. 런타임 출력은 자신의 실행에서 복사하며 다른 사람의 성공 로그를 붙이지 않습니다.

검토 질문을 실제 순서로 적용합니다

먼저 대상이 승인 범위에 있는지 확인하고 준비 단계가 성공했는지 확인합니다. 다음에 비교 코드가 같은 데이터와 설정을 받는지 살펴봅니다. 마지막으로 결함 관찰이 어떤 검증 층에 속하는지 표시합니다. 함수 호출 성공을 HTTP 쿠키 전달이나 브라우저의 보안 정책 성공으로 확대하지 않습니다. 더 읽기의 Node 테스트 장은 독립된 테스트 상태와 임시 저장소를 자세히 다룹니다.

카드 작성 뒤 동료에게 절차를 읽어 보게 합니다. 계정 생성과 로그인, 자료 생성, 타인 요청의 순서가 빠지면 재현 조건이 달라집니다. 특히 자료를 생성하지 않고 존재하지 않는 id만 요청하면 수정 전에도 404가 나와 결함을 놓칠 수 있습니다. 정상 생성 결과를 먼저 확인하고 반환된 id를 사용한다는 문장을 명시합니다. 테스트가 환경 준비 실패로 중단되면 그 이후 정책 검사는 미실행으로 표시합니다.