Parameter Tampering Attack

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. 중복 파라미터 정책 명확히 하기

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