Jins' Dev Inside

 SQL Injection 은 웹에서 DB에 접근하는 쿼리 자체에 공격을 가하는 것으로 해커들이 많이 이용하는 기법 중 하나이다. 

주로 학부과정의 컴퓨터 보안 시간에 기본적으로 다루는 내용이지만, 실제로 볼 일이 많이 없다가 대응해야할 일이 생겨서 정리해보았다. 

SQL Injection 을 이용해서 대표적으로 다음과 같은 방식의 공격이 사용된다.

(1)  인증 우회(Auth Bypass)

 : SQL 쿼리문의 TRUE/FALSE 논리 연산 오류를 이용해서 인증 쿼리문이 무조건 TRUE가 나오게끔 하는 방식이다. Select count(*) from member where uid=’입력된 아이디’ and pw = ‘입력된 비밀번호’ 에서 ‘입력된 아이디’ 부분에 ‘ or 1=1# 과 같은 내용을 삽입하면 뒤의 내용이 주석처리 되면서 무력화 시킬 수 있다.

(2)  Data disclosure (데이터 노출)

 : 서버가 반환하는 Error 등을 참고해 정보를 파악해서 각 Column과 자료형을 알아내는 방식이다. www.example.com?idx=1’ having 1=1# 과 같은 방식으로 날리는 쿼리 파라미터를 분석한 뒤, 위와 같이 요청했을 때 반환되는 에러메시지를 분석해서 테이블을 유추한다. Error Based / Union Based 와 같은 공격이 이런 방식을 이용한다. 에러 메시지가 뜨지 않는 경우 Delay 함수등을 Inject 하여 응답시간으로 동작을 유추한다.

 : 그 외에도 Procedure 호출 이나 명령어 삽입 등의 공격도 있다.

 위의 내용은 SQL Injection 의 원론적인 부분이고 실무에서 쓰는 프레임워크들은 대부분 SQL Injection 에 대해 방어코드가 기본적으로 되어있다. 

하지만 그래도 개발자로써 기본적으로 숙지해야할 보안의 기본적인 원칙들은 다음과 같다.

(1)  Validation : 자유롭게 입력가능한 값에 대한 Validation 이 필수적이다.

(2)  Parameter : 특히 API등에서도 Parameter 는 특수문자나 SQL 명령어가 입력될 수 없도록 필터링이 필요하다. 물론 더 문제인건 입력받는 Parameter를 바로 DB로 전달하는 것이다…

(3)  Prepared : SQL 입력이 되는곳은 Prepared Statement 를 통한 처리나 ORM 등을 통해 매핑시켜서 사용하는 것이 안전하다.

(4)  권한 : 데이터 다루는 권한은 최소한으로 부여한다.

(5)  에러메시지는 노출하지 않는다.

(6)  동적 SQL의 사용은 지양한다.

SSL 이란 Security Socket Layer 의 약자로  Netscape에서 서버와 브라우저 간 보안을 위해 만든 프로토콜이다. SSL은 CA(Certificate Authority)라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용된다. 서버와 클라이언트 간의 통신 과정은 다음과 같다.

(1) 클라이언트가 SSL로 암호화된 페이지를 요청한다(https)

(2) 서버는 Public key를 인증서와 함께 전송한다.

(3) 클라이언트는 인증서가 Trusted root CA(인증기관)로부터 서명된 것인지, 날짜 등이 유효한지를 확인한다.

(4) 인증을 확인한 클라이언트는Public key로 URL, http 데이터들과 자신의 대칭키을 암호화하여 전송한다.

(5) 서버는 인증서에 대한 Private key로 요청을 복호화하고 전달받은 대칭키로 응답을 암호화해서 전송한다.

(6) 브라우저는 대칭키로 응답을 복호화해서 사용자에게 보여준다.

 이렇게 대칭키를 공개키 암호화방식으로 암호화해서 전송한 후 대칭키로 통신하는 프로토콜을 SSL 방식이라고 한다.

 이 과정에서 사용되는 서명(Signing)이란 특정 메시지를 작성했다는 것을 인증하는 역할이다. 서명의 과정은 다음과 같다.

(1) 해쉬 생성

(2) Private key로 해쉬 암호화

(3) 암호화된 해쉬와 서명된 인증서를 메시지에 추가

(4) 받는 사람은 따로 해쉬를 생성

(5) 받은 메시지에 포함된 해쉬를 Public key를 이용해서 복호화

(6) 4, 5번 과정에서 생성된 해쉬를 비교한다.

 다음은 이 과정을 정리한 SSL 의 워크플로우를 나타낸 그림이다. 아래의 그림에서 1, 2, 3번 과정은 위의 설명 이전의 과정이 된다.

이처럼 SSL은 공개키로 대칭키를 전달하고 실제 암호화 및 해독 작업은 대칭키로 하여 비용과 안정성 측면에서 이점을 갖는 표준 보안 방식을 말한다. 공개키 암호화 방식은 대칭키 암호화 방식보다 훨씬 안정적이지만 속도가 훨씬 느리다. 

사이트에 대한 인증서 문제는 요청한 사이트가 ‘진짜’ 인지를 인증기관을 통해 검증받기 위해서 생긴다. 인증받은 신뢰할 수 있는 사이트의 경우 SSL 통신이 진행된다. 

 Linux 서버 관리를 하다가 가장 자주 마주치는 것 중 하나가 서버의 포트 및 방화벽 문제라고 할 수 있는데 삽질하면서 알아낸 바를 적는다.

 : 리눅스에서 열린 포트를 확인 하는 방법

 - netstat -tnlp : 상태를 인 아웃 port 정보를 포함해서 볼 수 있다.

 : CentOS, Fedora 등의 리눅스에서 포트 방화벽을 확인 하는 방법

-    iptables –-list

-    iptables -L(리스팅) -v(자세히)

 : Ubuntu 에서 포트 방화벽을 확인하는 방법

-    sudo ufw status

 : Ubuntu 에서 포트 방화벽을 활성화 / 비활성화 하는 방법

-    sudo ufw enable

-    sudo ufw disable

 : CentOS, Fedora 등의 리눅스에서 포트를 추가하는 방법

-    iptables -I INPUT 1 -p tcp –-dport 80 -j ACCEPT  (80 번 Input 포트를 1번으로 추가)

-    iptables -I OUTPUT 2 -p tcp –-dport 8080 -j ACCEPT     (8080번 Output 포트를 2번으로 추가)

 : Ubuntu 에서 포트를 추가하는 방법

-    sudo ufw allow <port>/<optional: protocol> (sudo ufw allow 443/tcp)

 : CentOS, Fedora 등의 리눅스에서 포트 예외를 제거하는 방법

-    iptables -D INPUT 2   (INPUT 2번째 규칙 제거)

 : Ubuntu 에서 포트를 제거하는 방법

-    sudo ufw deny <port>/<optional: protocol>

 : Iptables 를 이용한 포트포워딩

-    iptables -t nat -A PREROUTING -p tcp -m tcp –dport 80 -j REDIRECT –to-ports 8080

-    iptables -t filter -A FORWARD -p tcp -m tcp –dport 80 -j ACCEPT

 * 이 글을 정리할 때를 돌아보자면 클라우드 VM에서 자체 방화벽을 잘못 건드려서 2차 참사를 유발한 케이스였다, 당시 사내 플랫폼은 유일한 게이트웨이에서 리눅스 서버에 접속할 수 있도록 허용되어 있었는데, 이 부분이 기존 사내 플랫폼 방화벽에 WhiteList로 등록되어있지 않은 상태에서 방화벽을 걸어버려서, 인스턴스 하나를 날린 참사가 일어났었다... ㅡㅡ 

방화벽 설정은 각별히 주의하자.