32. 침해대응&CERT (10) : 웹 취약점 실습_4

오늘 알아볼 취약점 중 크로스 사이트 스크립트(XSS) 취약점과 SQL Injection 취약점은 

위험도가 높게 판정되는 취약점이면서 실무에서도 중요하게 다룬다.

 

 

---

 

 

크로스 사이트 스크립트(XSS) 취약점

 

 

정의
공격자가 페이지에 악의적인 스크립트를 삽입하여, 

해당 페이지를 열람하는 사용자의 권한으로 해당 스크립트가 실행되어 

 

사용자의 세션을 가로채거나, 피싱 공격, 정보 유출 등의 공격을 진행할 수 있는 취약점을 의미한다.

일반 사용자들 입장에서는 신뢰할 수 있다고 생각하는 웹 사이트에 공격자가 악성 스크립트를 삽입하고, 

해당 스크립트가 포함된 게시글을 열람하는 피해자들의 쿠키가 공격자에게 전송된다. 

이를 통해 공격자는 피해자의 브라우저에서 스크립트를 실행하여 웹사이트 변조, 

악성 콘텐츠 삽입 등의 여러 악의적인 행위를 수행할 수 있다.

https://learn.snyk.io/lesson/xss/

공격 유형

1. Stored XSS (저장형 XSS): 공격자가 악성 스크립트를 웹 애플리케이션의 서버에 영구적으로 저장하고,
   이를 다른 사용자가 웹 페이지를 방문할 때마다 실행되도록 하는 공격 유형이다.
   
   주로 게시판, 댓글, 프로필 정보 등 사용자 생성 콘텐츠를 저장하는 기능에서 발생한다.
   
   악성 스크립트가 서버에 저장된 후, 해당 데이터를 불러오는 모든 사용자의 브라우저에서 악성 스크립트가 실행되는
   지속적인 공격 유형이다. 열람하는 사용자들은 쿠키를 탈취당하거나 다른 사이트로 리디렉션 되는 등의 공격을 받는다.
   
   
2. Reflected XSS (반사형 XSS): 악성 스크립트가 웹 애플리케이션의 서버에 저장되지 않고,
   즉시 반사되어 공격 대상의 브라우저에서 실행되는 유형이다.
   
   주로 검색 결과 페이지, 에러 메시지, 또는 URL 파라미터를 이용해 공격이 이루어진다.
   
   공격자가 클릭을 유도하는 악성 링크를 생성하여 웹사이트에 배포하고, 사용자가 해당 링크를 클릭하면,
   사용자의 쿠키 값이 공격자에게 전송되며, URL에 포함된 악성 스크립트가 서버로 전송된 후 즉시 반사되어 브라우저에서 실행된다.
   
   즉, 불특정 다수를 대상으로 하는 Stored XSS 방식과는 달리, 공격자가 특정 사용자를 이용하여,
   사회공학적인 기법 등을 통해 공격을 수행하는 형태이다.
   
   이는 특정 사용자가 이용되어서 해당 사용자가 직접 서버 쪽으로 공격하는 형태로 동작하기 때문에 반사형이라 불리고, 
   서버 입장에서는 실제 공격자가 아닌, 이용된 사용자가 공격자인 것처럼 보이기 때문에 결과적으로는 실제 공격자를 알 수 없게 된다.
   
   
3. *DOM-based XSS (DOM 기반 XSS): DOM-based XSS는 피해자의 브라우저 즉, 클라이언트 측 자바스크립트 코드에서
   발생하는 XSS 유형으로, 웹 페이지가 DOM을 조작하는 방식에 악성 스크립트를 삽입하는 형식이다.
   
   응답 페이지 HTML에서 악성코드가 분명하게 나타나는 저장형, 반사형 XSS와는 달리
   DOM 기반 XSS는 웹사이트의 코드를 조사하지 않고는 취약점을 발견할 수 없다.
   
   
   DOM-based XSS의 주요 발생 지점
   DOM-Based XSS는 JavaScript의 취약한 DOM 조작 코드에서 주로 발생한다. 예시는 다음과 같다.
   
   1. innerHTML : 사용자의 입력이 HTML로 변환되어 삽입된다.
   const userInput = location.hash.substring(1); // #<script>alert('XSS')</script>
   document.getElementById("output").innerHTML = userInput;
   
   2. document.write : 사용자 입력을 HTML 문서에 직접 삽입한다.
   const userInput = location.search; // ?input=<script>alert('XSS')</script>
   document.write(userInput);
   
   3. eval() : 사용자 입력을 코드로 실행한다.
   const userInput = location.hash.substring(1); // #alert('XSS')
   eval(userInput);
   
   4. setAttribute : 속성 값에 사용자 입력을 삽입한다.
   const userInput = "javascript:alert('XSS')"; 
   element.setAttribute("href", userInput);
   
   주로 웹 페이지 상에서의 편집기를 통해서 공격하는 방식과 문서 내에서 스크립트 구문을 작성하거나 악성 매크로를 
   삽입하여 일반 사용자의 클릭을 유도하는 형태로 공격이 이루어진다.
   
   사용자의 입력 처리 또한 브라우저가 DOM 조작 과정에서 처리되는 것이며,
   데이터의 흐름 또한 클라이언트 → 서버 → 클라이언트가 아닌 클라이언트 → 클라이언트이다. 
   
   즉, 다른 XSS 유형(Stored, Reflected)과 달리, 
   DOM-Based XSS는 서버와 상호작용하지 않고, 클라이언트 측에서 발생한다.
   
   *문서 객체 모델(DOM) : 웹 페이지를 여는 즉시 생성되는 문서 객체 모델(DOM)은
   사용자가 서버와 상호 작용하지 않고도 페이지의 모든 콘텐츠에 접근할 수 있도록 돕는다.
   
   즉, 웹 페이지의 구조를 프로그래밍적으로 접근하고 조작할 수 있게 해주는 모델이다.

점검방안

1. 글쓰기 또는 검색 기능이 존재하는 페이지에 스크립트 문장을 입력하고 글쓰기 또는 검색을 시도한다.
2. 시도하는 도중 스크립트 태그 사용으로 인한 오류나 경고 메시지가 발생한다면 취약점이 존재하지 않는 것이다.
3. 하지만 별도의 경고 메시지 없이 그대로 내용이 나타나며, 스크립트가 실행된다면 취약점이 존재하는 것이다.

대응방안

1. 웹 서버 내에서 입력 값에 정의된 문자 길이를 검증하여 javascript 등의 명령이 삽입되지 않도록 수정하고, 
   사용자 입력 폼(로그인 폼, 검색 폼, URL 등)을 대상으로 특수문자, 특수구문 필터링 규칙 적용한다.
2. 웹 서버에서 HTML 형식의 입력이 불가피할 경우에는 XSS 공격에 주로 사용되는 Tag입력을 차단한다.
3. 홈페이지 소스코드에서는 사용자가 입력한 문자열에서 〈，〉，&，"，" 등을 replace 등의 
   문자 변환함수(혹은 Method)를 사용하여 &lt, &gt, &amp, &quot로 치환한다.
4. 홈페이지 게시판 등에서 HTML 태그 허용 시, HTML 태그의 화이트 리스트를 선정한 후,
   해당 태그만 허용하는 방식 적용한다.

 

크로스 사이트 스크립트(XSS) 취약점 - 실습

 

 

intitle:게시판 inurl:zeroboard
아래와 같이 Stored XSS 방식으로 게시판에 스크립트를 작성하여,
해당 게시글을 읽는 모든 사용자에게 경고 메시지가 표시되도록 할 수 있다.

 

타 웹 사이트의 경우는 아래와 같이 웹 애플리케이션 방화벽(WAF)을 통해서 
악의적인 요청으로 의심되는 것들을 탐지하고 차단한 것을 볼 수 있다.

 

---

 

 

SQL Injection 취약점

 

 

정의
데이터베이스(DB)와 연동된 웹 애플리케이션에서 공격자가 입력 폼 및 URL입력란에 

SQL문을 삽입하여 DB로부터 정보를 열람(또는 조작)할 수 있는 취약점을 의미한다.

사용자가 웹 애플리케이션의 입력 폼이나 URL 쿼리 문자열에 SQL 구문을 포함한 악성 코드를 입력할 수 있는 경우, 

애플리케이션이 이 입력값을 제대로 검증하지 않고 SQL 쿼리에 포함시키면 SQL 인젝션 취약점이 발생하는 원리이다. 

즉, 악의적인 사용자가 입력한 SQL 구문이 기존의 쿼리와 결합되어, 원래 의도된 쿼리와는 다른 동작을 하게 된다.

 

공격 유형

1. Error-based SQL Injection (에러 기반 SQL 인젝션) : SQL 쿼리에 오류를 유도하여,
   데이터베이스에서 발생한 에러 메시지를 통해 데이터베이스의 구조나 상태를 파악한다.
   
   예를 들어, 쿼리에 잘못된 값을 주입하여 반환된 에러 메시지로 테이블 이름, 칼럼 이름 등을 알아낼 수 있다.
2. Union-based SQL Injection (유니온 기반 SQL 인젝션) : UNION 연산자를 이용해 여러
   SELECT 쿼리의 결과를 하나로 결합함으로써 공격자가 원하는 데이터를 불러온다.
   
   이 방법은 데이터베이스의 다른 테이블에서 정보를 획득하기 위해 사용된다.
3. Boolean-based Blind SQL Injection (블라인드 참/거짓 기반 SQL 인젝션) : 데이터베이스의 결과를
   반환하지 않고, 참(true) 또는 거짓(false)으로 응답하는 방식을 이용해 데이터를 유추하는 공격이다.
   
   공격자는 참/거짓으로 응답을 얻어 데이터베이스의 구조와 데이터를 유추한다.
4. Time-based Blind SQL Injection (블라인드 시간 기반 SQL 인젝션) : 쿼리가 실행될 때,
   지연 시간을 이용해 응답 시간의 차이를 기반으로 데이터를 추론하는 방법이다.
   
   데이터베이스가 특정 조건에서 시간을 지연시키도록 해 참/거짓을 확인한다.
5. Out-of-band SQL Injection (대역 외 SQL 인젝션) : 데이터베이스가 외부 서버로
   HTTP 요청이나 DNS 쿼리를 전송하도록 하여 공격자가 그 응답을 받는 방식이다.
   
   이 방법은 공격자가 명령의 결과를 직접적으로 응답을 받을 수 없는 상황에서 사용된다.
   
   예를 들어, 데이터베이스 서버가 인터넷에 연결되어 있을 때,
   공격자가 데이터를 자신의 서버로 보내도록 SQL 쿼리를 주입할 수 있습니다.

 

점검방안

1. 로그인 페이지의 경우 아이디와 패스워드 란에 [ ' or 1=1;-- ] 문자열을 입력하여, 로그인이 될 경우 취약점이 존재하는 것이다. 
   만약, 웹 서버 오류 메시지가 나타날 경우, SQL Injection 취약점의 가능성이 있으므로, 
   정보시스템, 홈페이지 보안 가이드 등을 참고하여 세부적인 점검이 필요하다.
2. 게시판 등의 게시물 링크를 복사하여, 링크의 값 중 게시판 번호(또는 글 번호) 등의
   입력 값에 인용 부호( ‘ 또는 “ )를 입력하여 접속한다.
3. DB 오류 또는 웹 서버 디렉터리가 노출될 경우, 입력 값 검증 부재로 인해 
   추가 SQL Injection 공격을 차단(특수문자 치환 등)하는 장치가 마련되어 있지 않아 취약한 것을 의미한다.
   
   

대응방안

1. 웹 서버의 오류 정보가 일반 사용자에게 노출되지 않도록 조치한다.
2. 웹 애플리케이션과 연동되는 데이터베이스의 접근 권한을 최소화하고, 
   사용자 입력 폼(로그인 폼, 검색 폼, URL 등)을 대상으로 특수문자, 특수구분 필터링 규칙을 적용한다.
3. 홈페이지 소스코드는 사용자로부터 입력되는 입력 값에 대한 검증과 예외처리를 한다.
   - 모든 입력란에 특수문자를 입력하지 못하도록 한다.
   - 입력 값에 정의된 문자 길이를 검증하여 SQL문이 추가 삽입되지 않도록 예외처리한다.

대응방안을 새운다는 것은 현실적으로 조치가 가능한 방안을 제시를 하는 것을 의미한다.

예를 들어, 대응방안이 솔루션을 도입하는 것이라면 이 솔루션을 도입하는 데에는 별도의 비용과 시간이 들어갈 것이다.

 

하지만, 회사에 비용이 부족하여 해당 솔루션을 도입할 수 없다면, 현실적으로 대응방안에 들어갈 수 없기 때문에

이는 대응방안으로써의 역할을 수행하지 못하는 것이다. 즉, 대응방안을 세울 때는 현실적으로 조치가 가능한 것을 의미하는 것이다.

 

 

---

 

 

권한인증 취약점이란 보통 사용자를 인증하는 과정에서 해당 인증 과정이 올바르게 일어나지 않아서,

마치 일반 사용자가 관리자의 권한을 얻어 갖고서 뭔가 관리자인 것처럼 행위를 하고,

내부에 존재하는 정보들을 유출하거나 2차적인 피해를 입힐 수 있게끔 공격이 가능한 취약점을 의미한다.

 

해당 취약점은 보안성 심의 과정에서 확인하게끔 되어있기 때문에, 결과적으로는 발생 빈도가 적은 취약점이다.

 

 

권한인증 취약점 : 파라미터/URL 변조

 

 

정의
웹 서버에 전송되는 모든 HTTP 요청 값(URL, 파라미터 등)에 접근 제어를 검사하지 않거나 
불완전하게 검사하는 경우, 공격자가 조작을 통해 접근 가능한 실행경로로 정보가 유출될 수 있는 취약점이다.

점검방안

1. 프록시를 통해 파라미터 값을 조작하여 인증 우회를 시도한다.
   ex) [login_id]의 파라미터 값을 [admin]으로 변경 후 전송
2. URL을 조작하여 타 사용자의 게시글 수정을 시도한다.
   ex) 운영자의 글 열람 페이지 URL(m_view.php)을 수정 페이지 URL(m_modify.php)로 변경
   
   

대응방안

1. 홈페이지 중 중요한 정보가 있는 페이지(계좌이체 등)는 재인증을 적용한다.
   예를 들면, 홈페이지에서 로그인을 한 상태로 개인 정보를 변경하려고 시도할 때, 이러한 중요한 페이지로 접근 시 
   본인인증 또는 패스워드 재입력 등의 재인증을 적용하는 것이다. 이러한 기능이 구현되어 있기 않다면 취약점이 존재하는 것이다.
2. 홈페이지 소스코드에는 안전하다고 확인된 라이브러리나 프레임워크 (OpenSSL이나 ESAPI의 보안 기능 등)를 사용한다.
3. 응용프로그램이 제공하는 정보와 기능을 역할에 따라 배분함으로써 공격자에게 노출되는 공격노출면(attack surface)을 최소화한다.

 

권한인증 취약점 : 파라미터/URL 변조 - 실습

 

 

intitle:자유게시판 inurl:zb
관리자가 쓴 게시글의 URL 내에서 ‘view’를 ‘write’로 변경하여 글 수정을 시도한다.

하지만, 위와 같이 보안조치를 적용해 놓을 것을 확인할 수 있다.

 

 

권한인증 취약점 : 세션 탈취

 

 

정의
웹 애플리케이션 인증 시 발급되는 세션 ID가 일정한 규칙이 존재하거나, 
세션 타임아웃이 너무 길게 설정된 경우 공격자에 의해 사용자 권한이 도용될 수 있는 취약점을 의미한다.

공격자가 사용자 세션 ID를 유추하거나 유출된 ID를 통해 세션을 재사용하여 악용할 수 있다.

점검방안

1. 자신의 아이디로 로그인 후 세션 값을 프록시를 이용하여 확인한 후, 
   새로운 웹 브라우저에서 해당 세션 값으로 변조하여 로그인을 시도한다. 
2. 여러 번 로그인을 시도하여 로그인 대상의 세션 값이 특정한 규칙을 가지고 바뀌는지 확인한다. 
3. 만약 일정한 규칙이 존재하는 것을 확인했다면, 기존 세션 값에 규칙을 적용하여 세션 값을 변조하여 로그인을 시도한다.
   
   

대응방안

1. 홈페이지의 세션 ID는 로그인 시마다 추측할 수 없는 새로운 세션 ID로 발급한다.
2. 세션 타임아웃 설정을 통해 일정시간(최대 30분 이상) 동안 움직임이 없을 경우 자동 로그아웃 되도록 구현한다.

 

 

권한인증 취약점 : 쿠키 변조

 

 

정의
사용자 인증 방식 중 하나인 쿠키를 변조하여 다른 사용자로 전환하거나 권한 상승이 가능한 취약점을 의미한다.

 

게시판 소스보기를 통해 관리자 ID를 파악하여, 쿠키 값 중 UserID의 값을 관리자 ID로 변경하여, 

관리자 페이지로 접근하는 등의 공격이 가능하다.

점검방안

1. 프록시를 통해 쿠키 값 변조 후 로그인 결과를 확인한다. USERLEVEL 등의 숫자를 변경하여 권한을 상승시킬 수 있다.
   
   

대응방안

1. 홈페이지는 사용자 인증 등 중요 기능 구현 시, 가급적이면 쿠키 대신 세션 방식을 사용하고 
   안전한 알고리즘(SEED, 3DES, AES 등)을 사용한다.
   
   쿠키는 사용자에 대한 정보값이 남기 때문에, 해당 정보값을 가지고 얼마든지 다른 시점에 악용할 수 있다는 단점들이 존재한다.
   
   이러한 이유로 세션이라는 것을 이용하여, 해당 세션을 유지하고 있는 기간 동안에만
   해당 값을 사용할 수 있도록 하는 방법들을 사용하는 것이 안전한 방법이라고 할 수 있다.
   
   하지만 세션을 사용하더라도  항상 안전한 것은 아니다.
   
   전자금융감독규정 등의 법령에서 명시하고 있는 가이드를 보면,
   세션을 유지하고 있는 기간은 아무 동작도 하지 않을 때, 10분을 넘기지 말라는 식으로 권고하고 있다.
   
   그래서 공격이 세션을 통해서 탈취되는 것들을 방지하기 위해서
   이런 식으로 세션이 유지되는 시간도 조절을 하면서 조치하는 것이다.  
   
   

 

---

 

 

에러처리 취약점 

 

 

정의
웹 서버에 별도의 에러페이지를 설정하지 않은 경우, 에러 메시지를 통해 서버 데이터 정보 등 일반 사용자에게는 
불필요한 즉, 공격에 사용될 수 있는 정보가 노출되는 취약점을 의미한다.

점검방안

1. URL에 웹 서버 디렉터리명을 수정하여 에러페이지를 확인한다.
   
   

대응방안

1. 홈페이지의 에러페이지는 별도의 에러페이지를 제작하여 에러발생 시 에러페이지로 리디렉션 하도록 설정한다.

 

에러처리 취약점 - 실습

 

 

URL을 직접 조작하여 시도하였을 때, 아래와 같이 

별도의 에러페이지가 제작되어 있어 에러페이지로 리디렉션 되는 것을 확인할 수 있다.

하지만 아래와 같이, 서버 소프트웨어 및 버전 정보와 같이 불필요한 정보가 포함되어 에러 메시지가 나타날 수 있다.

 

만약 노출된 버전에 취약점이 존재한다면 해당 취약점을 이용해서 공격을 시도할 수 있을 것이다.

이러한 취약점을 방지하기 위해서는 서버 설정을 통해 버전 정보를 숨기고,

디렉토리 경로를 유추할 수 없는 커스텀 에러 페이지를 설정하는 것이 좋다.

 

 

---

 

 

인용 : 한국교육학술정보원 KERIS 『웹 서버 및 홈페이지 취약점 점검 가이드