Secure Coding & Input Validation

1. Overview

시큐어 코딩 및 입력 검증(Secure Coding & Input Validation, SCI)은 보안을 '나중에 덧붙이는 옷'이 아니라 '설계와 구현의 뼈대'로 인식하여, 코드 한 줄이 만들어낼 수 있는 수리적 부작용을 물리적으로 원천 차단하는 '결함 배제 공학'입니다.

학습자는 외부의 모든 입력값을 잠재적 위협으로 가정하고 물리적으로 정제하는 **입력 검증(Validation)**의 수리적 수순과, 보안 기능이 물리 디스크나 메모리에서 안전하게 작동하도록 보증하는 시큐어 코딩 기법을 배웁니다. 특히, 예외 처리 미흡으로 하드웨어 내부 정보가 누출되는 물리적 실수와 메모리 관리 오류(Buffer Overflow)의 수치적 궤적을 익힙니다. 이를 통해 서비스 가동 시간($Uptime$) 중 보안 사고를 수리적으로 '0'에 가깝게 유지하는 하이엔드 개발 품질 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Input Validation Strategies: Allow-list 기반의 수리적 필터링 및 형식 강제
• Data Sanitization: 위험한 특수 문자를 무해한 문자로 물리 치환하는 법(Escaping)
• Safe State Management: 메모리 공유 자원에 대한 물리적 경합 방지(Thread-safe)
• Secure Error Handling: 에러 메시지가 하드웨어 상세 정보를 넘겨주지 않도록 하는 수리적 캡슐화
• Standardized Code Review: 보안 관점에서의 수치적 코드 품질 검사 가이드라인

Out-of-Scope

• 웹 브라우저 자체의 보안 설정 및 정책 제어 (10-03-01 OWASP 영역에서 분담)
• 암호 알고리즘 자체의 복잡도 분석 (10-01-01 SAA 영역에서 분담)

Boundaries

• SCI vs. OWASP: OWASP(10-03-01)가 '공격자의 관점에서 무엇이 뚫리는가'를 분류한다면, SCI는 '개발자의 관점에서 어떻게 코드를 짜야 뚫리지 않는가'라는 구현의 물리 법칙에 집중하여 구분합니다.

3. Counterexample

• 단순히 "정규 표현식 사용"이라 설명하는 것은 SCI 학습이 아닙니다. 왜 클라이언트 측 검증은 보안 수치로 인정받을 수 없으며 '서버 측 하드웨어 검증'이 수리적으로 최종 방어선이 되는지 증명할 수 있어야 하며, 에러 처리(Try-catch) 시 로그 파일에 사용자의 평문 패스워드가 물리적으로 기록되는 '의도치 않은 정보 유출'의 수리적 재앙을 논증하지 못한다면 시큐어 코딩의 실체를 이해하지 못한 것입니다.

4. Prerequisites

• Software Construction & Code Physics (Basic): 09-01-04의 클린 코드 기법 및 프로그래밍 패러다임 이해가 필수입니다.
• Operating Systems & System Mechanics (Recommended): 03-01-XX의 메모리 구조(Stack, Heap) 및 포인터 연산 이해가 권장됩니다.

5. Learning Map

1. Gate of Trust: 모든 입력 데이터가 시스템의 논리에 합류하기 전 통과해야 하는 물리적 검문소를 세웁니다.
2. The Armor of Logic: 잘못된 수리 연산이나 예상치 못한 입력이 들어와도 하드웨어가 멈추지 않게 방패를 칩니다.
3. Internal Secrecy: 에러가 발생했을 때 내부 하드웨어의 생김새(Stack Trace 등)를 남들에게 수리적으로 숨깁니다.
4. Zero-Defect Code: 반복적인 보안 오딧(Audit)을 통해, 취약점이 자라날 수 없는 완벽한 수치적 청정 코드를 완성합니다.

6. Learning Topics

Basic

Core: 모든 입력은 범죄다 (Input Validation Physics)

• Why to Learn: 사용자가 입력한 숫자가 우리 서버의 파일 시스템을 물리적으로 파괴하는 일을 막기 위해서입니다.
• What to Learn:
  • Positive Validation (Allow-list): 유효한 수치 외에는 모두 수리적으로 거절하는 원칙
  • Type & Length Enforcement: 하드웨어 메모리를 넘치지 않게 하는 데이터 규격 제약
  • Escaping and Encoding: 특수 문자를 '그냥 문자'로 하드웨어가 인식하게 만드는 법
• How to Learn:
  • 숫자만 입력받는 폼(Form)에 긴 문자열을 넣어보고, 백엔드 하드웨어에서 'Integer' 타입 에러가 수리적으로 어떻게 발생하는지 확인 실습
  • <script> 태그를 입력했을 때, <script>로 물리 변환(Encoding)되어 브라우저에서 실행되지 않는 수순 관찰
• Implement: 복잡한 비즈니스 규칙을 통과해야만 데이터를 반환하는 SafeInputPipe

Recommended

Core: 메모리와 자원의 안전한 관리 (Resource Safety)

• Why to Learn: 프로그램의 논리적 맹점을 이용해 해커가 하드웨어의 제어권을 수리적으로 빼앗는 것을 막기 위함입니다.
• What to Learn:
  • Buffer Overflow Avoidance: 입력값이 물리적 메모리 경계를 넘지 않도록 하는 경계값 수치 제어
  • SQL Parameterization: 쿼리 문법과 데이터를 물리적으로 분리하여 해석하게 만드는 기제
  • Memory Safe Languages vs C: 하드웨어 자원을 직접 만지는 언어와 가비지 컬렉터($GC$) 언어의 보안 수리 차이
• How to Learn:
  • 고전적인 '버퍼 오버플로우' 코드를 작성하고, 실제 하드웨어의 'Return Address'가 어떻게 수리적으로 덮어씌워지는지 시뮬레이션
  • PreparedStatement를 사용했을 때와 문자열 더하기를 썼을 때의 수리적 로그 패턴 비교
• Implement: 문자열 연결을 차단하고 바인딩을 강제하는 기초 StoneWallQuery

Practical

Core: 예외처리와 보안 로그 거버넌스 (Defensive Handling)

• Why to Learn: 서비스가 무너지는 순간에 해커에게 시스템의 약점을 수치로 알려주는 친절한 로그를 삭제하기 위해서입니다.
• What to Learn:
  • Fail-Secure Architecture: 오류 발생 시 권한을 얻는 것이 아니라 '모든 권한을 물리 차단'하는 모드로 전환
  • Generic Error Messages: "DB Connection Error" 대신 "일시적 장애"로 수리적 정보를 은폐
  • Anti-tampering Log: 보안 로그 자체가 물리적으로 수정될 수 없도록 무결성을 보존하는 수순
• How to Learn:
  • 일부러 DB 연결을 끊고 웹 페이지에 뜨는 에러 메시지($Stack Trace$)를 보며, 개발자가 쓰는 하드웨어 경로가 수리적으로 유출되는지 관찰 실습
  • 로그 파일에 masking() 함수를 적용하여 개인정보가 별표(*) 처리되는 물리 필터 구축 실습
• Implement: 모든 예외를 잡아내어 보안 친화적 공통 포맷으로 반환하는 SafeGuardHandler

Advanced

Core: 보안 아키텍처 내재화 및 코드 오딧 (Internal Audit)

• Why to Learn: 개발자 한 명의 실수에 기대지 않고, 시스템과 문화 자체가 결함 코드를 물리적으로 밀어내게 하기 위함입니다.
• What to Learn:
  • Static Application Security Testing (SAST): 소스 코드를 실행하지 않고 수리적 결함 패턴을 자동 스캔
  • Security Design Patterns: '보안'을 위해 검증된 수리적 코드 골격(Pattern) 적용
  • Code Review Checklists: 보안 전문가의 눈을 수치화된 항목들로 바꾼 물리 거버넌스 가이드
• How to Learn:
  • SonarQube나 Checkmarx를 연동하여, 자신이 짠 코드의 보안 수치($Security Rating$)를 받아보고 수정하는 물리 교정 실습
  • "보안 코딩 표준(CERT, CWE)" 문서의 특정 항목이 실제 하드웨어 취약점으로 어떻게 번지는지 수리적 연관성 연구
• Implement: 커밋 시점에 자동으로 보안 결함을 찾고 경고를 주는 SecurityLinter

7. Terminology

8. References

Primary

• [P2] SWEBOK v4.0 - Software Construction / Security (Secure Coding Practice) — Development standards.
• [P3] CyBOK - Software Security Knowledge Area (Defensive Programming) — Definitive security context.

Secondary

• [Secure Coding in C and C++] Robert Seacord — The manual for resource safety.
• [Clean Code] Robert C. Martin — Context for maintainable secure logic.

Industry

• [OWASP Secure Coding Practices Quick Reference Guide] — Practical industry standard.
• [CERT Oracle Secure Coding Standard for Java] — Language specific guidance.

9. Final Checklist

Primary

• '블랙리스트' 방식 검증이 '화이트리스트' 방식보다 물리 보안 측면에서 왜 수리적으로 열등한지 설명 가능한가? (P3)
• '메모리 할당' 오류가 시스템의 '가용성'뿐 아니라 '권한 탈취'로 이어지는 수리적 경로를 기술할 수 있는 가? (P3)

Secondary

• '데이터 오염($Tainting$)' 추적 이론을 활용해 사용자 입력이 하드웨어 명령어로 전달되는 궤적을 수치적으로 소통 가능한가?
• SQL Parameterization이 단순한 문자열 필터링보다 왜 물리적으로 더 강력한 방어 기제인지 논증할 수 있는 가?

Industry

• 실무 개발 환경에서 '보안 취약점 스캔' 결과의 '거짓 양성($False Positive$)' 수치를 줄이기 위한 거버넌스 수순을 제안할 수 있는 가? (SFIA)
• 에러 핸들링 로직이 실패했을 때 시스템이 '가장 안전한 물리 상태(Fail-safe)'로 유지되도록 하는 아키텍처를 분석할 수 있는 가?