해커가 노리는 웹취약점 TOP 7: SQL Injection·XSS·CSRF 실전 분석 총정리
안녕하세요, 개발과 보안전문 ICT리더 리치입니다. 얼마 전, 지인이 운영하는 쇼핑몰이 하루아침에 고객 DB 전체를 털렸습니다. 원인을 추적해보니 단 한 줄의 SQL 쿼리 — 입력값 검증 한 번 안 한 로그인 폼이 문제였죠. 보안 취약점은 먼 나라 이야기가 아닙니다. 지금 이 순간에도 수천 개의 웹사이트가 해커의 자동화 스캐너에 노출되고 있습니다.
오늘은 실제 해킹 사고에서 가장 많이 등장하는 웹취약점 7가지를 골라, 공격 원리부터 탐지·차단 방법까지 실전 중심으로 낱낱이 풀어드립니다. 개발자든 보안 담당자든, 이 글 하나로 웹 보안의 핵심을 잡아가실 수 있습니다.
📌 바로가기 목차
 |
| 웹취약점 보안 분석 대표 썸네일 | 사이버보안 전문가 이미지 |
1. SQL Injection — 가장 오래됐지만 여전히 치명적인 공격
혹시 이런 경험 있으신가요? 로그인 창에 아이디를 입력하는데, 비밀번호 없이도 관리자 계정에 접속되는 상황. 소설 속 이야기가 아닙니다. SQL Injection은 1998년에 처음 공개된 공격 기법임에도 불구하고, 2024년 OWASP 보고서 기준 여전히 웹 해킹 사고의 약 34%를 차지하고 있습니다. 그 이유는 단순합니다 — 여전히 수많은 서비스가 사용자 입력값을 검증 없이 DB 쿼리에 직접 던지기 때문입니다.
공격자는 입력 폼에 ' OR '1'='1 같은 구문을 삽입해 쿼리 논리를 변조합니다. 이를 통해 인증 우회, 전체 DB 덤프, 심지어 서버 명령 실행까지 가능해집니다. 직접 경험한 사례를 보면, 단순 회원가입 폼 하나에 Union-based Injection을 넣어 users 테이블 전체가 유출된 케이스가 있었습니다. 방어의 핵심은 Prepared Statement(파라미터화 쿼리) 사용과 입력값 화이트리스트 필터링입니다.
# 취약한 코드 (SQL Injection 위험)
query = "SELECT * FROM users WHERE id='" + user_input + "'"
# 안전한 코드 (Prepared Statement)
cursor.execute("SELECT * FROM users WHERE id = %s", (user_input,))
⚠️ 주의: ORM을 사용한다고 해서 100% 안전한 건 아닙니다. raw() 또는 extra() 메서드로 직접 쿼리를 작성할 경우 동일하게 취약해질 수 있습니다.
👉 다음 섹션에서는 사용자의 브라우저를 직접 공격하는 XSS의 실체를 파헤칩니다.
2. XSS(크로스사이트 스크립팅) — 사용자를 노리는 스크립트 함정
"서버는 멀쩡한데 왜 쿠키가 털렸지?" — XSS를 처음 마주한 개발자들이 가장 당황하는 순간입니다. XSS는 서버가 아니라 사용자의 브라우저를 공격 대상으로 삼습니다. 공격자가 게시판·댓글창에 악성 스크립트를 심어두면, 그 페이지를 방문한 모든 사용자의 세션 쿠키·개인정보가 유출됩니다. Google의 HackerOne 리포트에 따르면, XSS는 버그바운티 플랫폼에서 가장 많이 제보되는 취약점 유형 1위를 꾸준히 유지하고 있습니다. 여러분이 지금 사용하는 서비스도 안전할까요?
| XSS 유형 | 특징 | 피해 범위 | 대표 대응 |
|---|---|---|---|
| Stored XSS | 악성 스크립트가 DB에 저장됨 | 페이지 방문자 전체 | 출력 이스케이프, CSP 설정 |
| Reflected XSS | URL 파라미터로 즉시 반사 | 링크를 클릭한 사용자 | 입력값 검증, 화이트리스트 |
| DOM-based XSS | 클라이언트 JS가 악성 값 처리 | 해당 페이지 사용자 | innerHTML 대신 textContent 사용 |
XSS 방어의 핵심은 출력 단계에서의 HTML 이스케이프와 Content Security Policy(CSP) 헤더 설정입니다. <script> 태그만 막는다고 끝나지 않습니다 — onerror, onmouseover 같은 이벤트 핸들러를 통한 우회 공격도 빈번합니다. 당신의 서비스는 CSP 헤더가 설정되어 있나요?
👉 다음 섹션에서는 로그인된 사용자를 몰래 조종하는 CSRF의 교묘한 수법을 살펴봅니다.
3. CSRF — 사용자 몰래 요청을 보내는 교묘한 수법
인터넷 뱅킹에 로그인한 채로 낚시 링크를 클릭했더니, 모르는 계좌로 송금이 완료됐다면? CSRF(Cross-Site Request Forgery)는 바로 이런 공격입니다. 피해자가 이미 인증된 세션을 가진 상태에서, 공격자가 만든 악성 페이지가 피해자의 브라우저를 통해 정상적인 요청처럼 서버에 명령을 보냅니다. 2023년 국내 한 커머스 플랫폼에서 CSRF를 이용한 포인트 전송 공격이 실제로 발생해 수천 계정이 피해를 입기도 했습니다.
- CSRF 토큰 적용: 서버가 폼 요청마다 고유한 임의 토큰을 발급하고, 요청 시 이를 검증합니다. 토큰 없이 들어온 요청은 즉시 거부됩니다.
- SameSite 쿠키 속성: 쿠키에 SameSite=Strict 또는 Lax를 설정하면, 외부 사이트에서 발생한 요청에 쿠키가 자동으로 포함되지 않습니다.
- Referer / Origin 헤더 검증: 요청이 허용된 도메인에서 발생했는지를 서버 측에서 확인하는 추가 방어선입니다.
- 중요 액션 재인증: 계좌이체·비밀번호 변경 같은 민감한 요청은 반드시 현재 비밀번호 또는 OTP를 추가로 요구합니다.
💡 실전 팁: Django·Laravel·Spring 등 주요 프레임워크는 CSRF 방어를 기본 내장하고 있습니다. 단, API 서버에서 이를 비활성화하는 경우가 많으니 반드시 설정 상태를 재확인하세요.
4. IDOR·인증·세션 취약점 — 권한 설계의 허점을 파고드는 공격
URL 주소창에서 숫자 하나만 바꿨더니 다른 사람의 주문 내역이 보인다면? 이게 바로 IDOR(Insecure Direct Object Reference), 불안전한 직접 객체 참조입니다. 의외로 많은 서비스가 /order?id=1234 처럼 순차적 ID를 URL에 노출시키고, 서버 측에서 "이 사용자가 이 리소스에 접근할 권한이 있는가?"를 검증하지 않습니다. Uber는 2016년 IDOR 취약점으로 드라이버 전체 정보가 열람 가능했던 사건을 겪었고, 이로 인해 $150만의 버그바운티를 지급했습니다. 여러분의 API는 모든 엔드포인트에서 권한 검증을 수행하고 있나요?
세션 관련 취약점도 함께 살펴봐야 합니다. 세션 고정 공격(Session Fixation)은 공격자가 미리 세션 ID를 발급받아 피해자에게 사용하도록 유도한 뒤, 피해자가 로그인하면 해당 세션을 탈취하는 방식입니다. 세션 ID는 로그인 성공 시 반드시 재발급되어야 하고, 만료 시간과 HttpOnly·Secure 속성도 빠짐없이 설정해야 합니다.
⚠️ 주의: UUID를 사용해도 서버 측 권한 검증 없이는 IDOR를 완전히 막을 수 없습니다. 예측 불가능한 ID + 서버 측 소유권 검증, 두 가지를 반드시 함께 적용해야 합니다.
👉 다음 섹션에서는 웹취약점 TOP 7을 위험도·탐지난이도·대응법 기준으로 한 표에 비교합니다.
5. 웹취약점 TOP 7 한눈에 비교 — 위험도·탐지·대응 총정리
실무에서 보안 진단을 할 때 가장 먼저 보는 것이 바로 취약점별 위험도와 탐지 난이도입니다. 아래 비교표는 OWASP Top 10 및 실제 침해사고 데이터를 기반으로 정리한 내용으로, 우선순위를 잡는 데 바로 활용하실 수 있습니다.
| 취약점 | 위험도 | 탐지 난이도 | 주요 피해 | 핵심 대응 |
|---|---|---|---|---|
| SQL Injection | 🔴 매우 높음 | 낮음 | DB 전체 유출·파괴 | Prepared Statement |
| XSS | 🔴 높음 | 중간 | 세션 탈취·피싱 | 출력 이스케이프·CSP |
| CSRF | 🟠 높음 | 중간 | 무단 트랜잭션 실행 | CSRF 토큰·SameSite |
| IDOR | 🔴 높음 | 낮음 | 타인 데이터 열람·변조 | 서버 측 권한 검증 |
| 디렉토리 트래버설 | 🟠 중간 | 낮음 | 서버 파일 열람 | 경로 정규화·화이트리스트 |
| XXE Injection | 🟠 중간 | 높음 | 내부 파일·SSRF 연계 | 외부 엔티티 처리 비활성화 |
| 보안 설정 오류 | 🟡 중간 | 낮음 | 정보 노출·무단 접근 | 보안 헤더·기본값 제거 |
위험도가 높고 탐지 난이도가 낮은 SQL Injection과 IDOR는 가장 먼저 점검해야 할 최우선 과제입니다.
6. 실전 방어 체크리스트 — 지금 당장 점검해야 할 항목들
보안은 한 번 설정하고 끝나는 게 아닙니다. 매 배포·매 업데이트마다 아래 체크리스트를 습관처럼 돌리는 팀과 그렇지 않은 팀의 차이는 결국 침해사고 여부로 나타납니다. 실제로 침해를 경험한 기업의 78%가 "알고 있었지만 미뤘던" 취약점에서 공격을 당했다는 통계가 있습니다. 지금 바로 체크해보세요.
- ☑ 모든 DB 쿼리 Prepared Statement 적용: ORM의 raw 쿼리 사용 여부를 코드 리뷰 단계에서 반드시 확인합니다.
- ☑ 출력 시 HTML 이스케이프 적용: 사용자 입력값이 화면에 렌더링되는 모든 지점을 점검합니다.
- ☑ HTTP 보안 헤더 전체 설정: CSP, X-Frame-Options, X-XSS-Protection, Strict-Transport-Security를 빠짐없이 적용합니다.
- ☑ API 엔드포인트 권한 검증: 모든 API가 요청자의 소유권을 서버 측에서 확인하는지 검토합니다.
- ☑ 세션 관리 설정 점검: 로그인 후 세션 재발급, HttpOnly·Secure·SameSite 쿠키 속성 적용 여부를 확인합니다.
- ☑ 정기적인 자동화 취약점 스캔: OWASP ZAP, Burp Suite 같은 도구로 배포 전 자동 스캔을 CI/CD 파이프라인에 통합합니다.
👉 다음 FAQ 섹션에서는 실무에서 가장 많이 받는 웹 보안 질문들을 정리했습니다 — 바로 확인하기
7. 자주 묻는 질문 (FAQ)
대부분의 최신 ORM은 기본적으로 파라미터 바인딩을 사용하지만, raw 쿼리나 format() 문자열을 직접 쓰는 순간 취약해집니다. 1번 섹션의 코드 예시를 반드시 참고해 팀 전체의 코딩 규칙으로 정착시켜야 합니다.
WAF는 알려진 공격 패턴을 탐지하는 보조 수단이지, 근본적인 해결책이 아닙니다. 난독화·우회 기법을 사용하면 WAF를 우회할 수 있으므로, 6번 섹션의 체크리스트처럼 소스코드 레벨 방어가 반드시 병행되어야 합니다.
XSS는 악성 스크립트를 피해자의 브라우저에서 실행시켜 정보를 탈취하는 공격이고, CSRF는 피해자의 인증된 세션을 이용해 서버에 원치 않는 요청을 전송하는 공격입니다. 공격 대상이 '사용자 브라우저'냐 '서버'냐의 차이로 이해하면 쉽습니다. 2번 섹션과 3번 섹션을 함께 비교해 보세요.
무료로 시작할 수 있는 도구로는 OWASP ZAP(자동 스캔), Burp Suite Community Edition(수동 프록시), nikto(서버 취약점 스캔)가 대표적입니다. 단, 반드시 자신이 소유하거나 허가받은 시스템에서만 사용해야 합니다. 5번 비교표를 참고해 우선순위를 정한 뒤 점검하시길 권장합니다.
KISA 인증을 받은 취약점 점검 업체 목록을 우선 확인하고, 산출물(취약점 보고서) 샘플과 재점검 범위를 계약 전에 명확히 확인해야 합니다. 자동화 스캔만 하는 업체와 수동 모의해킹을 병행하는 업체의 비용·품질 차이가 크니 주의하세요. 더 궁금한 점은 댓글로 남겨주세요!
8. 마무리 요약
✅ 웹 보안, 알고 있다는 착각이 가장 위험합니다
오늘 살펴본 SQL Injection, XSS, CSRF, IDOR를 포함한 웹취약점 TOP 7은 모두 이미 알려진 공격 패턴입니다. 그럼에도 매년 수천 건의 침해사고가 동일한 취약점에서 반복되는 이유는 단 하나 — "알지만 미룬" 보안 습관 때문입니다.
방어의 핵심은 고가의 솔루션보다 코드 레벨의 기본기, 즉 Prepared Statement·출력 이스케이프·권한 검증·보안 헤더 4가지를 철저히 지키는 것입니다. 지금 당장 할 수 있는 첫 행동은 바로 OWASP ZAP으로 본인 서비스를 한 번 스캔해보는 것입니다. 결과가 놀라울 수 있습니다.
여러분의 서비스에서 가장 먼저 점검한 취약점은 무엇인가요? 또는 실제 경험한 보안 이슈가 있다면 댓글로 공유해 주세요! 다음 포스팅에서는 "모의해킹(Penetration Testing) 입문 — Burp Suite 실전 활용법"을 다룰 예정입니다. 기대해주세요! 🔐
댓글
댓글 쓰기