SQL Injection과 XSS (Cross-Site Scripting)

사실 백엔드 공부를 하면서 인프라 단에서만 보안과 해킹 방어를 조심했지만, 어플리케이션 단에서의 보안은 크게 알아본 적은 없었던 것 같다. 프레임워크에서 기본적인 설정은 전부 되어 있어였지만, 알고 있지만 안하는 것이 아니라 아예 모르는 것은 문제가 될 수 있을 것 같다. 최근 참여한 모 기업의 채용 필기 테스트에서 이와 관련된 문제가 나왔었고, 최근 진행 중인 프로젝트에서 서버 리드가 UUID/ULID를 DB PK로 사용하는 것을 보고 찾아보던 중 이와 연관되어 한 번 정리해보고자 한다.

 

---

SQL Injection

워낙 유명해 다들 한 번쯤은 들어봤을텐데, 임의의 SQL문을 주입하고 실행되게 하여 데이터베이스가 비정상적인 동작을 하도록 조작하는 행위이다. 다양한 공격법이 있지만, 가장 대표적인 Error based SQL Injection에 대해 간단히 알아보자.

 

 

공격 방법

Error based SQL Injection은 논리적 에러를 이용한 방법으로 가장 많이 쓰이는 기법이다. 아래 사진은 로그인 시 사용하는 SQL 예문이다. 입력값에 대한 검증이 없어 악의적인 사용자가 공격하기 위한 SQL 구문을 주입했다고 가정해보자.

24'-- 라는 구문을 주입함으로써, 24' 부분이 id가 24인 조건절을 완성하고 -- 부분이 뒤의 password 검증 조건절을 주석처리하여 24번 유저의 개인 정보가 노출되는 것이다. 만약 password 컬럼이 암호화되어 있지 않다면, 계정까지 탈취될 것이다.

 

방어 방법

1. 입력 값에 대한 검증 : 서버 단에서 사용자의 입력 값을 검증하고 공격을 사전에 차단한다. 블랙리스트 기반으로 검증하게 되면 수많은 차단리스트를 등록해야 하고 하나라도 빠지면 공격에 성공하게 되기 때문에, 화이트리스트 기반으로 검증해야 한다.

 

2. Prepared Statement 구문 사용 :  DBMS가 SQL 구문을 미리 컴파일하여 실행계획을 생성하고, 파라미터만 입력받아 바로 실행한다. 즉, SQL String을 Java 단에서 들고 있다가 입력값을 치환하는 것이 아니라 DB에 미리 실행계획을 생성해두고 파라미터 값만 변경하는 것이므로, 사용자 입력값이 SQL 실행 계획을 변경시키지 못하는 것이다. 위의 사진 예시에서는 24'-- 라는 id를 찾게 될 것이다.

 

3. Error Message 노출 방지 : 공격자가 SQL Injection을 수행하기 위해서는 시행착오를 겪으며 데이터베이스의 정보(테이블명, 컬럼명 등)을 찾아내야 한다. 따라서 에러 핸들링을 통해, 데이터베이스 에러 발생 시 에러가 발생한 쿼리문과 에러 메시지를 사용자에게 노출시키지 않음으로써, 공격자가 데이터베이스 정보를 알기 힘들게 만든다.

 

스프링에서는?

스프링에서는 JPA 정확히는 ORM 구현체인 Hibernate가 Prepared Satement 구문으로 SQL을 실행시키고 있다.

https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core/src/main/java/org/hibernate/engine/jdbc/internal/StatementPreparerImpl.java

 

단, MyBatis는 일반 Statement도 함께 쓰고 있으므로 주의가 필요하다. 쿼리문에 ${}를 사용한다면 Statement, #{}를 사용한다면 Prepared Statement를 사용하는 것이다.

 

 

---

XSS (Cross-Site Scripting)

SQL Injetion은 SQL을 웹에 주입해 서버를 공격하는 것이라면, XSS는 스크립트를 웹에 주입해 사용자를 공격하는 것이다. XSS에는 세 가지 공격 기법이 있다.

 

 

공격 방법

1. Stored XSS : XSS에 취약한 웹 사이트의 게시판에 공격 스크립트를 포함한 게시글을 업로드한다. 웹사이트 사용자가 해당 게시글을 클릭하면, 공격 스크립트가 실행되기 시작한다.

 

2. Reflected XSS : 공격 스크립트가 포함된 URL을 사용자가 접속하게 유도한다. 해당 URL로 웹 사이트에 접속할 경우, 사용자의 브라우저가 서버로부터 정상 HTML을 받고 URL에 포함된 공격 스크립트를 문자열로 추출해 함께 실행하는 과정에서 공격 스크립트가 실행된다.

 

3. DOM XSS :  공격 스크립트가 포함된 URL을 사용자가 접속하게 유도한다. 해당 URL로 웹 사이트에 접속할 경우, 서버가 URL 파라미터를 검증없이 응답 HTML에 담고 사용자의 브라우저는 응답받은 비정상 HTML을 실행하는 과정에서 공격 스크립트가 실행된다.

https://junhyunny.github.io/information/security/dom-based-cross-site-scripting/

 

방어 방법

입력값과 출력값에 검증을 통해 방어할 수 있다. 입력값을 검증할 때는 공격 스크립트 실행에 사용되는 특수문자를 필터링하거나 HTML 엔티티로 인코딩할 수 있다. (HTML Entity: < -> &lt; , > -> &gt; 와 같이 특수문자를 다른 포멧으로 변환) 출력값을 검증할 때는 X-XSS-Protection 헤더나 CSP(Content Security Policy)헤더를 추가하여 브라우저가 XSS 공격을 감지될 경우 차단하도록 할 수 있다. 최신 브라우저는 이런 동작이 디폴트로 작동한다.

 

스프링에서는?

이는 WAS가 아니라 WA에서 신경써야할 부분이다. 하지만 스프링 MVC 등을 사용할 때는 신경써야 하고, 백엔드 개발자로서 프로젝트를 망라하는 네트워크 정도는 알아야 할 것 같아서 함께 정리해봤다.