정보보안기사 실기 재도전 07 — 웹 공격·시큐어코딩·웹로그 판독 (XSS·CSRF·SQL Injection·업로드)

정보보안기사 실기 재도전 07 — 웹 공격·시큐어코딩·웹로그 판독 (XSS·CSRF·SQL Injection·업로드)

출제기준 주요항목 1. 시스템·네트워크 보안특성 파악 (1-3 서비스별) / 2. 취약점 점검·보완 (2-2 서비스) + 출제기준 외 (웹 코드·공격)
서술·실무가 가장 자주 나오는 편입니다.
공격 이름만 외우지 말고 "코드나 로그를 보고 → 공격 유형 → 성공 근거 → 대응"을 쓰는 연습을 합니다.

---

이번 편 출제 맵 ⭐⭐⭐

주제	출제 회차 (예시)	유형
PHP 파일 업로드 취약점·우회·성공 조건	23회 13번, 29회 14번	서술
웹쉘 (Weevely)	29회 8번	단답
XSS 유형 3가지 / 2가지 정의	26회 9번, 31회 14번, 32회 6번	단답·서술
CSRF 토큰 코드 해석 + 세션/쿠키	31회 18번	실무
SQL Injection 로그 판독	22회 17번	실무
HttpOnly	28회 9번	단답
Apache 디렉터리 리스팅 차단	29회 11번	단답
버퍼 오버플로우 코드 (strcpy)	산업기사 30·31회 5번	실무
웹 로그 공격 판별	23회 15번 외	실무

 

(회차는 기출 파일과 이론 정리 문서에서 확인한 예시입니다. 전수 목록은 아니에요. 이 편은 반복 출제 서술이 많은 구간이라, XSS(26회·31회), PHP 업로드(23회·29회)가 두 번씩 나왔다는 점에 주목하세요.)

---

1. 웹 공격 구분 한눈에 보기 ⭐⭐⭐

공격	공격 대상	핵심
XSS	클라이언트(사용자 브라우저)	악성 스크립트 실행, 쿠키 탈취
CSRF	서버	사용자 권한·세션으로 의도하지 않은 요청
SQL Injection	DB	입력값에 SQL 구문 주입
파일 업로드	서버	웹쉘 실행
파일 삽입·트래버설	서버	외부 파일 포함 / ../로 경로 이탈
HTTP Response Splitting	응답 헤더	CR/LF 삽입

---

2. XSS (Cross-Site Scripting) ⭐⭐⭐

정의: 게시판·메일 등에 악성 스크립트를 삽입해 다른 사용자의 브라우저에서 실행되게 하는 공격

→ 세션 쿠키 탈취(document.cookie), 개인정보 유출, 피싱 유도, 리다이렉트

유형	동작	특징
반사형 (Reflected)	악성 URL 클릭 → 서버가 파라미터를 응답에 그대로 반영 → 실행	저장 안 됨, 이메일·링크로 유도
저장형 (Stored)	악성 스크립트가 서버 DB에 저장 → 해당 페이지 방문자 모두 감염	피해 범위 큼 (게시판)
DOM 기반	클라이언트 JS가 DOM을 처리하는 과정에서 실행	서버 응답에 흔적 없음

26회 9번 / 32회 6번 정답: (A) 반사형  (B) 저장형  (C) DOM 기반
구분 기준은 "저장 여부":
  저장 = 저장형 / URL 클릭 즉시 응답 반영 = 반사형 / 클라이언트 JS 처리 = DOM 기반
공격 코드 예: <script>alert(document.cookie)</script>
⚠️ HTML 코드에 <script>alert(document.cookie)</script>가 게시글에 들어 있으면 저장형 XSS
   (31회 17번 그림 2가 이 유형)

 

XSS 대응 ⭐⭐⭐

① 입력값 검증(화이트리스트) + 출력 시 HTML 인코딩/이스케이프 (< → &lt;, > → &gt;)
② 쿠키 HttpOnly 속성 (JS의 쿠키 접근 차단)
③ CSP(Content-Security-Policy) 헤더로 스크립트 출처 제한
④ 위험 태그·이벤트(<script>, onerror) 필터링, WAF

31회 14번 (서술): XSS 2가지 종류와 정의 → 반사형 + 저장형을 쓰고, 정의에 "저장 여부"와 "스크립트 실행 위치"를 넣는다

---

3. CSRF ⭐⭐⭐

정의: 인증된 사용자의 세션을 악용해 공격자가 만든 요청(비밀번호 변경·송금 등)이 사용자 모르게 서버로 전송되게 하는 공격.

서버가 "요청이 사용자 의도인지" 확인하지 않는 점을 이용합니다.

구분	XSS	CSRF
실행 위치	클라이언트에서 악성 스크립트 실행	서버로 의도하지 않은 요청 전송
결과	클라이언트 정보 탈취	서버에서 사용자 권한으로 작업 수행

 

대응

① CSRF 토큰: 요청 페이지 생성 시 난수 토큰을 만들어 세션에 저장,
              폼에는 hidden 필드로 전달 → 요청 시 세션 토큰 = 파라미터 토큰인지 서버가 검증
② Referer / Origin 검증
③ 재인증(비밀번호 재입력)·CAPTCHA로 중요 기능 보호
④ 쿠키 SameSite 속성 (Strict/Lax)
⑤ 상태 변경은 POST로, XSS 취약점 제거

 

31회 18번 — 코드 해석

session.setAttribute("SESSION_CSRF_TOKEN", UUID.randomUUID().toString());   // 난수 토큰을 세션에 저장

<input type="hidden" name="PARAM_CSRF_TOKEN" value="${SESSION_CSRF_TOKEN}"/>  <!-- 폼에 hidden으로 전달 -->

(1) 세션과 쿠키:
    쿠키 = 클라이언트(브라우저)에 저장, 텍스트(최대 약 4KB), 노출·변조 위험
    세션 = 서버에 저장, 클라이언트에는 세션 ID만(쿠키로) 전달, 보안성 높음
(2) 대응하는 취약점 = CSRF / 공격 기법 = 사용자 권한으로 위조된 요청을 서버에 전송
(3) 추가 보완: 시큐어 코딩, 입력값 검증, 소스코드 정적(SAST)·동적(DAST) 분석, 보안 약점 점검, 보안 코딩 교육, WAF

---

4. SQL Injection ⭐⭐⭐

정의: 입력값 검증이 미흡한 웹 애플리케이션에 SQL 구문을 주입해 DB를 조작·데이터 탈취·인증 우회하는 공격

유형	내용
인증 우회	' or '1'='1
Union Based	UNION SELECT로 다른 테이블 조회
Error Based	에러 메시지로 정보 획득
Blind	결과 대신 참/거짓 응답 차이·응답 시간으로 한 글자씩 추론 (Boolean Based, Time Based sleep())

 

22회 17번 — HTTP 요청 로그 판독

GET /member/login.php?user_id=1' or '1' = '1'# &user_pw=foo HTTP/1.1
GET /member/login.php?user_id=1' or '1' = '1 &user_pw=foo HTTP/1.1

1) 취약점: SQL Injection (인증 우회)
2) 판단 이유: user_id 파라미터에 작은따옴표와 항상 참인 조건(or '1'='1)이 들어 있고,
              # 로 뒤쪽 조건을 주석 처리하려는 시도가 보임. 로그인 인증을 우회하려는 패턴
3) 대응: PreparedStatement(파라미터 바인딩), 입력값 검증(특수문자 이스케이프·화이트리스트),
         에러 메시지 비노출, DB 계정 최소 권한, WAF

 

인증 우회 예 (산업기사 28회 17번)

원본: select * from users where id='[입력]' and pwd=PASSWORD('[입력]');
입력 id: admin'#
실행: select * from users where id='admin' #' and pwd=PASSWORD('password');
→ # 은 MySQL 주석이라 뒤의 비밀번호 조건이 무효화되어 비밀번호 검증 없이 admin 로그인
주석 기호: #(MySQL) · -- (공백 필요, 표준) · /* */

 

대응 코드

PreparedStatement pstmt = con.prepareStatement("SELECT * FROM users WHERE id=? AND pw=?");
pstmt.setString(1, id);  pstmt.setString(2, pw);

PreparedStatement = 쿼리 구조를 먼저 컴파일하고 입력은 데이터로만 바인딩 → SQL 구문으로 해석되지 않음
22회 10번 유형 (빈칸): DB 연결 계정에 (최소 권한)이 설정된 계정 사용 / 쿼리문을 (문자열 연결)로 생성하지 않는다 /
                      동적 SQL 생성 시 (입력값)에 대한 검증 수행
                      (22회 파일에 답이 없어 일반적인 시큐어 코딩 지침 기준으로 채운 답입니다)

---

5. 파일 업로드 · 웹쉘 ⭐⭐⭐

웹쉘(Web Shell): 서버에서 원격 명령을 실행할 수 있는 악성 스크립트(php·jsp·asp).

업로드 취약점으로 설치됩니다.

도구: China Chopper, Weevely

29회 8번: 공격자가 a.php를 게시판에 업로드하고 weevely로 원격 호출한다. 이 파일은? → 웹쉘(Webshell)

 

서술형 3요소 (23회 13번, 29회 14번)

문제는 "취약점명 / 업로드 로직 우회 기법 / 공격 성공 조건"을 묻습니다.

취약점명: 검증 미흡한 파일 업로드 취약점 (Unrestricted File Upload)
         — 실제 내용·확장자는 보지 않고 클라이언트가 보낸 Content-Type(MIME) 헤더만 검증

우회 기법:
  ① Content-Type 헤더 변조 (shell.php를 올리면서 image/jpeg 등으로 위장, Burp Suite 같은 프록시 사용)
  ② 이중 확장자 (shell.php.jpg), 대소문자·널 문자 (shell.php%00.jpg), 확장자 블랙리스트 허점

공격 성공 조건 (3가지):
  ① 업로드 디렉터리가 웹에서 접근 가능
  ② 해당 디렉터리에서 서버 측 스크립트(php 등) 실행이 가능
  ③ 업로드된 파일의 경로(이름)를 알 수 있음

 

대응 ⭐⭐⭐

① 확장자 화이트리스트 + 서버 측에서 파일 시그니처(매직 넘버)·MIME 검증
② 업로드 디렉터리를 웹 루트 밖에 두거나 실행 권한 제거 (.htaccess로 php 실행 금지)
③ 파일명 랜덤화·저장 경로 비노출, 업로드 크기 제한 (LimitRequestBody)
④ WAF, 웹쉘 탐지(YARA, 무결성 점검), 로그 모니터링

⚠️ 서술 포인트: 공격 성공 조건은 "올라가고 + 경로를 알고 + 실행된다"

---

6. 파일 삽입 · 트래버설 · 디렉터리 리스팅 ⭐⭐

공격	내용	대응
파일 삽입 (RFI/LFI)	include에 외부·로컬 파일 경로를 파라미터로 받아 원격 코드 실행	php.ini allow_url_fopen = Off, allow_url_include = Off, include 대상을 고정·화이트리스트
디렉터리 트래버설	../로 웹 루트 밖 시스템 파일(/etc/passwd) 접근	경로 정규화·검증, ../ 필터링, 최소 권한·chroot
디렉터리 인덱싱	인덱스 파일이 없을 때 파일 목록 노출	Apache Options -Indexes, IIS 디렉터리 검색 사용 안 함

• 트래버설 인코딩 우회: %2e%2e%2f, 유니코드 %c0%ae·%c0%af
• 로그 판단: 응답 200 = 성공 가능성, 404/403 = 실패
• FollowSymLinks 위험: 심볼릭 링크로 웹 루트 밖 파일 접근 → 제거(-FollowSymLinks)

29회 11번: Options Indexes FollowSymLinks Includes ExecCGI 에서 디렉터리 리스팅 방지를 위해 제거할 것 → Indexes

---

7. HTTP Response Splitting · 쿠키 속성 ⭐⭐

HTTP Response Splitting

원리: 사용자 입력값이 HTTP 응답 헤더(Location, Set-Cookie)에 반영될 때
      CR(\r, %0d)·LF(\n, %0a)를 삽입 → 응답을 둘로 분할 → 가짜 응답(헤더·본문) 주입
피해: XSS, 캐시 포이즈닝, 쿠키 설정, 페이지 변조
대응: 입력값의 CR·LF 제거·인코딩, 헤더에 사용자 입력 직접 사용 금지

 

쿠키 보안 속성 ⭐⭐⭐

속성	효과
Secure	HTTPS 통신에서만 쿠키 전송 → 스니핑 방지
HttpOnly	JavaScript로 쿠키 접근 불가 → XSS를 통한 쿠키 탈취 방지
SameSite	교차 사이트 요청에 쿠키 전송 제한 (Strict·Lax·None) → CSRF 완화
Domain · Path	쿠키가 전송될 범위

28회 9번 정답: JavaScript로 쿠키에 접근할 수 없게 하는 것 → HttpOnly
⚠️ HttpOnly는 XSS 자체를 막는 것이 아니라 "쿠키 탈취" 피해를 줄입니다.
세션 관리: 로그인 시 세션 ID 재발급, 로그아웃 시 세션 파기, 세션 ID 무작위·충분한 길이, 타임아웃

---

8. 시큐어 코딩 — 버퍼 오버플로우 ⭐⭐⭐

정의: 할당된 버퍼 크기를 초과하는 데이터를 입력해 인접 메모리를 덮어쓰는 공격
스택 오버플로우: 지역변수 초과 → 복귀 주소(RET) 덮어쓰기로 실행 흐름 탈취
힙 오버플로우: 동적 할당(힙) 영역의 경계 미검사
공격 요소: 셸코드 · NOP Sled(0x90) · JMP ESP · 힙 스프레이

취약 함수	안전 함수
strcpy strcat gets scanf sprintf	strncpy strncat fgets snprintf

산업기사 30·31회 코드: char buf[24]; strcpy(buf, string);  → 버퍼 오버플로우 (길이 검사 없음)
수정: strncpy(buf, string, sizeof(buf)-1); buf[sizeof(buf)-1]='\0';

방어 기법: Stack Canary(RET 앞 값 변조 탐지) · ASLR(주소 무작위화) · DEP/NX(스택 실행 금지) · 안전 함수·경계 검사
레이스 컨디션(TOCTOU): 검사 시점과 사용 시점 사이에 자원을 바꿔치기 → 권한 상승 / 대응: 원자적 연산, mkstemp, 락

⚠️ 코드가 주어지면 strcpy·gets 같은 취약 함수를 먼저 찾는다
⚠️ 스택 오버플로우 = 복귀 주소 / 힙 오버플로우 = 동적 할당 영역

---

9. Apache / IIS 웹 서버 보안 설정 ⭐⭐⭐

항목	설정	효과
디렉터리 리스팅 차단	Options -Indexes	파일 목록 노출 방지
심볼릭 링크 제한	Options -FollowSymLinks	웹 루트 밖 접근 방지
버전 노출 최소화	ServerTokens Prod, ServerSignature Off	배너 그래빙 대응
요청 크기 제한	LimitRequestBody 5242880	대용량 업로드·POST DoS 방지
.htaccess 제한	AllowOverride None	임의 설정 변경 방지
불필요 기능 제거	TraceEnable Off, 샘플·매뉴얼 삭제	공격 면적 축소
업로드 실행 제한	업로드 디렉터리 php·cgi 실행 거부 (FilesMatch + Deny from all)	웹쉘 실행 방지

• 로그: access_log, error_log / 설정: /etc/httpd/conf/httpd.conf
• IIS: 웹 루트 inetpub\wwwroot, 익명 계정 IUSR, 불필요 HTTP 응답 헤더는 URL Rewrite 모듈의 아웃바운드 규칙으로 제거 (31회 10번)

---

10. 웹 로그 판독 ⭐⭐⭐

Apache 접근 로그(combined) 한 줄:

IP - - [시각] "GET /경로?파라미터 HTTP/1.1" 상태코드 응답크기 "Referer" "User-Agent"

상태 코드	의미
200	정상 처리 → 공격이면 성공 가능성
301/302	리다이렉트
403	접근 거부
404	없음 → 시도 실패
500	서버 오류 → 취약점 탐색 단서
502/504	게이트웨이 오류

 

공격 패턴 판별표 ⭐⭐⭐

공격	로그에서 보이는 패턴
SQL Injection	' %27 · or 1=1 · union select · substr( ascii( sleep( · -- %23 · 같은 URL에 파라미터만 바꿔 반복
Blind SQLi	응답 크기 차이 · 응답 시간 지연
XSS	<script> %3Cscript%3E · onerror= · alert( · document.cookie
디렉터리 트래버설	../ %2e%2e%2f · %c0%ae · /etc/passwd
파일 업로드·웹쉘	POST /upload 후 .php 접근 (cmd= 파라미터)
스캐너·자동화 도구	User-Agent에 sqlmap nikto nmap · 짧은 시간 다수의 404
무차별 대입	POST /login 동일 계정 다수 반복

성공 판단: 같은 공격 요청 중 응답 크기·상태 코드가 다른 요청 = 참 조건(성공) / 모두 404·동일 = 실패
⚠️ 로그 문제는 ① 공격 유형 이름 ② 성공 근거(코드·크기) ③ 대응 — 3종 세트로 쓴다

 

(로그 해석은 10편 보안관제에서 패킷과 함께 다시 다룹니다.)

---

11. 악성코드·공격 용어 카드 ⭐⭐⭐

용어	한 줄 정의
APT	특정 대상을 장기간 지속적으로 공격 (침투 → 탐색 → 수집 → 유출)
워터링 홀	표적이 자주 방문하는 웹사이트에 악성코드를 심고 감염 대기
스피어 피싱	특정 개인·조직을 겨냥한 맞춤형 이메일·SMS
Drive-by Download	웹 사이트 방문·배너 클릭만으로 취약점을 이용해 악성코드 자동 다운로드·실행
랜섬웨어	파일 암호화 후 금전 요구
크립토재킹	몰래 암호화폐 채굴
웜 / 바이러스	웜 = 독자 전파 / 바이러스 = 숙주 파일 감염
제로데이	패치 배포 전 취약점 공격
크리덴셜 스터핑	유출된 ID·PW 목록을 다른 사이트에 대량 대입
퍼징 (Fuzzing)	다양한 비정상 입력으로 오류·충돌을 일으켜 취약점 탐지
Sandbox	격리된 가상 환경에서 악성 파일 실행·분석

악성코드 분석: 정적 분석(실행 없이 코드·문자열·PE 구조) vs 동적 분석(실행하며 레지스트리·파일·네트워크 변화 관찰)
설명문의 핵심어로 매칭: 표적이 자주 방문 = 워터링 홀 / 방문만으로 감염 = DBD / 특정 대상 + 메일 = 스피어 피싱

---

단답 키워드 표 ⭐⭐⭐

질문	답
URL 클릭 시 응답에 반영되어 실행	반사형 XSS
서버 DB에 저장된 스크립트	저장형 XSS
클라이언트 JS가 DOM 처리 중 발생	DOM 기반 XSS
JS의 쿠키 접근 차단 속성	HttpOnly
HTTPS에서만 쿠키 전송	Secure
CSRF 대응 핵심	CSRF 토큰 (세션 저장 + hidden 전달 + 서버 비교)
SQL Injection 대응 핵심	PreparedStatement (파라미터 바인딩)
원격 명령 실행 업로드 파일	웹쉘
디렉터리 리스팅 차단 옵션	-Indexes
외부 파일 include 차단 php.ini	allow_url_fopen = Off
응답 분할에 쓰는 문자	CR(\r), LF(\n)
취약한 문자열 복사 함수	strcpy, gets
주소 무작위화 / 스택 실행 금지	ASLR / DEP(NX)

---

서술형 답안 구조 ⭐⭐⭐

파일 업로드 취약점 (취약점명 / 우회 기법 / 성공 조건)

취약점명: 검증 미흡 파일 업로드 (MIME/확장자만 검증)
우회: Content-Type 변조(image/jpeg로 위장), 이중 확장자
조건: 웹 접근 가능 경로 + 스크립트 실행 가능 + 경로를 알 수 있음
대응: 확장자 화이트리스트 + 시그니처 검증, 업로드 폴더 실행 권한 제거, 파일명 랜덤화

 

XSS (정의 → 종류 → 대응)

정의: 악성 스크립트를 삽입해 다른 사용자의 브라우저에서 실행시키는 공격
종류: 반사형(URL 클릭 시 응답에 반영) / 저장형(서버에 저장되어 방문자 모두 감염) / DOM 기반
대응: 입력 검증 + 출력 인코딩, HttpOnly, CSP, WAF

 

SQL Injection (정의 → 원리 → 대응)

정의: 입력값에 SQL 구문을 주입해 DB를 조작하는 공격
원리: 입력이 쿼리 문자열에 그대로 결합되어 조건이 항상 참이 되거나 주석 처리됨
대응: PreparedStatement 바인딩, 입력 검증, 에러 비노출, 최소 권한, WAF

---

⚠️ 함정 모음

⚠️ XSS는 클라이언트에서 실행, CSRF는 서버로 요청이 전송 (대상 구분)
⚠️ HttpOnly = 쿠키 탈취 완화 (XSS 자체 차단 아님)
⚠️ 반사형/저장형 구분은 "서버에 저장되는가"
⚠️ 업로드 공격 성공 조건은 3가지 모두 필요 (경로 접근 + 실행 + 경로 인지)
⚠️ 로그의 404/403은 시도 실패, 200이면 성공 가능성
⚠️ 디렉터리 리스팅 차단은 Indexes 제거 (FollowSymLinks는 별개 설정)
⚠️ 단순 출력 이스케이프만으로 SQL Injection은 막지 못함 (바인딩이 핵심)

---

기출 Q&A

Q. (29회 8번) 공격자가 a.php 파일을 게시판에 업로드하고 weevely로 원격 호출한다. 이 파일은?

A. 웹쉘 (Webshell)

 

Q. (28회 9번) JavaScript를 통해 쿠키에 접근할 수 없게 하여, 악성 스크립트를 통한 쿠키 값 접근을 차단하는 것은?

A. HttpOnly

 

Q. (29회 11번) Options Indexes FollowSymLinks Includes ExecCGI 설정에서 디렉터리 리스팅을 방지하려면 제거해야 할 것은?

A. Indexes (또는 -Indexes로 변경)

---

💡 실무에서는?

20년 인프라/보안 SI 경험에서 웹 점검은 소스 리뷰와 모의 진단 둘 다 필요합니다.

 

웹쉘은 업로드 디렉터리에 실행 권한이 있는 환경에서 거의 항상 시작되고, 점검 때는 업로드 경로에서 php·jsp 파일이 실행되는지, 최근 변경된 파일이 있는지 확인합니다.

 

WAF를 두었어도 코드의 취약점이 사라지는 것은 아니기 때문에, 바인딩·출력 인코딩 같은 시큐어 코딩 원칙을 개발 표준에 넣고 SAST/DAST로 주기적으로 점검하는 방식이 가장 현실적이에요.

 

로그 분석은 공격 시도 자체보다 200 응답 중 이상 패턴을 찾는 데 집중합니다.

---

핵심 정리

✅ XSS: 반사형 / 저장형 / DOM 기반 — 대응 입력 검증 + 출력 인코딩 + HttpOnly + CSP
✅ CSRF: 세션 토큰 + hidden 필드 + 서버 비교, SameSite, 재인증
✅ SQL Injection: PreparedStatement 바인딩, 입력 검증, 에러 비노출, 최소 권한
✅ 파일 업로드: 우회(Content-Type 변조·이중 확장자) / 성공 조건 3가지 / 대응 실행 권한 제거
✅ 디렉터리: Options -Indexes, allow_url_fopen = Off
✅ 쿠키: Secure(HTTPS만) · HttpOnly(JS 불가) · SameSite(교차 사이트 제한)
✅ 버퍼 오버플로우: strcpy → strncpy, Canary · ASLR · DEP
✅ 웹 로그: 200 = 성공 가능성, 공격 유형 + 성공 근거 + 대응 3종 세트

 

📌 참고: 2027년 출제기준 개편에서 실기 1-3에 REST API 서비스 보안(OWASP API Security Top 10 등)이 신설됩니다.

이번 11/14 시험은 현행 기준이에요.

 

다음 편에서는 네트워크 장비 보안으로 이어갑니다!

 

궁금한 점은 댓글로 남겨주세요!

 

2026.10.27 - [자격증 정복/정보보안(산업)기사] - 정보보안기사 실기 재도전 01 — 소개·재도전 전략·출제 맵 (46점에서 합격으로)

정보보안기사 실기 재도전 01 — 소개·재도전 전략·출제 맵 (46점에서 합격으로)