웹 보안 기초

대부분의 AI 애플리케이션은 결국 웹 애플리케이션입니다 — 사용자는 브라우저나 모바일 앱을 통해 HTTP API를 호출하고, 그 뒤에서 LLM이나 다른 모델이 응답을 생성합니다. 따라서 전통적인 웹 보안 취약점은 AI 애플리케이션에도 동일하게(혹은 더 심각하게) 적용됩니다.

    flowchart LR
    subgraph WEB["전통적 웹 보안 (OWASP Top 10)"]
        A1["Injection\n(SQL/명령 인젝션)"]
        A2["Broken Authentication\n(인증 취약점)"]
        A3["Broken Access Control\n(접근 제어 취약점)"]
        A4["SSRF"]
        A5["Security Misconfiguration"]
        A6["Vulnerable Components"]
        A7["출력 인코딩 미흡\n→ XSS"]
        A8["Rate Limiting 부재"]
    end

    subgraph AI["AI/LLM 애플리케이션 보안"]
        B1["프롬프트 인젝션\n(데이터·명령 혼재)"]
        B2["API 키 유출\n→ 모델 무단 사용"]
        B3["RAG 권한 미검증\n과도한 에이전트 권한"]
        B4["에이전트 도구 호출로\n내부 자원/메타데이터 접근"]
        B5["모델 가중치·학습데이터\n노출"]
        B6["Pickle 역직렬화\n→ 임의 코드 실행"]
        B7["LLM 출력 그대로 렌더링\n→ 코드 실행/XSS"]
        B8["모델 추출, 비용 폭탄\n(DoS)"]
    end

    A1 --> B1
    A2 --> B2
    A3 --> B3
    A4 --> B4
    A5 --> B5
    A6 --> B6
    A7 --> B7
    A8 --> B8

    classDef web fill:#e7f1ff,stroke:#3b82f6,color:#1e3a8a;
    classDef ai fill:#fff3cd,stroke:#d39e00,color:#664d03;
    class A1,A2,A3,A4,A5,A6,A7,A8 web;
    class B1,B2,B3,B4,B5,B6,B7,B8 ai;
  

OWASP Top 10 핵심 항목

OWASP Top 10은 가장 널리 알려진 웹 애플리케이션 보안 위험 목록입니다. AI 보안을 공부하기 전에 반드시 이해해야 할 핵심 항목들을 정리합니다.

1. Injection (인젝션)

사용자 입력이 코드/명령/쿼리의 일부로 해석되어 실행되는 취약점입니다.

• SQL 인젝션: 사용자 입력이 SQL 쿼리에 그대로 삽입되어 데이터베이스 명령으로 실행됨.
• OS 커맨드 인젝션: 사용자 입력이 시스템 셸 명령에 삽입됨.
• 공통 원인: 신뢰할 수 없는 입력과 실행 가능한 명령/쿼리를 명확히 분리하지 않음(파라미터화되지 않은 쿼리).

2. Broken Authentication (인증 취약점)

• 약한 비밀번호 정책, 자격증명 노출, 세션 토큰의 부적절한 관리.
• 다중 인증(MFA) 미적용으로 계정 탈취 위험 증가.
• AI 시스템에서는 API 키가 사실상 “비밀번호” 역할을 함 — 키 유출 시 모델 무단 사용, 데이터 유출로 직결.

3. Broken Access Control (접근 제어 취약점)

• 수평적 권한 상승: 다른 사용자의 데이터에 접근(예: 다른 사용자의 대화 기록 조회).
• 수직적 권한 상승: 일반 사용자가 관리자 기능에 접근.
• RAG 기반 시스템에서는 “이 사용자가 이 문서에 접근 권한이 있는가"를 검색(retrieval) 단계에서 반드시 검증해야 함 — 그렇지 않으면 모델이 권한 없는 문서 내용을 답변에 포함시킬 수 있음.

4. SSRF (Server-Side Request Forgery)

서버가 사용자의 입력을 바탕으로 외부(또는 내부) 리소스에 요청을 보내도록 속이는 공격입니다.

• 예: 이미지 URL을 입력받아 서버가 다운로드하는 기능에서, 공격자가 http://169.254.169.254/... (클라우드 메타데이터 엔드포인트) 같은 내부 주소를 입력하여 자격증명을 탈취.
• 방어: URL 검증, allowlist 기반 도메인 제한, 내부망 접근 차단.

5. Security Misconfiguration (보안 설정 오류)

• 불필요한 기능/포트/계정이 활성화된 상태.
• 디버그 모드가 운영 환경에서 켜져 있어 상세 에러 메시지(스택 트레이스, 내부 경로) 노출.
• 클라우드 스토리지 버킷이 잘못 설정되어 모델 가중치나 학습 데이터셋이 공개됨.

6. Vulnerable and Outdated Components

• 사용 중인 라이브러리/프레임워크의 알려진 취약점(CVE)이 패치되지 않음.
• ML 생태계에서는 pickle 기반 모델 직렬화 포맷처럼, 역직렬화 시 임의 코드 실행이 가능한 구조적 위험을 가진 컴포넌트도 포함됨.

7. Identification and Authentication Failures / Software and Data Integrity Failures

• 소프트웨어 업데이트, 중요 데이터, CI/CD 파이프라인의 무결성을 검증하지 않아 변조된 코드/데이터가 그대로 배포됨.
• AI 맥락에서는 학습 데이터셋이나 사전학습 모델 체크포인트가 신뢰할 수 없는 출처에서 다운로드되어 그대로 사용되는 경우, 데이터 포이즈닝으로 이어질 수 있음.

인증과 인가 (Authentication vs Authorization)

두 개념은 자주 혼동되지만 명확히 구분해야 합니다.

• 인증(Authentication): “당신이 누구인지” 확인하는 과정. (예: 로그인, API 키 검증)
• 인가(Authorization): “당신이 무엇을 할 수 있는지” 결정하는 과정. (예: 이 사용자가 이 리소스에 접근 가능한가)

일반적인 패턴:

• 세션 기반 인증: 서버가 세션을 저장하고 클라이언트에 세션 ID(쿠키)를 발급.
• 토큰 기반 인증(JWT 등): 서버가 상태를 저장하지 않고, 클라이언트가 보낸 토큰 자체에 서명된 정보(클레임)를 검증. API 기반 AI 서비스에서 널리 사용.
• OAuth 2.0 / OpenID Connect: 제3자 서비스에 위임된 인증/인가. LLM 에이전트가 사용자를 대신해 다른 서비스(이메일, 캘린더 등)에 접근할 때 사용되는 표준 패턴.

세션 관리 (Session Management)

• 세션 토큰은 충분히 무작위적이어야 하며, 일정 시간 후 만료되어야 함.
• HTTPS 전용(Secure), HttpOnly, SameSite 속성을 쿠키에 설정하여 XSS/CSRF로부터 보호.
• 대화형 AI 서비스에서는 “대화 세션(conversation session)“과 “인증 세션"을 구분해야 함 — 긴 대화 컨텍스트가 누적되면서 권한 검증이 최초 한 번만 이루어지고 이후 요청에서는 누락되는 설계 실수가 흔함.

API 보안

LLM/AI 서비스의 핵심 인터페이스는 API입니다. API 보안의 기본 원칙:

• 레이트 리미팅(Rate Limiting): 동일 사용자/키의 과도한 요청을 제한 — 비용 폭탄(cost amplification) 공격과 모델 추출 공격을 완화.
• 입력 스키마 검증: 요청 본문의 형식, 크기, 타입을 엄격히 검증. 과도하게 긴 입력은 그 자체로 비용 및 컨텍스트 윈도우 남용 공격이 될 수 있음.
• 출력 인코딩: API 응답이 그대로 HTML에 렌더링될 경우 XSS로 이어질 수 있음 — LLM이 생성한 텍스트에 악성 스크립트가 포함되어 있다면 이를 그대로 프론트엔드에 렌더링하면 안 됨.
• 버전 관리와 폐기(Deprecation): 오래된 API 버전이 방치되어 보안 패치가 적용되지 않은 채 남아있는 경우가 많음.

AI/LLM 애플리케이션과의 연결

웹 보안의 핵심 개념들은 LLM 애플리케이션 보안에서 새로운 이름으로 다시 등장합니다.