[정보보안기사] 웹 취약점 및 대응 방법

1. SQL Injection

입력값에 SQL을 삽입하여 데이터베이스의 데이터를 인증 없이 얻어내는 공격 방법.

쿼리 조작을 통한 DB 노출 및 변조, 덤프, 파괴,

웹 애플리케이션 인증 우회, 시스템 주요 파일 노출 등의 피해가 발생할 수 있다.

 

1.1. 공격 방법

'or 1=1 #을 입력해서 SQL문이 참이 되도록 한다.

#은 뒤에 나오는 모든 문장을 주석으로 처리한 것.
(MySQL의 주석은 #, Oracle DB의 주석은 --)

; delete from user; --  (Mass SQL Injection, 한 번의 공격으로 대량의 DB가 변조)

'union select 1, 2 from dual --

 

 

1.2. 취약점 발생 원인

동적으로 Query 구문을 작성하여 사용자의 입력을 SELECT 문에 그대로 대입하기 때문이다.

 

 

1.3. 대응 방안

(1) 동적 쿼리를 사용하지 않는다.

(2) Prepared Statement를 사용한다.

(3) ORM(Object Relationship Mapping)을 사용한다.

(4) 만약 반드시 동적 쿼리를 사용해야 한다면, 입력값을 White List 필터링 한다.

 

 

1.4. Blind SQL Injection

SQL 실행 결과가 참, 거짓으로 나오기 때문에 입력해본 문자가 맞는지 틀린지 알 수 있는 특성을 이용한 공격.

'or substr(칼럼명, 1, 1)='a' #

칼럼명을 하나로 자르고 그 값이 'a'와 같은지 확인.

 

1.5. Union SQL Injection

SQL문 뒤에 union을 입력해서 공격자가 SELECT문을 붙여서 실행하는 것으로 원하는 테이블에 접근할 수 있다.

 

1.6. Time Based SQL Injection

SQL 응답시간으로 질의에 대한 참, 거짓을 판단.

SQL Injection을 실행해도 서버가 응답이 없을 때 수행한다.

 

 

 

---

2. 코드 삽입

임의의 코드를 삽입하여 소프트웨어의 의도된 동작을 변경하여 비정상적으로 동작하는 취약점.

 

2.1. 취약점 발생 원인

eval()  또는  ScriptEngine() 과 같은 동적 스크립트를 생성하는 함수를 사용하는 경우 발생.

javascript 함수이므로 클라이언트를 공격함.

 

2.2. 대응 방안

(1) 동적 스크립트를 생성하는 함수를 사용하지 않는다.

(2) 불가피하게 필요하면 화이트리스트 필터링을 한다.

 

 

 

---

3. 운영체제 명령어 삽입

입력 값을 검증하지 않아서 웹 입력을 통해 운영체제 명령을 실행할 수 있는 취약점.

 

3.1. 취약점 발생 원인

입력값을 검증하지 않아서 운영체제 명령어를 그대로 실행하게 되어 발생한다.

 

3.2. 대응 방안

외부로부터 입력받은 값에 대하여 화이트리스트 필터링을 수행한다.

 

 

 

---

4. 위험한 형식 파일 업로드

공격자가 악성 스크립트가 실행될 수 있는 프로그램을 웹 서버로 업로드하는 공격.

업로드 취약점을 이용하여 웹 서버에서 실행되는 스크립트를 웹셸(Web Shell)이라고 한다.

 

4.1. 취약점 발생 원인

사용자가 업로드하는 파일의 확장자를 검사하지 않으면 위험한 유형의 파일을 업로드할 수 있다.

웹 서버의 확장자 검사 우회 기법
(1) 이중 확장자 사용
(2) 파일 이름에 Null Byte 추가
(3) 취약한 Web Editor 사용
(4) 파일명 뒤에 ; 추가

 

4.2. 대응 방법

(1) 확장자를 화이트리스트 필터링 한다(doc, hwp, pdf 등만 허용).

(2) 파일 타입, 크기, 권한을 검사한다.

(3) 확장자를 제거하고 파일명을 암호화하여 저장한다. → 공격자는 파일 이름을 모르면 서버에 업로드 된 파일을 실행할 수 없다.

(4) 파일을 웹 서버 Document Root 디렉터리 밖에 저장한다. → 공격자가 직접 파일에 접근할 수 없다.

(5) 업로드 디렉터리와 다운로드 디렉터리를 분리한다.

 

 

 

 

---

5. XSS(Cross Site Scripting)

사용자가 특정 사이트를 신뢰한다는 사실을 이용하여, 공격자가 실행 가능한 코드를 재전송하도록 하는 공격 기법.

웹 브라우저(클라이언트)를 공격한다.

공격 방식에 따라 Stored XSS, Reflected XSS로  나뉜다.

구분	설명
Stored XSS (Client to Client, C2C 방식)	· 공격자는 악성 스크립트를 웹 서버(DB)에 저장. (웹 게시판 등) · 해당 게시물을 피해자에게 노출시킴. · 피해자가 게시물에 접근하면 악성 스크립트가 실행됨. · Persistent
Reflected XSS (Client to Itself 방식)	· 공격자는 악성 스크립트를 포함한 URL을 이메일 등으로 피해자에게 노출시킴. · 악성 스크립트는 서버에 저장되지 않음. · 클라이언트가 해당 이메일에 접근 시 악성 스크립트가 실행됨. · Non Persistent
DOM XSS

 

XSS Test Code

<script>alert("test");</script>

 

공격 코드(세션 정보 갈취)

<script>alert(document.cookie);</script>

이처럼 세션 정보를 갈취해서 웹 프록시를 통해 인증을 우회하는 CSRF 공격으로 이어진다.

 

 

5.1. 취약점 발생 원인

사용자로부터 입력된 데이터에 대한 부적절한 검증을 통하여 웹 도큐먼트로 출력.

서버를 경우하여 조작된 웹 페이지 및 URL을 열람하는 클라이언트를 공격.

 

 

5.2. 대응 방안

(1) replaceAll 함수를 사용하여 <, >, &, ', "를 각각 &lt, &gt, &amp, &quot로 대체한다.

(2) XSS Filter를 적용한다.

(3) HTML 인코딩을 적용한다.
예를 들어 공백은 %20, =은 %3D로 변환

 

 

 

---

6. CSRF(Cross Site Request Forgery, 크로스 사이트 요청 위조)

공격자의 요청이 인증된 사용자의 요청인 것처럼 속이는 공격 방식.

세션쿠키와 같이 자동으로 입력된 신뢰정보를 기반으로 사용자의 요청을 변조하여 해당 사용자의 권한으로 악의적 공격을 수행.

 

6.1. 취약점 발생 원인

웹 애플리케이션이 사용자의 요청이 실제 사용자가 전송한 것인지 확인하지 않는 경우 발생.

 

 

6.2. 대응 방법

(1) 중요한 기능에 대해 세션 검증과 재인증(비밀번호 변경 화면에서 재인증, CAPTCHA), 트랜젝션 서명을 수행.

(2) CSRF 토큰 사용

 

 

 

---

7. 포맷 스트링

7.1. 취약점 발생 원인

데이터에 대한 포맷 스트링을 정확하게 정의하지 않아서 발생하는 보안 취약점

 

메모리 열람, 메모리 변조, 셸코드(Shell Code) 삽입과 같은 피해로 이어질 수 있다.

 

7.2. 대응 방법

포맷 스트링을 정확하게 정의한다.

 

 

 

---

8. XXE Injection(XML External Entities, XML 외부 개체 삽입)

8.1. 취약점 발생 원인

잘못 구성된 XML Parser를 사용해서 신뢰할 수 없는 XML 공격코드를 주입하고 실행된다.

 

8.2. 대응 방법

XML Parser 설정에서 외부 엔티티 사용 금지.