ql 주입 공격 탐지 및 실례 분석

시계의 구조를 살펴보자.

mysql> show create table zzz;
+-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table                                                                                                                                                                                                                                            |
+-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| zzz   | CREATE TABLE `zzz` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(64) NOT NULL,
  `password` varchar(64) NOT NULL,
  `score` int(10) unsigned NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 |
+-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> 

표 내용:

mysql> select * from zzz;
+----+-------+----------+-------+
| id | name  | password | score |
+----+-------+----------+-------+
|  1 | taoge | 123      |   100 |
+----+-------+----------+-------+
1 row in set (0.00 sec)

mysql> 

설명하고자 하는 것은 암호를 명문으로 저장하는 것 자체가 안전하지 않다는 것이다.밀문 저장소를 사용해도 안전하지 않으니 소금을 넣은 해시를 고려해야 한다.그러나 본문은 간편하게 보기 위해 우선 이 문제를 토론하지 않는다.
현재 사용자가 name과password를 입력한 다음에 score의 값을 조회해야 한다고 가정하면 페이지는 백엔드로 보내기를 요청하고 백엔드에서 위조 코드는 다음과 같다.

string strName = ... ;
string strPassword = ... ;

select * from zzz where name=strName and password=strPassword  ...

이 때 taoge가 직접 검색하면name(taoge)과password(123)를 입력한 후 실행하는 검색 동작은 다음과 같습니다.

mysql> select * from zzz where name='taoge' and password='123';
+----+-------+----------+-------+
| id | name  | password | score |
+----+-------+----------+-------+
|  1 | taoge | 123      |   100 |
+----+-------+----------+-------+
1 row in set (0.00 sec)

mysql> 

자신의 점수를 정확하게 알아낼 수 있어 합리적이다.
그러나 위의 코드는 sql 주입 위험이 있다. 만약에 Jack이 Taoge의 점수를 조회하고 싶지만 Taoge의 비밀번호를 모르면 어떡하지?또는 조회 가능: Jack이 페이지에 각각 입력
사용자 이름: taoge'or 1 = 1; #     
암호:hehe
      
그러면 페이지를 통해 백그라운드로 전송된 후 백그라운드에서 수행되는 작업은 다음과 같습니다.

mysql> select * from zzz where name='taoge' or 1 = 1 ; #' and password='hehe';
+----+-------+----------+-------+
| id | name  | password | score |
+----+-------+----------+-------+
|  1 | taoge | 123      |   100 |
+----+-------+----------+-------+
1 row in set (0.00 sec)

이를 통해 알 수 있듯이 Jack이 Taoge의 비밀번호 123을 몰라도 sql 주입을 통해 이루어질 수 있다.위 문장에서 #은 주석 기호의 역할을 하고 1=1은 영원히 진실이기 때문에 백그라운드를 도는 암호 검사 논리에 해당한다.
백엔드 시스템은 어떻게 이런 ql 주입 공격에 대항해야 합니까?
      1.매개 변수에 대해 엄격한 검사를 진행하다
      2. mysql_real_escape_string 만들기
      3. 버퍼 오버플로우 방지
      ......
      
ql의 주입 공격에 관해서는 뒤에도 계속 소개할 것입니다.