비회원 폼메일 발송 시 From 헤더를 관리자 이메일로 고정하고 사용자 입력은 Reply-To로 설정
formmail_send.php에 세션 기반 발송 횟수 제한 추가 (직접 POST 우회 방지)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
sql_query()의 에러 처리가 die()로 SQL 쿼리 전문, MySQL 에러 메시지,
스크립트 파일 경로를 사용자에게 그대로 노출하고 있었음. 기본값
G5_DISPLAY_SQL_ERROR=false 덕분에 일반 호출에서는 트리거되지 않으나,
일부 admin 파일이 명시적으로 sql_query(\$sql, true)로 호출하여
관리자에게 raw SQL을 노출했고, SQLi 공격 시도 중 발생한 에러로 DB
구조(테이블/컬럼명)가 학습되어 정밀 공격에 활용될 수 있었음.
조치:
- 서버 로그(error_log)에는 항상 상세 기록 → 운영자가 디버깅 가능
- \$is_debug 모드(G5_DEBUG=true 또는 super admin)에서만 상세 표시
+ XSS 방지를 위해 htmlspecialchars로 escape
- 그 외 환경에서는 "데이터베이스 처리 중 오류가 발생했습니다." 만 표시
- mysqli/mysql 폴백 분기 둘 다 동일하게 적용
변경:
- lib/common.lib.php:1932 (mysqli 분기)
- lib/common.lib.php:1942 (mysql 분기, 레거시 PHP 5.x 폴백)
PHP 5.2.17 호환 유지 (htmlspecialchars + ENT_QUOTES 모두 PHP 4.0+).
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: == → ===
strstr()은 일치하는 부분 문자열 전체를 반환하므로 존재 여부만 체크할
때는 메모리 할당이 낭비됨. strpos()는 위치(int) 또는 false만 반환하여
메모리 할당 없이 더 빠르게 동일 동작 수행.
적용 파일 (19개, 약 25곳):
- lib/common.lib.php: wr_option html1/html2/secret 검사 3곳
- lib/shop.lib.php: de_taxsave_types 검사 2곳
- lib/latest.lib.php: wr_option secret 검사 1곳
- lib/thumbnail.lib.php: wr_option secret 검사 1곳
- lib/URI/uri.class.php: URI 확장자 검사 1곳
- bbs/view.php: subject/wr_option/content 검사 4곳
- bbs/view_comment.php: wr_option secret 검사 1곳
- bbs/search.php: wr_option/sfl 검사 3곳
- bbs/rss.php: wr_option html 검사 1곳
- bbs/write_update.php: html1/html2 검사 2곳
- bbs/move_update.php: wr_option html 검사 1곳
- adm/admin.lib.php: auth 권한 검사 1곳
- adm/admin.head.php: 메뉴 권한 검사 1곳
- adm/session_file_delete.php: sess_ prefix 검사 1곳
- adm/point_list.php, adm/auth_list.php: sfl mb_id 검사 2곳
- adm/sms_admin/_common.php: install.php 검사 1곳
- adm/shop_admin/configform.php: de_taxsave_types 검사 3곳
- head.sub.php: admin dir 검사 1곳
규칙:
strstr($a, $b) → strpos($a, $b) !== false
!strstr($a, $b) → strpos($a, $b) === false
제외:
- theme/, skin/, plugin/ (사용자 커스터마이징/서드파티)
- strstr() 반환값을 실제로 사용하는 케이스 (예: lib/common.lib.php:4135
if( \$freg = strstr(\$ori_params, '#') ), extend/gif2mp4.extend.php)
기존 구현은 일반 텍스트 게시글(URL/이메일이 전혀 없는 대부분의 경우)
에서도 3개의 preg_replace를 항상 호출하여, 모든 게시글 본문 렌더링
마다 불필요한 regex 컴파일/스캔 오버헤드가 발생.
개선:
1. Fast bailout: ://, www., @, &, ' 가 하나도 없으면 즉시 반환하여
forward/reverse str_replace와 3개의 preg_replace를 모두 생략.
2. 조건부 regex 실행: 각 regex 호출 전에 해당 패턴이 실제로 존재하는지
strpos로 먼저 확인. URL 패턴 없으면 URL regex 생략, 이메일 없으면
email regex 생략 등.
strpos x5 (~1ms) vs preg_replace x3 (~20ms+) 이므로 일반 텍스트 게시글
에서 10~20배 이상 빠르게 동작. 페이지에 수십~수백 개 게시글을 표시하는
목록/검색 페이지에서 누적 효과가 큼.
의미론적 동등성 유지: 각 marker가 없으면 해당 regex가 원래도 no-op였으므로
조건부 실행은 결과에 영향 없음. Fast path는 모든 marker가 없을 때만
동작하므로 str_replace의 부작용(& entity 디코딩 등)도 발생할 여지가 없음.
기존 구현은 preg_split("//u")로 입력 문자열의 모든 문자를 PHP 배열로
분해한 뒤 count/array_slice/join 3단계로 처리하여, 짧은 문자열이든
긴 문자열이든 항상 문자 수만큼 배열 원소를 할당하고 regex를 호출함.
게시글 목록의 제목/내용 표시 등 페이지당 수십~수백 회 호출되는
핫패스에서 불필요한 오버헤드를 발생시킴.
개선:
1. 바이트 길이 빠른 경로: strlen(str) <= len이면 UTF-8 특성상 문자 수도
보장되므로 즉시 반환. ASCII/짧은 제목은 mb_strlen 호출 없이 종료.
2. mbstring 확장 사용: mb_strlen + mb_substr로 배열 생성 없이 상수
메모리로 길이 체크/절단 처리.
3. preg_split 기반 기존 로직은 mbstring 미설치 환경 폴백으로 유지.
의미론적 동등성 유지 (잘라낸 결과와 suffix 부착 조건 모두 동일).
한 요청에서 html_purifier()가 N번 호출되면 매번 약 10~15MB의 HTMLPurifier
인스턴스를 새로 생성하여, 게시글 목록처럼 반복 호출되는 페이지에서
수백 MB~GB 단위로 메모리가 낭비되었음.
- HTMLPurifier 인스턴스를 요청 단위로 캐싱 (admin/normal 2개 변형만 유지)
- safeiframe.txt 파일 I/O + 파싱 결과도 요청 단위로 캐싱
- G5_HTMLPURIFIER_NO_CACHE 상수로 캐싱 opt-out 가능
($html 내용에 따라 config를 동적 변경하는 플러그인 호환용)
동작 변경:
- html_purifier_config / html_purifier_safeiframes hook은 캐시 미스 시점에만
실행됨 (요청당 최대 2회). 정적 config를 설정하는 일반적인 hook에는 영향 없음.
- html_purifier_result hook은 매 호출마다 정상 실행됨.
효과 (게시글 목록 30건 + 첨부파일 평균 3개 = 120회 호출 기준):
기존 ~1.8GB → 개선 후 ~15MB
insert_use_point, delete_use_point, delete_expire_point 함수의 SELECT-then-UPDATE
패턴이 동시 호출 시 데이터 무결성을 깰 수 있는 race condition을 가지고 있었음.
같은 회원의 포인트 작업이 동시에 발생하면 PHP 단에서 캐시한 잔여량을 기준으로
판단하여 결과적으로 음수/초과 차감 등 포인트가 꼬이는 현상이 발생.
MyISAM은 트랜잭션과 FOR UPDATE를 지원하지 않으므로, 락 없이 무결성을 보장하는
lock-free atomic UPDATE 패턴으로 재구현:
- 매 단계마다 가장 우선 처리할 행 1개를 SELECT (LIMIT 1)
- WHERE 절에 사전 검증 조건(잔여량/상태)을 포함한 원자적 UPDATE
- get_sql_affected_rows()로 성공/실패 판별, 실패 시 재시도
- max_iter=1000 안전장치로 무한루프 방지
특징:
- 단일 행 차감(가장 흔한 케이스)에서 기존과 동일한 쿼리 수
- GET_LOCK 등 추가 락 없음 → 같은 사용자 동시 요청도 throughput 손실 없음
- MyISAM/InnoDB 모두 호환, MySQL 5.0~8.x 모두 동작
- bbs/poll_update.php: 설문조사 중복 투표 방지 (FIND_IN_SET을 WHERE에 포함한 원자적 UPDATE)
- bbs/good.php: 추천/비추천 카운터 부풀리기 방지 (INSERT IGNORE 우선 후 카운터 증가)
- lib/common.lib.php: insert_point() 포인트 중복 지급 방지 (MySQL named lock GET_LOCK 사용)
thisgun