웹 보안 위협과 대응 방법 - XSS·SQL Injection·CSRF 완벽 가이드

OWASP Top 10 웹 보안 위협 목록 표준
XSS·SQL Injection 가장 흔한 공격 유형
2025 WAF 800Gbps DDoS 방어·AI 위협 탐지

웹 애플리케이션은 현대 디지털 생활의 핵심이지만, 동시에 다양한 보안 위협에 노출되어 있습니다. OWASP(Open Web Application Security Project)는 매년 가장 위험한 웹 보안 취약점 목록인 ‘OWASP Top 10’을 발표하여 개발자와 보안 전문가에게 중요한 지침을 제공합니다. 2024년 업데이트에서는 전통적인 SQL Injection, XSS 공격 외에도 API 보안, 클라우드 취약점 등 최신 트렌드가 반영되었습니다. 2025년 최고의 WAF(웹 애플리케이션 방화벽) 솔루션은 AI 기반 분석과 방대한 공격 서명 데이터베이스를 활용하여 OWASP Top 10 위협을 차단하며, 노드당 최대 800Gbps의 DDoS 공격을 방어합니다. 이 글에서는 XSS, SQL Injection, CSRF 등 주요 웹 보안 위협의 원리와 쿠키 보안 플래그, CSP, HTTPS, WAF를 활용한 실전 방어 전략을 상세히 소개합니다.

OWASP Top 10 - 웹 보안의 기준

OWASP(Open Web Application Security Project) Top 10은 웹 애플리케이션에서 가장 흔하게 발생하는 보안 취약점을 정리한 목록으로, 웹 보안의 사실상 표준 가이드입니다. 전 세계 보안 전문가들이 참여하여 3~4년마다 업데이트하며, 개발자, 보안 담당자, 조직이 웹 애플리케이션 보안을 강화하는 데 핵심 지침을 제공합니다.

2021년 OWASP Top 10에서는 SQL Injection, 크로스 사이트 스크립팅(XSS), 인증 및 세션 관리와 같은 전통적인 취약점들이 중심이었습니다. 2024년 업데이트에서는 API 보안과 클라우드 취약점 같은 최신 트렌드를 반영하여 현대적인 보안 문제를 해결할 수 있는 중요한 기준이 되었습니다.

주요 취약점으로는 인젝션 공격(Injection), 인증 실패(Broken Authentication), 민감한 데이터 노출(Sensitive Data Exposure), XML 외부 개체(XXE), 접근 통제 실패(Broken Access Control), 보안 설정 오류(Security Misconfiguration), 크로스 사이트 스크립팅(XSS), 안전하지 않은 역직렬화(Insecure Deserialization), 알려진 취약점이 있는 구성 요소 사용(Using Components with Known Vulnerabilities), 불충분한 로깅 및 모니터링(Insufficient Logging & Monitoring) 등이 포함됩니다.

이 중 인젝션 공격은 OWASP Top 10 중 첫 번째에 속해 있으며, 공격이 비교적 쉬운 편이고 공격에 성공할 경우 큰 피해를 입힐 수 있어 가장 위험한 위협으로 평가됩니다.

XSS(크로스 사이트 스크립팅) - 스크립트 삽입 공격

XSS(Cross-Site Scripting)는 공격자가 웹 페이지에 악의적인 스크립트(주로 JavaScript)를 삽입하여, 다른 사용자의 브라우저에서 실행되게 만드는 공격입니다. OWASP Top 10에 포함되어 있을 정도로 자주 발생하며, 웹 보안에서 가장 흔한 위협 중 하나입니다.

XSS 취약점은 애플리케이션이 올바른 유효성 검사 또는 필터링 처리 없이 신뢰할 수 없는 데이터를 새 웹 페이지에 포함하거나, 사용자 제공 데이터로 기존 웹 페이지를 업데이트할 때 발생합니다. 게시판 댓글, 검색어, 입력 폼 등 사용자 입력을 받는 모든 곳이 잠재적 공격 지점이 될 수 있습니다.

XSS 공격 유형

Stored XSS(저장형)는 가장 위험한 유형으로, 악성 스크립트가 서버 데이터베이스에 저장되어 해당 페이지를 방문하는 모든 사용자에게 영향을 미칩니다. 게시판에 악성 스크립트를 포함한 글을 작성하면, 이를 보는 모든 사용자의 브라우저에서 스크립트가 실행됩니다.

Reflected XSS(반사형)는 악성 스크립트가 URL 파라미터나 폼 입력에 포함되어 즉시 반사되는 형태입니다. 공격자가 조작된 링크를 이메일이나 메시지로 전송하여 사용자를 유인합니다. 피해자가 링크를 클릭하면 스크립트가 실행되어 쿠키나 세션 정보를 탈취당할 수 있습니다.

DOM-based XSS는 클라이언트 측 JavaScript가 DOM(Document Object Model)을 안전하지 않게 조작할 때 발생합니다. 서버가 직접 관여하지 않아 탐지가 어렵습니다.

XSS 공격의 피해

XSS 공격이 성공하면 공격자는 사용자의 쿠키를 탈취하여 세션 하이재킹(Session Hijacking) 공격을 수행할 수 있습니다. 이를 통해 로그인 인증을 우회하고 피해자 계정으로 활동할 수 있습니다. 또한 C&C(Command & Control) 서버로 리디렉션하기 위해 리디렉션 스크립트를 주입하거나, 가짜 로그인 페이지를 표시하여 비밀번호를 수집하는 피싱 공격을 수행할 수 있습니다.

XSS 방어 방법

가장 기본적이고 효과적인 방어 방법은 출력 데이터 인코딩(Output Encoding)입니다. HTML, JavaScript 및 기타 출력 데이터를 적절하게 인코딩하여 스크립트가 실행되지 않도록 합니다. <, >, ", ', & 등의 특수 문자를 HTML 엔티티(&lt;, &gt;, &quot;, &#x27;, &amp;)로 변환합니다.

입력 유효성 검사(Input Validation)도 중요합니다. 사용자 입력을 허용된 패턴(화이트리스트)과 비교하여 검증하고, 의심스러운 패턴(블랙리스트)을 차단합니다. 다만 블랙리스트 방식만으로는 우회 공격을 완벽히 막기 어려우므로 화이트리스트를 우선 적용해야 합니다.

Content Security Policy(CSP) 헤더를 설정하면 브라우저가 실행할 수 있는 스크립트의 출처를 제한할 수 있습니다. Content-Security-Policy: script-src 'self'처럼 설정하면 동일 도메인의 스크립트만 실행되어 외부 악성 스크립트를 차단합니다.

SQL Injection - 데이터베이스 공격

SQL Injection은 공격자가 웹 애플리케이션의 입력 필드를 통해 악의적인 SQL 쿼리를 삽입하여, 데이터베이스를 조작하는 공격입니다. 인젝션 공격은 OWASP Top 10 중 첫 번째에 속하며, 비교적 쉽게 공격할 수 있으면서도 성공 시 큰 피해를 입힐 수 있어 매우 위험합니다.

SQL Injection을 통해 공격자는 인증을 우회하여 관리자 권한을 획득하거나, 민감한 데이터를 추출하여 개인정보, 신용카드 번호 등을 탈취할 수 있습니다. 또한 데이터베이스 내용을 수정 또는 삭제하여 서비스를 마비시키거나 백도어를 설치할 수도 있습니다.

SQL Injection 공격 예시

예를 들어 로그인 폼에서 사용자 이름과 비밀번호를 입력받아 다음과 같은 SQL 쿼리를 생성한다고 가정합니다:

SELECT * FROM users WHERE username='입력값' AND password='입력값';

공격자가 사용자 이름 필드에 admin' --를 입력하면, 쿼리는 다음과 같이 변경됩니다:

SELECT * FROM users WHERE username='admin' --' AND password='...';

--는 SQL 주석으로, 이후 코드가 무시되어 비밀번호 확인 없이 admin 계정으로 로그인됩니다. 더 위험한 공격으로는 '; DROP TABLE users; --처럼 전체 테이블을 삭제하는 쿼리를 삽입할 수도 있습니다.

SQL Injection 방어 방법

가장 효과적인 방어 방법은 매개변수화된 쿼리(Parameterized Query) 또는 준비된 문(Prepared Statement)을 사용하는 것입니다. 이 방식은 SQL 쿼리 구조와 데이터를 분리하여, 사용자 입력이 쿼리 로직을 변경할 수 없게 만듭니다.

예를 들어 Java에서 PreparedStatement를 사용하면:

String query = "SELECT * FROM users WHERE username=? AND password=?";
PreparedStatement pstmt = connection.prepareStatement(query);
pstmt.setString(1, username);
pstmt.setString(2, password);
ResultSet rs = pstmt.executeQuery();

? 위치에 입력된 데이터는 자동으로 이스케이프 처리되어 SQL 명령으로 해석되지 않습니다.

ORM(Object-Relational Mapping) 프레임워크(Hibernate, JPA, Django ORM 등)를 사용하는 것도 좋은 방법입니다. ORM은 내부적으로 매개변수화된 쿼리를 사용하여 SQL Injection을 자동으로 방지합니다.

입력 유효성 검사최소 권한 원칙도 중요합니다. 데이터베이스 계정에 필요 최소한의 권한만 부여하여, 공격이 성공하더라도 피해를 제한할 수 있습니다. 읽기 전용 계정은 데이터 조회만 가능하도록 설정합니다.

WAF(Web Application Firewall)를 사용하면 SQL Injection 패턴을 자동으로 탐지하고 차단할 수 있습니다. 2025년 최신 WAF는 AI 기반 분석으로 새로운 공격 패턴도 실시간으로 학습하여 차단합니다.

CSRF 공격과 쿠키 보안

CSRF(Cross-Site Request Forgery, 사이트 간 요청 위조)는 공격자가 사용자가 의도하지 않은 요청을 웹 애플리케이션에 전송하도록 유도하는 공격입니다. 사용자가 이미 인증된 상태(로그인된 상태)에서 공격자가 조작한 링크나 스크립트를 실행하면, 사용자 권한으로 의도하지 않은 작업(송금, 정보 변경 등)이 수행됩니다.

예를 들어 사용자가 은행 사이트에 로그인한 상태에서 공격자가 만든 악성 사이트를 방문하면, 숨겨진 이미지 태그나 스크립트가 은행 사이트로 송금 요청을 자동으로 전송할 수 있습니다. 브라우저는 자동으로 쿠키를 포함하여 요청을 보내므로, 은행 사이트는 정상적인 사용자 요청으로 인식합니다.

쿠키 보안 플래그

CSRF 공격을 방어하는 핵심 방법은 쿠키 보안 플래그를 적절히 설정하는 것입니다. 현대 브라우저는 세 가지 중요한 쿠키 속성을 제공합니다.

SameSite 속성은 CSRF 공격에 대한 강력한 방어 수단입니다. 세 가지 값을 가질 수 있습니다. SameSite=Strict는 가장 강력한 보호를 제공하며, 브라우저가 교차 사이트 요청에 쿠키를 전혀 포함하지 않습니다. 같은 도메인에서 발생한 요청에만 쿠키가 전송됩니다.

SameSite=Lax는 일부 교차 사이트 요청(GET 방식의 안전한 탐색)에는 쿠키를 허용하지만, POST 요청 등에는 쿠키를 차단합니다. 사용성과 보안의 균형을 맞춘 설정입니다.

SameSite=None은 모든 교차 사이트 요청에 쿠키를 허용하지만, 반드시 Secure 속성과 함께 사용해야 합니다. 주로 임베디드 콘텐츠나 API에서 사용됩니다.

HttpOnly 속성은 JavaScript에서 쿠키에 접근하지 못하도록 제한하여 XSS 공격으로 인한 쿠키 탈취를 방지합니다. document.cookie로 쿠키를 읽을 수 없게 되어, 세션 하이재킹 위험이 크게 줄어듭니다.

Secure 속성은 쿠키가 HTTPS 연결에서만 전송되도록 보장하여 중간자 공격(MITM)을 방지합니다. HTTP로 전송된 쿠키는 평문으로 노출되어 네트워크 스니핑으로 쉽게 탈취당할 수 있으므로, 반드시 Secure 속성을 설정해야 합니다.

통합 보호 전략

HTTPS 사이트의 세션 쿠키에 Secure, HttpOnly, SameSite=Strict 속성을 모두 설정하면 매우 강력한 방어가 가능합니다. 예를 들어:

Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Strict; Path=/; Max-Age=3600

이렇게 설정하면 교차 사이트 요청에서 쿠키가 전송되지 않고, JavaScript로 접근할 수 없으며, HTTPS로만 전송되어 CSRF, XSS, MITM 공격을 모두 방어할 수 있습니다.

추가로 CSRF 토큰을 사용하는 방법도 있습니다. 서버가 각 폼에 무작위 토큰을 생성하여 포함시키고, 요청 시 토큰을 검증합니다. 공격자는 이 토큰을 알 수 없으므로 위조 요청을 보낼 수 없습니다.

Content Security Policy(CSP)

CSP(Content Security Policy)는 XSS, 클릭재킹(Clickjacking), 코드 인젝션 공격을 방지하기 위해 도입된 보안 정책입니다. HTTP 응답 헤더 Content-Security-Policy를 통해 브라우저에 로드할 수 있는 리소스의 출처를 제한합니다.

CSP를 설정하면 웹사이트 관리자가 사용자 에이전트(브라우저)가 특정 페이지에서 로드할 수 있는 리소스를 제어할 수 있습니다. 주로 서버 출처와 스크립트 엔드포인트를 지정하는 정책이 사용됩니다.

CSP 정책 예시

가장 기본적인 CSP는 다음과 같습니다:

Content-Security-Policy: default-src 'self'

이 정책은 모든 리소스(스크립트, 이미지, 스타일시트 등)가 동일 출처(같은 도메인)에서만 로드되도록 제한합니다. 외부 CDN이나 광고 스크립트는 차단됩니다.

더 세밀한 제어가 필요하다면:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src *; style-src 'self' 'unsafe-inline'

이 정책은 스크립트는 자신의 도메인과 cdn.example.com에서만 로드하고, 이미지는 모든 출처를 허용하며, 스타일시트는 자신의 도메인과 인라인 스타일을 허용합니다.

인라인 스크립트 차단

CSP의 가장 강력한 보호 기능은 인라인 스크립트 차단입니다. <script> 태그 안에 직접 작성된 JavaScript나 onclick 같은 이벤트 핸들러 속성의 스크립트는 기본적으로 차단됩니다. 이는 XSS 공격의 대부분을 막을 수 있습니다.

인라인 스크립트가 필요한 경우 nonce(일회용 토큰)나 hash(스크립트 해시값)를 사용하여 특정 스크립트만 허용할 수 있습니다:

<!-- HTML -->
<script nonce="r@nd0m">
  console.log('This script is allowed');
</script>
<!-- HTTP 헤더 -->
Content-Security-Policy: script-src 'nonce-r@nd0m'

CSP는 2025년 현재 모든 주요 브라우저에서 지원되며, 웹 보안의 필수 요소로 자리 잡았습니다.

WAF - 웹 애플리케이션 방화벽

WAF(Web Application Firewall, 웹 애플리케이션 방화벽)는 SQL Injection, XSS, DDoS 공격 같은 웹 취약점과 공격으로부터 웹 애플리케이션을 보호하는 중요한 방어선입니다. 일반 방화벽이 네트워크 계층에서 들어오거나 나가는 트래픽을 필터링한다면, WAF는 웹 애플리케이션 계층(HTTP/HTTPS)의 보안을 담당합니다.

2025년 최신 WAF 기능

2025년 최고의 WAF 솔루션은 AI 기반 분석과 방대한 공격 서명 데이터베이스를 활용하여 OWASP Top 10 위협을 실시간으로 차단합니다. Cloudflare WAF는 머신 러닝을 사용하여 새로 등장하는 위협(제로데이 익스플로잇)을 자동으로 학습하고 차단합니다.

DDoS 방어 능력도 크게 향상되었습니다. 글로벌 스크러빙 센터는 노드당 최대 800Gbps의 공격을 완화할 수 있으며, 클라이언트 지문 및 트래픽 분석을 통해 네트워크/전송/애플리케이션 레이어 DDoS 공격을 지능적으로 식별합니다.

봇 관리(Bot Management) 기능은 프로토콜 분석, IP 평판, AI 모델을 통해 합법적인 사용자와 악의적인 봇을 구분합니다. 자격 증명 채우기(Credential Stuffing), 리소스 스크래핑, 계정 탈취 시도를 방지합니다.

가상 패칭 기능

가상 패칭(Virtual Patching)은 WAF의 가장 유용한 기능 중 하나입니다. 애플리케이션 코드를 직접 수정하지 않고도 취약점을 신속하게 완화할 수 있습니다. 새로운 취약점이 발견되었지만 영구적인 수정(패치)이 개발되기까지 시간이 걸릴 때, WAF 규칙을 추가하여 공격 시도를 즉시 차단할 수 있습니다.

예를 들어 2021년 Log4j 취약점(Log4Shell)이 발견되었을 때, 많은 조직이 WAF 규칙을 업데이트하여 악용 시도를 차단하면서 시간을 벌어 애플리케이션 패치를 준비할 수 있었습니다.

2025년 현재 Cloudflare, AWS WAF, Azure WAF, Akamai, Imperva 등 주요 클라우드 및 CDN 업체들이 강력한 WAF 서비스를 제공하며, 중소기업도 합리적인 비용으로 엔터프라이즈급 웹 보안을 적용할 수 있게 되었습니다.

웹 보안 베스트 프랙티스

웹 보안은 단일 기술이 아니라 여러 방어 계층을 결합한 통합 전략이 필요합니다. 2025년 권장되는 웹 보안 베스트 프랙티스는 다음과 같습니다.

HTTPS 필수 적용: 모든 페이지에 HTTPS를 적용하고, HTTP 요청은 자동으로 HTTPS로 리디렉션합니다. HSTS(HTTP Strict Transport Security) 헤더를 설정하여 브라우저가 항상 HTTPS만 사용하도록 강제합니다. Strict-Transport-Security: max-age=31536000; includeSubDomains; preload 헤더를 추가하면 1년간 HTTPS 전용 모드가 유지됩니다.

보안 헤더 설정: 주요 보안 헤더들을 모두 설정합니다. X-Content-Type-Options: nosniff는 MIME 타입 스니핑을 방지하고, X-Frame-Options: DENY는 클릭재킹 공격을 차단하며, Referrer-Policy: no-referrer는 민감한 정보가 Referer 헤더로 노출되는 것을 방지합니다.

정기적인 보안 업데이트: 사용하는 모든 라이브러리, 프레임워크, 서버 소프트웨어를 최신 버전으로 유지합니다. 알려진 취약점이 있는 구성 요소는 OWASP Top 10에 포함될 정도로 위험합니다. npm, composer, pip 등 패키지 관리자의 보안 취약점 알림을 활성화하고 즉시 대응합니다.

입력 검증과 출력 인코딩: 모든 사용자 입력을 신뢰하지 않고 검증합니다. 화이트리스트 방식으로 허용된 패턴만 수용하고, 출력 시에는 컨텍스트에 맞게 인코딩(HTML, JavaScript, SQL)합니다. 이는 XSS, SQL Injection 등 대부분의 인젝션 공격을 방어합니다.

최소 권한 원칙: 데이터베이스 계정, API 키, 서버 권한 등 모든 계정에 필요 최소한의 권한만 부여합니다. 공격이 성공하더라도 피해 범위를 제한할 수 있습니다.

로깅과 모니터링: 모든 보안 관련 이벤트(로그인 시도, 권한 변경, 오류 등)를 로그에 기록하고 정기적으로 분석합니다. 비정상적인 패턴을 조기에 발견하여 대응할 수 있습니다.

자주 묻는 질문 (FAQ)

❓ XSS와 SQL Injection 중 어느 것이 더 위험한가요?

두 공격 모두 OWASP Top 10에 포함된 매우 위험한 위협이지만, 일반적으로 SQL Injection이 더 치명적입니다. SQL Injection이 성공하면 전체 데이터베이스에 접근하여 모든 사용자 정보를 탈취하거나 데이터를 삭제할 수 있습니다. XSS는 주로 개별 사용자를 타겟으로 하지만, SQL Injection은 시스템 전체를 위협합니다. 다만 Stored XSS는 여러 사용자에게 영향을 미치므로 매우 위험할 수 있습니다. 두 공격 모두 철저한 방어가 필요합니다.

❓ SameSite=Strict를 사용하면 문제가 없나요?

SameSite=Strict는 CSRF 공격에 대한 강력한 방어를 제공하지만, 사용성 문제를 일으킬 수 있습니다. 외부 사이트에서 링크를 클릭하여 들어올 때 쿠키가 전송되지 않아 로그인 상태가 유지되지 않습니다. 예를 들어 이메일 링크를 클릭하면 로그인이 풀려 있어 다시 로그인해야 합니다. 이런 경우 SameSite=Lax를 사용하면 GET 요청에는 쿠키를 허용하여 사용성과 보안의 균형을 맞출 수 있습니다. 중요한 작업(송금, 정보 변경 등)은 POST 요청을 사용하고 CSRF 토큰을 추가하여 보호합니다.

❓ CSP를 설정하면 기존 사이트가 작동하지 않을 수 있나요?

네, CSP를 갑자기 Strict하게 설정하면 인라인 스크립트, 외부 CDN, 광고 스크립트 등이 차단되어 사이트가 제대로 작동하지 않을 수 있습니다. 따라서 단계적으로 적용하는 것이 좋습니다. 먼저 Content-Security-Policy-Report-Only 헤더를 사용하여 실제로 차단하지 않고 위반 사항만 리포트받으며, 문제가 되는 스크립트를 파악하여 nonce나 hash를 추가하거나 외부 출처를 허용 목록에 추가합니다. 충분히 테스트한 후 실제 CSP 정책을 적용하면 안전합니다.

❓ WAF를 사용하면 보안 코딩을 하지 않아도 되나요?

절대 아닙니다. WAF는 중요한 방어 계층이지만 완벽한 보안을 보장하지 않습니다. 새로운 공격 패턴이나 비즈니스 로직 취약점은 WAF가 탐지하지 못할 수 있습니다. WAF는 '마지막 방어선'으로 생각하고, 근본적으로는 안전한 코딩 관행(매개변수화된 쿼리, 출력 인코딩, 입력 검증 등)을 철저히 적용해야 합니다. 다층 방어 전략(Defense in Depth)으로 애플리케이션 보안, WAF, 네트워크 보안을 모두 결합하는 것이 가장 안전합니다.

❓ 개인 블로그나 소규모 사이트도 이런 보안이 필요한가요?

네, 규모와 관계없이 모든 웹사이트는 기본적인 보안 조치가 필요합니다. 소규모 사이트도 봇 공격, SQL Injection, XSS 공격의 타겟이 될 수 있으며, 해킹당하면 피싱 사이트나 악성코드 배포지로 악용될 수 있습니다. WordPress, Django, Rails 같은 현대 CMS와 프레임워크는 기본적으로 보안 기능을 제공하므로, 최신 버전을 유지하고 HTTPS를 적용하는 것만으로도 큰 도움이 됩니다. Cloudflare 무료 플랜을 사용하면 기본적인 WAF와 DDoS 방어도 무료로 이용할 수 있습니다.

마치며

웹 보안은 XSS, SQL Injection, CSRF 같은 전통적인 위협부터 API 취약점, 클라우드 보안 같은 현대적 위협까지 다양한 측면을 다룹니다. OWASP Top 10은 웹 보안의 핵심 가이드라인으로, 개발 단계부터 보안을 고려하는 Secure by Design 접근이 중요합니다.

2025년 현재 AI 기반 WAF, CSP, 쿠키 보안 플래그, HTTPS, 보안 헤더 등 강력한 방어 도구들이 제공되고 있습니다. 매개변수화된 쿼리로 SQL Injection을 방지하고, 출력 인코딩과 CSP로 XSS를 차단하며, SameSite 쿠키 속성과 CSRF 토큰으로 위조 요청을 막는 등 기본 원칙을 철저히 적용하는 것이 가장 효과적입니다. 다층 방어 전략으로 애플리케이션, 네트워크, 인프라 보안을 모두 강화하여 안전한 웹 서비스를 제공하세요.

링크가 복사되었습니다