XSS와 SQL Injection: 왜 실행될까?
💡 핵심 질문:
"유저 입력에 JavaScript 코드나 SQL 문을 넣는다고 해서, 이게 클라이언트나 서버에서 실행될 수 있는가?"
✅ 답변: 실행될 수 있음.
- XSS는 클라이언트(브라우저)에서 실행되는 문제
- SQL Injection은 서버(DB)에서 실행되는 문제
둘 다 입력값을 제대로 처리하지 않으면 악성 코드가 실행될 수 있음.
1️⃣ XSS (Cross-Site Scripting) → 클라이언트에서 실행됨
XSS가 발생하는 이유:
브라우저는 HTML을 렌더링할 때, 스크립트(<script>
태그 등)가 있으면 실행하도록 설계되어 있음.
💡 즉, 입력값을 필터링하지 않으면 유저가 삽입한 스크립트도 브라우저가 정상적인 코드로 인식하고 실행함.
📌 XSS 공격 예시
✅ 1. Stored XSS (저장형 XSS)
- 공격자가 댓글 입력 필드에 악성 스크립트를 입력
<script>alert('해킹됨!');</script>
- 이 값이 그대로 데이터베이스에 저장됨
- 이후, 다른 사용자가 이 페이지를 방문할 때 저장된 악성 스크립트가 브라우저에서 실행됨
📌 왜 실행될까?
- 서버가 입력값을 필터링 없이 그대로 HTML로 반환하기 때문
- 브라우저는
<script>
태그를 만나면 실행하도록 설계되어 있음
✅ 방어 방법:
- 입력값 필터링 (
DOMPurify
,escape()
) Content-Security-Policy (CSP)
적용하여 외부 스크립트 차단innerHTML
대신textContent
사용
import DOMPurify from "dompurify";
const safeContent = DOMPurify.sanitize(userInput);
✅ 2. Reflected XSS (반사형 XSS)
- 공격자가 URL에 악성 스크립트를 포함한 링크를 보냄
https://example.com/search?q=<script>alert('XSS')</script>
- 서버가
q
값을 필터링 없이 HTML에 포함하여 응답 <h1>검색 결과: <script>alert('XSS')</script></h1>
- 사용자가 링크를 클릭하면 즉시 브라우저에서 스크립트가 실행됨
✅ 방어 방법:
- 입력값을 HTML 인코딩 (
<script>
→<script>
) - 입력값을 직접 HTML에 삽입하지 않고, 안전한 렌더링 방식 사용
2️⃣ SQL Injection → 서버(DB)에서 실행됨
SQL Injection이 발생하는 이유:
SQL 쿼리를 만들 때, 유저 입력값을 직접 문자열로 삽입하면, 공격자가 SQL 문법을 조작할 수 있음.
💡 즉, 서버가 입력값을 검증 없이 SQL 쿼리에 직접 포함하면, 데이터베이스가 이를 SQL 코드로 해석함.
📌 SQL Injection 공격 예시
✅ 1. 로그인 우회 공격
const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;
✔️ 정상 입력:
username = "admin"
password = "1234"
📌 실행되는 쿼리:
SELECT * FROM users WHERE username = 'admin' AND password = '1234';
✔️ 공격자 입력 (SQL 문 삽입):
username = "admin"
password = "' OR '1'='1"
📌 실행되는 쿼리 (항상 참이 됨 → 로그인 성공):
SELECT * FROM users WHERE username = 'admin' AND password = '' OR '1'='1';
✅ 방어 방법:
- Prepared Statements (프리페어드 스테이트먼트) 사용
- ORM(Prisma, Sequelize 등) 사용하여 SQL 직접 실행 방지
📌 SQL Injection 방어 코드 예시 (프리페어드 스테이트먼트 사용)
const query = "SELECT * FROM users WHERE username = ? AND password = ?";
db.execute(query, [username, password]);
🚀 프리페어드 스테이트먼트를 사용하면, 입력값이 SQL 코드로 해석되지 않고 안전하게 처리됨.
3️⃣ XSS vs SQL Injection 차이점 정리
구분 | XSS (Cross-Site Scripting) | SQL Injection |
---|---|---|
공격 대상 | 클라이언트(브라우저) | 서버(DB) |
공격 방식 | HTML에 악성 스크립트 삽입 | SQL 쿼리 조작 |
실행 위치 | 브라우저에서 실행 | 데이터베이스에서 실행 |
주요 원인 | 사용자 입력을 HTML에 그대로 삽입 | 사용자 입력을 SQL에 그대로 삽입 |
방어 방법 | escape() , DOMPurify , CSP 적용 |
Prepared Statements 사용 |
🎤 요약
XSS와 SQL Injection은 둘 다 사용자 입력값을 제대로 처리하지 않으면 발생하는 보안 취약점입니다.
XSS는 클라이언트에서 실행되는 스크립트를 삽입하는 공격으로, 브라우저가 <script>
태그를 그대로 실행하기 때문에 발생합니다.
이를 방지하려면 입력값을 인코딩하거나, DOMPurify
같은 라이브러리를 사용해 안전한 HTML만 렌더링하는 것이 중요합니다.
SQL Injection은 서버에서 실행되는 SQL 쿼리를 조작하는 공격으로, 사용자가 입력한 값을 SQL에 직접 삽입하면 발생할 수 있습니다. 이를 방지하기 위해서는 Prepared Statements를 사용하여 입력값이 SQL 코드로 해석되지 않도록 해야 합니다.
둘 다 입력값 검증이 핵심이며, 실제 프로젝트에서도 프론트엔드(XSS 방어)와 백엔드(SQL Injection 방어)를 모두 고려하는 것이 중요합니다.
'TIL' 카테고리의 다른 글
[250221 TIL] Number.EPSILON (0) | 2025.02.21 |
---|---|
[250216 TIL] Duck Typing (0) | 2025.02.16 |
[250215 TIL] XSS, CSRF 대응 (0) | 2025.02.15 |
[250214 TIL] HTTP, OSI7계층(개념정리) (0) | 2025.02.14 |
[250213 TIL] 추상화, 캡슐화(개념정리) (0) | 2025.02.13 |