03 애플리케이션 보안 요약집

범위 체크: HTTP/HTTPS · 주입/XSS/CSRF/SSRF/XXE/역직렬화 · 인증/세션/인가 · 업로드/경로조작 · DB 접근통제/암호화/감사 · 메일/FTP/DNS 응용 · 전자서명/전자상거래 · 보안 SDLC/SAST/DAST/공급망 · 모바일/IoT

1. 한눈에 흐름

사용자 입력 │ ├─ SQL 문맥 → SQLi → Prepared statement ├─ 셸 문맥 → 명령주입 → 허용목록·셸 미사용 ├─ HTML/JS → XSS → 문맥별 출력 인코딩·CSP ├─ XML 문맥 → XXE → 외부엔터티/DTD 비활성 └─ 객체 ID → BOLA → 요청마다 서버 인가 검사 별축: 세션·쿠키(고정/탈취/CSRF) · 업로드 · 메일 인증(SPF…)

원리: 공격은 “데이터를 코드처럼 해석하게 만드는 것”. 방어는 “데이터가 코드가 되지 않게 경계를 나누는 것”. 필터로 따옴표만 지우는 식은 문맥을 다 못 막는다.

2. HTTP와 웹 보안의 바닥

축	핵심	보안 포인트
메서드	GET 조회, POST 처리, PUT/PATCH 변경, DELETE 삭제	메서드 이름이 권한을 보장하지 않음. 서버 인가 필수
상태코드	2xx 성공, 3xx 이동, 4xx 요청 오류, 5xx 서버 오류	상세 오류·스택·SQL 노출 금지
HTTPS	HTTP를 TLS 채널로 보호	전송 기밀성이지 입력 검증·인가의 대체가 아님
헤더	CSP, HSTS, frame-ancestors/X-Frame-Options 등	브라우저 공격의 보조 방어, 앱 결함 자체 수정도 필요
CORS	브라우저가 다른 출처 응답을 읽는 정책	서버 인증·인가가 아니며 무분별한 origin 허용 금지

HTTP는 기본적으로 상태를 기억하지 않으므로 쿠키·세션·토큰으로 연속성을 만듭니다. 캐시·프록시·로그에 인증정보나 민감한 URL 파라미터가 남지 않도록 설계합니다.

3. 주입 계열 — 문맥이 전부

SQLi

입력이 쿼리 구조에 섞입니다. 1순위 방어는 Prepared statement(바인딩) — 값은 값으로만. DB 계정 최소권한은 피해 축소.

주문서 양식에 “메뉴 이름” 칸에 영수증 전체를 다시 쓰게 두는 것과 같다. 칸(구조)과 내용(데이터)을 분리해야 한다.

명령 주입

ping ${host}처럼 셸에 외부 입력을 붙이면 ;·치환으로 추가 명령이 됩니다. 허용 목록과 셸 미사용이 핵심.

XXE

XML 파서가 외부 엔터티를 따라가 파일·내부망에 접근. Base64는 인코딩일 뿐 파서 위험을 없애지 않습니다.

LDAP/템플릿/역직렬화

LDAP·템플릿·표현식도 입력이 문법 구조에 섞이면 주입입니다. 신뢰하지 않는 직렬화 데이터를 객체로 되살리면 gadget chain이 실행될 수 있으므로 안전한 형식·타입 허용목록·서명 검증을 사용합니다.

원리: 출력 인코딩은 주로 XSS(브라우저 문맥) 방어. SQLi·코드 주입을 “인코딩만으로 해결”이라 하면 틀린 말인 경우가 많다.

4. XSS · CSRF · 쿠키 — 브라우저 쪽

공격	한 줄	방어 축
XSS	페이지에 스크립트 주입 → 피해자 브라우저에서 실행	출력 문맥별 인코딩, CSP, HttpOnly(쿠키 탈취 완화)
CSRF	로그인된 브라우저의 쿠키가 자동으로 실려 위조 요청	CSRF 토큰, SameSite, 중요 작업 재인증
Clickjacking	투명 프레임으로 사용자의 클릭을 다른 버튼에 전달	CSP frame-ancestors, X-Frame-Options

쿠키 속성도 목적이 다릅니다.

HttpOnly — JS가 쿠키를 못 읽게 (XSS 탈취 완화). CSRF를 없애진 않음.
Secure — HTTPS로만 전송.
SameSite — 교차 사이트에 쿠키를 실을지 제한 (CSRF 보조).

원리: XSS 방어만으로 CSRF가 사라지지 않는다. 공격 경로가 다르다(스크립트 실행 vs 위조 요청에 쿠키 동반).

5. 인증 · 세션 · 인가

세션 고정: 공격자가 미리 심은 세션 ID로 로그인하게 유도. → 로그인 성공 직후 세션 ID 재발급.

URL에 세션 ID를 넣으면 로그·Referer로 새기 쉽습니다. 로그아웃 시 서버 세션도 폐기.

BOLA/IDOR: JWT·로그인이 유효해도 /orders/482의 소유권을 서버가 매 요청 검사해야 합니다. UI 버튼 숨김·UUID만으로는 부족.

JWT는 서명 알고리즘·키·iss/aud/exp를 검증하고, 탈취 대응을 위해 짧은 수명·회전·폐기 전략을 둡니다. MFA는 비밀번호 탈취를 완화하지만 서버의 인가 결함을 고치지는 않습니다.

원리: 인증(누구인가) ≠ 인가(이 객체에 권한이 있는가).

6. 업로드 · 경로 · 서버 측 요청

확장자만 믿으면 위장됩니다. MIME·매직값·실제 디코딩, 웹 루트 밖 저장, 서버 생성 이름, 업로드 경로 실행 금지를 함께.

경로 순회: ../../ 등으로 기준 디렉터리 밖 파일 접근. 정규화 후 허용된 루트 안인지 검사하고 파일 ID 매핑을 사용합니다.
SSRF: 서버가 사용자 URL로 내부망·클라우드 메타데이터에 요청. 목적지 허용목록, DNS/IP 재검증, 내부 대역·리디렉션 차단, egress 제한.
오픈 리다이렉트: 신뢰 도메인처럼 보인 뒤 외부 피싱으로 이동. 상대 경로나 목적지 허용목록을 씁니다.

7. 메일 · FTP · 인증 응용

흐름: MUA(클라이언트) → SMTP 제출 → MTA 전달 → MDA 사서함 배달. POP/IMAP은 사서함에서 가져오는 쪽.

SPF/DKIM/DMARC = 발신 도메인 인증. SPF fail만으로 본문 악성을 단정하진 않고, 포워딩·DMARC 정책을 함께 봅니다.

FTP는 제어 21/TCP와 별도 데이터 연결을 사용합니다. Active는 서버가 클라이언트 쪽으로, Passive는 클라이언트가 서버의 협상 포트로 데이터 연결을 엽니다. FTP 자체는 평문이므로 FTPS(TLS)와 SFTP(SSH)를 구분합니다.

PAM = 인증 모듈 스택. required 실패는 최종 실패로 이어지고, sufficient는 성공 시 단축될 수 있음. 서비스마다 include하는 파일이 다르면 정책이 어긋납니다.

비밀번호 저장: 빠른 SHA만 쓰지 말고 salt + 느린 KDF(bcrypt/scrypt/Argon2 등).

8. 데이터베이스 · 전자상거래

영역	핵심 통제	함정
DB 접근	업무별 계정, 역할/뷰, 최소권한, 관리자 분리	앱 계정에 DBA 권한 부여
암호화	전송·저장·컬럼/파일 보호, 키 분리·회전	TDE가 권한 있는 앱의 오용까지 막지는 않음
감사	로그인·조회/변경·권한/스키마 변경 기록	DB와 같은 계정·장소에 로그만 보관
추론/집계	작은 집합 제한, 마스킹·비식별, 쿼리 통제	개별 행을 숨기면 어떤 집계도 안전하다고 가정

전자상거래는 전송 암호만이 아니라 거래 당사자 인증, 주문·결제 데이터 무결성, 전자서명·인증서, 키 관리, 부인방지, 결제정보 최소화를 함께 봅니다. 전자봉투는 대용량 데이터는 대칭키로, 그 세션키는 수신자 공개키로 보호하는 하이브리드 구조입니다.

9. 보안 개발 생명주기

요구사항(보안·개인정보) → 설계(위협모델·신뢰경계) → 구현(시큐어코딩·비밀정보 분리) → 검증(코드리뷰·SAST·DAST·의존성/퍼징) → 배포(서명·최소권한·구성) → 운영(로그·취약점/패치·사고 피드백)

기법	강점	한계
SAST	실행 전 소스/바이너리 경로 분석	실제 배포 구성·런타임 문맥 한계
DAST	실행 중 외부 관점의 취약 동작 확인	코드 내부 경로·원인 파악 한계
SCA	오픈소스 의존성·라이선스·CVE 식별	실제 도달 가능성과 별도 검증 필요
코드리뷰/위협모델	업무 인가·설계 결함 탐색	숙련도와 범위에 좌우됨

소스코드에 키·토큰을 상수로 넣지 말고 비밀 저장소와 짧은 수명 자격증명을 사용합니다. CI/CD 권한, 빌드 산출물 서명, SBOM·의존성 고정은 공급망 통제입니다.

10. 모바일 · IoT

모바일: 민감정보를 로그·클립보드·평문 로컬 저장소에 두지 않고, 플랫폼 키 저장소·화면 캡처·권한·딥링크·WebView를 점검합니다. 인증서 pinning은 보조 통제이며 갱신·우회 대응이 필요합니다.
IoT: 기본 비밀번호 제거, 기기별 자격증명, 서명된 안전한 업데이트와 롤백 방지, 디버그 포트 통제, 최소 서비스, 수명 종료 정책이 핵심입니다.
API: 객체·기능별 인가, 요청 크기/비율 제한, 스키마 검증, 재전송 방지, 민감 응답 최소화를 적용합니다.

11. 헷갈림 짝

A	B	차이
SQLi	XSS	DB 문맥 vs 브라우저 문맥
필터링	바인딩	문자 제거 vs 구조/데이터 분리
XSS 방어	CSRF 방어	출력 인코딩 vs 요청 위조 방지
HttpOnly	SameSite	JS 접근 제한 vs 교차사이트 쿠키
인증	인가(BOLA)	로그인 유효 vs 객체 권한
SMTP	IMAP/POP	전송 vs 사서함 접근
SSRF	CSRF	서버가 목적지에 요청 vs 피해자 브라우저가 위조 요청
SAST	DAST	정적 코드 관점 vs 실행 중 외부 관점
FTPS	SFTP	FTP+TLS vs SSH 파일전송

12. 자가 체크

펼쳐서 답 확인

SQLi 1순위 방어는? → Prepared statement.
따옴표 제거만으로 충분한가? → 아니오.
로그인 직후 세션 ID를 바꾸는 이유는? → 세션 고정 방지.
유효 JWT만으로 주문 조회가 안전한가? → 아니오. 객체별 인가 필요.
XXE 핵심 완화는? → 외부 엔터티/DTD 비활성.
비밀번호에 SHA-256만 약한 이유는? → 너무 빨라 오프라인 대입 비용이 낮음 → KDF+salt.
SSRF의 대표 내부 목적지는? → 클라우드 메타데이터·관리 API·내부 서비스.
TDE만으로 DBA·앱 오용까지 막나? → 아니오. 접근통제·감사가 별도 필요.
SAST와 DAST를 함께 쓰는 이유는? → 정적 코드 경로와 실행 환경의 서로 다른 사각지대를 보완.