콘텐츠 상단/하단 파일 경로를 저장 전에 먼저 정규화한 뒤 확장자와 위치를
검증하도록 순서를 조정한다. 정규화 과정에서 확장자가 사라져 검증을
우회하던 경로를 차단한다. 실행 직전 bbs/content.php 에서도 승인 확장자와
data 디렉터리 귀결 여부를 다시 확인하는 is_content_include_allowed() 를
적용하고, 콘텐츠 상단/하단 이미지 업로드는 이미지 파일만 허용하도록 검사한다.
미완료주문 상세의 결제방법 출력에 get_text() 인코딩을 적용하고, 임시주문
저장 시 정제한 결제수단 값을 원본에도 반영한다. 개인결제 주문 세션은
결제정보 검증을 통과한 뒤에만 설정한다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
(cherry picked from commit 196255d76912531d7e13861821bd59ca15c967d1)
nicepay_reqPost() 가 원격 서버 인증서를 검증하지 않고 통신하던 것을
검증하도록 변경한다. 이니시스 연동부는 이미 동일하게 처리하고 있다.
API 호스트 4곳(webapi, pg-api, dc1-api, dc2-api) 인증서 검증 통과를
확인했다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
(cherry picked from commit 6c888bd53d0a5949bb1e2fc96567c132622a6f8b)
에스크로 배송등록 실패 시 알림 대신 주문 관리자 메모에 결과를 기록하고
이후 처리를 중단한다. 현금영수증 발급 후 DB 반영에 실패한 경우 자동 취소
요청을 제거하고 관리자가 나이스페이에서 직접 확인하도록 안내를 변경한다.
가상계좌 취소 요청금액이 없을 때의 응답 코드를 명시한다.
patch_5631 의 '회귀 점검 후 결제 및 쿠폰존 보강'(4405ddc1c) 중
나이스페이 관련 변경만 적용했다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
(cherry picked from commit 3f6d013f9466d11eacba29e81ad515a9a0ceeeef)
기존에는 쿠폰별로 잠금을 잡아, 같은 회원이 서로 다른 포인트 쿠폰을
동시에 요청하면 각 요청이 요청 시작 시점의 보유 포인트 값으로 검사를
통과하여 잔액보다 많은 쿠폰을 받을 수 있었다.
- 잠금 범위를 쿠폰별에서 회원별로 변경
- 보유 포인트를 잠금 획득 후 회원 테이블에서 다시 조회하여 검사
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
(cherry picked from commit fd04b432cf34dfba52e281fc74391f8e2d48fe6b)
게시판/그룹 관리자 문맥(bo_table)으로 타 회원 콘텐츠에 접근·변조되지
않도록 $is_admin 판정을 최고관리자(super) 기준으로 통일.
- bbs/poll_etc_update.php : 설문 기타의견 삭제 소유권
- shop/itemqaformupdate.php : 상품문의 수정/삭제 소유권
- shop/itemuseformupdate.php : 사용후기 삭제 소유권
- bbs/current_connect.php : 게스트 IP 원본 표기
- shop/kakaopay/kakaopay_cancel.php : TID 기반 결제취소
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
(cherry picked from commit 46a005129464d1fbab518fcb70bf524b258e65fc)
- shop/ajax.orderdatasave.php에 check_request_origin() 적용하여
외부 사이트발 자동 요청에 의한 임시 주문 데이터 교체 차단
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- 쿠폰/희망배송일/검색어/계정/결제 콜백 등 입력값을 SQL 컨텍스트에 맞게 재처리
- dt_data·PG 응답 등 비-GPC 값과 소셜 provider 입력 정제 보완
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
토스페이먼츠 결제 요청 폼의 customerName hidden 필드에 주문자명
($od_name)이 인코딩 없이 출력되던 것을 get_text() 적용으로 정리.
직전 주문 필드 인코딩 처리와 동일한 맥락의 마무리.
hidden value 의 엔티티는 결제 SDK 가 값을 읽을 때 브라우저가
디코딩하므로 토스로 전달되는 구매자명에는 영향 없음.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
영카트 주문자명/받는분/입금자명(od_name, od_b_name, od_deposit_name)
이 일부 출력 지점에서 인코딩 없이 노출되어, 저장된 값이 HTML/속성
컨텍스트에서 그대로 렌더링되던 문제 수정. 다음 출력에 get_text() 적용:
- adm/shop_admin/orderform.php, sale1today.php (관리자 주문 화면)
- shop/orderinquiryview.php (PC/모바일/테마 주문조회)
- shop/{inicis,kcp,lg,nicepay,toss}/taxsave_form.php (현금영수증 발행 폼)
- shop/mail/orderupdate{1,2,3}.mail.php, ordermail.mail.php (주문 메일)
비회원 주문 시 입력값이 관리자 화면에서 실행될 수 있는 경로를 차단.
폼 value 의 엔티티는 브라우저 제출 시 디코딩되므로 PG 전송값 및
정상 표시에는 영향 없음.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
KCP 가이드 개정으로 가상계좌 발급 정상 응답이 0000 에서 V000 으로
변경되어, 기존 코드가 발급 성공을 실패로 인식하던 문제를 수정.
결제 hub 의 res_cd 비교 두 곳에서 V000 을 0000 과 동등하게 처리.
가상계좌 입금 완료 처리는 Webhook 입금통보가 담당하므로 본 변경과
무관. 취소/현금영수증/본인인증 경로는 V000 응답 대상이 아니므로
0000 단독 비교 유지.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
카카오 우편번호 서비스의 oncomplete 콜백이 userSelectedType
으로 'R'(도로명) 또는 'J'(지번)을 반환하는데, 서버 측 정규식이
'N|R' 만 허용해 지번 선택 시 빈 문자열로 저장되던 문제를 수정.
N 은 print_address() 의 도로명 표기 분기를 위한 레거시 값으로
호환을 위해 유지.
적용 위치: 회원가입(bbs/register_form_update.php), PC/모바일
주문(shop/, mobile/shop/ orderformupdate.php), 관리자 미완료
주문(adm/shop_admin/inorderformupdate.php) 의 7곳.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
이전 커밋(e53689ac3)의 미수금 처리 방식은 사용자에게 결제 금액과
다른 청구가 발생해 혼란/분쟁을 유발할 수 있어, 동시 주문 race 로
포인트 잔액이 부족하면 결제 자체를 취소하는 방식으로 변경.
- PG 결제가 진행된 경우 (\$tno 존재): cancel_pg.inc.php 로 환불 요청
- 장바구니 복구: 기존 line 839 동일 패턴 (od_id = tmp_cart_id, ct_status = '쇼핑')
- 주문 삭제: g5_shop_order_table 에서 od_id 제거
- 사용자에게 die 로 명확한 오류 메시지 표시
lock timeout 케이스도 동일하게 결제 취소 처리 (보수적).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
shop/orderformupdate.php / mobile/shop/orderformupdate.php 의 포인트
검증과 차감 사이에 TOCTOU race 가 존재하여, 동일 회원이 여러 세션으로
동시에 주문 제출 시 같은 포인트 잔액을 반복 검증 통과 → 다중 차감으로
mb_point 가 음수가 되는 double spend 가 가능했음.
insert_point() 의 기존 named lock 은 (mb_id, rel_table, rel_id, rel_action)
조합 키 기반이라 서로 다른 od_id 주문 간에는 lock 이 다르고, 주문 차감
호출에 rel_* 가 전달되지 않아 lock 미적용 상태였음.
조치: KVE-2026-0687 (쇼핑몰 쿠폰) 와 동일한 회원 단위 MySQL GET_LOCK
패턴을 적용. lock 획득 후 g5_point SUM 으로 잔액을 재조회하여
- 충분하면 정상 차감
- race 로 부족하면 사용 가능한 만큼만 차감 + 부족분은 od_receipt_point
보정 + od_misu(미수금) 으로 반영하여 매장 손실 방지.
MyISAM 정책상 트랜잭션 금지이므로 named lock 으로 직렬화하는 방식이
가장 적합. 데스크톱·모바일 동일 패턴 적용.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
KVE-2026-0876 동일 패턴 추가 발견 5건 일괄 수정.
- shop/itemuselist.php / mobile/shop/itemuselist.php (상품후기 목록)
- shop/itemqalist.php / mobile/shop/itemqalist.php (상품문의 목록)
→ 비회원 접근 가능한 공개 페이지에서 sst/sod 가 ORDER BY 절에
검증 없이 삽입되어 CASE WHEN/SLEEP 기반 blind SQLi 가능했음.
sst 는 컬럼 화이트리스트, sod 는 asc/desc 정규식으로 검증.
- bbs/list.php (게시판 목록)
→ sst 는 wr_datetime/wr_hit/wr_good/wr_nogood 화이트리스트 적용
되어 있으나 sod 가 검증 누락되어 ORDER BY 절에 함수 표현식
삽입이 가능했음. sod 에 asc/desc 정규식 검증 추가.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
shop/kcp/pp_cli_hub_lib.php, shop/kcp/pp_ax_hub_lib.php 의
mf_do_tx() Windows 분기가 사용자 입력이 포함된 KCP CLI 인자를
큰따옴표로 감싼 단일 문자열로 만들어 mf_exec() 첫 인자로 전달했고,
mf_exec() 는 첫 인자를 escape 없이 exec() 에 넘겨 Windows cmd.exe
메타문자(`"`, `&` 등)로 인증 없는 OS 명령 실행이 가능했음.
Linux 분기와 동일하게 실행 파일 경로와 콤마 구분 인자 문자열을
분리하여 mf_exec($bin_exe, $args) 형태로 호출하도록 변경.
mf_exec() 의 foreach 가 두 번째 이후 인자에 escapeshellarg() 를
자동 적용하여 cmd.exe 메타문자가 안전하게 wrapping 됨.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
MySQL GET_LOCK 으로 동일 회원·동일 쿠폰 다운로드 요청을 직렬화하여,
동시 요청 시 is_coupon_downloaded() 체크를 중복 통과해 쿠폰이 중복
발급되는 문제를 방지함.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
shop/personalpayformupdate.php와 lib/shop.lib.php의 ss_personalpay_hash
검증이 loose 비교(==/!=)를 사용하여 PHP type juggling 잠재적 우회 가능성이
있었음. md5 결과 중 "0e..." 형식 hash는 PHP의 loose 비교에서 0e 지수
표기법으로 해석되어 다른 "0e..." 해시와 동등 판정될 수 있음
(소위 magic hash collision 패턴).
실제 익스플로잇 가능성은 낮지만 (md5 출력은 32자 hex 문자열이고 PHP의
문자열 vs 문자열 비교에서는 0e... 패턴이 적용되지 않는 경우가 많음),
defense in depth 차원에서 strict 비교로 변경.
mobile/shop/personalpayformupdate.php는 이미 strict 비교를 사용 중이라
core 두 곳만 동일한 패턴으로 정렬.
- shop/personalpayformupdate.php:35: != / != → !== / !==
- lib/shop.lib.php:2333: == → ===
thisgun