[현대이지웰 Java 풀스택 개발자 아카데미 6월] TIL 10차 - 시큐어 코딩

📚 서론

최근 개인 정보 탈취로 인한 피해 소식이 많았던 만큼, 보안에 대해 더욱 민감해져야 하는 순간이 온 것 같습니다.😥

마침 이번 주에는 시큐어 코딩에 대해 배울 수 있었고 거기서 배운 내용에 대해 정리해 보겠습니다.

 

 

시큐어 코딩 배우기 전 '해커'하면 떠올렸던 이미지... 출처:giphy

 

 

커뮤니티에서 크게 화자 되는 해킹처럼 누구도 생각하지 못한 허점을 파고들어 어마어마한 피해를 내는 사건들이 있는 한편,

대부분의 해킹은 개발자의 미흡한 사전 대처로 인해 발생한다고 합니다.

 

그중에서도 자주 발생하는 3가지 해킹 원인은 다음과 같습니다.

1. 입력값 미검증 및 원문 그대로 출력
2. 취약한 암호화 알고리즘 사용
3. 접근 권한 관리 및 검증 미흡

 

그중에서도 입력값 미검증과 원문 출력으로 인해 파생되는 공격법이 매우 다양한데요.

 

이번 포스팅에선 이 부분에 대해 자세히 다뤄보도록 하겠습니다.

 

 

 

 

 

🎷 입력값 미검증 및 원문 그대로 출력

말 그대로 사용자가 입력한 텍스트를 검증하지 않고 그대로 사용함으로 인해 발생하는 문제입니다.

대표적으로는 인젝션 (Injection) 공격이 있는데 조건이 더 충족되면 다양한 공격이 가능합니다.

 

1. 인젝션 (Injection) 공격 💉

SQL 쿼리가 갖고 있는 태생적 취약점을 이용한 공격입니다.

 

입력한 값이 그대로 SQL 쿼리에 활용될 경우 사용할 수 있는데,

로그인 검증을 무시하여 마음대로 계정에 로그인 하는 방법으로 잘 알려져 있습니다.

 

 

예를 들어 로그인 시스템이 사용자에게 ID, 패스워드를 입력받은 후

DB에 동일한 행이 있는지 찾아보는 방식으로 구현 되었다고 해보겠습니다.

SELECT * FROM MEMBER WHERE ID = 'id 입력값' AND PASSWORD = '패스워드 입력값';

위 쿼리를 실행해 결과값이 1개라도 있으면 해당 id로 로그인 할 수 있습니다.

 

 

이때 공격자가 특정 아이디를 입력하고 이어서 ' -- 이라는 값을 입력하면 어떻게 될까요?

SELECT * FROM MEMBER WHERE ID = 'admin' --' AND PASSWORD = '패스워드 입력값';

 

코드 블럭의 반응대로 -- 이후는 전부 주석처리 되기 때문에

위 쿼리는 admin 계정의 정보를 패스워드 확인 없이 그대로 불러오게 됩니다.

 

비밀번호가 없어도 최고 관리자 계정을 사용할 수 있게 되는 겁니다.

 

이제 이 키는 제 것입니다😉 출처: giphy

 

 

여기에 DB 검색 결과를 테이블 그대로 보여주는 페이지가 있다고 가정하면

데이터 자체를 보는 것도 가능해 집니다.

 

 

방금 본 로그인 쿼리에서 입력값에 ' or 1 = 1 -- 이라는 값을 넣으면 어떻게 될까요?

SELECT * FROM MEMBER WHERE ID = '' or 1=1 --' AND PASSWORD = '패스워드 입력값';

 

조건의 뜻은 ID값이 없거나 1이 1인 경우를 모두 불러오라는 뜻이 되는데

1이 1이 아닌 경우는 있을 수 없으니 MEMBER 테이블의 모든 행이 이 조건을 만족하게 됩니다.

 

즉, 이 공격으로 인해서 공격자는 MEMBER 테이블의 모든 내용을 볼 수 있게 됩니다.😨

 

 

 

2. 오류 기반 SQL 인젝션 (Error Based SQL Injection) 공격 ⚠️

인젝션 공격이 가능한 페이지에서 에러 발생시

에러 메시지를 그대로 보여주게 된다면 더 다양한 공격 시도가 가능합니다.

 

 

오라클을 예로 들어보겠습니다.

오라클에는 대량의 텍스트 정보에서 원하는 서치를 빠르게 할 수 있도록 제공된

CTXSYS.DRITHSX.SN 라는 프로시저가 존재합니다.

 

단순 에러 메시지라면 쿼리에 문법 오류가 있다던지 없는 결과라는 메시지만 보여주겠지만

CTXSYS.DRITHSX.SN에 서브쿼리를 붙이면 서브쿼리가 먼저 계산된 뒤 프로시저가 동작하기 때문에

에러 메세지에 서브쿼리 결과를 그대로 노출하게 됩니다.

 

즉, 해당 튜플의 특정 컬럼값 그 자체를 그대로 볼 수 있게 됩니다.

SELECT * FROM MEMBER WHERE MEMID = '				# 원본 쿼리 앞부분
' OR CTXSYS.DRITHSX.SN(USER,					# CTXSYS.DRITHSX.SN 사용
	(select BookName from					# 서브쿼리 시작
    	(select BookName, ROWNUM as RNUM from BOOK)		# 단일행으로 만들기위해 rownum 사용
    where RNUM=3))=1;						# BOOK테이블의 3번행 BookName값 보기
 --' AND PASSWORD = '';						# 주석처리된 원본 쿼리 뒷부분

 

이 쿼리를 실행하면 ORA-20000: Oracle Text 오류가 발생합니다

동시에 이어서 DRG-11701 오류를 표기하며 데이터베이스 이론 키워드 사전이 존재하지 않습니다라는 메시지를 띄웁니다.

 

BOOK 테이블의 3번째 튜플의 BOOKNAME이 데이터베이스 이론 이기에 값 하나를 온전히 가져온 것입니다!

 

이대로 수십번 반복하면 원하는 값이 있는 행을 알 수 있게 되고

그 행의 컬럼값을 전부 넣어봄으로써 하나의 튜플을 온전히 얻을 수 있게 됩니다.

 

이쯤되니 단순 반복노동에 가까워 보인다. 출처: giphy

 

 

 

3. 크로스 사이트 스크립팅 XSS (Cross-Site Scripting) 공격 🧑‍💻

크로스 사이트 스크립팅은 입력값 검증이 미흡하거나

입력값을 필터링 없이 그대로 브라우저에 출력할 경우 발생합니다.

 

스미싱이라고 알려진 스팸 문자의 링크를 이용한 공격이 주로 이것입니다.

 

 

자바 스크립트 코드를 입력값으로 전달하고 그것을 브라우저가 출력할 때

브라우저가 입력값을 텍스트가 아닌 코드로 인식하면서 그대로 실행되어 피해가 발생합니다.

 

 

XSS 공격 유형에는 3가지가 있습니다.

내용이 많아서 간단히 소개해보겠습니다...🥹

 

1. 반사형 XSS (Reflected XSS) 🪞

반사형은 URL에 악성 자바스크립트 코드를 GET 파라미터로 넘김으로써 실행됩니다.

 

전달 받은 GET 파라미터를 브라우저에 출력해주는 페이지가 있다면

공격자는 해당 GET 파라미터에 정상 값 대신 악성 자바스크립트 코드를 넣어 공격할 수 있습니다.

보자... 이 주소로 오랬는데... 어이쿠 깜짝이야! 출처: giphy

 

 

2. 저장형 XSS (Stored or Persistent XSS) 💾

저장형 XSS는 악성 자바스크립트 코드를 URL이 아닌 서버의 DB에 저장함으로써 이뤄집니다.

 

주로 게시글, 프로필에 악성 자바스크립트 코드를 저장합니다.

그리고 해당 글에 사용자가 접근하도록 유도합니다.

게시글 제목에 낚이면 안돼요.,, 출처: giphy

 

 

3. DOM 기반 XSS (DOM Based XSS) 🕵️

DOM은 클라이언트 측 자바스크립트 로직에 취약점을 이용한 공격입니다.

 

 

반사형과 마찬가지로 악성 자바스크립트 코드가 URL에 담겨져 있지만

 

반사형은 악성 스크립트 코드를 서버가 응답값으로 전달하여 실행되지만

DOM 기반은 클라이언트 브라우저에서 URL에 담긴 악성 코드를 읽고 실행합니다.

 

 

좀 더 비교하자면 반사형은 서버가 응답할 때 자신의 응답값을 검토하면 되므로 탐지가 쉽지만

DOM형은 코드에 오류가 없고 실행 주체가 사용자의 브라우저이므로 탐지가 어렵습니다.

탐지가 안된다니까요?!🤯 출처: giphy

 

 

 

 

 

🎺 대처법

위에서 소개한 모든 공격들은 입력값 검증, 필터링, 값 치환으로 간단하게 예방할 수 있습니다.

 

1. SQL 인젝션 공격 방어 🛡️

인젝션 공격의 경우 공격의 시작점이 되는 작은 따옴표 ' 를 입력할 수 없도록 하던가

아스키코드인 '로 바꿔 사용하면 됩니다.

 

또는 자바에서 기본 제공하는 PreparedStatement 클래스를 사용하여

쿼리에 사용할 입력값들을 바인딩해 사용한다면 더 안전하고 간단하게 해결할 수 있습니다.

 

 

2. 오류 기반 SQL 인젝션 공격 방어 💂

오류 기반 SQL 인젝션 공격의 경우 에러 메세지를 전부 그대로 노출하지 않고

개발자가 임의로 만든 오류 메시지를 표기하는 것으로 해결할 수 있습니다.

 

CS가 접수되었을 때 해결법을 찾으려면 적당히 세분화될 필요성이 있습니다.

 

 

3. 크로스 사이트 스크립팅 (XSS) 공격 방어 🤞

크로스 사이트 스트립팅의 경우 특수문자 입력을 제한하거나

출력할 때 특수문자를 아스키 코드로 전부 치환하여 출력하면 간단합니다.

 

&	&	"	"
<	&lt;	'	&#x27;
>	&gt;	/	&#x2F;
(	&#40;	)	&#41;

 

 

 

 

 

🔥 결론

사실 해커라고 했을 때 초기의 이미지는 코드를 두다다다 입력하면

뚝딱 하고 마법처럼 모든 걸 알아내는 막연한 이미지였습니다. 🧙‍♂️

 

하지만 시큐어코딩을 배우면서 알게된 해킹은 약간의 틈새를 꾸준히 공략하여 야금야금 정보를 탈취하는

단순 반복 작업을 꾸준하게 반복하는 일개미에 가깝다는 느낌을 받았습니다. 🐜

 

 

그 집요함이 조금만 더 좋은 방향으로 쓰였다면 얼마나 좋았을까요...ㅎㅎ