Step 102. Natas 0~5 — 웹 워게임의 문을 열다

Level 2 — 보안 입문과 공격 스킬 기초 | 난이도 ★★☆☆☆ | 예상 소요 시간 3시간

전제: Step 71(HTML), 73(HTTP), 94(서버의 시점)의 지식과 Bandit에서 단련된 워게임 사이클을 사용합니다.

준비물: 브라우저, 개발자 도구(F12), curl 또는 파이썬 requests, 그리고 Bandit의 비밀번호 체인을 관리하던 노트.
⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다.
주의: Natas는 Bandit과 같은 OverTheWire가 공식 운영하는 합법 학습 플랫폼입니다 — 공격을 전제로 열어 둔 연습장입니다. 다른 웹사이트의 소스를 보는 것은 합법이지만, 헤더·쿠키를 조작해 접근을 시도하는 것은 무단 침입이 됩니다.

Bandit이 리눅스 서버의 게임이었다면, Natas는 웹의 게임입니다. 주최는 같고(OverTheWire), 목표도 같습니다 — 다음 레벨의 비밀번호를 찾아라. 다만 이번에는 그 비밀이 서버 파일이 아니라 웹 페이지의 안팎에 숨어 있습니다. 오늘의 핵심 문장을 먼저 드립니다 — 웹 페이지는 보이는 것이 전부가 아니다. 브라우저 화면은 서버가 보낸 원본 문서를 예쁘게 그린 결과일 뿐, 원본에는 주석, 숨겨진 링크, robots.txt, 헤더와 쿠키가 함께 오갑니다. Level 1에서 배운 HTTP 지식이 여기서 공격 기술로 번역됩니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

새 사이트를 만나면 소스 보기→주석 검색→robots.txt→경로 추측의 정찰 루틴을 수행한다
HTML 소스에서 주석과 숨겨진 경로를 찾아낸다
robots.txt의 역설(금지 목록 = 숨김 경로의 지도)을 설명한다
curl과 파이썬 requests로 인증·Referer·쿠키를 조작한 요청을 보낸다
"클라이언트에서 오는 값은 전부 조작 가능하다"는 웹 보안 제1원리를 사례로 설명한다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

구분	내용
언어·환경	브라우저 + 개발자 도구(F12), curl, 파이썬 requests(로컬 실험)
오늘의 명령어	`curl -u`(인증), `curl -e`(Referer), `curl -b`(쿠키), `curl -v`(대화 전체 보기), `grep -n "<!--"`(주석 검색)
필요한 개념	HTML 주석, 디렉터리 리스팅, robots.txt, HTTP 헤더(Referer), 쿠키, Basic 인증
오늘의 산출물	`natas_mini/` — Natas식 미니 페이지, `cookie_server.py` + `cookie_client.py` — 쿠키 변조 실험 세트

2-1. 소스 보기 — 그림 뒤의 문서

브라우저에서 Ctrl+U(macOS는 Cmd+Option+U)는 현재 페이지의 HTML 원본을 보여 줍니다. HTML 안의 는 주석 — 개발자의 메모로, 화면에는 안 보이지만 문서에는 있습니다. 개발자가 "나중에 보려고" 적어 둔 것이 공격자에게는 안내판입니다.

개발자 도구(F12)는 한 발 더 나갑니다 — Elements 탭은 지금 렌더링된 문서를, Network 탭은 오간 요청·응답 전부를, Application(저장소) 탭은 저장된 쿠키를 보여 줍니다. 웹 해킹의 삼대 창구입니다.

2-2. robots.txt — 금지 구역의 지도

웹사이트 뿌리에는 종종 robots.txt라는 파일이 있습니다. 원래 용도는 검색엔진에게 "이 경로는 긁어가지 마세요"라고 알리는 안내판입니다.

User-agent: *
Disallow: /secret-folder/

역설을 보세요 — 숨기고 싶은 경로를 목록으로 적어 둔 파일입니다. 접근을 막는 장치가 아니라 안내문이니, 누구든 읽고 그 경로에 직접 가 볼 수 있습니다. 공격자에게 robots.txt는 "이 사이트가 신경 쓰는 경로의 지도"입니다.

2-3. 헤더와 쿠키 — 요청에 붙는 쪽지들

Step 73에서 배운 HTTP 요청에는 본문 외에 부가 정보가 붙습니다.

Referer(리퍼러) — "이 요청이 어느 페이지에서 왔는가". 일부 사이트는 이걸로 "우리 페이지를 거쳐 온 사람"인지 검사합니다.
Cookie(쿠키) — 서버가 심어 둔 표식. loggedin=0 같은 값이 들어 있을 수 있습니다.

중요한 사실: 이 둘은 전부 클라이언트가 보내는 것이므로, 클라이언트가 마음대로 고칠 수 있습니다. 브라우저가 정직하게 채워 줄 뿐, 지켜야 할 약속은 없습니다.

2-4. Basic 인증 — 회색 로그인 창의 정체

Natas의 로그인 창은 브라우저가 띄우는 회색 대화상자로, HTTP Basic 인증입니다. 구조는 간단합니다 — 아이디:비밀번호를 Base64로 변환해 Authorization 헤더에 넣는 것. Step 50에서 배운 대로 Base64는 암호가 아니라 변환이니, 평문 HTTP 위에서는 사실상 비밀번호가 그대로 오가는 셈입니다. curl의 -u가 바로 이 헤더를 만들어 줍니다. 로그인 창의 겉모습이 아니라 헤더의 실체를 보는 것 — 그것이 오늘의 숨은 수확입니다.

3. 따라 하기

3-1. Natas 0 → 1: 소스 보기의 첫 발견

입력: 브라우저에서 http://natas0.natas.labs.overthewire.org 접속 → 아이디·비밀번호 둘 다 natas0.

출력 예시: "비밀번호를 이 페이지 어딘가에 숨겨 두었다"는 안내 문구.

입력: Ctrl+U로 소스를 열고, Ctrl+F로 password를 검색합니다.

출력 예시: HTML 주석 안 — .

읽는 법: 화면에는 없던 문장이 원본에는 있습니다. 개발자의 메모가 그대로 전리품입니다.

왜 하는가: 모든 레벨의 시작 동작입니다 — 접속하면 소스부터 본다. 습관으로 만들 때까지 반복합니다.

3-2. 내 랩에서 재현 — 미니 페이지의 소스 뒤지기 (로컬 실측)

서버 없이도 "소스에서 숨은 값 찾기"는 완전히 재현됩니다. 작업 폴더에 Natas식 미니 페이지를 만들어 봅시다.

입력 (natas_mini/index.html로 저장):

<!DOCTYPE html>
<html>
<head><title>미니 워게임 Level 0</title></head>
<body>
<h1>비밀번호를 찾아라</h1>
<p>이 페이지 어딘가에 다음 레벨의 비밀번호가 숨겨져 있습니다.</p>
<!-- 개발자 메모: 다음 레벨 비밀번호는 miniwargame_level1_pass_777 나중에 꼭 지울 것 -->
<img src="files/pixel.png" alt="점 하나">
</body>
</html>

이 파일을 브라우저로 열면 주석은 화면에 나타나지 않습니다. 이제 공격자처럼 원본을 뒤져 봅니다 (2026-09-09 실측):

$ grep -n "<!--" natas_mini/index.html
7:<!-- 개발자 메모: 다음 레벨 비밀번호는 miniwargame_level1_pass_777 나중에 꼭 지울 것 -->

읽는 법: 7번째 줄의 주석에서 비밀번호가 나왔습니다. 브라우저가 그려 주는 화면과 원본 문서는 다릅니다 — 공격자는 항상 원본 쪽을 봅니다. 브라우저로 할 때는 Ctrl+U 후 Ctrl+F가 이 grep 한 줄과 같은 일을 합니다.

3-3. Natas 1 → 2: 같은 기술, 다른 얼굴

안내는 "이번엔 우클릭이 막혀 있다"고 합니다. 하지만 우리는 우클릭 메뉴로 소스를 보지 않습니다.

입력: Ctrl+U는 막히지 않습니다. 같은 검색을 반복합니다.

읽는 법: 화면의 조작을 막는 것과 문서를 숨기는 것은 다릅니다. 브라우저의 장식을 건드려도 보내진 문서 자체는 그대로입니다.

왜 하는가: "겉을 막으면 안심"이라는 착각의 첫 사례입니다. 웹에서 겉장식은 전부 우회 가능합니다.

3-4. Natas 2 → 3: 경로를 직접 걷기

소스에서 이번엔 비밀번호가 안 보입니다. 대신 수상한 이미지 태그가 있습니다 — 3-2의 미니 페이지에도 <img src="files/pixel.png">가 있었죠.

입력: 이미지가 아니라 그 이미지가 사는 곳(폴더)에 관심을 둡니다. 주소창에 직접 입력합니다.

http://natas2.natas.labs.overthewire.org/files/

출력 예시: 폴더의 파일 목록(디렉터리 리스팅)이 보이고, 그 안에 users.txt 같은 파일이 놓여 있습니다.

읽는 법: 주소창에 경로를 직접 치는 행위는 "사이트의 지도를 직접 걷는 것"입니다. "링크가 없으면 못 간다"는 사용자의 생각이고, "경로를 추측해 친다"는 공격자의 생각입니다.

왜 하는가: 디렉터리 리스팅이 켜진 서버는 실제로도 흔한 설정 실수입니다.

3-5. Natas 3 → 4: robots.txt의 역설

입력: 주소창에 /robots.txt를 붙여 봅니다.

출력 예시:

User-agent: *
Disallow: /s3cr3t/

입력: 그 경로로 직접 갑니다.

출력 예시: 숨겨진 폴더 속 파일에 다음 비밀번호.

로컬 실측 (2026-09-09): 같은 구조를 미니 사이트에도 만들어 두었습니다.

$ cat natas_mini/robots.txt
User-agent: *
Disallow: /s3cr3t/

$ cat natas_mini/s3cr3t/users.txt
mini_level2_password=robots_보물지도_1234

읽는 법: 금지 목록이 곧 보물 지도라는 2-2의 역설이 실물로 확인됐습니다.

왜 하는가: 실제 사이트 진단에서도 robots.txt는 반드시 확인하는 첫 파일 중 하나입니다.

3-6. Natas 4 → 5: Referer 헤더 조작

이번 페이지는 이렇게 말합니다 — "이 페이지는 지정된 다른 페이지에서 온 사람만 볼 수 있습니다."

입력: 브라우저로는 방법이 없습니다 — 헤더를 직접 만들어야 합니다. curl을 꺼냅니다 (서버에서, 출력 예시).

curl -u natas4:이전비밀번호 -e "http://natas5.natas.labs.overthewire.org/" http://natas4.natas.labs.overthewire.org/

출력 예시: "Access granted"와 함께 다음 비밀번호가 담긴 HTML.

읽는 법: -u는 Basic 인증(아이디:비밀번호), -e는 Referer 헤더 설정입니다. 우리는 "natas5에서 왔다"는 쪽지를 손으로 써서 붙인 것입니다. 서버는 그 쪽지가 진짜인지 확인할 방법이 없습니다 — 클라이언트가 보낸 값이니까요.

왜 하는가: "헤더 검사로 출입을 통제한다"는 발상의 허점을 보는 순간입니다. 검사는 서버에서, 서버가 통제하는 정보로 해야 합니다.

3-7. Natas 5 → 6: 쿠키 변조 — 로컬 실측으로 먼저

이번에는 로그인했는데도 "You are not logged in"이라고 합니다. 이 레벨의 핵심(쿠키 값 변조)은 내 컴퓨터에서 완전히 재현됩니다. 쿠키를 검사하는 미니 서버를 만들어 봅시다.

입력 (cookie_server.py):

"""쿠키를 검사하는 미니 서버 — Natas 5 스타일 실험용."""
from http.server import BaseHTTPRequestHandler, HTTPServer

SECRET = "cookie_lab_level3_pass_5555"

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        cookie = self.headers.get("Cookie", "")
        if "loggedin=1" in cookie:
            body = f"Access granted. The password is {SECRET}\n".encode()
        else:
            body = b"You are not logged in\n"
        self.send_response(200)
        self.send_header("Content-Type", "text/plain; charset=utf-8")
        self.send_header("Set-Cookie", "loggedin=0")
        self.end_headers()
        self.wfile.write(body)

HTTPServer(("127.0.0.1", 8123), Handler).serve_forever()

터미널 1에서 python cookie_server.py로 서버를 띄운 뒤, 터미널 2에서 클라이언트(cookie_client.py)를 실행합니다:

"""쿠키 변조 실험 클라이언트 — 로컬 서버(8123) 대상."""
import requests

URL = "http://127.0.0.1:8123/"

print("=== 1) 쿠키 없이 접속 ===")
r = requests.get(URL)
print(r.text.strip())
print("서버가 심어 준 쿠키:", r.headers.get("Set-Cookie"))

print()
print("=== 2) 받은 쿠키 그대로(loggedin=0) ===")
r = requests.get(URL, cookies={"loggedin": "0"})
print(r.text.strip())

print()
print("=== 3) 쿠키 값을 1로 변조 ===")
r = requests.get(URL, cookies={"loggedin": "1"})
print(r.text.strip())

출력 (2026-09-09 실측):

=== 1) 쿠키 없이 접속 ===
You are not logged in
서버가 심어 준 쿠키: loggedin=0

=== 2) 받은 쿠키 그대로(loggedin=0) ===
You are not logged in

=== 3) 쿠키 값을 1로 변조 ===
Access granted. The password is cookie_lab_level3_pass_5555

curl로도 같은 결과가 나옵니다 (2026-09-09 실측):

$ curl -s -b "loggedin=0" http://127.0.0.1:8123/
You are not logged in
$ curl -s -b "loggedin=1" http://127.0.0.1:8123/
Access granted. The password is cookie_lab_level3_pass_5555

읽는 법: 서버는 loggedin=1이 오면 로그인된 사람으로 믿습니다. 쿠키는 내 컴퓨터에 저장되는 값이라 내 마음대로이고, 서버의 그 믿음이 곧 문이 됩니다. 실험이 끝나면 터미널 1에서 Ctrl+C로 서버를 끄세요.

왜 하는가: 인증 상태를 클라이언트 측 값에만 의존하는 설계의 위험성 — 실제 웹 취약점(취약한 세션 관리)의 원형입니다.

3-8. Natas 서버에서의 쿠키 변조

이제 실제 레벨입니다. 개발자 도구(F12) → Application(저장소) 탭 → Cookies를 열어 보세요.

입력: loggedin 쿠키의 값이 0입니다. 더블클릭해 1로 고치고, 페이지를 새로고침합니다.

출력 예시: "Access granted" — 로그인된 사람이 되었습니다.

읽는 법: 3-7에서 내 랩 서버에 한 것과 정확히 같은 동작입니다. 도구만 파이썬에서 개발자 도구로 바뀌었을 뿐입니다.

curl 옵션 카드 — 오늘의 알파벳

웹 취약점 실험은 결국 "요청의 어느 조각을, 어떻게 바꿀까"의 반복이고, 이 네 옵션이 그 반복의 알파벳입니다.

옵션	하는 일	예
`-u 아이디:비번`	Basic 인증 헤더 생성	`curl -u natas4:...`
`-e 주소`	Referer 헤더 설정	`curl -e "http://..."`
`-b "이름=값"`	쿠키 실어 보내기	`curl -b "loggedin=1"`
`-v`	요청·응답 헤더 전부 보기	`curl -v http://...`

4. 미션과 연습문제

미션 — 웹 정찰 루틴 정착과 쿠키 실험 완성

natas0~5 전 레벨을 통과하고 비밀번호 체인을 노트에 기록합니다
3-2의 미니 페이지를 만들고, 브라우저 화면과 소스(Ctrl+U)가 다르다는 것을 확인한 뒤 주석의 비밀번호를 찾습니다
3-7의 쿠키 서버·클라이언트를 직접 실행해 "loggedin=0은 거부, 1은 통과"를 재현합니다
위키에 웹정찰루틴.md를 작성합니다 — 새 사이트를 만나면: ①소스 보기 ②주석 검색 ③robots.txt ④경로 추측 ⑤개발자 도구 Network·Application 확인
각 레벨이 "실제 서비스였다면 어떤 설정 실수인가"를 레벨별로 한 줄씩 정리합니다

연습문제

문제 1. robots.txt가 "숨기는 장치"가 아니라 "숨김 경로의 지도"가 되는 이유를 설명해 보세요.

문제 2. 우클릭을 막아 두어도 소스 보기가 되는 이유를 "보내진 문서"의 관점에서 설명해 보세요.

문제 3. Referer 검사로 출입을 통제하는 설계의 근본적인 문제를 한 문장으로 말해 보세요.

문제 4. loggedin=1 쿠키 변조가 먹히는 서버의 잘못은 무엇이며, 올바른 설계는 어떤 모습이어야 하나요?

5. 모범 답안과 완료 기준

미션 모범 답안

레벨별 풀이 요약 (서버 풀이는 출력 예시 기준):

natas0→1: 소스 보기(Ctrl+U) → 주석 속 비밀번호
natas1→2: 우클릭 무시, Ctrl+U로 같은 기술 반복
natas2→3: 소스의 이미지 경로에서 폴더를 추측해 /files/ 로 직접 이동 → users.txt
natas3→4: /robots.txt 확인 → Disallow 경로로 직접 이동
natas4→5: curl -u natas4:비번 -e "http://natas5..." 로 Referer 위조
natas5→6: 개발자 도구 Application → loggedin 쿠키 0→1로 수정 후 새로고침

로컬 실험의 검증 기준: 3-7의 클라이언트 출력이 실측 결과와 같은 순서(거부→거부→통과)로 나오면 정답입니다. curl 한 줄(curl -s -b "loggedin=1" http://127.0.0.1:8123/)로도 "Access granted"가 나와야 합니다.

검증하는 법: ① 비밀번호 체인이 6칸 이어졌는가. ② 미니 페이지에서 화면에는 안 보이는 주석을 소스에서 찾았는가. ③ 쿠키 변조 실험이 내 손으로 재현됐는가. ④ 정찰 루틴 다섯 단계가 문서로 남았는가. 전부 ‘예’이면 완성입니다.

연습문제 해답

문제 1 해답. robots.txt는 접근을 막는 기술 장치가 아니라 검색엔진에게 보내는 "부탁 문서"일 뿐이라서입니다. 누구든 파일을 열어 볼 수 있고, 적힌 경로에 직접 갈 수 있습니다. "긁어가지 마세요"라고 적힌 목록은 곧 "이 사이트가 신경 쓰는 경로"의 목록입니다 (3-5 실측처럼 Disallow 경로에 실제 파일이 있었습니다).

문제 2 해답. 우클릭 메뉴는 브라우저 화면 위의 장식이고, HTML 원본 문서는 이미 내 컴퓨터에 전부 내려와 있기 때문입니다. 장식을 막아도 문서 자체는 그대로이니 Ctrl+U, 개발자 도구, 심지어 curl로도 원본을 받을 수 있습니다.

문제 3 해답. Referer는 클라이언트가 만들어 보내는 값이라 조작이 자유인데, 서버가 그것을 검증 없이 신뢰했다는 것이 문제입니다. "클라이언트에서 오는 것은 전부 조작 가능하다"는 제1원리에 정면으로 어긋납니다.

문제 4 해답. 로그인 여부를 클라이언트가 고칠 수 있는 쿠키 값 하나에 맡긴 것이 잘못입니다 (3-7 실측에서 값 하나로 통과가 갈렸습니다). 올바른 설계: 로그인 상태는 서버가 관리하고, 쿠키에는 추측 불가능한 세션 토큰만 담아 서버 측 저장소와 대조합니다. "쿠키는 증표의 번호일 뿐, 신분 자체가 아니다."

완료 기준 체크리스트

[ ] 소스 보기와 주석 검색을 새 사이트의 첫 동작으로 할 수 있다
[ ] robots.txt의 역설(금지 목록 = 지도)을 설명할 수 있다
[ ] 경로를 주소창에 직접 입력해 숨은 자원을 찾을 수 있다
[ ] curl의 -u, -e, -b로 요청을 정밀하게 만들 수 있다
[ ] 쿠키 변조를 로컬 서버에서 직접 재현했다
[ ] "클라이언트의 값은 전부 조작 가능하다"를 오늘의 사례 두 개로 설명할 수 있다
[ ] 웹 정찰 루틴 다섯 단계를 순서대로 말할 수 있다

6. 흔한 실수와 해결

벽 1. 로그인 창이 계속 뜬다

증상: 아이디·비밀번호를 쳐도 다시 묻습니다.
원인: 주소의 레벨 번호와 아이디 번호가 다릅니다(natas3 페이지에 natas2 비밀번호 등). 또는 비밀번호 복사 시 앞뒤 공백이 딸려 온 경우입니다.
해결: 주소창의 번호, 아이디의 번호, 비밀번호의 출처 레벨 — 셋이 한 칸씩 밀려 있지 않은지 확인하세요. 체인은 정확해야 합니다.

벽 2. 소스 보기가 안 열린다

증상: Ctrl+U가 무반응.
원인: 브라우저나 단축키 설정 차이입니다.
해결: 주소창에 view-source:http://주소를 직접 입력하거나, F12 → Elements 탭을 쓰세요. 막혀도 문서 자체는 curl -u 아이디:비번 주소로 받을 수 있습니다.

벽 3. 폴더 경로를 쳤는데 403/404가 나온다

증상: /files/ 같은 경로가 거부됩니다.
원인: 디렉터리 리스팅은 서버 설정에 달렸습니다. Natas에서는 열려 있지만, 실제 사이트는 대부분 막혀 있습니다.
해결: 리스팅이 막혀 있어도 파일 경로를 직접 추측하는 방법은 남습니다(/files/users.txt 등).

벽 4. curl이 인증 오류(401)를 낸다

증상: curl이 접속을 거부당합니다.
원인: -u의 형식 오류(콜론 누락) 또는 비밀번호 오타입니다.
해결: curl -u natas4:비밀번호 주소로 가장 단순한 형태부터 확인하고, 성공하면 옵션을 하나씩 추가하세요. 옵션을 겹칠수록 원인 분리가 어려워집니다.

벽 5. 쿠키를 고쳤는데 그대로다

증상: 개발자 도구에서 값을 바꿨는데 새로고침하면 돌아갑니다.
원인: 서버가 응답 때마다 Set-Cookie로 다시 덮어쓰는 경우입니다 (3-7의 미니 서버도 매번 loggedin=0을 심습니다 — 실측 1번 출력의 Set-Cookie를 보세요).
해결: 값을 고친 뒤 새로고침 전에 다시 한 번 값을 확인하거나, 아예 curl/requests로 요청 자체를 만들어 보내세요 — 브라우저 저장소를 거치지 않으니 덮어쓸 기회가 없습니다.

7. 정리

오늘의 개념

개념	한 줄 설명
HTML 주석	`<!-- ... -->` — 화면엔 없고 원본엔 있는 개발자 메모
디렉터리 리스팅	폴더 경로를 치면 파일 목록이 보이는 설정 — 흔한 설정 실수
robots.txt	검색엔진용 부탁 문서 — 금지 목록이 곧 숨김 경로의 지도
Referer	"어디서 왔는가"를 적는 요청 헤더 — 클라이언트가 만드므로 위조 자유
쿠키	서버가 심고 내 컴퓨터에 저장되는 표식 — 내 마음대로 고칠 수 있음
Basic 인증	아이디:비번을 Base64로 실어 보내는 방식 — 변환이지 암호 아님
제1원리	클라이언트에서 오는 것은 전부 조작 가능하다

오늘의 명령어

명령어	하는 일
`Ctrl+U` / F12	소스 보기 / 개발자 도구(Elements·Network·Application)
`grep -n "<!--" 파일`	HTML 원본에서 주석 찾기
`curl -u 아이디:비번 주소`	Basic 인증으로 요청
`curl -e "주소"`	Referer 헤더 조작
`curl -b "이름=값"`	쿠키 값 실어 보내기
`curl -v 주소`	요청·응답 헤더 전체 관찰

명령어보다 중요한 감각

새 사이트를 만나면 손이 먼저 가야 할 순서가 생겼습니다 — ① 소스 보기, ② 주석 검색, ③ robots.txt, ④ 경로 추측, ⑤ 개발자 도구 Network·Application. 이 다섯 걸음은 "보이는 페이지"가 아니라 "보내진 문서 전체"를 보는 습관입니다. 평소 방문하는 사이트에서도 소스와 robots.txt를 읽기만 해 보세요(요청을 바꾸거나 숨은 경로를 두드리는 것은 절대 금지). 정찰의 눈은 일상에서 길러집니다.

그리고 오늘의 모든 기법을 꿰는 한 문장 — 클라이언트에서 오는 것은 전부 조작 가능하다. Referer도, 쿠키도, 숨겨진 입력칸도 서버에 도착하기 전까지는 내 손안의 값입니다. 이 원리 하나가 Natas 전체를, 나아가 웹 보안 전체를 관통합니다. 웹 공격자의 눈이 열렸습니다.

전부 체크되면 Step 102 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.