EIS

지도 위치 : 3과목 어플리케이션 보안 · README 4장 ③ 영역(어플리케이션) — 공격을 "만들어지기 전에" 없애는 쪽 | 출제기준: 3. 어플리케이션 보안 취약점 > 1. 어플리케이션 보안취약점 대응, 2. 어플리케이션 개발 보안 | 이전: 15 전자상거래 보안 | 다음: 17 인증과 접근통제 출제 빈도 : ⭐ (회당 약 2.3문항 — 출제분석.md. 1.2 → 3.3) · 변화 ▲ (개발보안 0.8 → 3.2) · ⚠️ 신규 범위 포함 (시큐어 코딩 정의, 보안약점 진단가이드 항목, 개발보안 방법론) 세세항목 : 어플리케이션 보안취약점 유형 / 어플리케이션 보안 취약점 대응 기술 / 소프트웨어 개발 보안 개념 및 요구사항 / 소스코드 개발 보안(Secure Coding) / 개발보안 툴

이 노트를 다 읽으면

1. 보안약점 ↔ 취약점 , 시큐어 코딩 ↔ 보안 테스트 를 정의(유 + 종차)로 구별할 수 있다.
2. KISA 소프트웨어 보안약점 진단가이드의 7개 유형 을 말하고, 주어진 약점이 어느 유형인지 분류할 수 있다.
3. 버퍼 오버플로를 일으키는 위험 함수와 안전한 함수 를 짝지을 수 있다.
4. 입력값 검증 원칙(서버 측 · 화이트리스트 · 정규화)과 경로 조작 · OS 명령어 삽입 코드를 고칠 수 있다.
5. 개발보안 생명주기와 방법론( MS-SDL · CLASP · Seven Touchpoints )을 구별할 수 있다.
6. 정적 분석(SAST) ↔ 동적 분석(DAST) , 화이트박스 ↔ 블랙박스 테스트, 대표 도구를 구별할 수 있다.
7. 코드 난독화 의 종류와 안드로이드 디컴파일 방지 설정을 말할 수 있다.

---

0. 이 노트의 판별 축

이 노트가 답하는 질문은 "12~15번 노트의 공격은 결국 코드의 어떤 결함에서 나오고, 그 결함을 어떻게 미리 없애나" 입니다. 앞 노트들의 SQL Injection · XSS · 업로드 · 경로 조작(13번 노트)은 거의 전부 "외부 입력을 검증 없이 썼다" 는 하나의 결함으로 모입니다(축 5의 왼쪽). 앞에서 배운 버퍼 오버플로 · 포맷 스트링(03번 노트), 스택 가드 · ASLR(04번 노트), 분석 도구(05번 노트), 암호 알고리즘과 키 길이(19번 노트)가 이 노트에서 코드 한 줄 단위로 다시 나옵니다. 출제가 가장 빠르게 늘고 있는 영역입니다(0.8 → 3.2).

---

1. 개발보안의 기본 개념

1.1 ⭐ 용어 정의

💡 관계: 개발보안 ⊃ 시큐어 코딩 . 시큐어 코딩은 개발보안의 구현 단계 부분입니다.

1.2 왜 개발 단계인가 · 제도

결함은 늦게 발견할수록 고치는 비용이 커집니다. 운영 중 WAF로 막는 것은 증상 차단이고, 코드에서 없애는 것은 원인 제거입니다(0절 축 1).

국내 공공 부문은 행정안전부의 「행정기관 및 공공기관 정보시스템 구축 · 운영 지침」에 따라 정보화사업에 소프트웨어 개발보안 적용 과 보안약점 진단 · 제거 를 요구합니다. 2012년 일정 규모 이상 사업부터 시작해 감리 대상 사업으로 단계적으로 확대됐습니다(확대 시점은 보도마다 차이가 있어 시험 전 지침 원문 확인 필요). 기준 문서는 KISA · 행정안전부의 「소프트웨어 개발보안 가이드」 와 「소프트웨어 보안약점 진단가이드」 (2021년판이 KISA 누리집에 공개)입니다. 2021년판 기준으로 설계 단계 보안설계 기준 20개, 구현 단계 보안약점 49개 입니다.

📝 기출 포인트 — " 소스코드의 잠재적 취약점을 제거하는 안전한 코딩 = 시큐어 코딩 "(2025 강사 "처음 등장" 언급 ⚠️). 출제분석.md의 관찰대로 이 영역은 보안약점 진단가이드가 출제 원천 이라, 가이드의 용어(예: "경로 조작 및 자원 삽입")가 그대로 보기에 나옵니다.

---

2. ⭐ 보안약점 7개 유형 — 분류가 곧 문제

KISA 소프트웨어 보안약점 진단가이드(2021) 구현 단계 기준입니다. 괄호의 항목 수는 2021년판 기준이며, 2019년판도 같은 7개 유형 구조입니다.

(출처: KISA 「소프트웨어 보안약점 진단가이드(2021)」. 항목 수는 공개된 분석 자료의 분류와 대조했으며, 세부 항목 명칭은 시험 전 원문 확인 권장.)

분류 요령 — 두 질문으로 대부분 풀립니다.

1. 원인이 "외부 입력을 믿었다"인가? → ① 입력데이터 검증 및 표현 (파일 업로드 · 다운로드, 버퍼 오버플로, 포맷 스트링도 여기)
2. 원인이 "보안 기능(인증 · 권한 · 암호 · 비밀번호)을 잘못 만들었다"인가? → ② 보안기능 (키 길이, 취약 알고리즘, 하드코드 비밀번호)
3. 둘 다 아니면 이름으로: 동시성 → ③, 예외 → ④, 메모리 · 자원 실수 → ⑤, 숨김 실패 → ⑥, API → ⑦

⚠️ 반례: "버퍼 오버플로"는 코드오류가 아니라 입력데이터 검증 및 표현 입니다(입력 길이를 검사하지 않은 것이 원인). "취약한 암호 알고리즘(SHA-1 · DES)"은 입력이 아니라 보안기능 입니다.

📝 기출 포인트 — " 파일 업로드 · 다운로드(입력 검증)와 불충분한 키 길이(보안기능)의 분류 차이 "(2024), "SW 보안약점 중 보안기능 유형 구분"(2014), 경로 조작 및 자원 삽입 (2024 · 2025), 코드 삽입(eval) , 메모리 버퍼 오버플로 약점, 운영체제 명령어 삽입(Runtime.exec) , 취약한 암호 알고리즘(SHA-1) (2025) — 진단가이드 항목명이 그대로 출제됩니다.

---

3. 입력값 검증과 대표 약점 코드

3.1 ⭐ 입력값 검증 원칙

입력값 검증 — [보안 대응 기술]인데, [ 외부에서 들어온 모든 값을 신뢰하지 않고 형식 · 길이 · 범위 · 문자 집합을 서버 측에서 확인 한다]는 점에서 출력 직전에 특수문자를 바꾸는 출력 인코딩과 구별된다(둘 다 필요).

3.2 운영체제 명령어 삽입 (Java)

// 약점: 외부 입력을 그대로 OS 명령에 붙임
String dir = request.getParameter("dir");
Runtime.getRuntime().exec("cmd.exe /c dir " + dir);     // dir = "C:\ & del /q C:\data\*"

// 개선: 허용 값 목록에서만 고름 (화이트리스트)
String[] allowed = {"report", "upload"};
if (!Arrays.asList(allowed).contains(dir)) throw new IllegalArgumentException();
Runtime.getRuntime().exec(new String[]{"cmd.exe", "/c", "dir", "C:\\app\\" + dir});

🔍 읽는 포인트 : & | ; 같은 명령 연결 문자 가 입력에 섞이면 두 번째 명령이 실행됩니다. 셸 호출 자체를 피하고, 불가피하면 허용 목록 으로 제한합니다.

3.3 경로 조작 및 자원 삽입 (Java)

// 약점
String name = request.getParameter("file");
File f = new File("/var/app/files/" + name);           // name = "../../../etc/passwd"

// 개선: 경로 문자 제거 + 정규화 후 허용 디렉터리 안인지 확인
name = name.replaceAll("[/\\\\]|\\.\\.", "");
File f2 = new File("/var/app/files/", name);
if (!f2.getCanonicalPath().startsWith("/var/app/files/")) throw new SecurityException();

🔍 읽는 포인트 : 13번 노트의 디렉터리 트래버설을 코드 쪽에서 본 것입니다. "자원 삽입"은 입력으로 포트 · 소켓 같은 자원 식별자 를 조작하는 경우까지 포함하는 이름입니다.

3.4 SQL 삽입과 취약한 암호 (Java)

// SQL 삽입 개선: 바인드 변수
PreparedStatement ps = con.prepareStatement("SELECT * FROM member WHERE id = ?");
ps.setString(1, request.getParameter("id"));

// 취약한 암호화 알고리즘 사용 (보안기능)
MessageDigest md = MessageDigest.getInstance("SHA-1");    // → "SHA-256" 이상

🔍 읽는 포인트 : 앞에서 배운 대로(19 · 20번 노트) MD5 · SHA-1 · DES는 취약 알고리즘입니다. KISA 암호 이용 안내 기준으로 AES 128비트 이상, RSA 2048비트 이상, SHA-256 이상 을 씁니다. 비밀번호 저장에는 솔트를 붙인 일방향 해시 를 씁니다.

📝 기출 포인트 — 입력값 검증 미흡으로 생기는 취약점 유형(2016), 특수문자 필터링이 필요한 OS 명령 실행 (2022), 출력 필터링 코드가 막는 것 = XSS (2022), 안전한 암호 알고리즘 · 키 길이 선택 (2022).

---

4. ⭐ 버퍼 오버플로 · 포맷 스트링 — 안전한 함수

4.1 위험 함수 ↔ 안전한 함수

void copy(char *input) {
    char buf[16];
    strcpy(buf, input);             // 길이 검사 없음 → 16바이트를 넘으면 스택의 리턴 주소까지 덮음
}
/* 개선 */
strncpy(buf, input, sizeof(buf) - 1);
buf[sizeof(buf) - 1] = '\0';        // strncpy는 널 종료를 보장하지 않으므로 직접 넣음

🔍 읽는 포인트 : 위험 함수의 공통점은 "목적지 버퍼 크기를 인자로 받지 않는다" 입니다. 안전한 함수는 길이(크기)를 인자로 받습니다.

4.2 포맷 스트링

포맷 스트링 취약점 — [입력데이터 검증 약점]인데, [ 사용자 입력이 printf 계열 함수의 포맷 문자열 자리에 그대로 들어가 %x · %s로 메모리를 읽고 %n으로 메모리에 쓰게 된다 ]는 점에서 버퍼 크기를 넘쳐 쓰는 버퍼 오버플로와 구별된다.

운영 · 컴파일 대응 (04번 노트에서 배운 것): 스택 가드(카나리), ASLR , 실행 불가 스택(NX/DEP), 컴파일러 경고 활성화.

📝 기출 포인트 — 안전한 함수 · strncpy 는 A3.2 최다(4회 + 위험 함수 5회): "BOF 방지를 위해 피해야 할 C 함수", " gets ↔ fgets, strcpy ↔ strncpy 짝짓기 "(2024), " 취약하지 않은 함수 고르기 "(2019 · 2025), strcpy 코드의 스택 오버플로(2025). 포맷 스트링의 직접 위험이 아닌 것 (2018 · 2019).

---

5. 개발보안 생명주기와 방법론

5.1 생명주기별 활동과 산출물

📝 기출 포인트 — "개발 단계별 산출물( 분석 단계 = 요구사항 정의서 )"(2025).

5.2 ⚠️ 개발보안 방법론

📝 기출 포인트 — CLASP · MS-SDL · Seven Touchpoints 구분 (2025). "마이크로소프트 = SDL", "OWASP = CLASP", "7개 접점 = Touchpoints"로 이름과 출처를 짝지으세요.

---

6. 개발보안 툴 — 분석과 테스트

6.1 ⭐ 정적 분석 ↔ 동적 분석

(실행 중 앱 내부에 센서를 심어 둘을 결합한 방식을 IAST 라 부릅니다.)

⚠️ 반례: Jenkins는 정적 분석 도구가 아니라 CI(지속적 통합) 서버 입니다. 정적 분석 도구를 파이프라인에서 돌려 주는 역할입니다(2025 기출 보기).

💡 축 2(실행하나)와 축 3(구조를 아나)은 다른 축 입니다. 정적 분석은 화이트박스이지만, 화이트박스 테스트가 모두 정적인 것은 아닙니다(커버리지 측정은 실행이 필요).

📝 기출 포인트 — " 정적 분석 ↔ 동적 테스트 구분 "(2017), " 내부 구조 기반 = 화이트박스 "(2019 · 2025), " 소스 정적 분석 도구(FindBugs · PMD · SonarQube)와 Jenkins 구분 "(2025), 포맷 스트링 점검 도구와 패킷 도구 구분(2016).

6.2 난독화 — 분석을 어렵게

난독화 (Obfuscation) — [역공학 방지 기법]인데, [ 프로그램의 기능은 그대로 두고 코드를 사람이 이해하기 어렵게 바꾼다 ]는 점에서 내용을 키 없이는 못 읽게 만드는 암호화와 구별된다.

// 안드로이드 app/build.gradle
buildTypes {
    release {
        minifyEnabled true          // 코드 축소 · 난독화(R8/ProGuard) 활성화
        proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    }
}

🔍 읽는 포인트 : 난독화는 release 빌드 타입 에서 minifyEnabled true로 켭니다. 디버그 빌드는 보통 끕니다. APK를 풀어 보는 도구( dex2jar , jadx, apktool 등)는 디컴파일 도구 이지 난독화 도구가 아닙니다.

📝 기출 포인트 — 난독화는 2023~2025에 매년(5회): 앱 디컴파일 방지 , 디스어셈블 방지, 소스코드 ↔ 바이너리 난독화 , 제어 흐름 난독화 , release에서 minify 활성화 , dex2jar = 디컴파일 도구 .

---

7. 실기 연결

관련 수행준거 : 2-2-5 WEB/WAS 서버 설정 점검(입력 검증 미흡에 대한 보완), 2-4-2 주요 서비스 보안점검 내용 · 도구 · 발견 취약점 · 보완사항 기록. 최근 강의에서 KISA 보안약점 진단가이드가 실기에서도 출제 원천으로 언급됩니다.

코드 진단 기록표 예시

---

8. 확인 문제

1. 시큐어 코딩에 대한 설명으로 가장 적절한 것은? ① 운영 중인 웹서버 앞에 WAF를 두는 것 ② 구현 단계에서 소스코드의 잠재적 보안약점을 제거하는 코딩 기법 ③ 완성된 프로그램을 실행하며 공격을 시도하는 테스트 ④ 배포 후 보안 패치를 적용하는 절차

2. KISA 소프트웨어 보안약점 진단가이드의 분류에서 유형이 나머지와 다른 하나는? ① 경로 조작 및 자원 삽입 ② 위험한 형식 파일 업로드 ③ 충분하지 않은 키 길이 사용 ④ 운영체제 명령어 삽입

3. 버퍼 오버플로 방지를 위한 함수 대체로 옳지 않은 것은? ① gets → fgets ② strcpy → strncpy ③ sprintf → snprintf ④ strncat → strcat

4. 다음 중 포맷 스트링 취약점의 직접적인 결과로 보기 어려운 것은? ① 스택 메모리 내용 노출 ② %n을 이용한 메모리 값 변조 ③ 프로그램 비정상 종료 ④ 네트워크 구간의 평문 도청

5. 정적 분석에 대한 설명으로 틀린 것은? ① 프로그램을 실행하지 않고 소스코드를 분석한다 ② 구현 단계부터 적용할 수 있다 ③ 실행 환경의 설정 오류까지 정확히 찾아낸다 ④ FindBugs · PMD · SonarQube가 대표 도구다

6. 마이크로소프트가 만든, 교육부터 대응까지 단계별 필수 보안 활동을 정의한 개발보안 방법론은? ① CLASP ② Seven Touchpoints ③ MS-SDL ④ OWASP Top 10

7. 안드로이드 앱의 디컴파일 분석을 어렵게 하기 위한 조치로 옳은 것은? ① dex2jar를 앱에 포함한다 ② release 빌드에서 minifyEnabled를 true로 둔다 ③ 디버그 코드를 남겨 둔다 ④ 문자열 상수에 키를 하드코드한다

정답과 해설

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수 · 함정

부록 C. AI · NotebookLM 복습 프롬프트

이 16번 노트(취약점 대응과 개발보안)만 근거로 4지선다 7문제를 내줘. 노트 밖 내용은 쓰지 마.
시큐어 코딩 정의, 보안약점 7개 유형 분류(입력데이터 검증 vs 보안기능), 위험 함수와 안전한 함수 짝, 경로 조작 코드, SAST/DAST, 개발보안 방법론, 난독화는 반드시 포함해줘.
내가 답하면 채점하고, 오답 보기가 0절의 어느 축 반대편인지 절 번호와 함께 설명해줘.