[Cloud | DeepDive] ZAP 을 사용한 취약점 분석 및 설명

취약점 분석 도구중에 ZAP이라는 게 있다는 걸 아시렵니까?
저도 최근에 알긴 했는데 생각보다 재밌더라구여
 
그래서 아는 척 좀 하려고 왔습니다
 
쭈고
 

---

 

# OWASP ZAP (Zed Attack Proxy) 이란?

• OWASP(Open Web Application Security Project)에서 개발한 오픈소스 웹 애플리케이션 보안 취약점 스캐너
• 실제로 대상 도메인에 다양한 공격 시도를 해보며 취약점을 분석진행
• 동적분석
• 무료임!! ( $ 0 $ )

 

# 주요 기능

1. 자동화된 취약점 스캔: 클릭 몇 번으로 SQL Injection, XSS, Clickjacking 등의 일반적인 취약점 탐지 가능
   • SQL Injection, XSS, Clickjacking 등 여러 유형의 공격 페이로드를 실제로 요청에 삽입해보고,
     이에 대한 서버의 응답을 분석하여 취약점이 있는지를 판단
2. 프록시 기반 수동 분석: ZAP 프록시를 통해 실시간으로 요청/응답을 분석하고 수정 가능
   • 사용자가 웹 브라우저를 통해 요청을 보내면 ZAP이 이를 중간에서 가로채고 분석
3. 리포트 생성: 스캔 결과를 HTML, XML 등 다양한 형식으로 출력
   • 발견된 취약점의 종류, 위험도(Risk), 신뢰도(Confidence) 등을 정리
   • 이거 되게 좋다고 생각합니다 굳굳.
4. 스파이더링: 크롤링을 통해 숨겨진 엔드포인트까지 탐색
   • 대상 웹사이트의 링크들을 따라가며 가능한 모든 경로와 요청을 탐색
5. 스크립트 확장성: 다양한 확장 기능 및 사용자 정의 스크립트 사용 가능

1.  

 

# 사용 목적

1. 웹 서비스의 보안 점검
2. CI 파이프라인 내 보안 테스트 통합
3. 보안 교육 등
4. 특히 개발 초기 단계에서의 보안 테스트에 효과적

 

# 취약점 분석 

 
이런 식으로 결과지가 주어지는데요. 어떻게 확인하는지 설명을 감히 해보겠습니다.
 

1. Risk (위험도) : 행

등급	설명
High	심각한 수준의 위험, 즉시 대응 필요
Medium	중간 수준의 위험, 조치 권장
Low	낮은 수준의 위험, 참고용
Informational	단순 정보 제공, 보안상 큰 위험은 없음

 
 

2. Confidence (신뢰도) : 열

등급	설명
High	확실한 취약점 (자동 도구로도 명확하게 검증됨)
Medium	어느 정도 신뢰 가능한 취약점, 수동 확인 권장
Low	의심 수준. 오탐 가능성 있음
User Confirmed	사람이 직접 검토 후 확인한 취약점. 신뢰도 매우 높음

 

✔️ Confidence(신뢰도)가 높을수록 실제 취약점일 가능성이 큼.
✔️ Confidence가 낮을수록 오탐(False Positive) 가능성이 높아 검토 필요

 
 
 

---

 

# 취약점 설명

 

취약점	핵심 문제
Content-Security-Policy	XSS 방어: 외부 script 제한
X-Frame-Options	Clickjacking 방지
X-Content-Type-Options	MIME-type 추측 방지
Strict-Transport-Security	HTTPS 강제
Server Header 노출	서버 정보 유출
기타 Info (e.g. Timestamp, Cache Control 등)	정보 노출 예방

 

• ZAP을 통해 필자의 서비스에 대해 보안 스캔을 진행한 결과, 총 5가지 주요 취약점이 탐지 되었습니다. 
  (단순 정보성 항목은 제외)

---

 

1. Content Security Policy (CSP) Header Not Set

항목	내용
위험도	Medium
신뢰도	High
시나리오	공격자가 악성 스크립트를 포함한 링크를 피해자에게 보냅니다. 사용자가 클릭하면 악성 JS가 동작해 세션 탈취(XSS) 가능.
문제	CSP 헤더가 없음, 공격자가 자유롭게 JS 등 외부 리소스 삽입 가능
설명	CSP는 악성 스크립트(XSS 등)의 삽입을 막아주는 보안 정책. 설정되지 않으면 외부 스크립트가 자유롭게 실행될 수 있어 사이트 변조, 정보 탈취 가능성 ↑
해결 방법	HTTP 응답에 다음과 같은 CSP 헤더를 추가:Content-Security-Policy: default-src 'self' 또는 필요에 따라 더 정교한 정책 구성 Lambda@Edge + Cloudfront Functions → 응답 헤더에 CSP 삽입 → 쿠키 탈취 / 로그인 정보 탈취 등 예방 가능

• 신뢰도가 높게 측정된 취약점이었기 때문에, 실제 서비스 운영 시 반드시 짚고 넘어가야 할 중요한 부분이라고 판단했습니다.
• 특히 JWT 토큰을 사용하는 구조에서는 토큰 탈취 시나리오를 항상 염두에 두고, 이를 예방할 수 있는 보안 설정이 필수적이라는 점을 깨달았습니다.
• 토큰이 탈취되면 사용자 정보가 그대로 노출될 수 있고, 보안을 위해 설정한 인증 구조 자체가 무력화될 수 있기 때문입니다.
  • 토큰 사용의 의미가 사라지면 서러우니까....힝구리ㅜ

> CSP; 컨텐츠 보안 정책

웹사이트에 악성 스크립트가 실행되지 못하도록 막아주는 보안 장치

 

왜 필요한가

XSS (Cross-Site Scripting) 공격 가능성 존재
CSP는 이런 XSS 공격을 브라우저 단에서 막는 마지막 방어선

• XSS 예시
  
  • 사용자의 쿠키 탈취
  • 로그인 정보 탈취
  • 사이트 화면 변조

 

작동 방법

웹서버가 응답 헤더에 아래 내용 추가

Content-Security-Policy: default-src 'self';

 

• 'self' = 내 서버의 리소스만 허용 (스크립트, 이미지 등)
• 외부 JS, 이미지 등은 브라우저가 차단함

---

구성 요소 예시

Content-Security-Policy:
  default-src 'self';
  script-src 'self' <https://trusted.cdn.com>;
  img-src *;

 

디렉티브	설명
default-src	기본 허용 도메인
script-src	자바스크립트가 어디서 오는지 허용
img-src	이미지 로딩 허용 도메인

 

CSP 정리 한 줄 요약

“딴 데 말고 내가 지정한 데서만 콘텐츠 불러오라!”는 보안 규칙을 선언

 

설정 위치

• CloudFront: Lambda@Edge / Functions로 응답 헤더 삽입 ✔️
• Nginx/Apache: add_header 설정
• Spring: 필터나 ResponseHeader 설정 ✔️
• API Gateway: 통합 응답에 추가

 

---

 

2. Missing Anti-clickjacking Header

항목	내용
위험도	Medium
신뢰도	Medium
시나리오	공격자가 투명한 <iframe>을 통해 route-33.click 페이지를 자신의 피싱 페이지에 감쌈. 사용자가 '다운로드' 같은 버튼을 클릭하면 실제로는 공격자가 의도한 악성 동작이 실행됨.
문제	iframe 방지를 위한 X-Frame-Options 또는 Content-Security-Policy: frame-ancestors가 없음
설명	공격자가 iframe에 페이지를 넣어 클릭 유도하는 "Clickjacking" 가능성. 특히 결제/로그인 페이지일 경우 치명적
해결 방법	아래 중 하나 이상을 응답 헤더에 추가: 1) X-Frame-Options: DENY 2) Content-Security-Policy: frame-ancestors 'none';

 
> X-Frame-Options란?

웹페이지가 다른 사이트의 <iframe> 안에 끼워지지 않게 막는 보안 설정

• 누가 내 사이트를 iframe에 몰래 띄워서 사용자를 속이고 클릭하게 만들 수 있음
• “나를 다른 사이트에 끼워 넣지 마라!” 하는 설정

 

Clickjacking이란?

사용자가 자신도 모르게 공격자가 원하는 걸 클릭하게 만드는 공격

 

예시 시나리오:

1. 나는 쇼핑몰 관리자다
2. 공격자가 iframe에 내 사이트 관리 페이지를 띄워 놓고,
3. 위에 투명 버튼을 덮어놓았다.
4. 나는 그걸 광고 배너라고 착각하고 클릭 ➡️ 실제로는 “상품 삭제” 클릭됨 

이걸 방지하는 설정이 X-Frame-Options

 

 

 X-Frame-Options 옵션들

옵션	의미	사용 예시
DENY	무조건 iframe 금지	가장 강력함
SAMEORIGIN	같은 도메인일 때만 iframe 허용	내부 관리 페이지 등에서 사용 가능
ALLOW-FROM uri	특정 도메인만 허용 (대부분 브라우저 지원 안 함)	구형 브라우저에서만 쓰임

 

요약

Clickjacking = 유도 클릭 공격
X-Frame-Options = 그걸 막는 보안 헤더

 

---

 

3. Server Leaks Version Information via "Server" Header

항목	내용
위험도	Low
신뢰도	High
시나리오	공격자가 HTTP 응답 헤더에서 서버 종류 및 버전(AmazonS3 등)을 확인 → 해당 버전에 알려진 취약점(CVE) 검색 → 취약점 공격 자동화 도구 실행.
문제	응답 헤더에 Server: AmazonS3 등 서버 정보가 노출됨
설명	서버 종류/버전이 노출되면 공격자가 해당 시스템의 알려진 취약점을 타겟으로 삼기 쉬움
해결 방법	Server 헤더 제거 또는 모호하게 설정 (Server: Secure) S3의 경우 CloudFront로 우회하며 Origin Response 헤더 제거 가능

 
 

4. X-Content-Type-Options Header Missing

항목	내용
위험도	Low
신뢰도	Medium
시나리오	공격자가 JS로 위장한 .txt 파일을 업로드. 브라우저가 MIME 타입을 text/plain이 아닌 JS로 추론하여 실행되며 공격 발생.
문제	X-Content-Type-Options: nosniff 헤더 없음 → 브라우저가 파일 타입을 잘못 판단할 수 있음
설명	일부 브라우저는 응답 콘텐츠 타입을 자동 추측(MIME sniffing)하는데, 이걸 방지하지 않으면 악의적인 파일이 다른 형태로 실행될 수 있음
해결 방법	모든 응답 헤더에 다음 추가:X-Content-Type-Options: nosniff

 
 

---

 

# 취약점 개선 방법

 
취약점 분석 당시 저희 서비스의 구조는 아래와 같습니다. 

프론트엔드 (CloudFront + S3) / 
백엔드 (EC2 + ALB + Spring Boot)

 
 
대부분의 취약점이 헤더를 통해서 해결할 수 있는 방법이 있단 말이죠.
 
그러면 이제 어떻게 하느냐 
 

1. FE

방법	목적
CloudFront Functions	보안 헤더 추가 (CSP, X-Frame, nosniff, HSTS 등)
Lambda@Edge	조건에 따라 다르게 처리할 때

프론트는 정적 파일이라서 S3에서 직접 설정 불가 →

무조건 CloudFront에서 보안 헤더 처리해야 함

 
 

2. BE

방법	목적
Spring Security 설정	대부분의 보안 헤더 설정 가능 (.headers()로 처리)
Spring Filter	Server 헤더 제거 등 커스텀 필요 시
Nginx 사용 시	add_header로 직접 설정 가능 (X-Frame, HSTS 등)

백엔드는 사용자가 직접 API 요청을 보내므로

→ 보안 헤더도 API 응답에 반드시 적용되어야 함!

 
 
이렇게 취약점을 개선하고자 합니다!
 
 
끗.