[기록일지] 📚 08주차 (💉SQLi - Find Vuln Point / 대응 방안)

SQL Injection Advanced Ver.

SQL Injection Vuln Point

앞서서 공부했던 SQLi를 보면 '어디에(Where)', '어떤 방법으로(How)' 공격하면되는지를 알려준 상태에서 진행되었다. 하지만 실무에서는 이렇게 대놓고

"여기가 이런 취약점이 있으니 뚫으시면 됩니다.~"

하고 친절하게 알려주지 않을 것이다.

그래서 공부할 때부터 취약점을 찾는 방법을 연습해야 한다.

우선적으로 서비스를 이용해보고, 그 과정에서 이동되는 페이지와, 오고가는 패킷(Packet)을 분석해볼 필요가 있다. 이것이 중요한 이유는 다음과 같다.

일단. 서비스를 직접 이용해보지 않는다면? 어떻게 구동되고 있는지 알 길이 없다. 어떤식으로 이루어져 있는지 알아보기 위해서는 직접 이용해보는게 BEST 이다.

그리고 우리는 한가지 착각을 하고 있을 수 있다는 사실을 인지 해야 한다.

 

사용자 입력

'사용자 입력' 이라고 하면 일반적으로 실제로 입력 창이 노출되어있는 입력 가능한 창만을 생각하지만 그렇지 않다.

파라미터(params)가 존재하는, DB에게 SQL 질의문이 사용되는 곳 이라면 어디든지 취약점이 될 수 있다는 사실이다.

(이 Data는 DB에서, SQL 질의문을 사용하는 구나! 하는 것을 Catch할 필요가 있다는 것이다.)

 

파라미터

데이터가 서버에서 입력을 기반으로 DB에서 SQL 질의문을 통해 데이터를 가져와서 출력을 해줬구나! 함을 인지하여야 한다.

SELECT / WHERE / LIKE 등을 기본적으로 인지해야하고, 이를 머리속에서 바로바로 그려지도록 해야한다.

 

WHERE문이 서버에서 어떤식으로 구성되어있는가에 대하여 생각해보는 것이 중요하다.

 

and '1' 

'의미 없는 값, 하지만 결과에는 지장을 주지 않는 값' 을 추가해봄으로써 SQL Injection이 가능한지의 여부를 확인하는 것이다.

WHERE user_id like '%___%' and '1'

위와 같은 방식으로 and'1' 을 추가해 봐야 한다.

gear / gear%' and '1%'='1

gear 를 입력했을 때와 gear%' and '1%'='1 입력한 경우의  두 결과가  같다면 우리는 SQL Injection이 가능하다고 판단할 수 있다는 것이다.

(and '1%'='1 : 의미 없는 값이지만, LIKE 문의 특성상 %와 ' 의 개수를 맞춰주어 결과에는 지장을 주지 않도록 입력하는 것이 관건이다.)

 

---

사용자의 입력 값은 화면에서 글자를 입력하는 칸만 있는 것이 아니다! 
어떤 값을 이용하는지 / 어떤식으로 데이터가 필터링 되는지 / 어떤 조건에 걸려서 동작이 되는지 를
확인하기 위해 Burp Suite을 활용해야 한다는 것이다.

취약점을 찾으려면 그냥 때려 넣어보는 것이 아니라,
해당 프로그램, 코드가 어떤식으로 동작하고 돌아가고 있는지를 파악해야 취약점을 찾을 수 있다는 것이다 !!

 

리버스 엔지니어링의 중요성을 생각해야 한다.

---

어떤 SQL을 사용하는가?

 

무언가 시도해 보기 전에 어떤 SQL을 사용하고 있는지 생각해보는 것이 우선이다.

회원가입은 insert를 쓰겠지.
insert into table() value()

"지금 이 파라미터가 SQL 문구의 어디에 들어가서 동작할 것인가." 를 생각해봐야한다. (실제로 사용해보면서 테스트하자.)

마이페이지
select ~~ where user_id = '____'


검색 기능
option_val=title&board_result=?
select where (option_val) like '%user%'

Burp Suite에서 Session을 보면서 확인해보는 것이 중요하다.

cookie
user-Agent

쿠키에서도 SQL Injection이 가능하다는 것을 인지 해야한다.

 

(+) 생각을 해보기

지금 내가 집어 넣는 데이터가 서버에 어떻게 들어가서 동작하고 있구나!

페이로드(Payload)를 짜고 눈으로 확인해봐야한다.

해킹 툴은 SQL Query를 추리하지는 못한다. 즉 우리가 고민해서 SQL Query를 확인해봐야한다.

(마구잡이로 때려넣다보면 방화벽에 차단된다.)

 

모의해킹 - 주석

모의해킹 시에 웬만하면 주석은 쓰지 않는 것이 좋다.

실제로 만나는 대형 사이트의 경우 질의문이 여러줄로 구성되어 있으므로 주석으로 제대로 동작하지 않는 경우가 많다.

(주석이 어디에서 먹히는지 감이 안오기 때문에 최대한 주석을 사용하지 않고 해결하려고 해야한다.)

 

SQL 삽입 위치

'1'='1' and title (참)
'1'='2' and title (거짓)

위와 같이 참/거짓을 앞쪽(반대쪽)에도 넣어줄 수 있다는 것을 인지해야 한다.

어떤 데이터냐에 따라 어느 위치에 넣어줘야하는지를 생각해봐야 한다.

---

취약점 발생 위치

1. cookie, HTTP 요청 헤더
2. column
3. order by 절 SQL Injection (가장 취약점이 많이 일어나는곳)

order by 절

sort -> order by (order by 절의 SQL Injection)

(참/거짓 조건을 어떻게 쑤셔 넣을까?!)

case when

SQL 질의문의 if 문 (만약에) 역할

case when (조건)  then (참일 때) else (거짓일 때) end
case when (1=1) then 1 else 2 end

위와 같은 방식으로 사용하게 된다.

-> case when (1=1) then username else title end  (참)
-> case when (1=2) then username else title end  (거짓)

정렬의 방식에 따른 참/거짓

정렬의 방식에 따라 다르게 정렬되는 것을 이용하여 참인 경우와 거짓인 경우의 정렬방식을 다르게하여 참/거짓을 판단 가능하도록 할 수 있다. (이 방식은 정렬을 위한 column을 알아야 사용이 가능하다.)
(참 과 거짓을 구분하는 조건을 넣어줄 수 있기 때문에 Blind Injection이 가능해진다.)

하지만 일반적으로 column명을 정확히 알지 못하는 경우가 더 많다.

그럴 경우 아래와 같이 일부러 에러를 발생시킨다.

에러 발생에 의한 참/거짓

case when (1=1) then 1 else (select 1 union select 2) end

행이 2개가 되어버리므로 order by행이 2개?! value가 아니라 matrix를 출력하라는 것이 되어버리므로 출력이 나오지 않는다.

order by 절에 select 1 이라고 넣어준다면? select 1 과 1 을 넣어준 것은 같다.

그런데 만약 select 1 union select 2 을 넣어준다면? 행이 하나만 나와야하는데 matrix 가 나오게 되어 구조체가 나온다는 것이다. 따라서 실행중에 에러가 발생하여 아무것도 출력되지 않게된다는 것을 이용하는 것이다.

select 1 union select 2 where (1=1)

참인 조건을 넣으면 둘다 참이므로
->  select 1 union select 2 가 되어 아무 출력이 되지 않는다. 

select 1 union select 2 where (1=2)

하지만 거짓인 조건을 넣으면 뒤가 거짓이므로
-> select 1 가 되어 (뒷부분이 거짓이므로 사라진다.) 출력이 나온다.

일부러 에러를 유발하여 SQL Injection Point를 찾는 것이다.

참인 조건과 거짓인 조건의 결과가 같다면?! (참 거짓의 결과가 구분이 안되는 경우 or 에러를 유발해야 할 때) 이런 경우 우리는 Blind SQLi를 활용할 수 없다. 하지만 에러를 유발한다면?

에러가 난다? / DB Error 가 난다?

SQL Injection이 가능한지 확인하기 위해 에러를 유발 시켜보는 것이다.

user = user 'and'1'='1
user = user 'and'1'='2

두 값의 결과가 같다면? 아래와 같이 에러를 유발 시켜본다.

user = user 'and (select 1 union select 2 where (1=1)) and '1'='1
user = user 'and (select 1 union select 2 where (1=2)) and '1'='1

이렇게 참/거짓을 에러로서 확인하여 SQL Injection을 시도할 수 있다.

에러를 유발하는 가장 좋은 방법

error 유발

select 1 union select 2

---

SQLi의 대응 방안

SQL Injection 대응 방법

1. Prepared Statement

대응 방법 1. prepared statement

SQL 질의문을 미리 컴파일 한다는 것이다. (SQL 질의문을 미리 준비한다.)

-> 미리 기계어로 바꾸어 놓는다는 것으로,  '?'로 입력값만 구멍을 뚫어놓으므로서 질의문 쿼리가 변할 수 없는 구조가 되어버려 SQL Injection이 원천적으로 차단되어 문자 그대로로를 받아오는 효과를 가지게 된다.

사실 Prepared Statement는 속도를 빠르게 하기 위해서 만들어졌는데, SQL Injection을 원천적으로 막는 효과를 가져왔다.

이에 대한 우회는 전! 혀! 불가능! 하다고 한다.

 

SQLi를 배우는 이유?!

prepared statement를 이용하는 경우 우회가 전혀! 절대! 불가능하다면?

그럼에도 SQL Injection을 배우는 이유는 무엇일까?

어차피 우회가 불가능하다면 배우는 의미가 없는 것이 아닌가 싶지만, 그렇지 않다.

 

1. Prepared Statement를 잘못 쓴 경우

Prepared Statement를 사용함에 있어 '?문법'을 제대로 쓰지 않고 그냥 Prepared Statement를 사용한다면? 이는 잘못 이용한 것이여서 막는 효과를 가지지 못한다는 허점이 있다. 개발자의 실수가 있다면 파고들 틈이 생긴다는 것을 의미한다.

2. Prepared Statement를 쓰지 못하는 경우

모든 SQL Query에 있어 Prepared Statement를 사용할 수 있는 것이 아니다. 사용하지 못하는 부분이 존재한다.

Prepared Statement 사용 불가능

1. order by 절
2. table 이름, column 이름
3. where ___ like 절

위와 같이 사용 불가능한 부분이 존재하므로 파라미터(parameter)에 sort, ord 가 있다? 라고 한다면 무조건 확인해봐야 한다.

 

2. White List Filtering

대응 방법 2. white list filtering

필터링이란? 특정 단어에 대하여 차단하거나 허용하는 것을 말한다.

White vs Black

'화이트리스트 필터링(White List Filtering)' vs '블랙리스트 필터링(Black List Filtering) '

화이트 (White) : 특정 단어만을 쓸 수 있도록 하는 것이다. (특정 단어만 허용)

블랙 (Black) : 특정 단어를 못 쓰게 하는 것이다. (특정 단어를 차단)

SQLi를 막겠다고 블랙리스트 필터링을 사용하게 되면 써져야할 단어들도 써지지 않을 수 있다.

그렇기 때문에 특정 단어를 지정해 놓고 리스트에 허용된 단어들 만을 이용 가능하게 해두는 방식을 취하는 화이트리스트 필터링을 이용한다.

if(sort == 'title'){
}elif(sort == 'author'){
}else{
    sort = 'title';
}

 

---

질문 환영, 수정 및 보완에 대한 지적 환영