cw2007/POSA_LEAKSMS

유창욱 90f121e14c chore: import codebase with security hardening

SHT30 온습도 모니터링 시스템 전체 소스(서버 PHP, STM32 펌웨어, SQL, 테스트).
전체 코드리뷰에서 도출된 보안 하드닝 10건 반영:
- 요청 서명 HMAC-SHA256 전환(펌웨어 sig.c/서버 config.php/호스트 패리티 동시)
- 재전송 방어 + 기본 API_KEY fail-closed + 디바이스 문자열 정제(api/sensor_data.php)
- 오프라인 SMS 중복 발송 경합 제거(cron_heartbeat.php, 원자적 선점)
- CSV 수식 주입 방지(monthly_report.php), 감사로그 회전 락(retention_cleanup.php)
- 브루트포스 카운터 원자화(login.php), 예시 TOTP 비밀키 무효화, 마이그레이션 멱등화

_backup/(하드코딩 실 비밀값 포함)·config.local.php·런타임 상태는 .gitignore 제외.

2026-06-20 09:37:40 +09:00

3.8 KiB

Raw Blame History

title

date

last_updated

Review Cycle Knowledge Capture for Leak SMS v2605

참고: 이 문서는 누수감지 시절의 기록(레거시)이며, 현재 시스템은 SHT30 온습도 전용으로 전환되었습니다.

Context

The v2605 hardening work touched PHP pages, MySQL schema, Raspberry Pi capture logic, operations documentation, and deployment notes at the same time. That creates two recurring risks: a feature can be visible in the UI before the DB migration is applied, and static syntax checks can miss broken HTML or operational gaps.

Guidance

At the end of each execution-review cycle, capture the concrete lessons in docs/solutions/ before declaring the work finished. For this project, the minimum checklist is:

Run PHP syntax checks on every changed PHP entry point, including new admin pages.
Run Python compile checks after Raspberry Pi runtime edits.
Search non-backup files for stale secrets, old endpoint names, or legacy phone numbers.
Keep stale-secret search patterns out of durable docs or mask them; otherwise the verification command can reintroduce the exact legacy values it is meant to detect.
Confirm new SQL migrations are documented in both the project README and the top-level report.
If a feature depends on optional schema, code the PHP page to degrade safely when the table or column is absent.
When adding security-evidence features, update both sides of the handoff: runtime screens/scripts (security_evidence.php, collect_evidence.py) and the HWP attachment docs that tell an operator what to submit.
After python -m py_compile, remove all generated __pycache__ directories under the workspace, not just the runtime package that was edited.

Why This Matters

The deployment target is a small operational system where a hidden migration miss can block incident response after a real leak alert. Capturing these checks makes the next cycle faster and reduces repeat mistakes around migrations, secrets, and PHP pages that pass php -l but still need markup review.

When to Apply

Before calling a v2605 improvement complete.
After adding DB columns used by dashboard/report pages.
After adding Raspberry Pi environment variables or runtime timing logic.
Before handing off deployment notes to an operator.

Examples

For photo timeline work, the compatible pattern is to detect leak_photo.sequence_no and leak_photo.photo_stage before using them. New installs can use sql/schema_v2605.sql, while existing installs apply sql/migration_photo_timeline.sql.

For final verification, keep generated cache directories out of the handoff after running python -m py_compile.

For security evidence work, the runtime artifacts and the submission guide must stay aligned. If php/security_evidence.php?format=md exists, docs/SECURITY_EVIDENCE_PACKAGE.md, docs/SECURITY_PLAN_PASS_READINESS.md, and docs/SECURITY_PLAN_HWP_REVIEW.md should all point to it. If a Pi evidence collector exists, installation docs must include the exact command and explain that raw API/SMS keys are not printed.

docs/README.md
sql/migration_photo_timeline.sql
php/setup_wizard.php
php/security_evidence.php
php/monthly_report.php
raspberry_pi/collect_evidence.py
docs/SECURITY_EVIDENCE_PACKAGE.md

3.8 KiB Raw Blame History