SQL Injection은 웹 애플리케이션이 사용자 입력을 제대로 검증하지 않고 SQL에 그대로 넣을 때 발생하는 대표적인 취약점이에요.
정보보안기사에서 거의 필수로 나오는 주제라, 공격 방법 + 대응방안을 같이 외우면 훨씬 기억에 잘 남습니다.
1. SQL Injection 대표 공격 방법 정리
| 구분 | 공격 방법 | 설명 (쉽게) | 예시 입력 / 쿼리 |
|---|---|---|---|
| 1 | 기본 형태(클래식) | 입력값에 ' 나 OR 1=1 같은 조건을 넣어서 WHERE 조건을 항상 참으로 만들기 |
로그인 ID 입력창에: admin' OR 1=1 --→ SELECT * FROM users WHERE id='admin' OR 1=1 --' AND pw='...'; |
| 2 | 인증 우회 | 비밀번호 확인 없이 조건을 무력화해서 로그인 통과 | ID: admin' -- / PW: 아무거나→ 뒤쪽 비밀번호 조건이 주석 처리되어 로그인 성공 |
| 3 | 에러 기반 (Error-based) | 일부러 문법 오류 등을 발생시켜 DB 에러 메시지에 테이블/컬럼 정보를 노출 | order by 100 -- 처럼 존재하지 않는 컬럼 번호 사용 → 에러 메시지로 컬럼 수 추정 |
| 4 | UNION 기반 | UNION SELECT를 사용해 원래 쿼리 결과 + 공격자가 원하는 결과를 합쳐서 출력 |
…' UNION SELECT username, password FROM users -- |
| 5 | 블라인드 – 논리(Boolean) 기반 | 화면에 에러가 안 떠도, 참/거짓에 따라 페이지 반응 차이를 이용해 한 글자씩 추출 | 1' AND substring(db_name(),1,1)='t' -- 참/거짓에 따라 응답 달라짐 |
| 6 | 블라인드 – 시간(Time) 기반 | 응답 시간을 이용해 정보 추출, SLEEP() 같은 함수 이용 |
1' IF(substring(user(),1,1)='r', SLEEP(5), 0) -- 응답 지연 여부로 글자 추측 |
| 7 | 스토어드 프로시저 악용 | DB에 정의된 프로시저/함수를 호출해 파일 읽기, 시스템 명령 실행 등까지 노리는 공격 | MSSQL에서 xp_cmdshell 호출 등 |
| 8 | 2차(Stored) SQL Injection | 악성 입력이 먼저 DB에 저장되었다가, 나중에 다른 쿼리에 다시 사용될 때 터지는 유형 | 게시판 글 제목에 악성 문자열 저장 → 통계 쿼리에서 그대로 사용되어 공격 발생 |
2. SQL Injection 대응 방안 정리
| 구분 | 대응 방법 | 핵심 포인트 (쉽게) | 정보보안기사 키워드/비고 |
|---|---|---|---|
| 1 | Prepared Statement / 파라미터 바인딩 | SQL을 미리 컴파일하고, 값은 나중에 변수처럼 넣기 → 값이 쿼리 구조를 바꾸지 못함 | ?, :id 같은 바인딩 사용. 가장 중요한 1순위 방어 |
| 2 | 입력 검증(화이트리스트) | 허용할 문자/패턴만 통과시키기. 숫자만 필요하면 정수만 허용 | 블랙리스트보다 화이트리스트 우선. 길이 제한도 함께 적용 |
| 3 | ORM 사용 시 쿼리 빌더 활용 | ORM이 제공하는 쿼리 빌더/파라미터 기능을 쓰고, 문자열로 직접 쿼리 조합하지 않기 | JPA, Hibernate, MyBatis 등 사용 시 동적 SQL 직접 문자열 합치기 금지 |
| 4 | 최소 권한 원칙 | 웹 앱이 사용하는 DB 계정에 필요한 권한만 부여 (SELECT/INSERT 등 최소) | root 계정으로 서비스 돌리지 말 것. DROP/ALTER 권한 제한 |
| 5 | 에러 메시지 제한 | DB 에러(테이블명, 컬럼명, 경로)가 사용자에게 그대로 보이지 않게 공통 에러 페이지로 처리 | “시스템 오류가 발생했습니다” 정도만 노출, 상세 에러는 서버 로그로만 |
| 6 | 입력 값 인코딩/이스케이프 | 불가피하게 동적 SQL이 필요할 때는 ', " 등 특수문자를 DB 전용 이스케이프 함수로 처리 |
근본 해결책은 아니지만, 보조 방어 수단으로 사용 |
| 7 | WAF / 보안 게이트웨이 | 웹 방화벽(WAF)을 통해 **SQL 패턴(OR 1=1, UNION SELECT 등)**을 탐지·차단 | 정보보안기사에서 자주 나오는 시그니처 기반 탐지 예시 |
| 8 | 정기적인 보안 점검 | 모의 해킹, 취약점 스캐너(DAST/SAST)로 SQLi 취약점 사전 발견 | 개발/운영 단계 모두에서 주기적 점검 필수 |
| 9 | 보안 코딩 가이드 & 교육 | 개발자에게 **보안 코딩 원칙(입력 검증, 파라미터 바인딩)**을 교육하고 코드 리뷰에 반영 | “보안은 개발 단계부터”라는 시험·실무 공통 키워드 |
3. 정리
SQL Injection은 사용자가 입력한 값이 그대로 SQL 문에 붙으면서
“데이터 조회 → 수정/삭제 → 시스템 장악”까지 이어질 수 있는 치명적인 취약점입니다.
공격 기법은 다양하지만 결국 핵심은 쿼리 구조가 사용자 입력에 의해 바뀌지 않게 하는 것입니다.
따라서 정보보안기사 공부에서는
Prepared Statement(파라미터 바인딩),
입력 값 검증(화이트리스트),
DB 최소 권한,
에러 메시지 통제와 WAF
를 세트로 외워 두면, 이론 문제는 물론 실무 보안 코딩 감각까지 같이 잡을 수 있습니다.
