🌏 주요 웹 보안 공격 기법
✅ XSS (Cross-Site Scripting)
사이트에 스크립트를 삽입해 공격하는 방식
예를 들어 게시판에 악성 자바스크립트 코드를 심어두면, 다른 사용자가 그 글을 열었을 때 브라우저가 그대로 실행해버립니다. 이때 공격자는 사용자의 세션 정보나 입력 값을 직접적으로 훔칠 수 있습니다.
- 탈취할 수 있는 것
- 세션 쿠키
- 예:
document.cookie를 읽어서 공격자 서버로 전송 (단, HttpOnly 옵션을 붙이면 탈취할 수 없음) - 로컬 스토리지 / 세션 스토리지 값
- JWT 토큰 같은 인증 정보가 저장되어 있다면 노출
- 사용자 입력 값
- 폼(form)에 입력한 계좌번호, 비밀번호, 카드 정보 등
- DOM 조작을 통한 피싱
- 가짜 입력창을 띄워 ID/비밀번호 입력 유도
- 브라우저에서 접근 가능한 API 응답 데이터
- 예: AJAX 응답(JSON)을 가로채서 탈취
즉, **XSS는 브라우저 안에서 돌아가는 모든 정보**를 공격자가 가로챌 수 있습니다.
- 방어 전략
- 쿠키를 HttpOnly로 설정해 JS에서 접근 불가하게 만들기 (cf. CSRF에는 큰 효과 없음)
- 입력값 철저히 검증(escape, sanitize)
- 사용자가 입력한
<script>...</script>같은 값이 그대로 페이지에 뿌려지면 공격자가 코드 심을 수 있기 때문에 들어오는 데이터는 전부 검사 + 안전하게 변환- 예:
<를<로 바꿔주면 브라우저는 단순 텍스트로만 보여줌.
- 예:
- sanitize는 불필요하거나 위험한 태그를 아예 잘라내는 것
- 사용자가 입력한
- CSP(Content Security Policy) 적용해 스크립트 실행 제어
- 브라우저에게 이 사이트에서 어떤 스크립트만 실행해도 되는지를 규칙으로 알려주는 방식으로, 외부에서 몰래 심은 스크립트는 실행되지 않음
✅ CSRF (Cross-Site Request Forgery)
사용자가 로그인된 상태를 악용해, 사용자를 속여 원치 않는 요청을 보내는 공격
예를 들어 은행에 로그인한 상태에서 공격자가 숨겨둔 폼을 클릭하게 만들면, 사용자의 브라우저는 은행 서버로 요청을 보내면서 피해자의 세션 쿠키가 자동으로 전송됩니다. 결과적으로 공격자가 의도한 계좌 이체 요청이 실행될 수 있습니다.
- 탈취할 수 있는 것
- 사용자 계정의 권한으로 요청 실행
- 예: 비밀번호 변경 요청, 송금 요청, 게시글 작성 요청
- 서버에 저장된 정보 조작 가능
- 예: "깃짱 계좌에 10만원 송금" 같은 요청 실행
단, 쿠키/세션 정보 자체는 탈취 불가(Same-Origin Policy 때문에 응답을 읽을 수 없음)
- 방어 전략
- 쿠키에 SameSite 옵션 설정 (
Lax또는Strict)- SameSite 옵션: 쿠키를 외부 사이트 요청에 포함할지 말지 정하는 규칙
- Strict
- 철저히 차단
- 다른 사이트에서 온 모든 요청에는 쿠키 안 붙음
- 단점: 소셜 로그인, 외부 링크 후 로그인 유지 등 불편함
- Lax (권장)
- 기본적인 안전 보장 + 사용성 확보
- 링크 클릭(GET) 요청에는 쿠키 포함 가능
- 하지만 폼 전송(POST), 스크립트 요청 등은 차단
- None
- 외부 사이트 요청에도 항상 쿠키 전송
- 단,
Secure옵션(HTTPS 전송만 허용)도 같이 걸어야 함.
SameSite=Lax를 기본으로 쓰고, 민감한 쿠키는Strict를 쓰는 게 좋습니당!
- Strict
- SameSite 옵션: 쿠키를 외부 사이트 요청에 포함할지 말지 정하는 규칙
- CSRF Token 사용: 폼이나 요청마다 무작위 토큰을 발급하고, 서버에서 검증
- 사용자가 페이지를 열면, 서버가 랜덤 토큰을 발급 → HTML 폼 안에 숨겨서 넣어둠
- 사용자가 폼 제출 시, 토큰도 함께 서버로 전송
- 서버는 세션에 저장된 토큰과 일치하는지 검사
- 일치 → 정상 요청으로 판단해 처리함
- 불일치 or 없음 → CSRF 공격으로 간주하고 차단
- 중요한 요청에는 재인증 요구 (비밀번호 재입력, OTP 등)
- 쿠키에 SameSite 옵션 설정 (
✅ SQL Injection (SQLi)
입력값을 조작해 서버의 SQL 쿼리를 변형하는 공격
서버(Java 코드)에서 로그인 검증을 다음처럼 작성했다고 합시다:
String sql = "SELECT * FROM users WHERE id = '" + userId + "' AND password = '" + password + "'";
즉, 사용자가 입력한 값(userId, password)을 그대로 문자열에 끼워 넣는 방식입니다.
이렇게 문자열로 만들면, 사용자가 입력값에 "' OR '1'='1" 같은 SQL 구문을 넣어버릴 수 있습니다. 그러면 비밀번호 검증이 무시되고 모든 조건이 참이 되어 누구든 로그인할 수 있게 됩니다. 이것이 SQL Injection의 핵심 문제입니다.
- 공격 특징
- 공격 경로: 서버가 사용자 입력을 그대로 SQL 쿼리에 포함시킬 때
- 목표: DB 데이터 조회·수정·삭제, 관리자 권한 탈취
- 방어 전략
- Prepared Statement만 잘 써도 SQL Injection은 사실상 막을 수 있습니다.
- ORM 사용으로 직접 쿼리 작성 최소화 (보조수단, 절대적인 방어책은 아님)
- 입력값 검증 및 화이트리스트 기반 필터링
✅ Command Injection
서버에서 실행되는 명령어를 조작해 임의의 커맨드를 실행하게 만드는 공격
예를 들어 파일 업로드 기능에서 입력값을 제대로 검증하지 않으면, 공격자가 ; rm -rf / 같은 명령을 주입할 수 있습니다. 이렇게 되면 서버에서 원래 의도와 전혀 다른 명령이 실행될 수 있습니다.
- 공격 특징
- 공격 경로: 애플리케이션이 사용자 입력을 OS 명령에 직접 전달할 때
- 목표: 서버 장악, 시스템 명령 실행
- 방어 전략
- 사용자 입력을 OS 명령어에 직접 연결하지 않기
- 실행 가능한 명령은 화이트리스트 기반으로 제한
- 최소 권한 원칙 적용
✅ Directory Traversal
상대 경로(../) 등을 이용해 원래 접근하면 안 되는 디렉토리의 파일에 접근하는 공격
예를 들어 GET /download?file=../../etc/passwd 같은 요청을 통해 민감한 서버 파일을 열람할 수 있습니다.
- 공격 특징
- 공격 경로: 파일 경로 입력값 검증 부족
- 목표: 서버 내부 민감 파일 접근
- 방어 전략
- 입력값 정규화(normalization)
- 접근 가능한 경로를 화이트리스트로 제한
- 파일 다운로드 시 절대경로 매핑 사용
✅ DoS / DDoS (Denial of Service)
서버 자원을 고갈시켜 정상 사용자가 서비스를 이용하지 못하게 하는 공격
단일 공격자가 과도한 요청을 보내는 경우를 DoS, 다수의 분산된 공격자가 동시에 공격하는 경우를 DDoS라고 합니다.
- 공격 특징
- 공격 경로: 네트워크 트래픽 과부하, 애플리케이션 자원 고갈
- 목표: 서비스 마비, 가용성 저하
- 방어 전략
- Rate Limiting 적용 (로그인은 1분에 5번 이상 불가)
- WAF(Web Application Firewall) 사용 (보조 방어책)
- 웹 트래픽을 서버 앞단에서 검사하고 의심스로운 요청을 차단하는 방화벽
- SQLi, XSS, 잘 알려진 취약점 공격 패턴들을 막을 수 있다.
- CDN을 통한 트래픽 분산
- 요청을 전세계 여러 캐시 서버에서 나누어 처리하기 때문에 트래픽을 분산해 서버가 죽는 것을 방지
- 비정상 트래픽 필터링
- 초당 1000번 로그인 시도 같은 비정상적인 접근을 탐지
- AI 기반 보안 솔루션이나 로그 분석을 활용해 자동으로 차단
✅ Brute Force / Credential Stuffing
비밀번호를 무작위로 대입하거나, 유출된 계정 정보를 자동으로 시도하는 공격
Brute Force는 비밀번호를 무작위 또는 흔한 비밀번호 목록으로 계속 대입하는 것이고, Credential Stuffing은 이미 다른 서비스에서 유출된 계정 또는 비밀번호 조합을 재활용해서 시도합니다.
- 공격 특징
- 공격 경로: 로그인 API
- 목표: 계정 탈취
- 방어 전략
- 로그인 시도 횟수 제한 및 지연 적용
- CAPTCHA 도입 (사람인가요?)
- MFA(이중 인증) 적용
- 유출 비밀번호 차단 정책 적용

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!
'컴퓨터과학 > 네트워크' 카테고리의 다른 글
| [네트워크] TCP/IP 헤더와 패킷의 구조 (0) | 2025.09.13 |
|---|---|
| [네트워크] CORS & SOP: Preflight (OPTIONS) 요청은 매번 보내나요? (0) | 2025.09.12 |
| [네트워크] 인증을 구현하는 방법들: 클라이언트는 쿠키 이외에 인증 정보를 어디에 저장할 수 있을까? (0) | 2025.09.11 |
| [네트워크] HTTP Header: Virtual Hosting, 컨텐츠 협상, Accept의 우선순위, Authorization, Cache-Control (0) | 2025.09.10 |
| [네트워크] Stateless & Connectionless: 서버는 왜 Stateless? HTTP/1.1부터 왜 Persistent Connection? (0) | 2025.09.10 |