침해대응 & CERT 10주차. 웹 취약점(4)

1. Cross-Site Scripting (XSS) 취약점

출처 : portswigger.net

 

• 여러 사용자가 보는 게시판이나 메일 등을 통해 악성 스크립트를 삽입하는 공격 기법
• 웹 서버 사용자에 대한 입력값 검증이 미흡할 때 발생한다.
• 쿠키/세션 값, 키보드 입력 값을 탈취하거나 피싱 사이트로의 접근을 유도하여 사용자에게 직접적 피해를 줄 수 있다.

 

공격자가 삽입합 악성스크립트가 사용자 측에서 어떻게 동작하는지에 따라 크게 세 가지로 분류할 수 있다.

1. Reflected XSS
   • 공격자의 악성스크립트가 URL click을 통해 사용자 화면에 즉시 출력되어 피해가 발생하는 취약점
     

     

     출처 : sk_shieldus

    
2. Stored XSS
   
   • 공격자의 악성스크립트가 데이터베이스에 저장되고 이 값을 출력하는 페이지에서 피해가 발생하는 취약점
   • 반사형(Reflected) XSS 보다 공격 대상 범위가 보다 넓다.
     

     

     출처 : sk_shieldus

    
3. DOM-based XSS
   • 피해자 브라우저에서 DOM 환경을 수정하는 방식
     ※ DOM (Document Object Model) : 브라우저가 웹 페이지를 렌더링 하는데 사용하는 모델로 HTML 및 XML 문서에 접근하기 위한 인터페이스
   • 악성스크립트가 서버와 상호작용 없이 브라우저 자체에서 실행된다
     

     

     출처 : sk_shieldus

XSS vs. CSRF

• XSS는 웹 페이지에 악성 스크립트를 삽입하는 공격인데 반해, CSRF는 사용자가 웹사이트에서 악성 action을 수행하도록 농락하는 공격이다.
• XSS는 사용자 브라우저에서 임의 스크립트를 실행하지만 CSRF는 사용자 action을 target 사이트로 한정한다.
• XSS, 특히 stored XSS의 경우 사용자가 단순히 정상적인 웹페이지를 방문하는 것만으로도 공격을 실행할 수 있어 사용자 상호작용이 비교적 필요 없는 반면, CSRF는 악성 링크 클릭, 조작된 페이지 방문 등 사용자의 상호작용이 항상 요구된다.
• XSS는 target 사이트 session을 요구하지 않지만 CSRF는 target 사이트 session을 필요로 한다.

---

대응 방안

1. 웹 서버에서 입력 값에 정의된 문자 길이를 제한 또는 검증하여 클라이언트 측에서 실행 가능한 스크립트 명령을 삽입하지 않도록 설정한다.
2. HTML 태그 사용이 불필요할 경우, 사용자 입력 값에서 HTML 특수 문자들 모두 HTML Entity로 변환하여 스크립트가 모두 일반 문자열로 인식되도록 한다.
3. HTML 태그 사용이 불가피한 경우, blacklist 또는 whitelist 방식을 이용하여 반드시 사용해야만 하는 특정 태그만 사용하도록 설정한다.
4. 웹 방화벽(WAF)을 사용하여 비정상적 데이터의 전송을 차단한다.

 

---

2. SQL Injection 취약점

출처 : PortSwigger.net

• 데이터베이스와 연동된 웹 애플리케이션에서 공격자가 입력 폼 또는 URL 입력란에 SQL 구문을 삽입하여 DB를 조작할 수 있는 취약점
• 입력란 데이터의 유효성을 검증하지 않아 발생하는 보안 취약점이다.

 

공격 방식에 따라 아래와 같이 분류된다.

1. Blind SQL Injection
   • True / False 쿼리문을 각각 입력 시 반환되는 데이터를 비교하여 데이터를 추출하는 방법.
   • 위의 반복적인 비교를 통해 DB 전체 테이블 개수와 이름, 컬럼의 개수와 이름 등 실제 데이터를 하나씩 추출하는 공격 기법.
2. Union SQL Injection
   • UNION 연산자 : 두 개 이상의 SELECT 문에 대한 결과를 하나로 묶어 DB에서 추출
   • 기존의 SELECT 문에 원하는 데이터를 조회하기 위한 UNION SELECT문을 추가하여 DB 조회.
3. Error based SQL Injection
   • DB 문법에 맞지 않는 쿼리문 입력 시 반환되는 에러 정보를 기반으로 공격하는 방법

---

대응 방안

1. 입력 란에 대한 검증 로직을 구현하여 사전 정의된 특수 문자들이 입력되지 않도록 조치한다.
   

   

2. Prepared Statement 구문을 사용하여 개발함으로써 입력 값에 들어가는 데이터가 단순 문자열로 처리되도록 한다.
   

   

3. 불필요한 데이터베이스 에러 메시지가 노출되지 않도록 한다.
4. 웹 방화벽(WAF)를 통해 비정상적 데이터의 전송을 차단한다.

---

3. 권한 인증 취약점

• 사용자 인증 등에 사용되는 정보를 수정하여 접근 권한이 없는 정보 접근 및 기밀 정보 조회/변경/악용하는 취약점

 

공격 방식에 따라 아래와 같이 분류된다.

1. URL/Parameter 변조
   • 웹 서버에서 전송되는 모든 HTTP 요청 값(URL, parameter 등)을 조작해 접근 권한이 없는 정보에 접근하는 방식.
2. 세션 탈취 (불충분한 세션 관리)
   • 사용자 로그인 시 발급되는 세션 ID를 유추하여 사용자 권한을 도용하는 방식.
3. 쿠키 변조
   • 쿠키를 변조하여 다른 사용자로 전환하거나 권한 상승을 수행하는 방식.

---

대응 방안

1. 중요 정보를 가진 웹 페이지에 MFA 등 2차 인증 적용
2. 개발 시 안전이 확인된 라이브러리 및 프레임워크를 사용하여 개발
3. 사용자 권한에 따른 ACL(Access Control List) 설정
4. 로그인 시 마다 예측 불가능한 새 세션 ID를 발급하고, 기존 세션 ID는 파기되도록 설계한다.
5. 세션 만료 시간을 설정하여 일정 시간 움직임이 없을 경우 자동으로 로그아웃되도록 설정한다.
6. 쿠키 대신 세션 방식을 사용하여 사용자 인증을 구현한다.

---

4. 에러 처리 취약점

• 에러 처리가 미흡하여 노출된 에러 메시지를 통해 웹 서버 중요 정보 등이 노출되는 취약점
• 응용 프로그램이 실행환경, 사용자 등 관련 데이터에 대한 민감한 정보를 포함하는 오류 메시지를 생성하여 외부에 제공하는 경우, 공격자의 악성 행위를 도울 수 있다.

try
{
	rd = new BufferedReader(new FileReader(new File(filename)));
}
catch(IOException e)
{
	// 에러 메시지를 통해 스택 정보가 노출됨
    e.printStackTrace();
}

---

대응 방안

1. 오류 메시지는 정해진 사용자에게 유용한 최소한의 정보만 포함되도록 한다.
2. 별도의 에러 페이지를 제작하여 다양한 에러 발생 시 해당 페이지로 redirection 되도록 설정한다.
3. printStackTrace() 메서드를 사용하지 않도록 로직을 구현한다.

---

참고 출처

 - [웹 취약점] Cross-Site Scripting(XSS) 취약점의 정의 및 대응 방안 — Maker's security

 - 웹 취약점과 해킹 매커니즘#7 XSS(Cross-Site Scripting) - ① 개념

 - 웹 취약점과 해킹 매커니즘 #6 SQL Injection 보안대책

 - [웹 취약점]SQL Injection 취약점의 정의 및 대응 방안 — Maker's security

 - [웹 취약점]권한인증 취약점의 정의 및 대응 방안 — Maker's security

 - [웹 취약점]에러처리 취약점의 정의 및 대응 방안 — Maker's security

 - [에러처리] 오류 메세지를 통한 정보 노출 (5등급)