😱 웹 애플리케이션의 오랜 숙적: OWASP A1:2017 - 인젝션(Injection) 파헤치기

안녕하세요! 👋 사이버 보안의 세계를 탐험하는 여러분, 오늘은 웹 애플리케이션 보안의 교과서, OWASP Top 10의 단골손님이자 2017년 버전에서 당당히 1위를 차지했던 A1: 인젝션(Injection)에 대해 깊이 알아보겠습니다.

"인젝션이 뭐길래 그렇게 위험하다고 할까?" 궁금하셨다면, 오늘 포스트로 그 궁금증을 시원하게 해결해 드릴게요! 💉

 

https://github.com/OWASP-Seoul/owasp/raw/master/OWASP%20Project/OWASP_Top_10-2017-ko.pdf

 

---

🤔 인젝션(Injection)이란 무엇인가요?

인젝션 공격은 아주 간단한 개념에서 출발합니다. 바로 "신뢰할 수 없는 사용자 입력 데이터를 코드나 명령어의 일부로 해석하게 만드는 것"이죠.

개발자는 사용자가 아이디, 비밀번호, 검색어처럼 정해진 '데이터'만 입력할 거라고 예상하지만, 공격자는 그 입력창에 교묘하게 숨겨둔 '명령어'를 주입(Injection)합니다. 만약 애플리케이션이 이 악의적인 명령어를 제대로 거르지 못하고 그대로 실행해버리면, 공격자는 시스템을 마음대로 주무를 수 있게 되는 끔찍한 상황이 발생합니다. 💥

마치 주사기(공격자)가 애플리케이션(혈관)에 악성 코드(약물)를 주입해 시스템 전체를 감염시키는 것과 비슷하다고 생각하면 이해하기 쉬워요.

---

대표적인 인젝션 공격의 종류들

A1:2017 - 인젝션은 한 가지 공격 기법을 말하는 것이 아니라, 다양한 유형의 공격을 포함하는 광범위한 카테고리입니다. 대표적인 공격들을 살펴볼까요?

1. SQL 인젝션 (SQL Injection)

가장 유명하고 파급력이 큰 인젝션 공격입니다. 데이터베이스와 통신하는 SQL 쿼리문에 악의적인 구문을 삽입하는 방식이죠.

예시: 허술한 로그인 시스템 🧑‍💻

개발자가 의도한 정상적인 SQL 쿼리는 다음과 같습니다.

SELECT * FROM users WHERE username = '사용자입력ID' AND password = '사용자입력PW';

 

하지만 공격자가 ID 입력란에 ' OR '1'='1 이라고 입력하면 어떻게 될까요?

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '...';

 

'1'='1'은 항상 참(True)이기 때문에, WHERE 절의 조건이 무조건 참이 되어버립니다. 결국, 비밀번호를 입력하지 않아도 모든 사용자의 정보가 조회되거나, 첫 번째 사용자인 관리자 계정으로 로그인이 될 수 있습니다. 😱

• 피해: 데이터베이스 정보 유출(개인정보, 금융정보 등), 데이터 변조/삭제, 인증 우회, 시스템 장악

2. OS 커맨드 인젝션 (OS Command Injection)

애플리케이션이 운영체제(OS)의 명령어를 실행하는 기능이 있을 때, 사용자 입력값을 통해 악의적인 시스템 명령어를 주입하는 공격입니다.

 

예시: 파일 다운로드 기능 📁

웹사이트에 특정 파일을 다운로드하는 기능이 있고, 파일 이름을 파라미터로 받는다고 가정해 봅시다.

https://example.com/download?file=report.pdf

 

만약 공격자가 file 파라미터에 report.pdf; rm -rf / 와 같은 값을 넣는다면? (;는 명령어 구분자)

download_script("report.pdf; rm -rf /")

 

시스템은 정상적인 파일 다운로드 명령어에 이어, 모든 파일을 삭제하라는 rm -rf / 명령어를 실행하게 될 수 있습니다. 상상만 해도 아찔하죠?

• 피해: 시스템 파일 및 데이터 유출/삭제, 악성코드 설치, 시스템 전체 장악

3. 그 외 다양한 인젝션 공격들

• LDAP 인젝션: LDAP(Lightweight Directory Access Protocol) 쿼리에 악의적인 구문을 삽입하여 디렉터리 서비스 정보를 탈취하거나 변조합니다.
• XPath 인젝션: XML 문서의 특정 부분을 찾기 위해 사용하는 XPath 쿼리에 악의적인 구문을 삽입하여 XML 데이터에 무단으로 접근합니다.
• NoSQL 인젝션: MongoDB와 같은 NoSQL 데이터베이스의 쿼리문에 악의적인 구문을 삽입합니다.

---

🛡️ 인젝션 공격, 어떻게 막을 수 있을까요? (대응 방안)

다행히도 인젝션 공격은 올바른 개발 습관과 보안 원칙을 통해 효과적으로 방어할 수 있습니다.

1. 준비된 구문 (Prepared Statements) 사용이 최우선!

SQL 인젝션을 막는 가장 확실하고 강력한 방법입니다. **매개변수화된 쿼리(Parameterized Queries)**라고도 불립니다. 이 방식은 SQL 쿼리의 구조(틀)를 먼저 컴파일 해놓고, 사용자 입력값은 나중에 데이터로만 전달합니다.

사용자 입력값이 절대 '코드'로 해석될 여지를 주지 않고, 오직 '데이터'로만 취급되도록 강제하는 원리입니다.

 

안전한 코드 예시 (Python):

# '?' 자리에 user_id 값이 안전하게 데이터로만 삽입됩니다.
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))

2. 입력값 검증 (Input Validation)

사용자가 입력한 데이터가 우리가 예상한 형식, 타입, 길이, 문자셋에 맞는지 항상 서버 측에서 검증해야 합니다.

• 화이트리스트 방식: 허용할 문자와 형식의 목록을 만들어두고, 목록에 있는 것만 허용합니다. (ex: ID는 영문/숫자만, 길이는 8~16자)
• 블랙리스트 방식: 위험한 문자(', ;, -- 등) 목록을 만들어 차단합니다. 하지만 우회 기법이 많아 완벽하지 않으므로 화이트리스트 방식이 더 안전합니다.

3. 특수 문자 이스케이프 (Escaping)

사용자 입력값에 포함될 수 있는 SQL 쿼리나 시스템 명령어에서 특별한 의미를 갖는 문자들(예: ' " ; -- 등)을 일반 문자로 취급하도록 변환(이스케이프)하는 방법입니다. 하지만 이 방법만으로는 부족하며, 준비된 구문을 사용하는 것이 근본적인 해결책입니다.

4. 최소 권한 원칙 (Principle of Least Privilege)

데이터베이스 계정이나 애플리케이션 실행 계정에 꼭 필요한 최소한의 권한만 부여해야 합니다. 예를 들어, 웹사이트의 일반 사용자가 사용하는 DB 계정에는 데이터를 조회(SELECT)하는 권한만 주고, 수정(UPDATE)이나 삭제(DELETE) 권한은 주지 않는 것입니다. 이렇게 하면 만에 하나 인젝션 공격이 성공하더라도 피해를 최소화할 수 있습니다.

---

📈 2017년 이후의 이야기

인젝션은 2021년에 발표된 OWASP Top 10에서는 3위로 순위가 다소 내려왔습니다. 이는 최신 개발 프레임워크들이 SQL 인젝션 등을 방어하는 기능을 기본적으로 제공하고, 개발자들의 보안 인식이 높아졌기 때문입니다. 하지만 XSS(Cross-Site Scripting)가 인젝션 카테고리에 통합되는 등 여전히 강력하고 위험한 위협임에는 변함이 없습니다.

보안은 '한 번 설정하고 끝'이 아니라, 끊임없이 변화하는 위협에 맞춰 지속적으로 학습하고 방어 체계를 개선해나가야 하는 과정이라는 점을 꼭 기억해주세요! 👨‍💻👩‍💻