- 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: == → ===
