할로윈 특가사탕 안 주면, 영상을 고친다!세 플랜 모두 인하. 영구 라이선스 $30 할인11월 2일 23:59(태평양 시간)까지

요금 보기

데스크톱 앱이 내부망 스캐너가 되지 않게: AI 에이전트를 위한 SSRF 방어

AI가 데스크톱 앱에 공유기 주소를 링크로 넘길 수 있습니다. KwaFlux가 브라우저처럼 호스트를 해석하고 DNS를 다시 확인하는 방법과 방어의 한계를 설명합니다.

핵심 요약

  • AI 어시스턴트가 데스크톱 앱에 링크를 가져오라고 요청할 수 있다면, 오염된 지시 하나로 영상 대신 공유기, 로컬 서비스, 클라우드 메타데이터 주소를 가리키게 만들 수 있습니다.
  • 같은 주소도 여러 가지로 쓸 수 있습니다. 127.1, 2130706433, 0x7f000001, [::ffff:127.0.0.1]은 모두 이 컴퓨터로 연결됩니다. KwaFlux는 브라우저와 같은 방식으로 호스트 이름을 해석하므로, 어떤 표기든 실제 주소로 바꾼 뒤 검사합니다.
  • 다운로드를 진행하기 직전에는 호스트 이름도 조회해, 그 이름이 이 컴퓨터나 사설 네트워크를 가리키면 거부합니다. 프록시 도구가 fake-IP 모드에 쓰는 주소 대역은 막지 않습니다.
  • 다운로드 중의 리디렉션과 DNS 리바인딩은 아직 막지 못합니다. 이 점을 숨기지 않고 밝히며, 개발 로드맵에 올라 있습니다.

AI 어시스턴트가 KwaFlux에 링크 다운로드를 요청하면, 실제로 연결하는 것은 KwaFlux의 다운로드 엔진입니다. 이 엔진은 사용자의 컴퓨터, 즉 사용자의 네트워크 안에서 돌아갑니다. 링크가 영상 페이지가 아니라 http://192.168.1.1/을 가리킨다면, 허술한 앱은 어시스턴트를 대신해 아무렇지 않게 공유기에 접속해 버립니다.

KwaFlux는 어시스턴트가 제출한 링크가 이 컴퓨터와 사설 네트워크에 닿지 못하게 막습니다. 어떻게 막는지, 그리고 그 방어가 어디까지인지 정리했습니다.

이 글에서는 데스크톱 앱에서 SSRF가 무엇을 뜻하는지, 차단 목록이 주소의 다른 표기법 앞에서 무너지는 이유, KwaFlux가 적힌 호스트와 조회된 호스트를 모두 검사하는 방식, 그리고 아직 남아 있는 과제를 알아봅니다.

목차

  1. SSRF란?
  2. AI가 조작하는 데스크톱 앱이 노출되는 이유
  3. 주소는 하나, 표기는 여러 가지
  4. 계층 1: 브라우저처럼 호스트 해석하기
  5. 계층 2: 이름이 가리키는 곳 확인하기
  6. fake-IP 예외
  7. 방어가 닿지 않는 곳
  8. 자주 묻는 질문

SSRF란?

서버 측 요청 위조(SSRF)는 공격자가 프로그램을 이용해 자신이 고른 목적지로 요청을 보내게 만드는 공격입니다. 목적지는 대개 같은 컴퓨터의 서비스나 내부 네트워크처럼 공격자가 직접 닿을 수 없는 곳입니다.

이름은 웹 서버에서 왔지만, 다른 사람을 대신해 URL을 가져오는 프로그램이라면 어디든 같은 패턴이 적용됩니다. MCP 보안 가이드는 흔한 표적으로 http://192.168.1.1/admin 같은 내부 IP, http://169.254.169.254/의 클라우드 메타데이터 엔드포인트, http://localhost:6379/ 같은 localhost 서비스를 꼽습니다.

AI가 조작하는 데스크톱 앱이 노출되는 이유

세 가지 조건이 겹칩니다.

  1. 앱이 URL을 가져옵니다. KwaFlux의 파일 다운로드 기능은 주어진 링크라면 어디든 연결합니다.
  2. 앱이 사용자의 네트워크 안에 있습니다. 사용자의 컴퓨터에서 보면 192.168.x.x는 공유기, NAS, 프린터이고, 127.0.0.1은 로컬에서 돌리는 모든 서비스입니다.
  3. 링크가 모델이 읽은 텍스트에서 올 수 있습니다. 영상 설명이나 웹 페이지가 어시스턴트에게 "이 링크부터 확인하라"고 시킬 수 있습니다. 이런 일이 어떻게 일어나는지는 웹 영상 제목 속 프롬프트 인젝션을 참고하세요.

내부 주소를 가져온 다운로드 엔진이 응답을 누구에게도 보여 주지 않을 수도 있습니다. 하지만 오류 메시지 하나만으로도 그 주소에 기기가 있는지 공격자가 알아낼 수 있습니다. 데스크톱 앱이 내부망 스캐너로 바뀐다는 말은 바로 이런 뜻입니다.

주소는 하나, 표기는 여러 가지

127.0.0.1과 localhost를 문자열 비교로 막는 것만으로는 부족합니다. URL 파서는 같은 주소를 다른 여러 방식으로 쓴 것도 받아들입니다. Node.js 20의 WHATWG URL 파서가 몇 가지 표기를 어떻게 해석하는지 보겠습니다.

링크에 적힌 값해석된 호스트
http://127.0.0.1/127.0.0.1
http://127.1/127.0.0.1
http://2130706433/127.0.0.1
http://0x7f000001/127.0.0.1
http://0x7f.0.0.1/127.0.0.1
http://0177.0.0.1/127.0.0.1
http://017700000001/127.0.0.1
http://127.0.0.1./127.0.0.1
http://[0:0:0:0:0:0:0:1]/[::1]
http://[::ffff:127.0.0.1]/[::ffff:7f00:1]
http://10.1/10.0.0.1
http://0xa9fea9fe/169.254.169.254

마지막 두 줄을 뺀 나머지는 모두 이 컴퓨터로 연결됩니다. 10.0.0.1은 사설 주소이고, 169.254.169.254는 클라우드 플랫폼이 인스턴스 메타데이터에 쓰는 링크 로컬 주소입니다.

이유는 WHATWG URL 표준에 나와 있습니다. 0x로 시작하는 부분은 16진수로, 0으로 시작하는 부분은 8진수로 읽고, 네 부분보다 적은 주소는 마지막 부분이 남은 바이트를 채웁니다. OWASP의 SSRF 방어 가이드도 같은 "Hex, Octal, Dword" 인코딩을 경고하며, MCP 보안 가이드는 이렇게 덧붙입니다. "IP 검증을 직접 구현하지 마라. 공격자는 직접 만든 파서가 놓치기 쉬운 인코딩 수법(8진수, 16진수, IPv4 매핑 IPv6)을 악용한다."

계층 1: 브라우저처럼 호스트 해석하기

KwaFlux는 문자열을 비교하지 않습니다. 브라우저와 같은 규칙으로 호스트를 해석한 뒤 그 결과를 검사합니다.

  • WHATWG 호스트 파싱으로 축약형, 8진수와 16진수 부분, 숫자 하나로 쓴 주소, 끝에 붙은 점을 검사 전에 실제 주소로 바꿉니다.
  • IPv6는 16바이트 전체를 검사합니다. 그래서 [::ffff:7f00:1] 같은 IPv4 매핑 형식도 낯선 IPv6 주소로 넘기지 않고 루프백으로 잡아냅니다.
  • **%가 들어간 호스트는 거부합니다.** IPv6 영역 ID(zone ID)와 호스트에 퍼센트 인코딩을 쓰는 수법을 이것으로 차단합니다.
  • 루프백, 사설, 링크 로컬 주소는 거부합니다. 127.0.0.0/8, ::1, 10.0.0.0/8, 192.168.0.0/16, 169.254.0.0/16 등이 여기에 해당합니다.

사용자가 입력한 텍스트가 아니라 "메서드나 라이브러리가 출력한 값을 IP 주소로 사용하라"는 OWASP의 권고를 따른 것입니다.

계층 2: 이름이 가리키는 곳 확인하기

호스트 이름은 겉보기에 멀쩡해도 사용자의 네트워크 안을 가리킬 수 있습니다. router.example.net의 DNS 레코드가 192.168.1.1일 수도 있습니다.

그래서 로그인한 상태의 다운로드가 대기열에 들어가기 직전, KwaFlux는 호스트 이름도 조회합니다. 제한 시간은 2초입니다. 이름이 이 컴퓨터나 사설 네트워크로 조회되면 다운로드를 거부합니다.

DNS 레코드가 127.0.0.1이나 사설 주소를 가리키는 공개 호스트 이름은 이 검사에서 걸러집니다.

fake-IP 예외

일부 프록시 도구는 "fake-IP" 모드로 동작합니다. 모든 DNS 조회에 198.18.0.0/15 대역의 주소로 답하고, 실제 연결은 직접 중계하는 방식입니다. IANA 레지스트리는 이 대역을 사설이나 루프백 대역이 아니라 "Benchmarking"(RFC 2544)으로 분류합니다.

KwaFlux가 이 대역을 내부 주소로 취급하면, 이런 프록시를 쓰는 컴퓨터에서는 다운로드가 전부 실패합니다. 그래서 조회된 주소를 검사할 때 이 대역은 제외합니다.

방어가 닿지 않는 곳

SSRF 방어는 실제보다 부풀려 말하기 쉬우므로 여기서는 정확하게 적겠습니다.

  • 검사하는 것: 어시스턴트가 제출한 링크입니다. 적힌 그대로의 호스트와, 그 이름이 조회되는 주소를 모두 검사합니다.
  • 아직 검사하지 못하는 것: 다운로드 도중에 일어나는 일입니다. 링크가 검사할 때는 공개 주소로 조회되다가 잠시 뒤에는 사설 주소로 조회될 수 있고(DNS 리바인딩), 공개 페이지가 내부 주소로 리디렉션할 수도 있습니다. MCP 보안 가이드는 앞의 경우를 검사 시점과 사용 시점의 차이(TOCTOU) 문제라고 부르고, OWASP는 "검증과 연결 사이에 검사받지 않은 두 번째 DNS 조회가 일어나면 이러한 검사를 우회할 수 있다"고 지적합니다.

근본적인 해결책은 다운로드 엔진의 연결을, 리디렉션 하나하나를 포함한 모든 연결을 맺는 순간에 검사하는 구성 요소를 거치게 하는 것입니다. 이 작업은 로드맵에 올라 있습니다. 아직 하지 못한 이유는 세 개의 코드베이스에서 다운로드 엔진이 네트워크에 연결하는 방식을 바꿔야 하고, 사용자가 직접 시작한 다운로드까지 모든 다운로드에 영향을 주기 때문입니다. 그래서 별도의 릴리스와 테스트가 필요합니다.

따라서 정확한 표현은 이렇습니다. KwaFlux는 AI 어시스턴트가 이 컴퓨터와 사설 네트워크의 주소로 KwaFlux를 보내지 못하게 막습니다. 어떤 연결도 끝내 그곳에 닿지 않는다고 약속하지는 않으며, "공용 인터넷에만 접속한다"고 설명하지도 않습니다.

그동안에는 다른 두 가지 제한이 도움이 됩니다. 에이전트 다운로드는 기본값이 꺼짐이고, 매번 확인 모드에서는 무엇이든 가져오기 전에 사용자가 링크를 먼저 보게 됩니다. AI가 다운로드를 대신 승인할 수 없는 이유를 참고하세요.

마치며

표기가 아니라 주소를 검사하세요. 브라우저처럼 호스트를 해석하고, 다운로드를 진행하기 전에 이름이 가리키는 곳을 확인하고, 프록시의 fake-IP 대역은 건드리지 말고, 아직 남은 과제는 분명히 밝히세요. KwaFlux는 이렇게 해서 어시스턴트의 링크가 KwaFlux를 사용자 네트워크의 스캐너로 바꾸지 못하게 합니다.

어시스턴트가 가져와도 되는 것만 가져오게 하세요

KwaFlux의 로컬 MCP 서버를 쓰면 Codex, Claude, Cursor 등 MCP 앱이 내 파일을 다룰 수 있고, 어시스턴트가 제출하는 링크는 하나하나 검사합니다. AI 처리는 사용자 GPU에서 실행되며 미디어 파일이 처리를 위해 업로드되지 않습니다. Windows 10(64비트, 버전 1809 이상), Windows 11, Apple Silicon 탑재 macOS 12 이상에서 실행됩니다. 파일 가져오기와 앱 둘러보기에는 계정이 필요 없습니다. 내보내기, 변환, 파일 복구, 링크에서 파일 다운로드에만 로그인과 유료 플랜이 필요합니다.

KwaFlux 받기 · 플랜 보기

내 실제 영상으로 효과를 확인하세요

KwaFlux를 받고 결제 전에 내 영상으로 효과를 무료로 미리 보세요. 계정이 필요 없고, 내 GPU에서 처리하며 처리를 위해 미디어를 업로드하지 않습니다. 영상 미리보기는 1, 3 또는 5초, 흔들림 보정 미리보기는 5, 15 또는 30초 중에서 고를 수 있습니다.

자주 묻는 질문

SSRF를 쉽게 설명하면 무엇인가요?

프로그램을 속여, 내가 직접은 닿을 수 없는 곳에 대신 요청을 보내게 만드는 것입니다. 공유기 관리자 페이지나 같은 컴퓨터의 서비스가 그런 곳입니다. 다른 사람을 대신해 링크를 가져오는 프로그램이라면 무엇이든 이렇게 악용될 수 있습니다.

127.1이 127.0.0.1과 같은 이유는 무엇인가요?

WHATWG 표준을 따르는 URL 파서는 IPv4 주소가 네 부분보다 적어도 받아들이고, 마지막 부분이 남은 바이트를 채우게 하기 때문입니다. 127.1은 127.0.0.1이 됩니다. 16진수와 8진수 부분도 받아들입니다.

사설 IP 주소를 막으면 DNS 리바인딩도 막을 수 있나요?

아니요. 리바인딩은 검사와 연결 사이에 이름이 가리키는 주소를 바꿉니다. 이를 막으려면 연결하는 시점에 검사해야 합니다. 조회된 주소를 고정하거나, 연결마다 검사하는 이그레스 프록시를 거치게 하는 방법이 있습니다.

198.18.0.0/15 대역은 어디에 쓰이나요?

RFC 2544에 따라 네트워크 벤치마킹용으로 예약된 대역입니다. 일부 프록시 도구는 이 대역의 주소로 DNS 조회에 답하는 fake-IP 모드에도 씁니다. 사설 대역이나 루프백 대역은 아닙니다.

데스크톱 앱도 SSRF를 신경 써야 하나요?

네, 다른 사람이 영향을 줄 수 있는 URL을 가져온다면 그렇습니다. 데스크톱 앱은 집이나 사무실 네트워크 안에 있으므로, 내부 주소를 가져오면 웹사이트로는 닿을 수 없는 기기에까지 닿을 수 있습니다. 로컬 AI 채널을 안전하게 지키는 방법을 참고하세요.

참고 자료

  1. OWASP, SSRF prevention guide (encodings; DNS rebinding; redirects) (2026-10-25 확인)
  2. WHATWG, "URL Standard" (IPv4 parser; IPv4 number parser; ends-in-a-number checker) (2026-10-25 확인)
  3. IANA, "IPv4 Special-Purpose Address Registry" (198.18.0.0/15 Benchmarking, RFC 2544; 127.0.0.0/8; 169.254.0.0/16; last updated 2025-10-09) (2026-10-25 확인)
  4. Model Context Protocol, security guidance for implementers (2026-07-28; Server-Side Request Forgery) (2026-10-25 확인)
  • 신뢰
  • MCP

KwaFlux 작성자 겸 편집자. 글은 KwaFlux 편집팀이 검토하며, 제품 조사 노트와 공개된 사양을 바탕으로 합니다.