소개
스튜디오 팀은 Sign out this browser가 세션을 처리하는 방식을 변경했습니다. 모든 세션을 끝내면 이전 쿠키는 실패하겠지만, 회원이 계속 사용하려는 다른 브라우저도 중단됩니다. 수용 여부를 판단하려면 보안 결과와 약속한 정상 동작을 모두 확인해야 합니다.
Browser A의 원래 계정 및 예약 요청을 Burp Repeater에 보관하고, 같은 회원에 대한 별도의 Browser B 세션을 만든 다음 A를 로그아웃한 뒤 둘을 테스트합니다. 인계할 산출물은 비공개 HTTP 증거와 비밀번호 없는 수용 여부 판단을 결합한 것입니다. 환경은 독립적이며 이전 파일, 세션, Burp 탭은 이어지지 않습니다.
먼저 로그아웃 후 예약 요청 다시 보내기를 완료하세요. Burp 임시 프로젝트를 시작하고, 가로채기를 끈 상태로 유지하며, 기록 행을 Repeater로 보내고, HTTP 상태를 읽고, XML 항목을 저장하는 방법을 알고 있어야 합니다. 이 실습에서는 조작 과정을 반복하고 독립 세션 비교를 추가합니다. 모든 계정과 예약은 합성 데이터입니다. 읽기와 일반적인 실수를 포함해 약 60분을 예상하세요. 이는 작성자의 추정치입니다.
Browser A의 정상적인 예약 확인하기
이 단계에서는 새 배포의 정상적인 사용 흐름을 확인합니다. Auditor를 열고 제공된 신원, 주소, 허가 범위를 읽으세요.
cat scope.json
http://members.test:8080/autumn, 사용자 이름 morgan, 비밀번호 PaperDay!47만 사용하세요. 예약은 Morgan Reed의 Printmaking, P12 좌석입니다. 제공된 범위, 대상 설정, 데이터, 프로세스를 보존하세요.
GUI 작업 공간에 Disconnected가 표시되면 상단의 Reconnect 버튼을 클릭하세요. 기존 창에 다시 연결되며 브라우저 쿠키, Burp 요청, 대상에서의 진행 상황은 유지됩니다.
Burp를 여세요. Temporary project를 선택한 상태로 Next를 클릭하고, Use Burp defaults를 선택한 상태로 Start Burp를 클릭하세요. Burp Suite is out of date가 표시되면 OK를 클릭하여 준비된 교육용 버전으로 계속하세요. 기본 창에서 Proxy → Intercept를 선택하고 버튼이 Intercept is off인지 확인하세요. Intercept is on이면 한 번 클릭하여 정상 요청이 일시 중지되지 않도록 하세요.
Browser A로 전환하세요. Chromium 주소 표시줄을 클릭하고 다음 URL을 입력한 뒤 Enter를 누르세요.
http://members.test:8080/autumn/
View my booking을 선택하고 Username에 morgan, Password에 PaperDay!47을 입력한 다음 Sign in을 클릭하세요. Chromium이 비밀번호 저장을 제안하면 Never를 선택하세요. Your next day of making에서 Morgan Reed, Printmaking, P12 좌석을 확인한 다음 Download booking을 클릭하세요. 실제 CSV에는 그 회원, 워크숍, 좌석이 들어 있습니다.
자격 증명에 오타가 있으면 Sign-in unsuccessful가 표시됩니다. try again을 사용해 제공된 값을 바로잡으세요. 경로가 잘못되었다면 정확한 기본 URL로 돌아가세요. 브라우저 연결 오류는 HTTP 거부가 아닙니다. Burp 마법사를 끝내고 가로채기와 정확한 주소를 확인한 다음 다시 이동하세요. LabEx 탭을 닫아도 환경은 초기화되지 않습니다.
Browser A의 성공한 요청 보관하기
이 단계에서는 다른 브라우저를 도입하기 전에 Browser A의 원래 세션을 보존합니다. Burp로 전환한 다음 Proxy → HTTP history로 이동하세요. members.test:8080의 GET /autumn/account 행을 찾아 마우스 오른쪽 버튼으로 클릭하고 Send to Repeater를 선택하세요. GET /autumn/booking.csv에 대해서도 반복하세요. 기록 필터 때문에 CSV가 보이지 않으면 필터 표시줄을 열고 Show all을 켜세요.
기본 탭 Repeater를 여세요. 첫 번째 요청 탭에서 계정 경로와 원래 Cookie: studio_session=... 헤더를 확인한 다음 Send를 클릭하세요. Raw 응답을 읽으세요. HTTP 200과 Morgan Reed의 예약이 표시됩니다. 두 번째 요청 탭을 선택하고 Send를 클릭하세요. 실제 CSV 예약 행과 함께 HTTP 200을 반환해야 합니다.
두 요청은 Browser A의 동일한 원래 세션 쿠키를 사용합니다. 호스트, 경로, 쿠키를 포함해 그대로 유지하세요. Repeater의 번호 탭은 요청을 식별하고, LabEx의 Browser A와 Browser B 탭은 독립 브라우저 프로필을 식별합니다. LabEx 탭을 바꿔도 Repeater 내부에서 선택된 요청은 바뀌지 않습니다.
이 성공 응답들이 기준 상태입니다. 처음부터 작동한 적이 없는 쿠키로는 로그아웃이 이후 실제 세션을 무효화했는지 판단할 수 없습니다. 잘못된 기록 행을 골랐다면 올바른 경로를 Repeater로 보내고 그 요청 탭을 대신 사용하세요. 탭 번호를 추측하지 말고 경로로 식별하세요.
현재 세션의 경계 테스트하기
이 단계에서는 브라우저 하나를 로그아웃하면 그 세션만 끝나는지 확인합니다. 독립 브라우저 프로필에는 고유한 쿠키 저장소가 있습니다. Browser A 내부의 두 번째 탭은 A의 쿠키를 공유하므로 이 비교에 사용할 수 없습니다.
LabEx의 Browser B 탭으로 전환하세요. Chromium 주소 표시줄에서 다음 주소로 이동하세요.
http://members.test:8080/autumn/login
같은 회원인 morgan과 PaperDay!47로 로그인하세요. 비밀번호 저장을 묻는다면 Never를 선택하세요. 예약을 확인하고 Download booking을 클릭하세요. Browser B는 로그인한 상태로 두세요. B의 계정 및 다운로드 성공 요청은 A가 로그아웃하기 전에 이루어져야 합니다.
신원을 직접 비교하려면 Burp → Proxy → HTTP history로 전환하세요. B의 가장 최근 /autumn/account 요청을 선택하고 Raw 요청을 살펴보세요. studio_session 값은 A의 원래 Repeater 탭에 보관된 값과 다릅니다. 두 세션은 모두 Morgan Reed를 나타내지만 서로 다른 인증 상태입니다. 어느 쿠키도 보고서에 복사하지 말고, A에 보관한 쿠키를 B의 쿠키로 교체하지 마세요.
Browser A로 전환하고 Sign out this browser를 클릭하세요. 로그인 페이지가 나타납니다. 그런 다음 Burp → Repeater로 전환하고 A의 원래 계정 요청에서 Send를 클릭하세요. 401 Unauthorized와 Sign in required가 나와야 합니다. A의 원래 예약 요청도 보내세요. HTTP 401이 나와야 하며 회원 예약 CSV가 없어야 합니다. 두 원래 쿠키를 그대로 유지하세요. 쿠키가 비어 있는 요청으로는 A의 이전 세션 무효화를 테스트할 수 없습니다.
왼쪽 창에서 변경되지 않은 Cookie를, 오른쪽 창에서 401 Unauthorized와 Sign in required를 읽으세요. 이는 이전에 작동하던 A의 세션을 거부한 것입니다.
이제 Browser B로 전환하세요. Chromium 주소 표시줄 옆의 새로고침 버튼을 클릭하세요. 예약 페이지에 Morgan Reed의 예약이 계속 표시되어야 합니다. Download booking을 다시 클릭하고 실제 다운로드를 확인하세요. 이 새로운 요청들이 지속적인 접근을 입증합니다. 새로고침하지 않은 채 화면에 남은 페이지는 오래된 것일 수 있습니다. B도 접근을 잃었다면 모든 세션을 끝내는 동작은 A의 이전 쿠키를 거부하더라도 이 과정에서 명시한 this browser 계약을 위반합니다. 다른 제품에서는 별도로 모든 곳에서 로그아웃하는 기능을 의도적으로 제공할 수 있습니다. 이는 다른 계약입니다.
마지막으로 Browser A로 전환하고 제공된 자격 증명으로 다시 로그인하여 예약을 확인한 다음 Download booking을 클릭하세요. 새 세션은 계속 작동합니다. A의 원래 Repeater 요청을 변경하지 않고 Burp로 돌아가세요. 가장 최근 응답은 로그아웃 후의 두 HTTP 401 응답으로 남아 있습니다.
이 한정된 변경은 수용할 수 있습니다. A의 이전 세션은 두 보호 리소스에서 모두 실패하고, B에 이미 만들어 둔 독립 세션은 계속 작동하며, 새 로그인도 작동합니다. 이것이 세션 보안의 모든 측면을 입증하는 것은 아닙니다.
실수로 B를 로그아웃하거나 A의 이전 쿠키를 교체했다면 두 개의 새로운 독립 세션을 만들고 전체 순서를 반복하세요. 두 브라우저에서 두 리소스의 기준 상태를 확인하고, A의 요청을 보관하고, A를 로그아웃하고, A의 요청을 다시 보내고, B에서 새로고침과 다운로드를 수행한 다음 A에서 새 로그인을 확인하세요. 탭을 다시 여는 것만으로 대체 세션이 만들어지지는 않습니다.
수용 판단을 뒷받침하는 테스트 증거 보존하기
이 단계에서는 비공개 증거와 근거 있는 수용 판단을 제출합니다. /home/labex/project에서 시작하는 Auditor로 전환하세요. 앞에서 배운 대로 umask 077은 이 셸의 새 파일 권한을 제한하고, mkdir -p는 증거 디렉터리를 만들며, chmod 700은 그 디렉터리를 비공개로 만듭니다.
umask 077
mkdir -p evidence
chmod 700 evidence
Burp → Repeater로 전환하세요. A의 원래 계정 요청을 선택하고 가장 최근 응답이 로그아웃 후 HTTP 401인지 확인하세요. Request 편집기를 마우스 오른쪽 버튼으로 클릭하고 Save item을 선택한 다음, File Name에 다음 절대 경로를 입력하세요.
/home/labex/project/evidence/account-after.xml
Base64-encode requests and responses를 선택한 상태로 Save를 클릭하세요. 성공 안내에 OK가 나타나면 닫으세요. A의 원래 예약 요청에도 반복하세요. 그 요청의 가장 최근 응답도 HTTP 401이어야 합니다.
/home/labex/project/evidence/booking-after.xml
이 XML 항목에는 A의 원래 쿠키가 들어 있습니다. Base64는 인코딩이며 암호화가 아닙니다. Auditor로 전환하고 소유자만 파일에 접근하도록 제한하세요.
chmod 600 evidence/account-after.xml evidence/booking-after.xml
ls -l evidence
두 파일 모두 -rw-------가 나와야 합니다. 앞에서와 같은 문자 그대로의 here-document 형식으로 비밀번호 없는 보고서를 작성하세요. >는 assessment.json을 덮어쓰며, 마지막 JSON은 한 줄에 단독으로 있어야 합니다.
cat > assessment.json <<'JSON'
{
"decision": "accept",
"account_after_logout": 401,
"booking_after_logout": 401,
"independent_browser_preserved": true,
"fresh_sign_in_works": true
}
JSON
cat assessment.json
비밀번호, 쿠키, 원시 요청은 보고서에서 제외하고 원래 XML 요청·응답 쌍과 이 보고서를 제출하세요. 기존 서버 사실이 B의 독립 접근과 새 로그인을 뒷받침합니다. 검증은 누락된 로그인, 로그아웃, 재전송 요청을 수행하지 않습니다. 공개 페이지 보존을 확인하는 요청은 접근 기록을 추가할 수 있으며, 반복 채점은 파일을 보존합니다.
파일 이름이 잘못되었다면 같은 실제 응답을 올바른 경로로 내보내고 chmod 600을 다시 적용하세요. 셸 위치가 다르다면 pwd로 확인하고 cd /home/labex/project로 돌아오세요. 정상적인 공개 사이트와 모든 대상 리소스를 그대로 유지하세요.
요약
수정된 현재 브라우저 로그아웃을 계정 페이지와 예약 다운로드 모두에서 테스트했습니다. 이전 쿠키는 거부되었고, 이미 존재하던 별도의 브라우저 세션은 접근을 유지했으며, 새 로그인도 계속 작동했습니다. 비공개 Burp XML 요청·응답 쌍과 비밀번호 없는 평가가 근거 있는 수용 판단을 보존합니다.
독립 챌린지에서는 회원, 배포 주소, 예약이 바뀝니다. 같은 완전한 계약을 적용하고 실제 두 리소스의 응답을 바탕으로 판단하세요.
