웹 어플리케이션 취약점 7 ~ 10

크로스 사이트 요청 위조(CSRF: Cross Site Request Forgery)
개요
- 정상적인 경로를 통한 요청과, 비정상적인 경로를 통한 요청을 서버가 구분하지 못할 경우 발생할 수 있는 취약점.
- 조작된 요청정보를 담고 있는 게시물 등록(db 저장)
- 희생자가 게시물을 읽으면, 희생자 권한으로 조작된 요청 내용이 처리됨 (ex 희생자 비밀번호가 변경됨)

 

예시

/modify.php?pass=1234&pass_confim=1234
=> 회원정보 수정 요청 url

<img src="http://test.com/modify.php?pass=1234&pass_confim=1234 width=1 height=1">
=> 조작된 요청이 들어간 img 태그

 

취약점 판단기준
- img src 속성을 이용해 조작된 요청을 입력, 요청이 실행되면 취약한 것으로 판단

대응책
- 중요한 HTTP 요청에 대해서는 접근권한 정보가 포함된 CSRF토큰을 사용하거나, 재인증(추가인증)을 유도한다.

- 크로스 사이트 스크립트XSS와 공격방식이 유사하므로, XSS 취약점(입력값 필터링이 없음)을 제거한다.

 

CSRF 토큰의 사용
1. 중요한 페이지 접속시 서버에서 매번 CSRF 토큰 발급
2. 중요한 변경 요청시 발급된 CSRF 토큰 검증 후 요청처리

** XSS와 CSRF의 차이점
공통점 : 클라이언트 측에서 악성 스크립트가 동작함

차이점 : 악의적 행위의 발생 위치
XSS : 쿠키정보 탈취, 악성코드 다운로드 등이 클라이언트에서 발생
CSRF : 악의적 행위(개인정보 변경)가 서버에서 발생

정리
XSS 취약점은 악성 스크립트가 클라이언트 측에서 실행되어, 쿠키 정보를 탈취하거나 악성코드를 다운로드 하는 등 클라이언트를 중점으로 악의적 행위가 발생한다.
CSRF 취약점은, 악성 스크립트가 클라이언트 측에서 실행되지만, 희생자의 권한으로 서버에 악의적인 요청을 보내 서버(데이터베이스 변경 등)에 대한 악의적 행위가 발생한다.

 

취약점 7 END --

 

 

서버 사이드 요청 위조SSRF:Server Side Request Forgery
개요
(2021 owasp top 10에 추가된 취약점으로 중요)
- 공격자는 웹서버의 내부 요청을 조작할 수 있도록 사용자 요청 조작
- 웹서버가 내부서버(ex 이미지 서버, 데이터베이스)에 서비스를 요청하여, 내부정보를 공격자에게 유출
- 적절할 검증절차를 거치지 않은 사용자 입력값을 서버간의 요청에 사용하여 악의적인 행위가 발생하는 취약점.
- 공격자가 조작된 요청을 웹서버에 전송하여, 웹서버가 내부 네트워크에 위치한 다른 서버에 악의적인 요청을 보내는 취약점 (내부 정보 탈취, 내부 시스템 스캔 등)

CSRF 취약점과 SSRF 취약점의 차이점
1. CSRF는 공격자가 정상적인 사용자의 요청정보를 조작하여, 사용자 권한으로 웹서버에 악의적인 행위를 수행. 주체: 클라이언트
2. SSFR는 공격자가 요청정보를 조작하여, 웹서버가 내부 서버에 조작된 요청을 하도록 함. 주체 : 웹서버

 

실습

정상
: 공개된 웹서버는 사용자 입력 파라미터로 전달받은 과일을 내부 이미지 서버에 URL로 요청해 사용자에게 응답한다
http://test.com/board/view.php?url%3Dhttp%3A%2F%2Fimg.test.com%2Fapple.png

악의적 요청
: 공격자는 고객 정보가 이미지 서버에 위치하고 있다는 사실을 알아내, 웹서버로 요청
http://test.com/board/view.php?url=http%3A%2F%2Fimg.test.com%2FcustImg%2F20240328.png

=> url= 항목이 있으면 SSRF 취약점 의심

 

대응책
- 사용자 입력값을 다른 시스템 서비스 호출이 사용하는 경우, 사용자 입력값을 화이트리스트 방식으로 필터링한다.
- 무작위 입력값을 사용해야 하는 경우 블랙리스트 방식으로 필터링한다.
- 동일한 내부 네트워크 서버간이라도 기기인증, 서비스 접근 권한 등을 확인하여 처리한다.

 

 

취약점 8 END --

 

 

운영체제 명령 실행 (OS Command Execution) 취약점
개요
- 적절한 검증절차를 거치지 않은 사용자 입력값이 운영체제 명령어의 일부 또는 전부로 구성되어 실행되는 경우, 의도치 않은 시스템 명령어가 실행되어 부적절하게 권한이 변경되거나 시스템/운영에 악영향을 미칠 수 있다
- 개발보안 가이드라인 : 운영체제 명령어 삽입 (OS Command Injection) 보안약점 이라고도 정의
- 웹 어플리케이션에서 system(), exec()와 같은 시스템 명령어를 실행할 수 있는 함수가 있고, 사용자 입력값 필터링이 제대로 되지 않을 경우 공격자가 시스템 명령어를 호출할 수 있는 취약점

php 코드의 일부
: $cmd  = shell_exec('ping -c 4 ' . $target);

echo "<div>".$cmd."</div>";

정상
http://test.com/ip_ping.php?ip%3D192.168.0.1

악의적 요청
http://test.com/ip_ping.php?ip%3D192.168.0.1%3Bcat%20%2Fetc%2Fpasswd

: 콜론; %3B 를 이용해 다수의 시스템 명령어 실행

 

=> ping 명령어의 인자값 ip를 입력받아 실행하는 서비스. ip 뒤에 콜론으로 악의적인 시스템 명령어를 붙여 cat으로 /etc/passwd 파일을 보려고 하고 있다.

 

2개 이상 명령어 연속 실행 가능한 구분자

; : 선행 명령어 수행 후 후행 명령어 수행 ( %3B )
&& : 선행 명령어 수행이 참일 때 후행 명령어 수행 ( %26%26 )
|| : 선행 명령어 수행이 거짓일 때 후행 명령어 수행 ( %7C%7C )
| : 선행 명령어 수행 결과를 후행 명령어의 입력으로 전달 ( %7C )

 

안전한 사이트
: 블랙리스트 체크(;, &&, ||, | 등)로 입력값 필터링

 

php 운영체제 명령어 실행 함수
: shell_exec, passthru, exec, system

 

대응책
- 사용자 입력값에 대해 운영체제 명령어를 실행할 수 있는 문자열 필터링/치환
- 웹방화벽 등 필터링이 가능한 보안장비의 룰셋 적용
- 허용 가능한 명령어 리스트(화이트리스트)를 선정하여 해당 명령어만 실행할 수 있도록 설정

 

 

취약점 9 END --

 

 

 

파일 업로드 취약점
개요
- 파일 업로드가 가능한 페이지에 악성 스크립트 파일 업로드
- 업로드 파일 필터링 미흡으로 웹서버에 업로드가 되고, 웹셀을 이용한 명령 실행
- 업로드 파일 타입이나 확장자를 체크하지 않고 업로드를 허용하는 경우 웹셀이 업로드되어 악의적인 명령이 수행되거나 악성코드 파일이 업로드되어 침해사고를 당할 수 있음
- 웹셀Webshell : 악의적 목적으로 웹서버 내 임의의 명령을 실행할 수 있는 서버사이트 스크립트 파일. (JSP, ASP, PHP 등)
- 업로드 파일 개수나 크기에 제한을 두지 않으면 다량의 업로드로 시스템 부하나 장애 유발 가능

 

(정적 자원 : 클라이언트가 요청하면 그대로 내려주는 파일 (html, 클라이언트 사이드 스크립트, css 등)
동적 자원 : 클라이언트가 요청시 서버에서 직접 실행하여 결과를 내려주는 파일 (JSP, ASP, PHP 등))

 

HTML 폼 데이터 전송 방식
<form method="post" action="/board_upload" enctype="multipart/form-data">
 <input type="file">
</form>

 

폼 데이터 POST 전송시 Content-type 유형
1. application/x-www-form-urlencoded : 일반적인 폼 데이터 전송시 사용하는 MIME 타입
2. multipart/form-data : 파일 전송시 사용하는 MIME 타입

MIME 타입 : 웹을 통해 다양한 파일을 전송할 때 사용하는 표준 파일 형식
- text 타입 : 텍스트 포함 모든 문서 (test/plain, text/html 등)
- image 타입 : 이미지 (image/jpg, image/png 등)
- application 타입 : 모든 종류의 바이너리 데이터 (application/pdf, application/xml 등)

 

 

시험에서 출제된 GET과 POST 타입의 차이점(클라이언트 히스토리, 서버 로그 관점으로)
GET 방식 : 요청 URL 끝에 데이터를 담아서 전달하는 방식. 클라이언트 히스토리, 서버 로그 정보에 고스란히 남아 보안 이슈가 있음.
POST 방식 : HTTP 요청 메시지 바디부에 데이터를 담아서 전달하는 방식. 캐시가 남지 않지만, 보안성 측면에서 안전함.

 

 

Content-Type: application/x-www-form-urlencoded
URL 인코딩되어 쿼리 스트링으로 메시지 바디부에 담아 전송된다.

 

패킷정보 예시
Content-Type:multipart/form-data; boundary=------------7e42a9c

------------7e42a9c
Content-Disposition: form-data; name="title"

 

타이틀
------------7e42a9c
Content-Disposition: form-data; name="content"

 

내용
------------7e42a9c
Content-Disposition: form-data; name="upload"; filename="wepshell.php"
Content-Type: application/octet-stream

<?php
eval(base64_decode("ZHVtbXljb250ZW50X3Rlc3RfdGV4dF9kdW1teV90ZW1w ... 하략

 

eval("문자열")
: 문자열을 php 코드로 해석하여 실행시키는 함수

base64_decode()
: 인코딩된 php 코드를 디코딩하여 실행되도록 하는 역할

웹셀의 내용을 base64 인코딩(난독화) 해놓는 이유 : 분석이 어렵게 하기 위해 / 패턴 기반의 보안 장비를 우회하기 위해

 

 

대응책

- 화이트리스트로 업로드를 허용할 파일 타입을 체크 (ex $white_list = array('image/gif', 'image/jpeg', ... 하략); )

- 화이트리스트로 파일 확장자명 추가 검증

(공격자가 Content-Type를 image/~ 로 조작하여 전송할 수 있다. Content-Type만 체크해선 부족함.)

 

 

취약점 10 END --