SQL Injection이 가능한 대상은 parameter를 서버로 요청하고 받는 곳에서 SQL Injection이 일어 날 수 있다.
단순 게시판의 검색, 로그인창과 같은 input 태그의 사용되는 곳 뿐만이 아니다.
CASE 1 쿠키
마이 페이지를 요청하는 request와 response다.
mypage를 요청 할 때 GET Method로 요청을 진행하지만 쿼리 파라미터에 값은 보이지 않지만 cookie에 user라는 항목을 볼 수 있다.
해당 페이지는 cookie에 있는 user 항목으로 mypage를 불러온다고 유추 할 수 있으며 해당 쿼리는
select 컬럼 from 테이블 where 유저컬럼 = '___쿠키값___' 이라고 유추할 수 있다.
이를 통해 SQL Injection이 가능한지 확인해보자
3가지 방법으로 테스트를 진행해보자
1. ABCD
2. ABCD' and '1'='1
3. ABCD' and '1'='2
SQL Injection이 가능하다면 1번케이스와 2번케이스는 동일한 값이 나오며 3번 케이스에서는 값이 나오지 않게 될 것이다.
CASE 1
CASE 2
CASE 3
위의 결과로 1,2번의 케이스는 두번 째 항목에 notthing here값이 나왔으나 3번 케이스의 경우 빈 칸이 나왔다.
첫 번째 항목의 경우 값 false임에도 출력이 되는 것을 보아 DB에서 user 값을 가져오는 것이 아닌 Cookie의 값을 그대로 사용 함을 추측해 볼 수 있다.
CASE 2 where 절의 컬럼
게시판의 검색을 작성자, 제목, 내용으로 검색 할 수 있다.
request를 보면 option_val=title 확인가능
옵션이 title로 념어가는 것을 볼 수 있다.
만약 SQL이 가능 하도록 구성되어 있다면
select {컬럼} from {테이블} where {option_val} like '{board_search}'
의 형식으로 되어 있을 것이다.
option_val에 SQL Injection을 한다면
where 1=1 and title like '%1%' 형태로 넣어 볼 수 있을 것이다.
case 1: title like '%1%'
SQL Injection을 시도 하지 않은 결과:
case 2: 1=1 and title like '%1%'
option_val=1=1 and title:
case 3:1=2 andtitle like '%1%'
option_val=1=2 and title
위와 같이 직접 입력하지 않는 부분이라도 SQL Injection이 가능 한 것을 확인 할 수 있다.
CASE 3 order by
sort 부분을 보자
request에 sort가 추가 된 것을 확인 할 수 있다.
sort를 사용한다는 것으로 order by 구문이 사용됨을 유추 할수 있으며 쿼리는 아래와 같을 수 있다.
select {컬럼} from {테이블} where {option_val} like '{board_search}' order by {sort}
order by에 SQL Injection을 사용해보자
case 1: order by title
sort 부분을 보자
case 2: order by (select 1 from dual union select 2 from dual where 1=1)
order by에 select 구문으로 1, 2 두개의 row가 생기기 때문에 문법 오류가 발생하므로 결과가 나오지 않는다.
이를 통해 Blind SQL Inection이 가능하다.
Ex (select 1 from dual union select 2 from dual where length(database()) = 11) -> 확인 결과 db의 길이는 11 이다.(참 조건일 경우 화면에 아무 결과 없음)
case 2: order by (select 1 from dual union select 2 from dual where 1=2)
거짓 조건의 경우 화면에 결과가 출력된다.
결론
SQL Injection은 단순 화면에서 입력가능 한 부분이 아니라 SQL로 전달 되는 모든 파라미터에서 가능 할 수 있다.
SQL Injection의 대처방법
SQL Injection의 대처방법은 매우 간단하다. prepared Statement를 사용하면 된다.
prepared Statement란 SQL 질의문을 미리 컴팡일링하여 캐시에서 사용하도록 하는 방식이다.
이를통해 SQL 질의문을 전달 받을 때마다 컴파일 할 필요가 없기에 속도 향상에 이점이 있다
부가적으로 입력받는 parameter를 제외하고 모두 컴파일링을 진행 해두었기 때문에 추가적인 SQL Injection이 들어와도 동작하지 않게된다.
Ex )
select * from user where userName =(컴파일)=> 10101010111010101010 ? =(파라미터 입력)=> 10101010111010101010 '팥들었슈' and '1'='1'
위는 예시일 뿐이며 정확이 이와 동일하게 동작하지는 않는다.
prepared Statement를 사용할 수 없는 SQL 구문이 있다.
order by 구문이다.
동적은 order by를 사용하고 SQL Inection을 방지하려면 입력받는 order by 구문을 화이트리스트로 관리하는 것이 적절하다.
if (sortWhiteList.include(request.getSort())) {
// 입력 받은 sort가 화이트 리스트에 있는 경우 진행
} else {
// 입력 받은 sort가 화이트 리스트에 없다면 기본값으로 세팅
request.setSort("기본값");
}
PS. 구문해석하기
case 1: sotingAd=,(case+when+ascii(substr((select+user+from+dual),1,1))=0+then+1+else+(1/0)+end)
case 2: page=1&board_id=&sorting=A.REG_DT&sotingAd=ASC;if+substring((select%20user_name()),1,1)=%27a%27+waitfor+delay+%270:0:1%27&startDt=&endDt=&keyword=
case1은 request의 sorting에 넣은 값으로 보여지며 +는 url encoding의 space이다.
sql에 들어가는 구문으로 변경해본다면
select * from user order
by Ad, (case when ascii(substr((select user from dual),1,1))=0 then 1 else (1/0) end)
로 변경되어 SQL에 들어가게 되며 Ad, 뒷부분이 injection이 된다.
'user' 문자열을 1,1로 substr 하였기 때문에 나오는 값은 u
u를 ascii로 변환하면 117이며 117 = 0 은 false 이기 때문에 1/0이 실행되지만 0으로 값을 나눌 수 없기 때문에 에러가 발생
즉 참이라면 화면의 결과가 나오고 거짓이라면 에러가 발생하기 때문에 화면에 값이 표출 않는다. 즉 blind SQL을 사용하기 위한 구문
case2을 url decode 하면
if substring((select user_name()),1,1)='a' waitfor delay '0:0:1'&startDt=&endDt=&keyword=
sql Injection 되는 부분은 order by A.REG_DT ASC 구문 이후가 될 것이다.
select * from user order
by order by A.REG_DT ASC;
if substring((select user_name()),1,1)='a' waitfor delay '0:0:1'
