BYTE BACK 방어전 시작 틀 R5

이 저장소는 1단계에서 학생 본인이 GitHub 저장소와 Vercel 배포를 만드는 출발점입니다. 포함된 메모 네 건은 가상 자료입니다. 실제 학생 자료, 토큰, 비밀키를 넣지 마세요.

7단계: 평소와 다른 접속은 다시 확인함 (현재 상태)

• 판정기(src/decider.mjs)에 규칙이 둘 있습니다. RULE_IDS는 ['device_registered', 'step_up_required']입니다. 기기 등록 규칙(6단계)이 먼저 적용되어 미등록 기기는 deny(device_not_registered)입니다.
• 입력 검사: 접속 정보(signals)는 엔진이 검증해 넘긴 가상 정보(source: judge_fixture)일 때만 믿습니다. none(현재 실제 경로)·모르는 출처·누락·잘못된 모양은 "근거 없음"이고, 비어 있는 값을 정상값으로 채우지 않으며 위험하다고 단정하지도 않습니다. 판정기는 헤더·쿠키·브라우저가 보낸 위치를 읽지 않습니다(위조해도 신뢰하는 정보로 올라가지 않음). recentEvents는 최대 12건, 모양이 틀린 항목은 버립니다.
• 복합 이상 규칙 step_up_required: 평소와 다른 시각(722시 밖), 낯선 네트워크(unusual), 다른 지역(foreign), 최근 15분의 활동 10건 이상 중 두 가지 이상이 겹치면 step_up(이유 step_up_required)입니다. 하나만으로는 허용하고, 지역 하나만으로 막지 않습니다. 이 기준(722시, 10건, 두 가지 이상)은 이 저장소의 가상 사건 연습에 맞춰 제가 정한 값이고, 심판이 쓰는 사건의 실제 조합은 알지 못합니다.
• 다시 확인한 요청(stepUp.verified가 true이고 authAgeSeconds가 0~900)은 허용합니다. 사유 이름(odd_hour·new_network·foreign_region·heavy_activity)은 riskReasons()로 시험에서 확인하며, 응답 형식(다섯 항목)에는 실리지 않습니다.
• 확인 순서(로컬 연습): npm run decider:test(등록 기기 통과·미등록 거부·복합 이상 접속 추가 확인·다시 확인 후 허용 네 항목이 모두 통과), npm run fixture:7(정상 사건 allow, 복합 이상 사건 step_up), npm run test:decider(입력 검사·규칙 시험). 가상 요청 연습이며 실제 반 엔진이나 심판의 결과가 아닙니다.
• 확인하지 못한 것(미실행): 계약서에는 stepUp과 step_up 결정이 있지만, 이 저장소의 서버 함수(/api/notes)는 판정기를 부르지 않고 반 엔진이 새 로그인 시각을 검증하는 환경도 여기에 없습니다. 그래서 "추가 확인 전 실제 자료 차단"과 "새 로그인 뒤 요청 허용"은 측정하지 않았습니다. 제출 묶음의 직접 점검에도 미실행으로 적었습니다.
• 5단계까지의 기능(로그인·본인 메모·DB 권한·/aleph.json·nosniff)은 그대로입니다.

6단계: 등록한 기기만 자료실에 들어옴 (이전 단계)

• 판정기(src/decider.mjs)에 규칙 device_registered 하나가 있습니다. 판정 요청의 deviceRegistered가 true일 때만 allow(이유 approved)이고, false이거나 값이 없거나 true가 아닌 모든 경우는 deny와 이유 device_not_registered입니다. 요청에서는 계약(docs/DECIDER_REQUEST.md)에 있는 requestId와 deviceRegistered만 읽고, request.identity·device·role·geo는 쓰지 않습니다. RULE_IDS는 ['device_registered']입니다.
• 응답은 계약의 다섯 항목(schema·requestId·decision·reasonCode·ruleIds)만 담습니다. 자료실 주소와 브라우저 화면은 바꾸지 않았고, 5단계까지의 기능은 그대로입니다.
• 기기 등록·인증서·접속 프로그램은 이번 과정에서 학생이 설치하거나 만들지 않습니다. 인증서·CA·서명 키는 만들지도 Git에 넣지도 않았습니다. 미등록 기기로 들어오는 공격은 심판이 맡습니다.
• 확인 순서(로컬 연습): 저장소 폴더에서 npm run decider:test를 실행합니다. 정상이면 「등록 기기의 정상 요청」과 「미등록 기기의 가상 요청」이 둘 다 통과로 나옵니다. 이 명령은 가상 요청 연습이며 실제 심판 판정이나 반 엔진의 결과가 아닙니다.
• 확인한 것: 위 연습에서 두 항목 통과. 값이 없거나 문자열 'true', 숫자 1, null인 요청도 거부되고 응답 형식이 맞음.
• 확인하지 못한 것: 실제 반 엔진이 전달하는 요청으로 돌려 본 것은 아닙니다. 서버 함수(/api/notes)와 이 판정기는 아직 연결되어 있지 않습니다.
• 제출 묶음의 직접 점검(src/attack-check.mjs)은 5단계와 같고, 6단계용 항목을 더하지 않았습니다. 기기 등록 여부는 엔진이 정하는 값이라 학생 컴퓨터에서 바깥 요청으로 흉내 낼 수 없기 때문입니다.

5단계: 자료 요청을 서버 한곳으로 모음 (이전 단계)

• 브라우저의 메모 읽기·추가·수정·삭제는 모두 Vercel 서버 함수(/api/notes, /api/notes/:id)로만 갑니다. 화면 코드(public/index.html)가 Supabase를 직접 부르는 곳은 로그인·로그아웃·세션 확인(auth)뿐이고, 메모 자료를 직접 읽거나 고치는 곳은 없습니다(찾아봤고 없음). 그래서 제작 1에서는 파일을 바꾸지 않았습니다.
• DB(학습용 Supabase public.notes): PUBLIC·anon·authenticated의 직접 권한이 모두 없습니다. 서버 함수는 서버 전용 비밀 키(service_role)로만 접속합니다. 서버 함수의 로그인·소유자 검사는 그대로입니다. RLS 정책 네 개도 남아 있어, 나중에 권한이 다시 열려도 본인 행만 허용되는 두 번째 방어선이 됩니다. 적용한 SQL은 supabase/*.local.sql에 있고 Git에는 올리지 않습니다.
• aleph.config.json: step은 5, originalApiUrl은 쿼리 없는 원본 자료 HTTPS 경로(…supabase.co/rest/v1/notes)입니다. 허용 경로(allowedRoutes)와 로그인 발급자 정보는 4단계와 같습니다.
• 확인한 것: 학생이 직접 실행한 DB 권한 확인에서 anon·authenticated는 SELECT·INSERT·UPDATE·DELETE가 모두 false, service_role은 모두 true. 공개(anon) 키로 DB에 직접 요청하면 401(permission denied for table notes)(4단계에서 확인). 시험 계정 A·B로 화면에서 각자 자기 메모 읽기·추가·수정·삭제가 정상.
• 확인하지 못한 것: 로그인 토큰(authenticated)으로 실제 직접 요청을 보내 본 시험은 하지 않았습니다. 권한 표로만 확인했습니다. 심판의 재현도 아닙니다.
• 남은 약점: 화면 코드에 Supabase 공개 키(sb_publishable_…)가 있습니다. 로그인(Auth)을 브라우저가 직접 부르기 때문이고, 공개용 키이며 DB 직접 접근 권한은 없습니다. 이전 공개 커밋(dd089bb)과 옛 배포에는 가상 메모가 그대로 남아 있습니다.
• 다시 실행: npm run test:notes, npm run test:attack, npm run test:r5. 가상 요청 연습이며 실제 배포나 심판 판정이 아닙니다.
• 제출 묶음: npm run bundle은 4단계 점검에 더해 공개 화면 HTML과 /aleph.json에 서버 전용 키·토큰 모양의 문자열이 있는지 봅니다(있는지 여부만 기록하고 값은 싣지 않음). 요청을 보내지 못하면 미실행으로 남습니다.

4단계: 로그인해도 내 자료만 보임 (이전 단계)

• 서버 함수(src/notes-service.mjs)는 읽기·추가·수정·삭제를 모두 본인 메모로 제한합니다. 한 건 요청은 DB에 id와 owner_id(검증된 사용자)를 함께 걸고, 돌아온 행의 주인도 다시 비교합니다. 추가할 때 주인은 검증된 사용자 ID로만 저장하며 URL·본문의 소유자 값은 믿지 않습니다.
• 남의 메모에 대한 읽기·수정·삭제는 없는 메모와 같은 404입니다. 수정 본문에 owner_id·userId 같은 소유자 값이 있으면 403(OWNER_CHANGE_FORBIDDEN)으로 거부하고 소유자는 바뀌지 않습니다.
• DB(학습용 Supabase public.notes): RLS를 켜고 PUBLIC·anon·authenticated의 권한을 모두 회수한 뒤, authenticated에 SELECT·INSERT·UPDATE·DELETE만 주었습니다. 네 정책 모두 auth.uid() = owner_id일 때만 허용합니다(UPDATE는 기존 행과 새 행 둘 다). 서버 함수는 서버 전용 비밀 키로 접속하므로 이 변경과 상관없이 동작합니다. 적용한 SQL은 supabase/*.local.sql에 있고 Git에는 올리지 않습니다.
• 확인한 것: 학생이 직접 실행한 결과, anon은 네 권한 모두 없음, authenticated는 네 권한 있음, 정책 네 개. 공개(anon) 키로 DB에 직접 요청하면 401(permission denied for table notes). 시험 계정 A·B로 화면에서 각자 자기 메모만 보이고 추가·수정·삭제가 됨.
• 확인하지 못한 것: 심판 계정으로 한 재현, authenticated 역할의 직접 접근(심판이 재현할 수 없는 부분이라 점수에서 제외됨).
• 다시 실행: npm run test:notes(서버 함수·A/B 소유자 시험, 가짜 Supabase), npm run test:attack(자기 점검 코드), npm run test:r5. 가상 요청 연습이며 실제 배포나 심판 판정이 아닙니다.
• 제출 묶음: npm run bundle은 3단계 점검에 더해 공개 키로 DB에 직접 묻는 요청(anon_direct_data_api)이 거부되는지 봅니다. 요청을 보내지 못하면 미실행으로 남습니다. 두 시험 계정의 토큰이 없어서 A가 B의 메모를 건드리는 요청은 이 점검에 넣지 않았고 서버 시험으로만 확인합니다.
• 남은 약점: 이전 공개 커밋(dd089bb)과 옛 배포에는 가상 메모가 그대로 남아 있습니다. 서버 함수가 비밀 키로 DB를 읽으므로 앱 쪽 검사 코드가 틀리면 RLS가 막아 주지 못합니다(RLS는 직접 접근을 막는 두 번째 방어선입니다).
• 계정: 화면 시험은 가짜 시험 계정(example.com)으로 합니다. 실제 이메일은 코드·Git·제출 묶음에 넣지 않습니다.

This is the beginning of the README. Read the rest at the original. Read the full README ↗