웹 어플리케이션 취약점 16~18, 웹서버 취약점 1,2

기타 웹 애플리케이션 취약점
1) HTTP 응답 분할 (Response Splitting)
- 클라이언트의 HTTP 요청에 포함된 요청 파라미터값이 HTTP 응답 헤더에 포함되어 다시 클라이언트에게 전달될 때, 파라미터 값에 개행문자인 CR과 LF가 포함되어 있으면 HTTP 응답이 2개 이상으로 분리될 수 있다. 공격자는 개행문자를 이용해 첫 번째 응답을 종료시키고, 두 번째 응답에 악의적인 코드를 삽입해 XSS 등의 공격을 수행하는 취약점.

*개행문자 CR(%0D) 커서의 위치를 맨 앞으로
                 LF(%0A) 커서를 다음 행으로 이동

공백(0x20=%20)

 

(클라이언트가 보낸)HTTP 요청 파라미터가, 응답 헤더에 포함되는 서비스가 있다면?
ex Set-Cookie(쿠키 설정시), Location(리다이렉션시)

 

공격자는 Content-Length를 0으로 설정하고, 빈 라인을 넣어서 첫 번째 응답 메시지를 강제로 끊어버린다.
두 번째 응답 메시지에는 악의적 메시지를 담는다.

정상 응답 메시지
Set-Cookie:aaa=abce4567(개행)
다른 파라미터들:값(개행)
(개행)

응답 메시지 바디 : 정상 응답 메시지 바디

악의적 응답 메시지
Set-Cookie:aaa=abce4567(개행)
Content-Length:0(개행)
(개행)                                  <- 응답을 끊어버리는 시점
HTTP/1.1 200 CK (개행)    <- 두 번째 응답 메시지 시작
헤더값들(개행)
(개행)
응답 메시지 바디 : 악의적 코드들

 

동작 방식

1. 공격자는 희생자에게 조작된 파라미터가 포함된 요청을 배포함
2. 희생자는 클릭을 하는 순간 웹서버로 조작된 요청이 전달
3. 웹서버 응답이 돌아오는데, 응답은 두 개로 분할되며 두 번째 응답에 악의적 스크립트가 들어있음.

 

 

조작된 파라미터가 포함된 요청

/login.jsp?cookieVal=user1(개행)
Content-Length: 0(개행)
(개행)
HTTP/1.1 200 OK(개행)
Content-Type: text/html(개행)

... 하략

 

인코딩된 조작된 파라미터가 포함된 요청                         ┌ :     ┌공백          ┌개행 두 번(첫번째 응답 종료)
/login.jsp?cookieVal%3Duser1%0D%0AContent-Length%3A%200%0D%0A%0D%0A HTTP%2F1.1%20200%20OK0D%0AContent-Type%3A%20text%2Fhtml ... 하략

 

 

대응책
- 클라이언트 요청 파라미터가 서버에서 쿠키로 사용되거나, 리다이렉션을 위해 응답 헤더로 사용되거나, 기타 응답 헤더 설정에 사용될 경우, 응답이 분할되지 않도록 적절히 필터링하여 사용

 

 

취약점 16 END --

 

XXE(XML External Entity) Injection 취약점
개요
- 취약한 XML 파서가 외부개체(External Entity)를 참조하는 XML 데이터를 처리할 때 공격자가 삽입한 공격 구문이 포함된 외부 개체가 동작하여, 서버 파일 접근, 인증 우회, 정보 노출 등이 발생할 수 있는 취약점

XML의 구조
- XML 문서에는 DTO(문서유형 선언)를 포함할 수 있고, DTD는 XML 개체를 정의할 수 있다

- DTD는 <!DOCTYPE> 태그 내에 위치

- 계층적 구조

- 내부개체 : DTD 내부에 직접 정의한 개체
- 외부개체 : 외부 자원등에서 가져와서 정의함. SYSTEM 키워드 사용

<?xml version="" encoding="" ?>
<!DOKTYPE ITEM[                                                          <- DTO 선언
  <!ELEMENT NAME (NAME.CONTENTS)>
  <!ELEMENT CONTENTS (NAME.)>
  <!ENTITY test "테스트 벨류">                                         <- 내부개체
  <!ENTITY test SYSTEM "file://www/html/entity.txt">      <- 외부개체 (SYSTEM 키워드 사용)
]>
<ITEM>
  <NAME>TEST NAME</NAME>
  <CONTENTS>$test;</CONTENTS>                               <- 참조방식 &개체명; 
</ITEM>

 

 

내부개체 악용 예시
<!DOKTYPE ITEM[
   <!ENTITY test SYSTEM "file:///etc/passwd">
]>
<TEST>
  <RESULT>&test;</RESULT>
</TEST>

- XXE 인젝션을 이용한 LFI(Local File Inclusion) 공격 형태

 

외부개체 악용 예시

<!DOKTYPE ITEM[
   <!ENTITY test SYSTEM "http://info.test.com/home/memberInfo.txt">
]>
<TEST>
  <RESULT>&test;</RESULT>
</TEST>

- 외부적으로 접근 불가능한 주요정보 페이지를, XML 파서를 이용해 내부에서 호출하여 중요정보에 접근

- XXE 인젝션을 이용한 RFI(Remote File Inclusion) 공격 형태

 

 

도스DoS 공격 악용 예시
<!DOKTYPE ITEM[
   <!ENTITY test "test">
   <!ENTITY test1 "&test;&test;&test;&test;&test;&test;&test;&test;">
   <!ENTITY test2 "&test1;&test1;&test1;&test1;&test1;&test1;&test1;&test1;">
   <!ENTITY test3 "&test2;하략">
   <!ENTITY test4 "&test3;하략">
   <!ENTITY test5 "&test4;하략">
]>
<ITEM>&test5;</ITEM>

- 하나의 개체가 다른 개체를 반복적으로 참조하도록 구성하여 서버에 부하를 발생시킴 (XML Bomb 공격)

- 다수의 개체들을 반복적으로 참조하여 생성함으로써, 서버의 메모리 자원 소모 발생

 

 

대응책
- XML 파서의 외부 개체 참조 기능을 사용하지 않도록 비활성화한다.
- PHP의 경우 libxml_disable_entity_loader(true); 설정
- 외부 개체를 사용하지 못하도록 외부개체를 선언하는 DTD를 필터링 또는 제거

 

(XXE 인젝션 취약점은 2021 OWAST TOP 10에 포함됨)

 

 

 

취약점 17 END --

 

(종류 : SQL 인젝션, LDAP 인젝션, XPath/XQuery 인젝션)

 

XPath/XQuery 인젝션 취약점

개요

- 데이터베이스와 연동된 웹 어플리케이션에서, XPath 또는 XQuery 질의문에 대한 필터링이 제대로 이루어지지 않을경우, 공격자가 조작된 질의문을 삽입하여 인증우회를 통해 중요 정보를 열람할 수 있는 취약점

 

대응책
- XPath, Xquery에 사용되는 외부 입력데이터에 대해 특수문자/쿼리 예약어 필터링
- 인자(파라미터)화된 쿼리문 사용 (선처리 질의문 Prepared Statement 처럼)

 

 

악성 컨텐츠 취약점
- 입력값 필터링이 제대로 이루어지지 않으면 악성 컨텐츠를 삽입할 수 있다

대응책
- SQL 인젝션, Cross Site Script, 파일 업로드를 통한 위변조 기법 등을 통해 삽입되므로 해당 취약점들을 제거

 

 

불충분한 인증 및 인가 취약점
- 사용자 인증 미흡으로 공격자가 파라미터로 전달되는 값을 수정하여 사용자 도용 및 개인정보 노출 문제가 발생하는 취약점
- 인증: 자신의 신원을 알리고, 신원이 올바른지 증명 Authentication / 인가 : 인증에 성공한 사용자가 자원에 대해 접근/사용을 허용할지 결정하는 과정 Authorization

 

 

취약한 패스워드 복구 취약점
- 비밀번호 찾기 기능 또는 임시 비밀번호 발급시 사용자 인증이 미흡하거나 비밀번호를 화면에 즉시 출력할 경우 공격자가 불법적으로 타 사용자의 비밀번호를 획득/변경/복구할 수 있는 취약점

대응책
- 사용자를 식별하기 위한 수단 활용 시 그 사용자의 유일한 값 사용
- 본인인증 메커니즘을 추측 불가하게 구현, 임시 패스워드 발급시 안전한 난수값 사용

 

 

자동화 공격 취약점
개요
- 특정 프로세스에 대한 접근시도 횟수 제한을 설정하지 않을 경우, 공격자가 자동화 툴 및 봇을 활용하여 일분에 수백 번의 접근을 시도할 수 있다.
- 이로 인해 자동으로 수많은 프로세스가 진행되어 시스템 성능에 영향을 미칠 수 있는 취약점

대응책
- 일정 횟수 이상 로그인 시도가 발생시 자동화 공격으로 인식하고 로그인을 할 수 없도록 차단
- 사용자가 사람인지, 프로그램인지 구별할 수 없도록 캡차CAPTCHA 를 적용

- 캡차CAPTCHA는 실제 사람인지 프로그램인지 구별하기 위한 방법. 문자나 숫자를 그림으로 변환하고 왜곡되거나 덧칠되어 기계가 자동으로 읽기 어려운 상태로 만드는 것이 특징.

 

 

데이터 평문전송 취약점
- 민감한 데이터가 평문으로 송수신 될 경우 감청(스니핑)을 통해 획득할 수 있는 취약점

대응책
- 중요 데이터 송수신시 암호화 적용
- 보안 서버 SSL(HTTPS) 등 암호화 통신 적용

 

 

쿠키Cookie 변조
- 사용자 인증 방식 중 하나인 쿠키를 공격자가 변조하여 다른 사용자로 전환하거나 권한 상승이 가능한 취약점
- 클라이언트에 저장되는 쿠키는 변조위험에 노출되어 있으나 활용분야가 다양하고 구현이 쉽다는 이유로 현재까지 많이 사용됨

대응책
- 웹 어플리케이션 운영 시 가급적 쿠키방식 대신 세션 방식을 사용하는 것을 권장. 부득이할 경우 암호화 적용
- 세션 방식은 서버의 자원을 사용하여 접속자별로 세션을 생성하여 사용자의 정보를 각각 지정할 수 있는 객체. 페이지의 접근 허가/금지하거나 사용자 별 정보를 저장할 때 많이 사용함

 

개발 보안 관리
- 사전 작업으로 서비스에 사용하는 웹 서버와 웹 어플리케이션 서버의 환경 설정에 대한 보안 강화 안내서라인을 만들어 이를 준수하도록 해야 한다

개발 보안 안내서
1) 사용자에게 전달된 값을 재사용할 경우 신뢰해서는 안 된다 (ex Hidden Form 필드, 파라미터)
2) 최종 통제 메커니즘은 반드시 서버에서 수행되어야 한다
- 클라이언트 사이드 스크립트 등을 사용해 입력값을 검증하는 것은 쉽게 우회될 수 있으므로, 서버에서 최종 점검하는 것이 반드시 필요
- 서버 부하를 줄이기 위해 1차적으로 클라이언트에서 검증할 수 있으나, 보안통제 수단으로 사용할 수 없다.

3) 클라이언트에게 중요 정보를 전달하지 않는다
- 클라이언트의 컴포넌트에 중요 정보를 하드코딩해선 안된다. 쿠키에 중요 정보를 전달할 경우 암호화해서 사용

4) 중요정보 전송시 POST 메서드 및 SSL(HTTPS)을 적용한다

- GET 메서드는 URL 상에 정보가 그대로 노출됨
5) 중요한 트랜젝션이 일어나는 프로세스에 사용자의 비밀번호를 재확인한다(재인증)

- CSRF 취약점 (Cross Site Request Forgery) 에 대응
6) 중요 정보를 보여주는 페이지는 캐쉬를 사용하지 못하도록 설정한다
- no-cache 설정을 하지 않을 경우, 로그아웃을 한 이후에도 뒤로가기 버튼을 통해 해당 내용을 볼 수 있는 위험이 존재한다.

- HTML HEAD 부분에 아래 내용을 추가

<meta HTTP-EQUIV="Pragma" CONTENT="no-cache">                    <- http 1.0
<meta HTTP-EQUIV="Cache-Control" CONTENT="no-cache">             <- http 1.1

7) 적절한 방법으로 암호화한다
- 공인된 암호화 알고리즘(AES, 3DES) 사용 고려
- 암호화키를 사용하지 않는 알고리즘은 암호화 알고리즘이 아니며 기밀성을 보장할 수 없다 (base64 인코딩은 암호화 알고리즘이 아님)
- 암호화키는 하드코딩되면 안되며 제한된 사람만 접근 가능하도록 해야한다

8) 각 언어에서 제공하는 보안 수단을 이해한 후 사용

 

 

취약점 18 END --

 

 

디렉터리 리스팅Directory Listing 취약점
- 서버의 미흡한 설정으로 인해 인덱싱(리스팅) 기능이 활성화 되어 있을 경우, 공격자의 강제 브라우징을 통해 서버 내 모든 디렉터리 및 파일 목록을 볼 수 있는 취약점
- 인덱싱 기능이 활성화된 경우 서버 구조, 백업파일, 소스파일, 중요 파일들이 노출될 수 있다

 

1. 디렉터리 리스팅 취약점 공격 요청 메시지
ex GET /home/board/ HTTP/1.1
=> 특정 페이지가 아닌 디렉터리 경로를 요청하고 있음

이에 대한 응답 예시

HTTP/1.1 200 OK Date: ~~ Server: ~~ Content-Length: 2111 ... 중략 <html>  <head>   <title> Index Of /lome/board </title>  </head>  <body>   <h1>Index of /home/board</h1>   <table><tr><th></th><th>Name</th><th>List modify</th><th>Parent Directory</th><th>Size</th><th>Description</th></tr></table>   중략 ...  </body> </html>

 

Q. 해당 응답 예시를 보고 어떤 취약점인지 적고 이유를 서술하시오
A. 디렉토리 리스팅 취약점. 응답 상태코드가 정상을 의미하는 200(OK)이고 응답 메시지를 살펴보면 title이 Index Of 디렉토리 URL이며, body 내용에는 Name, Last modify 등 디렉토리 정보에 대한 내용들이 나타나 있다.

 

또는

이런 캡쳐 이미지도 해당됨

 

Q. 해당 응답 예시를 보고 어떤 취약점인지 적고 이유를 서술하시오
A. 디렉토리 리스팅 취약점. 해당 취약점이 존재할 경우, 웹 브라우저상에 해당 디렉터리 내의 디렉터리/파일 정보가 그대로 노출된다. 또한 파일을 클릭하면 내용을 확인할 수 있어 정보가 노출된다.

 

 

대응책
1) 아파치 웹서버 httpd.conf 설정에서 디렉터리 인덱싱 기능 제거 : Options 지시자의 Indexes 인덱시스 제거
<Directory>
   Options Indexes           <- 디렉터리 인덱싱 기능 허용 인덱시스

   Options None               <- 디렉터리 인덱싱 기능 차단 논
</Directory>

(기존 Options에 다른 기능들이 있을 경우, Indexes만 지워주면 된다)

2) 윈도우 IIS 웹서버 환경에서 디렉터리 인덱싱 기능 제거
- 홈 디렉터리 메뉴의 디렉터리 검색 체크 해제

3) Tomcat 웹서버 환경에서의 디렉터리 인덱싱 기능 제거
web.xml
<init-param>
    <param-name>listings</param-name>
    <param-value>false</param-value>
</init-param>

 

 

웹 서비스 메소드 설정 취약점
- GET, POST 메소드 이외의 불필요한 메소드를 허용하지 않는다

telnet을 이용해 지원하는 메소드 확인
ex telnet 192.168.0.1 80로 접속하여

OPTIONS / HTTP/1.1

OPTIONS 메소드로 요청하여 Allow 응답헤더에서 지원가능 메소드를 확인가능

 

 

대응책
- 아파치 웹서버 httpd.conf 불필요한 메소드 차단 설정. 해당 디렉터리 섹션에 LimitExcept.

<Directory "설정할 폴더디렉터리">
 <LimitExcept GET POST>
   Order Allow,Deny
   Deny from all                                  <- GET, POST 외에는 다 차단하겠다는 뜻
 </LimitExcept>

</Directory>

 

 

관리자 페이지 노출 취약점
- 관리자 페이지가 추측 가능한 형태로 구성되어 있을 경우, 공격자가 관리자 페이지에 쉽게 접근할 수 있으며 무작위 대입 공격(Brute Force Attack)을 통해 관리자 권한을 획득할 수 있는 취약점

 

(실무) 관리자 페이지/사이트
1. 사용자 인증 강화
- 2 Factor 인증 : 지식기반/소유기반/바이오 인증 중 2가지 이상
- 2 Channel 인증 : 서비스 채널, 인증(ex ARS 인증)채널

 

취약사이트

- /admin.php, /manager.php 등의 추측 가능한 페이지 이름.

- 접근제어가 없어 아무나 접근 가능.

 

대응책

- 관리자 페이지를 추측하기 어렵게 만들고, 접근제어 설정
아파치 웹서버 httpd.conf
<Directory "/var/www/html/admin">
   Order Deny,Allow                               <- 뒤쪽의 정책이 우선되므로, Allow 정책이 우선됨
   Deny from all
   Allow from 192.168.11.1             ( 192.168.11.0/24 대역도 가능 )
</Directory>

+ Allow from 192.168.11.1 192.168.11.2 192.168.11.3 ... 이렇게 공백으로 구분하여 리스트 허용도 가능

 

 

웹서버 취약점 1 END --

 

 

위치공개 취약점
- 소스코드를 수정하였을 경우 백업파일, 로그파일, 압축파일과 같은 파일이 자동으로 생성되어 웹 어플리케이션 상에 노출될 경우 공격자가 유추 후 직접 접근을 요청하여 정보를 획득할 수 있는 취약점
- 불필요한 파일 삭제, 서비스와 관련없는 디렉터리는 일반 사용자의 접근이 불가능하도록 적절한 접근제어 수행

 

(실무에서는 보편적으로

개발 시스템 > 검증(테스트)시스템 > 운영 시스템 순으로 서비스에 반영됨)

 

취약한 사이트
- 개발소스 운영 이관 시 사용한 소스 압축파일을 운영 웹서버에 삭제하지 않고 그대로 보관한 경우, 외부에서 이를 유추하여 다운로드 가능

 

대응책
- 불필요한 파일 삭제 및 적절한 접근제어 설정 (아파치 웹서버 httpd.conf)
1) .gz 파일
<Files ~ "\.gz$">       또는 <FilesMatch "\.gz$">
   Order Allow,Deny
   Deny from all
</Files>
2) .bak 파일
<Files ~ "\.bak$">
   Order Allow,Deny
   Deny from all
</Files>

ULR을 통한 접근제어를 설정. 모든 접근에 대한 차단.

 

 

검색엔진 정보 노출 취약점
개요
- 검색엔진에 의해 웹 사이트 해킹에 필요한 정보(시스템/개인정보)가 검색되어 해킹의 빌미가 제공되는 취약점
- 로봇 배제 표준은 검색 로봇에 대한 웹 사이트의 디렉터리 및 파일들에 대한 검색조건을 명시해놓은 국제 규약. 접근제한에 대한 설정을 robots.txt 파일에 기술한다.
- 검색로봇은 로봇배제표순 robots.txt를 확인하고 이를 준수하여 컨텐츠를 수집한다. (악의적인 검색엔진은 무시하고 컨텐츠 수집)

 

 

robots.txt 설정방법
1) 로봇의 이름을 적는 User-agent와 URL의 접근허용 여부를 적은 Allow/Disallow로 구분
2) 반드시 웹 사이트의 최상위주소(루트 디렉터리)에 저장. 하위디렉터리에 효력이 없음

 

설정 예

User-agent: * Disallow: /	모든 검색로봇에 대해 웹사이트 전체 접근 허용
User-agent: Yeti Disallow:	Yeti 검색로봇에 대해 웹사이트 전체에 대한 접근 허용. (Disallow가 공백이면 Allow: / 와 같다.)
User-agent: * Disallow: /admin/ Disallow: /private/	모든 검색로봇에 대해 admin, private 폴더에 대한 접근 차단
User-agent: Googlebot Disallow: /admin/login.html	Googlebot 검색로봇에 대해 admin/login.html 페이지 접근 차단
User-agent: Googlebot Disallow: /admin/ Disallow: /*.pdf$ Disallow: /*.xml$	Googlebot 검색 로봇에 대해 admin 디렉터리와 모든 pdf 파일, 모든 xml 파일에 대한 접근 차단
User-agent: * Disallow: / Allow: /$	모든 검색로봇에 대해 루트 페이지만 접근 허용

- 대소문자를 구분한다. user-agent 안됨. User-agent, Allow, Disallow 이렇게 대소문자 구별

- 디렉터리는 /로 끝나야한다 ( ex /admin 이 아니라 /admin/ )

- 설정명과 콜론은 붙어있어야 한다. Allow : 이렇게되면 안되고, Allow: 이렇게 붙여서 씀

- 서로 다른 검색 로봇에 대한 설정을 할 때는 한 줄을 띄워야한다.

잘못된 설정	올바른 설정
User-agent: Goole Disallow: User-agent: Naver Disallow: /admin/	User-agent: Goole Disallow: User-agent: Naver Disallow: /admin/

- 설정파일 위치는 최상위 디렉터리(루트)여야 한다.

ex http://www.test.com/robots.txt 에 있어야 함

 

 

tistory에 입력해보았다 /login 로 시작하는 페이지와 /auth로 시작하는 페이지에만 비허용

 

브라우저 주소창에 '웹 사이트 URL/robots.txt'를 입력하여 robots.txt를 확인할 수 있다.

( /login의 경우, 폴더든 파일이든 /login으로 시작하는 모든 경로에 대해 차단한다는 뜻. 단, Allow로 /login/fail이 지정되어 있을 경우 지정된 경로로는 접근가능 )

 

 

웹서버 취약점 2 END --