어플리케이션 기본학습 7~9, 웹 어플리케이션 취약점 1,2

FTP(File Transfer Protocol)
개요
- 평문전송이므로 필요한 경우를 제외하고는 사용을 제한해야 한다 (스니핑 공격에 취약)
- 암호화된 대체 서비스
  - SFTP(SSH File Transfer Protocol): SSH 기반의 파일 전송 프로토콜 22/tcp
  - FTPS(FTP over SSL/TLS): SSL/TLS 기반의 파일 전송 프로토콜 990/tcp
- 제어채널과 데이터채널, 능동active 모드와 수동passive 모드로 구분

(순서상 제어채널을 먼저 생성한 후에 데이터 채널이 생성됨. 제어채널을 통해 FTP 클라이언트와 서버간에 FTP명령어를 주고받고, 데이터 채널을 통해 데이터를 전달한 후 데이터 채널이 종료됨.)

 

 

동작모드

1) FTP 능동모드 active mode
개요
- 기본적으로 적용되는 모드
- 제어채널은 FTP 명령을 전달하기 위한 채널이다.  클라이언트에서 서버의 21/tcp 포트로 접속하여 제어채널을 생성한 후 명령을 전달한다 (클라->서버)
- 데이터채널은 데이터를 전달하기 위한 채널로, 서버(20/tcp)에서 클라이언트의 1024/tcp 이상 포트로 접속하여 데이터 채널을 생성한 후 데이터를 전달한다. (연결방향이 반대. 서버->클라)

 

동작방식
1. 클라이언트가 서버의 21/tcp로 connect()하여 제어채널 생성
2. 클라이언트의 ls 명령 PORT_CLIENT_IP, 5001                  <- 서버에게 클라이언트가 포트/ip정보를 알려주는 명령어
3. 서버는 OK 응답을 한 후, 클라이언트의 5001번 임시 포트로 connect()하여 데이터 채널을 생성하고, file 리스트 전송
4. 데이터채널 종료, 전송완료

 

문제점: 클라이언트에 방화벽이 설치되어 원격 ftp 서버에서 클라이언트로의 접속을 허용하지 않는다면, 데이터채널 접속이 불가능하여 데이터를 받을 수 없는 문제 발생
(기본적으로 방화벽의 Inbound연결(외부->내부): 화이트리스트 / outbound연결(내부->외부): 블랙리스트)
해결방안: 방화벽에 원격 FTP 서버 (20/tcp)에서 클라이언트로의 접속을 허용하도록 설정
                 또는 수동모드로 원격 FTP 서버에 접속

 

 

문제예시

Q. 클라이언트는 원격 FTP 서버에 접속은 되지만 데이터를 받을 수 없는 문제가 발생하고 있다. 원인과 해결방안이 무엇인가?

A. 클라이언트에 방화벽이 설치되어, 원격 FTP 서버의 클라이언트로의 접속이 차단되고 있다. 클라이언트 방화벽에 원격 FTP 서버(20/tcp)의 접속을 허용하거나, 수동모드로 원격 FTP 서버에 접속한다.

 

 

2) FTP 수동 모드passive mode
개요
- 제어채널 : FTP 명령을 전달하기 위한 채널이다.  클라이언트에서 서버의 21/tcp 포트로 접속하여 제어채널을 생성한 후 명령을 전달한다 (클라->서버)
- 데이터채널 : 클라이언트에서 서버의 1024/tcp 이상 포트로 접속하여 데이터 채널을 생성하고 데이터 전달 (클라->서버)

 

동작방식
1. 클라이언트가 서버의 21/tcp로 connect()하여 제어채널 생성
2. 클라이언트의 ls 명령 PASV 명령어
3. 서버는 PASV OK 응답을 한 후, 4900번 임시 포트를 알려준다

4. 클라이언트는 서버의 4900번 포트로 connect()하여 데이터 채널을 생성하고, 서버는 file 리스트 전송
4. 데이터채널 종료, 전송완료

 

문제점: 인바운드 트래픽에 대한 방화벽의 1024/tcp 이상 포트를 모두 허용해야 하는 문제점
해결방안: 방화벽의 상태검사Stateful inspection 기능을 통해 연결상태를 추적하여 데이터 채널을 허용하도록 설정

(상태검사기능 : 방화벽을 통과하는 모든 프로토콜의 연결상태를 추적)

 

( iptables -A INPUT -d 192.168.55.ftp서버 -p tcp --dport 21: -j ACCEPT
=> 제어채널 생성을 위해 21 tcp포트 허용)
( iptables -A INPUT -d 192.168.55.ftp서버 -p tcp --dport 1024: -j ACCEPT
=> 데이터채널 생성을 위해 1024이상 tcp 포트 허용)

====> 보안취약점

 

(iptables -A INPUT -m state --state ESTABLISHED, RELATED -j ACCEPT
=> 이미 연결된 상태거나, 연관된 인바운드 트래픽의 경우엔 허용 )
(iptables -A INPUT -m state --state NEW -p tcp --dport 21 -j ACCEPT
=> 제어채널 생성을 위해 21번 포트를 허용 )

====> 상태검사 state 를 적용하여 21번 포트만 열고, 연관된 경우(데이터채널 연결시)에 열어줌

 

 

7 END --

 

 

FTP 보안 취약점을 이용한 공격
1) FTP 바운스 공격 (FTP bounce attack)
가) 개요
1. 제어 채널과 데이터 채널이 분리되어 있고 Active 모드에서 데이터 채널을 생성할 때 서버에 임의의 목적지 IP와 Port 번호를 설정할 수 있는(목적지를 확인하지 않는) FTP 설계의 구조적 취약점을 이용. 공격 대상 네트워크를 스캔하거나, 공격자가 원하는 서버로 데이터는 전송하는 형태의 공격.
2. 능동모드active에서 데이터채널 생성시 클라이언트는 PORT 명령으로 IP와 Port를 서버에 전달해준다. 이 때, 공격자가 클라이언트가 아닌 임의의 주소로 지정할 수 있다.

 

나) 공격방식
1) 주로 익명Annoymous FTP 서버를 이용하며 PORT 명령의 목적지 IP와 Port 번호를 조작하여, FTP 서버가 공격자가 원하는 목적지 호스트와 데이터 채널을 연결하도록 시도 (무작위로 임의의 IP와 Port번호를 대입하여 다수의 연결시도)
2) FTP 서버를 거쳐 외부에서 접근할 수 없는 내부 네크워크를 스캔하거나, 공격자가 원하는 내부서버로 데이터를 전송할 수 있다

(ex 내부를 스캔하다가 25/tcp 메일서버가 열린 것을 발견하면, 공격자는 FTP 서버에 스팸 메일 메시지를 올려놓고 메일서버에 다운로드 시킬 수 있음)

 

2) TFTP (Trivial FTP) 공격

- 매우 단순하고 간단한 파일 송수신 프로토콜. 69/udp 포트 이용.
- 별도의 인증과정 없이 디렉터리에 접근하여 파일 송수신을 할 수 있는 보안상 취약점
- 자체 디스크가 없는 워크스테이션에 부팅이미지 전달
- 네트워크 장비의 운영체제를 백업/복구하거나 설정정보를 저장하거나 가져오는 용도
- 보안기능이 없는 TFTP의 취약점을 이용해 공격자가 TFTP 서버의 파일에 접근하거나, 악의적인 파일 생성

 

대응책
- TFTP 서비스가 불필요한 경우 제거 (inetd.conf 설정 파일에서 tftp 서비스 주석처리후 inetd 데몬 재시작)
- xinetd 환경에서는 TFTP 설정 파일의 disable 속성을 yes로 설정하여 xinetd 데몬 재시작
- 필요한 경우엔 secure mode로 운영. chroot로 가상의 최상위 디렉터리로 지정하여 상위 디렉터리로 접근하지 못하게 함

(inetd.d의 경우 tftp 필드의 마지막에 in.tftpd -s /tftpboot 추가

xinetd.d의 server_args = -s /tftpboot
=> -s secure모드. /tftpboot를 최상위 디렉터리로 설정하겠다는 뜻)

 

netstat -anup | grep 69
=> 69번은 tftp이므로 열려있는지 확인하여 활성화 여부를 알수있다

 

3) 익명 FTP 공격 Anonymous
- 익명 계정으로 FTP 접속이 가능한 서비스
- 익명 계정이란 ID가 anonymous이고 비밀번호가 없는 계정
- 익명 계정을 허용하면 비밀번호 인증 없이 서버의 파일에 접근할 수 있으므로 보안상 심각한 문제
- 익명 FTP 서비스의 취약점을 이용하여 FTP 서버에 접근하거나 악의적인 파일을 생성

 

설정 vsftpd.conf의 anonymous enable = YES   <- NO로 설정 권고

대응책
- 반드시 사용해야 하는 경우가 아니라면 허용하지 않도록 설정

 

 

FTP 접근제어 설정
1) 설정 파일을 이용한 계정별 접근제어
개요
1. 기본적으로 평문 송수신을 하므로, 중요계정은 FTP 접속을 제한해야한다
2. ftpusers 파일은 접속을 제한할 계정정보를 담고 있는 설정 파일
3. vsFTP 서버의 경우 ftpusers 파일뿐만 아니라 **vsftpd.conf에 userlist_enable=YES로 설정했을 때, user_list 파일을 이용해서 계정별 FTP 접속 제한을 설정할 수 있다. (root 등 중요계정은 제한)

 

TCP Wrapper를 이용한 IP 접근제어
- vsftpd.conf의 tcp_wrappers=YES로 설정하면, hosts.allow (허용)파일과 hosts.deny(차단)파일을 이용해 제어할 수 있다

 

 

8 END --

 

 

SNMP (Simple Network Management Protocol)
개요
- 각 호스트로부터 정기적으로 여러 관리 정보를 자동으로 수집하거나, 실시간으로 상태를 모니터링 및 설정할 수 있는 서비스
- 이를 활용하여 실제 네트워크 관리정보를 얻기 위해서는 관련 프로그램(ex NMS)이 준비되어야 한다
- 구성요소 : 관리 시스템Manager, 관리대상Agent로 나뉜다
- Manager는 Agent에 필요한 정보를 요청하는 모듈. Agent는 관리 대상 시스템에 설치되어 정보를 수집하고 Manager에 전달하는 모듈
- MRTG 프로그램을 이용해 트래픽 관리 등을 위해 사용됨 
- 7계층 프로토콜 udp 프로토콜 사용 (161, 162 port)

동작방식
1) 관리시스템Manager는 162 udp 포트를 이용하고 대행자Agent는 161 udp 포트를 이용한다.
(Trap 비동기적으로 발생하는 메시지. 162 udp)
2) 관리 시스템과 대행자간에 통신하기 위해서는 SNMP 버전, Community String, PDU가 일치해야 한다
3) PDU 타입의 종류
         - Get Request : 관리시스템이 에이전트로 원하는 객체의 특정 정보 요청
[161  - Get Next Request : 관리시스템이 에이전트로 이미 요청한 정보의 다음 정보 요청
 udp] - Set Request : 관리시스템이 에이전트로 특정한 값을 설정
         - Get Response : 대행자가 관리 시스템에 해당 변수 값 전송
[162  - Trap : Agent가 Manager에 어떤 정보를 비동기적으로 알리기 위해 사용. 
 udp]              notify라고 하며, 콜백함수와 같은 역할.

- Get Bulk Request : SNMPv2에 추가된 PDU. 관리시스템이 에이전트로 객체의 범위를 지정해 한번에 요청함. (DRDoS에서 증폭 공격용도로 사용)
- InformRequest : SNMPv2에 추가된 PDU. 관리 시스템간의 정보 전달 목적

4) SNMP 데이터 수집 방식
- Polling 방식 : 관리시스템이 에이전트(161 udp)에게 정보를 요청해주면 응답해주는 방식. 동기적 방식. 
- Event Reporting 방식 : 에이전트가 이벤트 발생시 관리시스템(162 udp)에게 알리는 방식 (Trap)

 

주요용어
1) MIB (Management Information Base)
- 관리 되어야 할 특정한 정보, 자원을 객체라 하고 이러한 객체들을 모아놓은 집합체를 MIB라 함
- 객체별로 트리 형식 구조

2) SMI (Structuer Manngement Infomation)
- MIB를 정의하기 위한 일반적인 구조
- ANS.1 언어를 사용한다. 데이터와 데이터의 속성들을 설명하기 위한 공식 언어.
- 정의된 모든 객체는 name, syntax, encoding을 가짐. name은 객체를 식별하기 위한 식별자OID.
   syntax는 데이터유형, encoding은 메시지 전송 시 비트 변환 규칙.
   SNMP는 ANS.1의 encoding rule중 BER을 사용한다

 

 

SNMP 접근 제한 설정
가) 보안설정
- 트래픽 정보, 각종 하드웨어 정보까지 제공하는 등 매우 중요한 정보를 제공하므로 보안에 주의

나) 버전별 특징
1) SNMP v1
- 보안기능 없음, 암호화 없음, community string만 일치하면 모든 정보를 얻을 수 있음

2) SNMP v2
- 가장 많이 사용되는 SNMP v2c는 복잡한 보안기능을 제거한 버전. 보안취약.

3) SNMP v3
- 데이터 인증, 암호기능 및 재사용 방지, 세분화된 접근통제 등 개선된 보안서비스 제공

다) Community string
1) SNMP데몬과 클라이언트가 데이터를 교환하기 전에 인증을 위해 사용하는 일종의 패스워드. 초기값은 public 또는 private인데, 추측하기 어렵고 의미가 없는 문자열로 바꾸는 것을 권고
2) RO(Read Only)와 RW(Read Write)모드가 있다. 쓰기모드는 가급적 사용 자제를 권고함

라) 암호화 여부
- SNMP v2까지는 평문전송. 스니핑에 쉽게 노출됨. SNMP v3에선 암호로 인증하는 보안기능이 추가되었다.

 

SNMPv3 보안서비스 메시지 구조
개요
- 데이터의 변경(무결성 침해), 도청(기밀성 침해), 재사용 공격에 대응하는 사용자 기반 보안모델USM과 인가된 사용자의 MIB 접근 통제 기능을 제공하는 뷰기반 접근통제모델VACM에 의해 제공된다
- Authoritative 엔진은 SNMP 에이전트 기능을 수행하는 엔진

 

보안매개변수

Authoritative 엔진 ID msgAuthoritativeEngineID	재전송 공격 방지 메시지 유효시간을 계산, 재전송 여부를 판단
Authoritative 엔진부트횟수 msgAuthoritativeEngineBoots
Authoritative 엔진시각 msgAuthoritativeEngineTime
사용자 msgUserName	위장공격, 메시지 위변조 공격 방지 메시지 인증 HMAC(MA5, SHA) 사용
인증 매개변수 msgAuthoritativeParameters
암호 매개변수 msgPrivacyParameters	도청/스니핑 공격, 정보노출 공격 방지 메시지 암호화DES-CBC

 

 

NMS (Network Management System)
- 네트워크 상의 자원들을 모니터링하고 제어하기 위한 도구. 네트워크 요소의 각 지점과 특정한 속성에 주소와 이름을 지정하고, 주기적으로 각 요소가 가진 정보를 중앙 제어 센터에 제공하는 구조를 가진다.
- 관리자-대행자Manager-Agent구조.

모니터링 방식
- Polling 방식 (Manager가 원하는 정보를 Agent에 요청하면 Agent가 MIB로부터 정보를 추출하여 응답)
- Event Reporting 방식 (Agent가 자신의 상태를 주기적으로 Manager에게 알리는 방식)

 

 

DHCP (dynamic host configuration protocol)
- 동적으로 클라이언트의 네트워크 주소를 설정하기 위한 프로토콜
- 67/udp(서버), 68/udp(클라이언트)

관련 명령어
- ipconcig /release : 할당받은 ip 주소 해제
- ipconfig /renew : 새로운 ip 주소를 DHCP서버로부터 받는다

할당 절차
1) DHCP Discover 메시지 (MAC 정보를 담아 브로드캐스트)
2) DHCP Offer 메시지 (클라이언트에게 ip정보를 제공해준다)
3) DHCP Request 메시지 (해당 IP를 사용하겠다고 서버에게 요청하는 메시지)
4) DHCP Ack 메시지 (서버는 해당 MAC와 IP정보를 테이블에 저장. 할당된 주소정보를 클라이언트에게 전송)

DHCP Starvation 공격
- DHCP서버의 할당 가능한 IP를 모두 소진하게 만들어 Ip할당이 불가능하게 만드는 공격
- discover 메시지를 서로 다른 MAC 주소로 대량으로 보내서 request까지 보내고 실제로는 할당하지 않음

 

 

-- 애플리케이션 기본학습 9 END --

 

 

* 웹 어플리케이션 취약점

 

선수지식
웹 개발에 필요한 구성요소
- 클라이언트(웹 브라우저, 모바일앱) : html, css(스타일 지정) / 클라이언트 사이드 스크립트 javascript ...
- 서버(웹서버) <-> 데이터베이스

: 웹서버 apache, iis, jeus / DBMS mysql, mssql,oracle, mariadb / 프레임워크 spring / 서버 사이드 스크립트 php, jsp, asp ... 

(컴파일 기반 : 소스파일을 컴파일해서 실행파일을 만듦. C, C++ 등
스크립트 : 한줄씩 읽어 실행되는 언어)

웹서버 = (물리적인 서버 장비 / 웹서버 프로그램)

APM 환경 : Apache 웹서버에, php 언어와 mysql 쓰는 환경

 

 

1. SQL Injection 취약점
개요
- 정상적인 SQL 질의를 변조, 삽입하여 불법 로그인, DB 데이터 열람, 시스템 명령 실행 등 비정상적인 데이터베이스 접근을 시도하는 공격 기법
- 조작한 입력으로 데이터베이스를 인증없이 접근 및 자료를 무단 유출하거나 변조할 수 있음
- 무료 SQL Injgection 취약점 스캐너 : Nikto, SQLMap, Absinthe ...

공격방식에 의한 분류
1) Form SQL Injection
개요
- HTML Form(입력필드의 집합) 기반 인증을 담당하는 애플리케이션의 취약점이 있는 경우, 사용자 인증을 위한 질의문의 조건을 임의로 조작하여 인증을 우회
- 질의문의 조건절(where)이 항상 참이 되도록 조작
- 공격에 성공하면 반환되는 레코드 셋의 첫 번째 레코드에 해당하는 사용자 권한을 획득하게 된다

 

 

선행학습
- (DML) Select문
- 폼 필드, 입력 데이터 전달 과정

mysql -u user1 -p 1234
show database;             (데이터베이스 구조 출력)
show tables;                  (테이블들 출력)

desc member;               (member 테이블의 구조 출력)
=> 리눅스 환경에서 mysql 접속, 사용하기

 

select * from tablename;

select * from tablename where name='홍길동' and id='hkd9804';

 

Form 데이터 전송방식과 php 코드
html 코드 예시 : 
<form method=POST action='login.php'>
  <input type='text' name='id'>
  <input type='password' name='pass'>
</form>

=> POST 방식으로 login.php에 id와 pass라는 이름으로 파라미터 전달

GET 방식으로 파라미터를 전달할 수도 있지만, 쿼리스트링(?id=tester&pass=12345)은 보안이 취약하므로 POST 권장

(GET 방식은 파라미터가 쿼리스트링에 담기고, POST는 요청 메시지 바디에 데이터가 담긴다)

php 페이지에서 파라미터 참조
공통 : $id, $pass
GET : $_GET['id'], $_GET['pass']
POST : $_POST['id'], $_POST['pass']

프로그램 내에서 $변수명(생성할때)으로 쓰기 때문에, POST나 GET을 명시해서 파라미터를 참조하는 것이 혼동의 여지가 적다

(centos7의 기본 YUM 저장소에는 mysql 최신 버전이 없어서 설치파일을 다운로드 받아야 한다고 한다
https://dev.mysql.com/downloads/repo/yum/ 에서 적당한 것으로 선택
yum install https://dev.mysql.com/get/mysql80-community-release-el7-6.noarch.rpm
yum install mysql-server

gpg key 관련 오류시, vi /etc/yum.repos.d/mysql-community.repo 파일을 열어서
[mysql80-community] 항목의 gpgcheck 옵션을 0으로 수정

mysqld -V 버전체크

systemctl start mysqld
systemctl enable mysqld
mysql 실행. 부팅시 자동으로 실행되도록 설정.)

 

 

실습
1. HTML 폼 기반의 로그인 페이지

(땡처리) ' 는 싱클쿼테이션으로, 문자열을 표시하는 특수기호이다

에러가 나는지 안 나는지를 확인하여, 에러가 나면 취약한 사이트로 판단

Select id, pass from member where id=''' and pass='1234';

=> 사용자 입력값을 검증하지 않는 경우 SQL syntax 문법 오류가 발생됨

질의문에 사용되는 특수문자 등을 입력했을 때 에러 메시지가 발생한다면, 입력한 값이 데이터베이스 서버까지 전달되어 처리 중 오류가 발생한 것이므로, 입력값에 대한 검증이 없는 SQL Injection에 취약한 페이지로 볼 수 있다

 

 

취약점 1 end --

 

 

$sql = "select id, pass from member where id='$id' and pass='$pass'"
=> php 코드의 일부. 검증없이 무조건 참조해온다

$result = mysql_query($sql, $connect);
=> sql 구문을 실행하여 result 변수에 저장
$num_match = mysql_num_rows($result);
=> 쿼리 결과 레코드 수를 반환

mysql_fetch_array($result);
=> 결과값의 첫 번째 레코드 추출

 

공격자가 악의적으로 넣는 파라미터
' or 1=1#
' or '1'='1'#
' or 'a'='a'#

=> where id='' or 1=1#' and pass=''
=> where id='' or '1'='1'#' and pass=''
=> where id='' or 'a'='a'#' and pass=''

 

'을 넣어 앞의 id값을 빈값으로 만들고, 그 뒤에 or절로 1=1 조건을 무조건 참으로 만든 뒤, #으로 뒤의 조건들을 주석처리 해버리면서 무력화시킨다.

쿼리 결과값은 회원의 모든 레코드를 출력하게 된다. (조건없이 무조건 참이 되므로)
로그인 로직에 따라 다르지만, 결과값이 첫 번째 레코드를 무조건 로그인처리 하게 된다면, 첫 번째 레코드는 관리자일 확률이 높다.

 

URL 인코딩Encoding?
- 영문자, 숫자, 일부 특수문자를 제외하고 사용할 수 없는 문자를 URL 상에 안전하게 표현하기 위한 인코딩 방식. Percent Encoding 방식 사용
- Percent Encoding 방식 : 대상 문자를 바이트 단위로 [%xx] 형식으로 표현하는 방식. xx는 16진수
- 주요 ASCLL 코드 16진수값 (암기)

기호	헥사값	인코딩
<	0x3C	%3C
=	0x3D	%3D
>	0x3E	%3E
'	0x27	%27
공백(space)	0x20	%20 또는 +
#	0x23	%23

id=%27+or+1%3D1%23&pass=1234
=> id=' or 1=1#&pass=1234                   (이정도는 해석할 수 있어야 함)

 

모범답안

' or 1=1 을 통해 조건절이 항상 참이 되도록 만들어, 모든 레코드가 select 될 수 있도록 하고 있으며, #을 통해 그 이하 구문을 주석처리 하여 다른 조건을 무력화시킨다.

 

MY-SQL 주석 처리 : #     ' or 1=1#
MS-SQL 주석 처리 : --     ' or 1=1--
Oracle 주석 처리 : --        ' or 1=1--

여러 줄 주석 처리 : /* 주석 내용 */

 

 

실무형 기사 문제 예시
웹서버에서 다음과 같은 SQL SELECT문이 수행된다고 할 때 아래의 항목에 관해 설명하시오

[ SELECT password FROM user WHERE username='test' ]

1) 쿼리 결과
: user table의 username test의 password가 반환된다

2) 모든 사용자의 정보를 획득하기 위해 test 부분에 들어갈 예시를 작성하시오
: ' or 'a'='a
( 조건이 여러개일 경우 ' or 1=1# 으로 사용 )

3) 2번의 예시가 가능한 이유는 무엇인가?
: or절은 조건 중 하나만 참이어도 참이되므로, 'a'='a'는 늘 참이므로 모든 레코드가 반환된다

 

php의 설정 파일 : php.ini
magic_quotes_gpc = On 또는 Off
=> Get, Post, Cookie로 전달되는 데이터에서 ' " \ Null 등 특수문자를 일반문자로 치환해주어 SQL Injection 공격을 방지함
    \(back clash)를 붙이면 특수문자의 기능이 제거되고 일반문자로 처리됨

단, 최선 PHP(5.4버전 이상)에서는 이 설정을 지원하지 않으므로 mysql_real_escape_string()과 같은 MySQL 라이브러리 함수를 이용해야 한다.

활성화시 : where id='\' or 1=1#' and pass=''         <- back clash가 붙음

라이브러리 함수 사용 예시 : $id = mysql_real_escape_string($id);

 

 

*선처리 질의문 Prepared Statement 를 이용한 SQL Injection 방지

$stmt = $connect-> prepare("select id, pass, nick from member where id=? and pass=?");
$stmt->bind_param("ss", $id, $pass);
$stmt->execute();

- 일반 질의문Statement 방식은 요청할 때마다 질의를 컴파일하여 생성한 후 실행하는 방식. 성능상의 문제 및 사용자 입력값 조작에 따라 의도하지 않은 질의가 생성되어 실행될 가능성이 있다
- 선처리 질의문 Prepared Statement는 외부로부터의 입력을 제외한 질의 부분을 미리 컴파일하여 생성한 후 반복적으로 입력값만을 매개변수로 전달하여(바인드) 질의문을 실행
- 선처리 질의문 Prepared Statement는 반복적인 컴파일 과정을 수행하지 않고, 사전에 컴파일된 질의문을 사용하므로 성능상의 장점과 함께 공격자가 악의적인 입력값을 삽입해도 매개변수로 바인드할 뿐, 질의문 자체는 영향받지 않음. SQL Injection 공격을 방어하는 효과가 있다.

 

선처리 질의문 Prepared Statement가 어째서 SQL Injection을 방어할 수 있는가?

-> 일반적인 질의문과 달리, 사전에 컴파일된 질의문을 사용하기 때문에 사용자가 악의적인 입력값을 넣더라도 매개변수에 바인드될 뿐, 질의문 자체에는 영향을 주지 못하기 때문.

 

 

취약점 2 END --