Prepared Statement

강의를 듣고 정리한거 이후 수정할 예정임

 

 

Prepared Statement는 SQL Injection을 막는 방법 중의 하나이다.

SQL Injection을 막을 때는

1. Prepared Statement

2. 입력값 검증 로직(입력 타입에 따른)

3. 입력 길이 제한

으로 시큐어 코딩을 적용한다고 한다. 보통 1이 우선순위가 제일 높고 2,3이 보조하는 구조임

 

그럼 Prepared Statement 에 대해 알아보자

 

SQL에 쿼리를 날리고 실행되는 구조는 다음과 같다.

 

1. 구문 분석 및 정규화

2. 컴파일

3. 트리 최적화

4. 캐시

5. 실행

 

문자열로 쿼리를 적당히 만들어 두고 execute하면 statment이다. 1,2,3,4,5 를 바로 간다.

prepared statement는 3까지 간다. 사용자의 입력을 ?로 받는데 이를 placeholder라고 한다.

placeholder는 바인딩을 통해서 prepared statement에 붙는다. 이는 4번에서 이루어진다.

컴파일이 이미 끝난 상태니까 placeholder에 뭐가 들어오든 SQL 구문으로서 처리되지는 않는다.

 

아래는 강의하면서 정리한 내용이다.

 

# Prepared Statement는 왜 안전한가?

* 그냥 string으로 쿼리문 작성하고 execute => 위험

 -> 사용자의 입력도 같이 컴파일 가능함. SQL Injection 발생!!!

* prepared statement로 쿼리문 만들어두고 execute => 비교적 안전

SQL 구문 실행 순서
1. 구문 분석 및 정규화
2. 컴파일
3. 쿼리 최적화
4. 캐시 
5. 실행

String keyword = request.getParameter("keyword");
String query = "select * from board where content like ?";

(이때 ?은 placeholder : 메타문자같은거)

pstmt = conn.prepareStatement(query);
pstmt.setString(1, "%"+keyword+"%"); // 입력값 바인딩 해서 placeholder 치환

set*(setString, setInt 등등)을 통한 바인딩은 캐시 단계에서 실행됨
prepared statement는 캐시단계에 있으므로 사용자가 뭔 값을 때려 박아도 걍 순수 데이터로 취급됨. SQL 구문으로 해석이 안된다는거

이미 쿼리로 해석되는 부분은 pstmt. 이건 이미 쿼리 최적화 까지 끝났음. placeholder에서 어떤 값이 들어가도 구문으로 안들어간다는거!

@@placeholder를 query에 두고, prepareStatement(query), setString, setInt등을 통해 바인딩해주는게 안전

만약 query에 사용자 입력을 그대로 박는다면 컴파일에 사용자 입력 들어감 => SQL Injection 발생!

Q. 테이블, 컬럼명을 사용자 입력에서 받는다면?
A. prepared statment 사용이 불가함. 그냥 statement로 처리해줘야함
->placeholder 는 테이블, 컬럼명을 처리하지 못하고 순수하게 사용자의 데이터로 예상되는 것만 처리 가능. e.g) 검색어
왜냐하면 placeholder는 나중에 set* 을 통한 바인딩을 해줘야 하기 때문임

Q. 그럼 테이블, 컬럼명을 placeholder 로 두고 set* 을 써서 바인딩하면 안돌아감?
A. 그래도 안돌아감
-> set*을 통한 바인딩은 캐시 단계. 즉 prepared statement가 이미 컴파일, 쿼리 최적화를 맞췄어야 함
그런데 테이블, 칼럼등을 placeholder에서 둔 상태라면 컴파일, 쿼리 최적화부터가 안됨(의사 결정 트리 구성이라던가 구문 분석이라던가 안됨)

->그래서 캐시로 가기도 전에 prepared statement를 만드는 것 부터가 실패함!