웹 애플리케이션 공격
요약
웹 요청과 세션을 악용하는 주요 웹 애플리케이션 공격을 정리합니다. SQL Injection, XSS, CSRF, 파일 업로드 취약점의 원리와 Prepared Statement, CSP, CSRF 토큰, SameSite 쿠키, WAF 같은 대응책까지 정보처리기사 실기 대비용으로 살펴봅니다.
웹 애플리케이션 공격이란?
웹 애플리케이션 공격은 HTTP 요청·응답·세션·쿠키 등 웹 특유의 구조를 악용한 공격입니다. 방화벽·IDS가 네트워크 계층을 방어하더라도, 웹 서비스는 80/443 포트를 개방해야 하므로 애플리케이션 계층에서 별도의 방어가 필요합니다.
대표적인 분류 기준은 OWASP Top 10이며, 국내 시험에서는 다음 4종이 반복적으로 등장합니다.
| 공격 | 공격 대상 | 원리 한 줄 요약 | 핵심 대응 |
|---|---|---|---|
| SQL Injection (SQLi) | DB 질의 | 입력에 SQL 구문을 섞어 원래 질의를 조작 | Prepared Statement |
| XSS (Cross-Site Scripting) | 다른 사용자의 브라우저 | 웹페이지에 악성 스크립트를 심어 피해자 브라우저에서 실행 | HTML 이스케이프, CSP |
| CSRF (Cross-Site Request Forgery) | 피해자의 인증 세션 | 피해자의 브라우저가 공격자 의도대로 정상처럼 보이는 요청을 보내게 함 | CSRF 토큰, SameSite 쿠키 |
| 파일 업로드 취약점 | 서버 파일시스템 | 확장자·MIME 검증 우회로 웹쉘 업로드 → 서버 장악 | 확장자 화이트리스트, 실행 권한 분리 |
입력 경로에
../를 끼워 웹 루트 밖 파일을 읽는 디렉터리 트래버설(Directory Traversal / Path Traversal) 도 OWASP Top 10에 자주 거론되지만, 본질적으로 소프트웨어 개발 보안의 경로 조작과 같은 취약점이라 그쪽 페이지에서 한 번에 정리합니다.
SQL Injection
SQL Injection(SQL 삽입) 은 사용자 입력을 SQL 질의문에 그대로 끼워 넣을 때, 공격자가 입력에 SQL 구문을 섞어 원래 질의의 의미를 바꿔버리는 공격입니다. 인증 우회·DB 전체 유출·테이블 삭제까지 가능해 가장 위협적인 웹 공격으로 꼽힙니다.
위험한 질의 구조
공격자가 user_id 자리에 admin' --을 입력하면:
SQL에서 --는 주석 시작 기호이므로 그 뒤의 AND pw = '아무거나' 부분이 통째로 주석 처리되어 사라집니다. 결국 DB가 실제로 실행하는 질의는 다음과 같습니다.
비밀번호 조건이 없어졌으니 users 테이블에서 id가 admin인 행이 그대로 반환되고, 애플리케이션은 "admin 계정이 인증됐다"고 판단해 비밀번호 없이 admin 계정으로 로그인을 통과시킵니다.
XSS
XSS1(Cross-Site Scripting, 크로스 사이트 스크립팅) 는 공격자가 웹페이지에 악성 자바스크립트를 삽입하여, 그 페이지를 방문한 다른 사용자의 브라우저에서 스크립트가 실행되도록 하는 공격입니다. 피해자의 쿠키·세션 토큰을 탈취하거나, 피해자 계정으로 임의 요청을 수행할 수 있습니다.
유형
| 유형 | 저장 위치 | 트리거 |
|---|---|---|
| Reflected XSS (반사형) | 저장되지 않음 | URL 파라미터에 악성 스크립트 → 피해자가 그 링크를 클릭하면 실행 |
| Stored XSS (저장형) | 서버 DB | 게시판·댓글에 스크립트 저장 → 방문자가 볼 때마다 실행 |
| DOM-based XSS | 없음 (클라이언트 전용) | 서버를 거치지 않고 클라이언트 스크립트가 innerHTML 등으로 직접 DOM에 삽입 |
XSS 공격 예
방문자가 게시글을 열 때마다 이 스크립트가 실행되어 세션 쿠키가 공격자 서버로 전송됩니다.
CSRF
CSRF(Cross-Site Request Forgery, 크로스 사이트 요청 위조) 는 로그인된 피해자의 브라우저가 피해자 의도와 무관하게 특정 요청(송금·글쓰기·설정 변경 등)을 보내도록 유도하는 공격입니다. 피해자가 이미 해당 사이트에 로그인한 상태에서 공격자 사이트를 방문하면, 브라우저가 자동으로 세션 쿠키를 첨부해 요청을 보내기 때문에 서버는 정상 사용자의 요청으로 오인합니다.
공격 시나리오
- 피해자가
bank.com에 로그인 → 브라우저에 "피해자로 로그인된 상태"라는 신분증 역할의 세션 쿠키가 저장됨 (세션 ID·인증 토큰 등이 담김) - 피해자가 공격자의 페이지
evil.com방문 evil.com에 숨겨진 이미지 태그:<img src="https://bank.com/transfer?to=attacker&amount=1000000" />- 피해자 브라우저는 이 URL을 요청하면서 목적지(
bank.com)에 해당하는 쿠키를 자동 첨부 — 요청이evil.com에서 시작됐든 말든 상관없음 bank.com은 쿠키 속 신분증을 보고 "피해자 본인이 보낸 송금 요청"으로 오인해 공격자에게 100만 원을 송금
즉 공격자는 비밀번호를 모르더라도, 피해자의 브라우저가 들고 있던 로그인 신분증(세션 쿠키)을 그대로 빌려 쓰는 셈입니다.
XSS와의 차이
| 구분 | XSS | CSRF |
|---|---|---|
| 실행 위치 | 피해자 브라우저에서 스크립트 실행 | 스크립트 필요 없음. 요청을 보내기만 함 |
| 공격 대상 | 피해자의 데이터 (쿠키·세션 탈취) | 피해자의 권한 행사 (송금·변경) |
| 필요 조건 | 취약 페이지가 스크립트를 실행함 | 피해자가 사이트에 로그인된 상태 |
파일 업로드 취약점
파일 업로드 취약점(Unrestricted File Upload) 은 서버가 업로드된 파일의 종류를 제대로 검증하지 않아, 공격자가 실행 가능한 파일(웹쉘) 을 올리고 웹에서 직접 호출해 서버를 장악하는 공격입니다.
공격 흐름
- 공격자가
shell.php·shell.jsp같은 웹쉘을 업로드 - 서버가
/uploads/shell.php로 저장 - 공격자가
https://site.com/uploads/shell.php?cmd=whoami호출 - 서버가 PHP/JSP로 해석·실행 → 공격자 명령 수행, 서버 쉘 획득
업로드 우회 기법
- 확장자 대소문자 -
.php금지 →.PHP·.pHp시도 - 이중 확장자 -
.jpg.php - MIME 조작 - 요청 헤더의
Content-Type만image/jpeg로 변경 - 파일 시그니처 - 파일 시작에 JPEG 매직 바이트를 심어 "이미지로 보이지만 실제는 PHP"
공통 대응
웹 공격 전반에 공통으로 적용되는 방어 계층을 정리합니다.
| 대응 | 방어 계층 | 주 타겟 |
|---|---|---|
| 입력 검증 | 애플리케이션 (서버) | 모든 공격의 1차 방어선 |
| 출력 인코딩 | 애플리케이션 (서버) | XSS |
| Prepared Statement | 애플리케이션 (서버) | SQL Injection |
| CSRF 토큰 | 애플리케이션 (서버) | CSRF |
| HttpOnly / Secure / SameSite 쿠키 | 애플리케이션 + 브라우저 | XSS·CSRF |
| CSP (Content Security Policy) | 브라우저 | XSS |
| WAF (Web Application Firewall) | 네트워크 계층 | 시그니처 기반 차단 (보조) |
| HTTPS / TLS | 전송 계층 | 스니핑·세션 하이재킹 방지 |
WAF는 만능 해결책이 아닙니다. 애플리케이션 레벨 대응을 최우선으로 하고, WAF는 "방어 심화(defense in depth)" 차원의 추가 레이어로 사용합니다.
정보처리기사 실기 대비 문제
Footnotes
-
Cross-Site Scripting의 약자라면 자연스럽게
CSS가 되어야 하지만,CSS는 이미 Cascading Style Sheets(웹 스타일링 언어)에 선점된 약자라 충돌을 피하려고 Cross의 첫 글자C대신X를 씁니다. 영어권에서X가 종종 "cross"의 시각적·발음적 대체 기호로 쓰이기 때문입니다(예: Xmas = Christmas, Xing = Crossing). 같은 이유로 CSRF의C는 충돌 약자가 없어 그대로 두었습니다. ↩