SD-01
🗄️ DBMS 조회 및 결과 검증 (설계)
설계단계 보안설계 · 입력검증
위험도: 상💡 쉽게 말하면
DBMS 질의를 설계할 때 입력값을 문장에 그대로 이어붙이면, 손님이 적어준 메모를 주방이 명령서로 착각하는 것과 같습니다. 입력값은 항상 데이터 칸에 따로 꽂아(파라미터 바인딩) 명령과 섞이지 않게 설계해야 합니다.
DBMS 질의를 설계할 때 입력값을 문장에 그대로 이어붙이면, 손님이 적어준 메모를 주방이 명령서로 착각하는 것과 같습니다. 입력값은 항상 데이터 칸에 따로 꽂아(파라미터 바인딩) 명령과 섞이지 않게 설계해야 합니다.
🎯 직접 해보기 — 공격을 실행해 보세요
아래에서 시스템 상태를 취약 또는 안전(조치 적용)으로 바꾼 뒤 공격 실행을 눌러, 같은 공격이 어떻게 다르게 끝나는지 직접 확인하세요.
# 로그인 입력란에 SQL 구문을 넣어 인증을 우회한다
# [공격 실행] 버튼을 누르면 시작합니다.
📋 설정 비교 (왜 막혔나?)
✗ 취약한 설정
# 설계 결정
입력값을 문자열 이어붙여 SQL 생성
애플리케이션 DB 계정 = 관리자(DBA)
→ SQL 인젝션 + 피해 범위 무제한
✓ 안전한 설정
# 설계 결정
PreparedStatement/ORM 표준 강제
DB 계정 = 해당 테이블 CRUD만
→ 구조 변조 불가 + 피해 국소화
🔧 조치 방법
- 외부 입력으로 SQL 구조가 바뀌지 않는 API(파라미터 바인딩/ORM)를 표준으로 지정합니다.
- DB 연결 계정은 애플리케이션이 쓰는 데이터의 읽기/쓰기/수정/삭제 권한만 부여합니다.
- 공통 Validator/인터셉터로 입력 검증을 일괄 적용하도록 설계합니다.
✅ 점검 체크리스트
- 파라미터 바인딩/ORM이 표준으로 정의됨
- DB 계정이 최소권한으로 설계됨
- 공통 입력검증 지점이 설계됨
점검기준: 개발보안 설계기준 1.1 DBMS 조회 및 결과 검증