6. 애플리케이션 보안

DNS

: 도메인 정보를 관리하는 분산 데이터베이스 시스템

 

DNS 질의 순서

1. PC의 로컬 DNS Cache 검색

( 윈도우 명령어 : ipconfig /displaydns , ipconfig /flushdns)

2. hosts 파일 검색(hosts.ics를 먼저 검색 후 hosts파일 검색)

( 윈도우 파일경로 : C:\Windows\System32\drivers\etc )

( 리눅스 파일경로 : /etc/hosts )

3. DNS서버 질의

 

Recursive/Cache/Resolving DNS서버

: 관리하는 도메인이 없으며 모든 도메인 질의에 대해서 응답해주는 DNS서버

: 재귀적 질의(Recursive Query)가 들어오면 캐시에 정보를 먼저 확인하고 없으면 Authoritative dns서버에 반복적 질의(Iterative Query)를 통해 dns정보를 받아온다

: 일반적으로 ISP 업체에서 제공하는 DNS서버

 

Authoritative DNS서버

: 관리하는/위임받은 도메인을 가지고 있는 DNS서버

: 자기가 관리하는 도메인에 대해서만 응답한다

: 관리하는 도메인 영역을 '존(zone)'이라 하고 관리 도메인에 대한 정보를 담고 있는 파일을 '존 파일(zone file)' 이라 한다

: 회사/사이트별로 자신의 도메인을 관리하는 DNS서버가 해당됨

 

* PC뿐만 아니라 DNS 서버도 TTL(Time to live)이 있어 일정시간 동안만 캐시에 도메인정보를 저장한다

 

포트

응답 데이터가 512 byte 이하일 경우 UDP/53 포트 사용(일반적인 경우)

응답 데이터가 512 byte 초과 시 TCP/53 포트 사용

( any/txt 같이 데이터가 큰 질의나 존(Zone) 정보 동기화 시[Slave DNS가 마스터 DNS 존 정보를 동기화할때] 주로 사용)

 

DNS Lookup 명령어

윈도우 : nslookup [도메인] [네임서버]

리눅스/유닉스 : dig [@네임서버] 도메인 [쿼리유형] [쿼리옵션]

(네임서버는 생략가능하며 정보는 /etc/resolv.conf 에 존재)

* whois 명령 : 도메인/IP를 입력하여 소유정보, 네트워크 할당정보 등을 알수있다

 

질의유형(쿼리유형)

A : (기본) 도메인에 대한 IP주소 질의

AAAA : 도메인에 대한 IP주소(IPv6) 질의

ANY : 도메인에 대한 모든 레코드 질의, 일반적으로 요청대비 응답이 크기 때문에 DNS 증폭 DRDos공격에 활용

MX : 도메인의 메일서버 질의

NS : 도메인의 네임서버 질의

SOA : 존의 기본속성 정보 질의

TXT : 도메인에 대한 텍스트 정보 질의, 일반적으로 요청대비 응답이 크기 때문에 DNS 증폭 DRDos공격에 활용

PTR : IP에 대한 도메인 정보 질의(Reverse zone 파일이 설정된 경우)

AXFR : 존 형식에 상관없이 무조건 존 전송 요청

( 예시 : dig @마스터네임서버 도메인명 axfr )

IXFR : 존 버전을 비교하여 상위 버전일 경우 존 전송 요청

( 예시 : dig @마스터네임서버 도메인명 ixfr=버전정보 )

 

 

DNS Spoofing 공격

: 희생자에게 전달되는 DNS 응답을 조작하거나 DNS서버의 캐시 정보를 조작하여 의도하지 않은 주소로 접속하게 만드는 공격

: DNS 질의/응답은 UDP프로토콜의 비연결 특성 취약점을 이용한다(응답을 식별하기 위한 정보만 일치하면 먼저 수신한 응답을 신뢰, 이후에 수신한 응답을 모두 폐기 하는 특성)

 

공격 방법

스니핑 기반의 DNS Spoofing

 

대응방법

: 보통 동일 네트워크에서 스니핑을 이용하기 때문에 이를 탐지 및 차단한다

: 중요 사이트의 IP주소에 대해서는 DNS 질의보다 우선순위가 높은 hosts파일에 등록하여 관리

 

DNS 캐시 포이즈닝(Cache Posioning)

: DNS 서버의 캐시 정보를 조작하려는 공격

: 공격자는 특정 도메인에 질의 요청하고 DNS서버는 캐시에 공격하려는 도메인의 정보가 없을경우 Authoritative dns 서버에 질의. 공격자는 이때 Authoritative dns서버보다 빠르게 dns 응답패킷을 보내서 dns 정보를 조작 할 수 있다.

( 하지만 DNS 서버가 응답패킷을 신뢰하기 위해서는 출발지 IP/Port, 목적지 IP/Port, Transaction ID가 일치해야 하는데 출발지 IP, 목적지 IP/Port는 알수있어도 출발지 Port와 Transaction ID는 알 수 없기 때문에 공격자는 랜덤한 값으로 다수 생성하여 공격을 시도해야 한다. 스니핑 환경이면 알 수 있겠지만 보통 스니핑이 불가능한 상황이다 )

( 하지만! 한방에 23명의 사람이 모여있을때 그중에 생일이 같은 사람이 있을 확률이 50%이상이라는 생일의 역설이라는 말이 있는데 이처럼 생각보다 가능성이 높은걸 생일 공격이라고 한다. 출발지 port와 Transaction ID가를 맞출 확률이 우리가 생각한것 보다는 매우 높다는 점에서 가능한 공격으로 인식해야 한다 )

 

대응방법

: Authoritative DNS 서버는 재귀적 질의(Recursive Query)를 허용하지 않도록 설정하고, Recursive dns 서버인 경우 사용자를 제한해서 허용하도록 한다

* 재귀적 질의(Recursive Query)에 대한 제한방법( /etc/named.conf )

: DNSSEC 기술 활용(IETF에서 DNS 취약점을 개선하기 위해서 만든 기술로 DNS에 공개키 암호화 방식의 보안기능을 추가 부여하여 DNS의 보안성을 대폭 강화하는 역활을 한다)

 

 

 

DNS 마스터/슬레이브 서버

: 마스터에 있는 원본 존 데이터를 슬레이브가 동기화하는 작업을 존 전송(Zone Transfer)라 한다

: 서로 동일한 기능을 수행하며 부하분산을 통해 안전성을 높이는 역활을 한다

 

 

존 전송(Zone Transfer)에 대한 제한

: Master 서버만 운영할경우 존 전송을 허용하지 않고 Master/Slave를 운영하는 환경은 Slave만 지정해서 허용한다

설정파일 : /etc/named.conf

존 전송 허용 안함 : allow-transfer {none;};

Slave(192.168.159.137)만 허용할경우 : allow-transfer {192.168.159.137;};

 

* dig 명령의 axfr/ixfr 질의 유형을 통해 존 전송 허용 여부를 테스트할 수 있다

( ex : dig @192.168.159.149 alfisa.com axfr )

( 허용 시 정보가 출력되고 차단될 시 transfer failed라고 표시됨 )

 

* BIND 버전정보가 노출여부 확인 및 조치방법

( 버전 노출여부 확인명령 : dig @192.168.159.149 chaos version.bind txt )

/etc/named.conf options에 

version "BIND 9.3.1"; 

가 설정되어있다면

version "unknown";

으로 변경

 

-------------------------------------

HTTP

: 비연결형 구조 -> Keep-Alive옵션 사용

: 상태정보를 유지하지 않는다 -> 클라이언트(쿠키)와 서버(세션) 기술 사용

 

HTTP/1.0 버전까지는 HTTP 요청할때마다 TCP 연결하여 HTTP 응답 후 바로 TCP를 종료하는 비효율적인 구조

 

HTTP/1.1 버전부터는 Connecton헤더에 Keep-Alive 옵션이 추가되었다. 이는 TCP 연결 상태를 웹 서버 설정에 따라 일정시간 지속시키는 옵션으로 한번의 연결 이후에 요청/응답을 반복할 수 있다.

*아파치 웹 서버 설정 파일에 설정 가능(/etc/httpd.conf)

KeepAlive On     (Keep Alive 설정 On)

MaxKeepAliveRequests 100     (연결을 지속하는 동안 허용할 최대 요청 건수)

KeepAliveTimeount 15     (연결 지속 시간)

 

 

쿠키(Cookie)

: 개별 클라이언트 상태정보를 HTTP 요청/응답 헤더에 담아서 지속적으로 전달하는 작은 데이터

: 서버에서 클라이언트 식별을 위한 쿠키 정보를 생성하여 HTTP 응답헤더를 통해 전달(Set-Cookie)

영속 쿠키 : 클라이언트에 파일형태로 지속적(또는 일정시간)으로 존재하며 쿠키에 설정된 사이트 요청 시 마다 Cookie 요청 헤더에 쿠키 정보를 담아서 전달한다

세션 쿠키 : 클라이언트 메모리상에 세션이 유지되는 동안 존재하는 쿠키로 세션이 종료되면(일반적으로 웹 브라우저 종료시) 소멸된다

 

쿠키 보안 취약점

상태 정보를 클라이언트에 저장하고 HTTP 요청/응답 헤더에 담아서 전달하기 때문에 해킹 및 스니핑 공격에 의한 변조 및 노출에 취약하다. 따라서 중요정보(개인정보,비밀번호 등)를 저장할 경우에는 쿠키방식이 아닌 서버에 상태정보를 저장하는 "세션 방식"이 안전하며 부득이하게 쿠키를 사용해야 할 경우 암호화를 적용해야 한다.

 

* 세션 방식 : 서버는 개별 클라이언트를 식별하기 위해 세션ID를 부여하고 세션 쿠키를 이용하여 주고 받는다. 쿠키방식에 비해 상대적으로 안전하지만 공격자가 세션 ID정보를 탈취한다면 정상 사용자로 위장한 접근이 가능하다( HTTP 세션 하이재킹 )

 

 

HTTP 쿠키 관련 보안 설정

httponly 속성

: 'Set-Cookie 응답 헤더'에 설정하는 속성으로 클라이언트에서 스크립트를 통해 쿠키에 접근하는 것을 차단해 주는 속성

: 일반적으로 세션 ID를 저장하고 있는 세션 쿠키를 탈튀하기 위한 XSS 공격(자바 스크립트를 통해 접근 시 참조불가)에 대응하기 위해 사용, 스니핑에는 여전히 취약

: PHP 설정파일(php.ini)의 'session.cookie_httponly =1 또는 True' 설정을 통해 httponly 속성 활성화 가능

 

secure 속성

: 'Set-Cookie 응답 헤더'에 설정하는 속성으로 https(ssl/tls) 통신일 경우에만 해당 쿠키를 전송하고 http통신일 경우에는 전송하지 않는 속성, 기밀성을 보장하기 위한 목적

: http면 쿠키정보를 전달하지 않기때문에 로그인을 해도 로그인상태가 안됨, https를 통해야지만 로그인 후 세션 유지됨

: PHP 설정파일(php.ini)의 'session.cookie_secure =1 또는 True' 설정을 통해 secure 속성 활성화 가능

 

 

(주요 메소드)

GET : 요청 URI로 지정한 자원을 서버에 요청하는 메소드, 요청 메시지 바디가 없고 필요 시 쿼리 스트링(Query String)을 이용하여 제한된 데이터 전송이 가능

( 쿼리 스트링 : neverr.com?param1=value1&param2=value2&param3=value3......)

(요청 URL의 끝에 데이터를 담아서 전달하는 방식)

* GET방식은 데이터를 쿼리스트링으로 전달하기 때문에 주소창에 정보가 쉽게 노출되고 서버 access 로그상에 그대로 남아있다. 중요정보(ID/PW)를 쿼리스트링으로 전달하는것은 보안상 매우 취약하므로 POST방식으로 전달하는것을 권장

POST : 요청 URI로 지정한 자원에 데이터를 전달하여 이를 처리한 결과를 서버에 요청하는 메소드

 

(불필요한 메소드)

HEAD : GET메소드와 유사하게 요청하지만 서버 응답 시 메시지 바디를 제외하고 헤더부만 응답해주는 메소드, 주로 검색엔진에서 URL/링크의 유효성을 검증하기 위한 목적으로 사용

(HTTP 요청 메시지 바디부에 데이터를 담아서 전달하는 방식)

OPTIONS : 서버가 지원하는 메소드를 확인하는 목적으로 사용하는 메소드

CONNECTS : 클라이언트와 서버간에 터널링 목적으로 사용하는 메소드로 웹서버가 프록시 역활을 수행

PUT : 데이터를 요청 URL로 지정한 자원으로 저장하도록 하는 메소드

DELETE : 요청 URL로 지정한 자원을 서버에서 삭제하도록 하는 메시지

TRACE : 클라이언트로부터 수신한 메시지를 서버에서 그대로 반환, 루프백 테스트 용도로 사용

 

 

주요 상태코드

- 1xx : information

100 - Continue : 클라이언트로부터 일부 요청을 받았으며 나머지 정보를 계속 요청

 

- 2xx : Success

200 - OK : 요청이 성공적으로 수행되었음

 

- 3xx : Redirection (재지정 응답코드, 요청 자원의 의미가 재지정 되었음을 의미)

301 - Moved Permanently : 요청자원의 위치가 영구적으로 변경됨, 응답헤더 Location을 통해 자원의 변경된 URL정보 전달

302 - Found : 요청자원의 위치가 임시적으로 변경됨, 응답헤더 Location을 통해 자원의 변경된 URL정보 전달

304 - Not Modified : 요청자원의 위치가 변경되지 않았으니 클라이언트 로컬 캐시에 저장된 자원을 이용하라는 의미

 

- 4xx : Client Error

400 - Bad Request : 요청 메시지 문법 오류, 요청 라인이 잘못되었거나 헤더가 잘못되었거나 하는 등

401 - Unauthorized : 요청한 자원에 대한 권한이 없음

403 : Forbidden : 요청한 자원에 대한 접근이 금지되어있음(보안설정된 페이지로 공격자가 접근시 보통 403 오류가 표시)

404 : Not Found : 요청한 자원이 존재하지 않음

 

- 5xx : Server Error

500 - Internal Server Error : 내부 서버 오류

 

 

 

HTTP 응답 분할(Response Splitting) 취약점

: HTTP 요청 파라미터가 응답 헤더에 포함되는 서비스가 있다면 HTTP 응답을 분할시켜 첫번째 응답을 종료시키고 두번째 응답에 악의적인 코드를 삽입하여 XSS 등의 공격을 수행할 수 있는 취약점

 

* HTTP 요청 파라미터가 응답 헤더에 포함되는 서비스

1. 쿠키 설정에 사용되는 경우

ex) Set-Cookie : nicname=kiwi

2. 리다이렉션에 사용되는 경우

ex) location : algisa.com

 

* 개행이 2번 나오면(헤더값 끝 개행과 빈라인 개행) 응답헤더 전송이 끝났음을 의미

( 개행 : CR / LF )

( URL인코딩된 개행 : %0D / %0A )

 

시나리오

1. 희생자는 공격자에 의해 CookieValue 파라미터가 조작된 링크 등을 클릭하여 요청을 웹서버에 전달

(조작된 CookieValue 파라미터 예시)

Set-Cookie : nicname=kiwi<개행>

content-Length :0<개행>

<개행>

HTTP1.1 200 OK<개행>

헤더 : 악의적인 코드에 맞게끔 헤더 설정

빈라인

응답 메시지 바디 : 악의적인 코드

2. 서버는 요청 파라미터값에 대한 검증없이 이 값을 쿠키(nickname)로 설정하여 응답헤더에 담아 전달

3. 희생자는 서버로부터 2개의 분할된 응답을 받고 처리(두번째 응답에 악의적인 코드가 있어서 실행됨)

 

대응방안

: 사용자 요청 파라미터(입력값)이 서버에서 쿠키(Set-Cookie 응답헤더)로 사용되거나, 리다이렉션을 위해 Location 응답헤더로 사용되거나, 기타 응답헤더 설정에 사용될 경우 HTTP 분할이 발생하지 않도록 적절히 필터링하여 사용

 

-------------------------------------

FTP

: 평문 전송되어 ID/PW노출될수 있어서 암호화 서비스를 사용하거나 FTP 사용을 제한해야 한다

*암호 통신 서비스 : SFTP=SSH(TCP/22), FTPS(FTP over SSL/TLS)(TCP/990)

 

제어 채널 : 명령을 주고 받는 채널

데이터 채널 : 파일 및 데이터를 주고 받는 채널

 

 

능동 모드(Active mode)

FTP 명령을 전달하기 위해서 클라이언트 -> 서버(TCP/21) 접속하여 제어채널 생성

데이터를 전달하기 위해 서버(TCP/20) -> 클라이언트(TCP/1024 이상) 접속하여 데이터 채널 생성

 

문제점 : 만약 클라이언트에 방화벽이 설치되어 원격 FTP서버에서 클라이언트로 연결을 허용하지 않는다면 원격 FTP서버로 제어채널은 연결되지만 이후 데이터 채널 접속이 불가능하여 데이터를 받을 수 없는 문제가 발생할 수 있다

해결방안 : 능동 모드에서 데이터 채널을 생성하기 위해서는 서버에서 클라이언트로의 접속을 허용하도록 설정하거나 FTP수동 모드로 FTP서버에 접속한다.

 

 

수동 모드(Passive mode)

FTP 명령을 전달하기 위해서 클라이언트 -> 서버(TCP/21) 접속하여 제어채널 생성

데이터를 전달하기 위해 클라이언트 -> 서버(TCP/1024 이상)에 접속하여 데이터 채널 생성

 

문제점 : FTP서버는 인바운드 트래픽에 대해 방화벽 TCP/1024 이상 포트를 모두 허용해야 하는 문제점이 있다

해결방안 : 방화벽의 '상태 검사 기능(Stateful inspection)'을 통해 연결 상태를 추적하여 데이터 채널을 허용하도록 설정

 

 

FTP 보안 취약점을 이용한 공격

1. FTP 바운스 공격(FTP bounce attack)

: 능동모드(Active) FTP서버는 Port 명령을 통해 출발지IP와 Port정보를 알려주는데 공격자는 이를 악용하여 IP/Port를 무작위로 입력해보고 연결이 이루어지는지 여부를 통해 내부 네트워크를 스캔할수도 있고 내부 서버로 파일을 전송하는 등의 악의적인 행위를 할 수 있다.

: 주로 익명 FTP서버를 이용

 

2. TFTP(Trivial FTP) 공격

: TFTP는 UDP/69 포트를 사용하며 별도의 인증과정이 없는 매우 단순하고 간단한 파일 송수신 프로토콜이다.

: 네트워크 장비의 운영체제를 백업 또는 복구하거나 설정 정보를 저장하거나 가져올때 사용

: 공격자는 서버에 접근하여 파일다운 및 악의적인 파일을 생성하는 공격을 할 수 있다

 

대응방법

: inetd 환경일 경우 /etc/inetd.conf 설정파일에서 TFTP 서비스를 주석(#)처리하여 비활성화 후 inetd 데몬을 재시작

: xinetd 환경일 경우/etc/xinetd.d/tftp 에서 'disable = yes' 로 변경 후 x inetd 데몬을 재시작

: 만약 TFTP가 필요한 경우 Secure mode로 운영

* Secure mode : 최상위 디렉터리를 지정하여 다른 디렉터리로 접근 할 수 없게 제한, '-s 최상위 디렉터리' 형식으로 지정해서 설정

: inetd 환경일 경우 /etc/inetd.conf 설정파일에서 TFTP 서비스 실행 인수 부분에 -s /최상위 디렉터리로 설정

: xinetd 환경일 경우/etc/xinetd.d/tftp 에서 'server_args = -s /최상위 디렉터리' 로 설정

 

3. 익명 FTP 공격(anonymous FTP attack)

: ID가 anonymous이고 비밀번호가 없는 익명계정으로 FTP 접속이 가능한 서비스로 공격자는 서버에 있는 파일에 접근하거나 악의적인 파일을 생성하는 공격

 

대응방법 : 반드시 사용해야하는 경우가 아니면 허용하지 않는다

* vsFTP 서버의 경우 /etc/vsftpd.conf 파일에 'anonymous_enable=NO' 설정

 

 

 

FTP 접근제어 설정

: 중요계정(root)에 대해서 FTP 접속을 제한해야 한다

ftpusers : 접속을 제한할 계정정보를 담고 있는 설정 파일(root 등 추가해야함)

설정경로 : /etc/vsftpd/ftpusers

 

vsFTP서버의 경우 ftpusers파일뿐만 아니라 user_list 파일을 이용해서 계정별 FTP접속을 제한할 수 있다

/etc/vsftpd/vsftpd.conf 파일에 userlist_enable=YES 설정

/etc/vsftpd/user_list 파일에 제한할 계정정보 추가

 

 

TCP Wrapper를 이용한 IP 접근제어

: TCP Wrapper를 통해 hosts.allow/hosts.deny 파일로 IP기반으로 FTP서비스를 제한할 수 있다

FTP TCP Wrapper 연동설정 : /etc/vsftpd/vsftpd.conf 파일에 'tcp_wrappers=YES'로 설정

 

-------------------------------------

SNMP
: 여러 관리 정보를 자동으로 수집하거나 실시간으로 상태를 모니터링 및 설정할 수 있는 서비스
: UDP/161, 162 port를 사용
: 관리 시스템(Manager)과 대행자(Agent)가 통신하기 위해서는 최소 SNMP 버전, Comunity String, PDU가 일치해야 한다

SNMP 데이터 수집 방식
Polling 방식 : Manager가 Agent에게 정보를 요청하면 응답해주는 방식으로 Agent가 UDP/161 port를 사용하고 동기적 동작 방식이다.
Event Reporting 방식 : Agent가 이벤트 발생 시 이를 Manager에게 알리는 방식(Trap)으로 Manager가 UDP/162 port를 사용하며 비동기적인 동작 방식이다

* Trap : 대행자(Agent)가 어떤 정보를 비동기적으로 관리 시스템에 알리기 위해 UDP/162 로 요청
(Trap을 제외하고는 모두 동기적으로 동작)

* MIB (Management Information Base)
: 관리되어야 할 특정한 정보/자원을 객체라 하고 이러한 객체들을 모아놓은 집합체를 IB라 한다

* SMI (Structure Management Information)
: MIB를 정의하기 위한 일반적인 구조를 의미하며 ASN.1 언어를 사용한다

* Community String
매니저와 에이전트가 데이터를 교환하기 전에 인증을 위해 사용하는 일종의 패스워드로 초기값으로 public/private가 설정되어있어 변경해야한다. RW(Read Write) 쓰기 권한이 있을 경우 중요 설정을 수정할 수 있는 등 문제가 발생할 수 있어 사용을 자제하게끔 권고하고 있다.

SNMP 버전별 특징
SNMPv1 : 보안기능(인증,암호화)이 없으며 community string만 일치하면 모든 정보를 얻을 수 있다
SNMPv2 : 암호화(DES)와 해시(MD5)기능을 추가했으나 여전히 송신처 인증기능이 없다
SNMPv3 : 데이터 인증, 암호기능 및 재사용 방지, 세분화된 접근통제 등 개선된 보안서비스를 제공

SNMPv3 보안 서비스
- USM(User Security Model) : 비인가된 사용자에 의해 데이터의 변경/도청/재사용공격에 대응하는 기능을 제공
- VACM(View-based Access Control Model) : 인가된 사용자의 MIB 접근 통제 기능을 제공
- Authoritative 엔진 : SNMP 명령을 처리하거나 통지를 발생시키는 엔진으로 일반적으로 에이전트 기능을 수행하는 엔진을 나타낸다

 

SNMP 구조
Authoritative 엔진 ID / Authoritative 엔진 부트 횟수 / Authoritative 엔진시각
(msgAuthoritativeEngineID / msgAuthoritativeEngineBoots / msgAuthoritativeEngineTime)
: 재전송 공격 방지, SNMP 엔진ID/부트 횟수/엔진시각정보를 이용하여 메시지 유효시간을 계산하고 재전송 여부를 판단

사용자(msgUserName) / 인증 매개변수(msgAuthenticationParameters)
: 위장공격, 메시지 위/변조 공격 방지, 메시지 인증을 위해 HMAC(MD5,SHA)을 사용

암호 매개변수(msgPrivacyParameters)
: 도청/스니핑 공격, 정보노출 공격 방지, 메시지 암호화(DES-CBC)를 지원


NMS(Network Management System)
: 네트워크 상의 자원들을 모니터링하고 제어하기 위한 도구로, 각 요소가 가진 정보를 중앙제어센터에 제공하는 구조
: SNMP 프로토콜을 사용

-------------------------------------
DHCP (Dynamic Host Configuration Protocol)
: 서버에서는 UDP/67, 클라이언트는 UDP/68 port 사용

IP 할당 절차
1. DHCP Discover 메시지
: 클라이언트가 DHCP 서버를 찾기위해 자신의 MAC정보를 담아서 브로드캐스트

2. DHCP Offer 메시지
: DHCP서버들이 클라이언트에게 IP정보를 제공

3. DHCP Request 메시지
: 해당 IP를 사용하겠다고 서버에게 요청

4. DHCP Ack 메시지
: 서버는 해당 MAC과 IP정보를 테이블에 저장하고 할당된 주소를 클라이언트에게 전송
(클라이언트는 이 메시지를 받고 해당 IP정보를 설정)

DCHP Starvation 공격
: DHCP 서버의 할당 가능한 IP를 모두 소진하게 만들어 IP할당이 불가능하게 만드는 공격
: discover 메시지를 서로 다른 MAC주소로 대량으로 보내고 DHCP Request 메시지까지는 보낸 후에 실제로는 할당하지 않는 방법으로 공격

-------------------------------------
SQL Injection 취약점
: 사용자 입력값을 조작하여 비정상적인 데이터베이스 접근을 시도하는 공격 기법
: 인증절차 없이 접근하거나 자료를 무단으로 유출 및 변조할 수 있다

* APM 환경 : Apache, PHP, Mysql을 사용하는 환경

* URL 인코딩
: 영문,숫자,일부 특수문자를 제외하고 한국,중국, 일본 문자같이 사용할 수 없는 문자를 URL상에 안전하게 표현하기 위한 인코딩 방식을 말하며 Percent Encoding(%xx 형식으로 표현하는 16진수 표기) 방식을 사용
(0x3C = %3C, 0x27 = %27.....)
- 필수로 외워야 하는 주요 16진수값

+ 추가 기호

기호     16진수(헥사)

(            0x28

)            0x29

/            0x2F

 
id=%27+or+1%3D1%23&pass=1234
id=%27%20or%201%3D1%23&pass=1234
를 해석하면 아래와 같다
id='or 1=1#pass=1234


Form SQL Injection
: HTML Form(입력 필드의 집합) 기반 인증을 담당하는 애플리케이션의 취약점이 있는 경우 질의문의 조건을 임의로 조작하여 인증을 우회하는 기법
: 아이디/패스워드를 입력할 수 있는 로그인 페이지에서 주로 사용
: 입력필드에 ', "등을 입력했을 때 에러 메시지가 발생한다면 입력한 값이 DB서버까지 전달되어 오류가 발생한것으로 입력값에 대한 검증이 이루어지지 않는 페이지로 볼 수 있다.
: 공격자는 질의문의 조건절이 참이 되도록 질의문 조작( ' or 1=1 # )
: 공격자는 ;를 이용하여 다른 쿼리문을 입력할 수 있다
( select id from member where id=''; update membet set pass='9999' where id='kwi99' #';
: #은 MySQL에서 주석 처리할때 쓰는 기호로 MS-SQL이나 Oracle은 -- 를 사용한다


Union SQL Injection
: Union 함수를 이용하여 공격자가 원하는 select 결과를 만들 수 있다
( union - 2가지 select문 중복 제거해서 출력  /  union all- 2가지 select문 중복제거하지 않고 출력 )
( 공격 조건 : 선select문과 후select문 컬럼 개수가 일치해야하고 문자열이 호환되어야 함 )

( blind sql injection공격과 연계하여 데이터 탈취 가능 )

select id, pass from member where id='' union select 'admin','adminpass';
라고 쿼리 질의 시 아래와 같은 결과를 낼 수 있음
id        | pass
admin | adminpass
그러면
ID : 'union select 'admin', 'adminpass' #
PW : adminpass
를 입력하여 공격 가능

* 컬럼 개수 파악하는 방법
- 컬럼 개수를 하나씩 늘려가면서 공격( 'union select 'admin', 'admin' # ) ( 'union select 'admin', 'admin', 'admin' # )......
- order by문을 이용해서 하나씩 늘려가면서 공격해보고 만약 4에서 오류가 나면 컬럼개수는 3이라는걸 알 수 있음
( 'order by 2# ) ( 'order by 3# ) ( 'order by 4# ).....


Stored Procedure SQL Injection

: MS-SQL 확장 저장 프로시저를 사용해 마치 하나의 함수처럼 실행하기 위한 질의 집함

(EXEC xp_ ~~~)형식이면 sql injection공격이라고만 인지하면 됨

예시)

Mass SQL Injection

: 한번의 공격으로 대량(Mass)의 DB값이 변조되어 홈페이지에 치명적인 영향을 미치는 공격
예시)

SQL Injection 공격 유형

Error-Based SQL Injection(에러 기반 SQL Injection)

: 에러값을 기반으로 한 단계씩 점진적으로 DB(테이블명, 컬럼명 등)정보를 획득하는 방법

: 최근에는 웹서버 보안 강화로 인하여 에러 값을 노출하는 경우가 많진 않지만 과거에 많이 발견되었던 공격유형

 

Blind SQL Injection
: 오류 메시지가 아닌 질의 결과의 참과 거짓을 통해 의도하지 않은 SQL문을 다수 실행함으로써 DB정보 획득

 

게시판 검색 공간 쿼리문 : select * from table where $find like '%$search%' order by num desc;

검색($search)공간에 입력 : ' or 1=1 #, ' or 1=2 #

하여 참이면 전체값이 출력, 거짓이면 어떠한 값이 출력되지 않는다. 이 원리를 이용한다

* information_schema.tables = 데이터베이스에 있는 모든 테이블 정보를 가지고 있는 테이블, table_type 컬럼의 base table은 사용자가 생성한 테이블을 의미

* limit 0,1은 첫번째 행값만 출력, substr 1,1은 첫번째 문자만 출력이라는 뜻

: 사용자가 생성한 테이블명을 알기 위해 첫번째 테이블 첫번째 글짜를 따오는 구문으로 d가 나오게 되는데 이 값이 ='d' # 했을때 참이되면 d라는 문자열을 알수있고 이렇게 노가다(보통 툴을 씀)를 통해서 다른 테이블명과 데이터까지 알 수 있다.

 

공격문 : ' and substr((select table name from information_schema.tables where table_type='base table' limit 0,1),1,1)='d'#%'

 

 

 

SQL Injection 공격 대응 방법
: 사용자 입력값 검증을 통해 SQL구문에 사용되는 특수문자/문자열이 사용자 입력을 통해 데이터 베이스에 전달되어 실행되지 않도록 적절히 제한

- PHP 설정파일(php.ini)의 'magic_quotes_gpc = On' 설정
: gpc(get, post, cookie)로 전달되는 데이터에서 특수문자앞에 \(back slash)를 붙여서(이스케이프 처리라고함) 일반문자로 치환하여 공격을 방지
: 하지만 문제가 발생하는 경우가 많아서 최신 PHP버전(5.4버전 이상)에서는 magic_quotes_gpc 설정을 더 이상 지원하지 않으므로 mysql_real_escape_string()과 과 같은 MySQL함수를 이용해야 한다.

- mysql_real_escape_string() 함수를 통한 특수문자 이스케이프 처리(특수문자 앞에 \ 붙여서 일반문자로 치환)
ex) mysql_real_escape_string($id);  mysql_real_escape_string($pass);

- ★Prepared Statement(선처리 질의문)을 이용★
: SQL처리도 더 빠르고 SQL Injection도 방지
: 일반 질의문 방식은 DB에 요청할 때마다 질의를 컴파일(질의 분석 및 최적화)하여 생성한 후 실행하는 방식으로 사용자 입력값 조작에 따라 의도하지 않은 질의가 생성되어 실행될 가능성이 있다.
: 선처리 질의문은 외부로부터의 입력값을 제외한 질의부분을 미리 컴파일하여 생성한 후 반복적으로 입력값만을 매개변수로 전달(바인드)하여 질의문을 실행하는 방식으로 성능상의 장점이 있으며 공격자가 악의적인 입력값을 삽입하더라도 매개변수로 전달(바인드)할뿐 질의문 자체는 영향받지 않아 SQL Injection 공격을 방어하는 효과가 있다
ex) prepare("select id, pass from member where id=? and pass=?");

- ★파라미터 필터링을 통한 방지★
\, #, --, =, select, insert, update, delete, and, or 등 사용할 수 없는 문자열을 blacklist 방식으로 생성하여 차단

 

-------------------------------------

크로스 사이트 스크립트(XSS : Cross Site Script)

: 공격자가 입력이 가능한 폼(웹브라우저 URL 또는 게시판)에 악의적인 스크립트를 삽입, 해당 스크립트가 희생자(사용자) 측에서 동작하도록 하여 악의적인 행동을 수행하는 취약점

: 개인정보 및 쿠키정보(세션쿠키)를 탈취(세션 쿠키 획득 시 HTTP 세션 하이재킹 공격 가능), 악성코드 감염, 웹페이지 변조 등의 공격을 수행한다

 

XSS 점검문 : <script>allert(document.cookie);</script>

 

 

Stored XSS (저장형 XSS)

: 공격자가 취약한 웹서버에 악성 스크립트를 게시판 등을 통해 DB에 저장해 놓으면 희생자가 해당 자료를 요청(클릭)할 때 해당 악성 스크립트가 삽입된 응답 페이지가 전달되어 클라이언트 측에서 동작하는 방식

 

iframe 예시)

iframe 태그 = 웹 페이지 내 다른 페이지를 삽입시킬때 사용하는 태그

클라이언트가 iframe태그가 동작하는 것을 볼 수 없도록 width=0 height=0 설정

현재 사용자의 쿠키정보(document.cookie)를 www.attack.com/hacker/attack.php로 전달하는 공격

 

image 객체 예시)

image 객체의 src속성을 이용하여 악성 스크립트를 삽입

www.attack.com/hacker/attack.php로 사용자 쿠키정보(document.cookie)가 인코딩(encodeURIComponent)되어 전달

 

 

 

Reflected XSS (반사형 XSS)

: 악성 스크립트를 사용자에게 전송(이메일 링크 등)하여 희생자(사용자) 액션(클릭)에 의해 취약한 웹서버로 전달되고 웹서버의 응답 페이지(DB에 저장되지 않고) 에 해당 악성 스크립트가 삽입되어 희생자(사용자) 측에서 동작하는 방식

: 요청 파라미터가 응답 파라미터에 그대로 사용되는 경우

-> 링크 클릭 시 취약한 웹서버(192.168.254.129)로 id 파라미터에 악성 스크립트(URL 인코딩된)를 포함한 GET요청 메시지가 전달되고 있다.

 

(실제 사용자에게 전달되는 html문)

 

 

 

DOM based XSS (DOM 기반 XSS)

: 악성 스크립트를 사용자에게 전송(이메일 링크 등)하여 희생자(사용자) 액션(클릭)에 의해 웹서버로 전달되지만 웹서버는 응답 페이지에 악성 스크립트를 포함하지 않고(URL에만 악성 스크립트가 있는 상태) 자바스크립트만(정상적인 스크립트) 전달한다. 희생자(사용자)의 웹 브라우저에서 자바스크립트가 동작되면서 DOM객체를 실행할 때 URL 등에 포함된 악성스크립트가 동작하는 방식

: 저장형/반사형 XSS와 달리 응답페이지에는 악성 스크립트가 없고 사용자 웹 브라우저에서 발생한다

* 자바스크립트 DOM(Document Oject Model) : 문서 객체 모델로 웹페이지 내 객체를 조작/관리 할 수 있는 구조의 모델

 

예시)

<a herf="http://www.algisa.com/home/vul/vul_02_02.php?default=<script>alert()</script)">클릭하세요</a>

/www.algisa.com/home/vul/vul_02_02.php 페이지에서 DOM 자바스크립트 객체를 쓰고 default= 이후의 값을 참조하는 경우 뒤에 <script>alert()</script) 스크립트가 실행될 수 있다.

 

 

XSS 대응 방법 : 사용자 입력값을 서버단에서 검증(클라이언트 단에서 검증을 수행해도 웹 프록시가 중간에서 필터링을 우회하거나 데이터를 조작할수 있기 때문에)

 

- htmlspecialchars() 함수

: HTML 특수문자의 기능을 제거(이스케이프 처리)하고 일반문자(HTML Entity)로 처리

<, >, &, ", ' 등을 &lt; , &gt; , &amp; , &quot; , &#039; 로 변환하여 처리

 

만약 게시판 등에서 HTML태그를 허용해야만 하는 경우 HTML 태그를 화이트리스트 방식으로 선정해서 허용하는 방식을 적용해야 한다

 

 

 

 

크로스 사이트 요청 위조(CSRF : Cross Site Request Forgery)

: 공격자는 조작된 요청정보(비밀번호를 변경하는 등)를 담고있는 게시물을 취약한 웹서버에 등록(DB에 저장됨)하고 희생자(사용자)가 게시물을 읽을 경우 희생자(사용자) 권한으로 공격자의 요청이 실행됨

예시)

-> img 태그의 src속성을 통해 조작된 요청을 발생시키고 있으며 패스워드를 10102로 변경하게끔 하고, 이름과 닉네임 등 다른 정보도 변조하고 있다

 

CSRF 점검문 : <img src="조작된 요청">

 

대응방안

1. 중요한 HTTP요청(개인정보 변경 등)에 대해서는 정상적인 요청과 비정상적인 요청을 판별할 수 있는 '접근권한 정보가 포함된 토큰(CSRF토큰)'을 사용한다

(개인정보 변경 페이지 요청시 난수값으로 CSRF를 생성, 변경 요청 시 CSRF토큰을 토함해서 요청하게끔 설정)

2. 중요한 HTTP요청(개인정보 변경 등)에 대해서는 추가인증(재인증)을 유도

3. XSS 취약점을 제거(HTML 특수문자 이스케이프 처리)

 

 

 

 

서버 사이드 요청 위조(SSRF : Server Side Request Forgery)

: 검증절차는 거치지 않은 사용자 입력값을 서버간의 요청에 사용하여 악의적인 행위가 발생하는 취약점

: 외부에 노출된 취약한 웹서버가 있는 경우 공격자는 요청정보를 위조하여 접근통제를 우회하여 보호되는 내부서버에 있는 정보를 획득하거나 비정상적인 행위를 유도 할 수 있다

: 다른 서버의 정보(고객정보, 이미지 등)를 요청해야하는 웹서버인경우 공격자는 요청 파라미터를 조작하여 웹서버가 다른 서버에 요청하는 정보를 조작할 수 있다

예시)

공격자 -> 취약한 웹서버(www.algisa.com) -> 내부서버(img.algisa.com) -> 내부서버 정보(2022001.png 이미지) 획득

 

대응방안

1. 사용자 입력값을 다른 시스템의 서비스 호출에 사용하는 경우 화이트 리스트 방식으로 필터링

(만약 무작위의 입력값을 사용해야 한다면 블랙리스트 방식으로 중요정보를 필터링한다)

2. 동일한 내부 네트워크에 있는 서버 간이라도 기기인증,서비스 접근권한 등을 확인하여 요청을 처리한다

 

 

 

XSS와 CSRF 취약점 차이

(공통)

사용자(희생자)측에서 악성 스크립트가 동작한다

(차이점)

XSS : 악위적인 행위(쿠키정보 탈취, 악성코드 다운로드 등)가 클라이언트에서 발생

CSRF : 조작된 요청을 서버로 보냄으로써 악의적인 행위(개인정보 변경 등)가 서버에서 발생

 

CSRF와 SSRF 취약점 차이

CSRF : 공격자가 요청정보를 조작해서 웹서버에 사용자의 권한으로 정보조작등의 악의적인 행위를 수행

조작된 요청 발생 주체 : 사용자

SSRF : 공격자가 요청정보를 조작해서 웹서버가 내부서버에 조작등의 악의적인 행위를 수행

조작된 요청 발생 주체 : 웹서버(웹 어플리케이션

 

-------------------------------------

운영체제 명령 실행(OS Command Exceution) 취약점

: 검증절차를 거치지 않은 입력값이 명령어의 일부 또는 전부로 실행되어 의도하지 않은 시스템 명령어가 실행되는 취약점

: 소프트웨어 개발 보안 가이드라인에서는 운영체제 명령어 삽입(OS Command Injection) 보안약점으로 정의하고 있다

: 웹 어플리케이션에서 [PHP기준] exec(), shell_exec(), passthru(), system() 와 같은 시스템 명령어를 실행할 수 있는 함수를 제공하며 입력값에 대한 필터링이 제대로 이루어지지 않을 경우 발생할 수 있음

예시)

-> ; 세미클론을 사용하면 명령을 연속해서 사용할 수 있기 때문에 뒤에 cat /etc/passwd 명령의 결과를 추가로 표시해준다

 

; 뿐만 아니라 &&, ||, | 를 이용해서도 다른 명령어를 실행시킬 수 있다.

명령1 &&(short and 연산) 명령2 = 명령1(선행) 명령어가 참일경우 명령2(후행) 명령어도 수행

명령1 ||(short or 연산) 명령2 = 명령1(선행) 명령어가 거짓일경우 명령2(후행) 명령어도 수행

명령1 | 명령2 = 명령1(선행) 수행 결과를 명령2(후행)의 표준입력으로 전달

[명령2가 입력값을 요하지 않으면 결국 명령1의 결과는 무시되고 명령2의 결과만 출력됨]

 

 

대응방안

1. 블랙리스트 방식으로 명령을 연속해서 사용할 수 있는 특수문자 ( ; , && , || , | )를 필터링하고 웹방화벽 등 필터링이 가능한 보안장비를 운영 중이라면 룰셋(필터링 정책)을 적용

2. 만약 운영체제 명령을 사용해야한다면 허용 가능한 명령어만(화이트리스트 방식) 선정하여 허용 설정해야한다

-------------------------------------

파일 업로드 취약점

: 업로드 파일 타입이나 확장자를 체크하지 않고 업로드를 허용하는 경우 웹셀(web shell)이 업로드되어 서버에서 악의적인 명령이 수행되거나 악성코드 파일이 업로드 되어 이를 다운받은 사용자 PC가 침해사고를 당할 수 있다.

* 웹셀(web shell) : 웹서버 내 임의의 명령을 실행할 수 있는 서버 사이드 스크립트 파일(JSP, ASP, PHP 등의 파일)

: 파일의 개수나 크기에 제한을 두지 않을 경우 시스템 부하나 장애를 유발시킬 수도 있다

 

Form 데이터 POST 전송 시 Content-Type 유형

application/x-www-form-urlencoded : 일반적인 form/데이터 전송 시 사용하는 MIME 타입

multipart/form-data : 일반적인 폼/데이터/파일 전송 시 사용하는 MIME 타입

*MIME 타입 : 웹을 통해 파일을 전송할 때 사용하는 표준 파일 형식(타입/서브타입 형식)

(ex : test/plain, text/html, image/gif, image/png, application/octet-stream, multipart/form-data........)

 

 

* 공격자는 웹셀 파일 업로드 시 인코딩을 하여 난독화 -> 분석을 어렵게하고 패턴기반의 보안장비를 우회하기 위해 사용

* PHP eval 함수는 문자열을 php 코드로 해석하여 실행시키는 함수

 

 

 

 

대응방안

1. 업로드를 허용할 파일타입(MIME 타입)과 파일 확장자를 화이트 리스트 방식으로 체크

(공격자는 파일타입도 변조해서 전송이 가능하기 때문에 파일 확장자에 대한 추가검증이 필요)

(ex : 이미지 업로드 메뉴의 경우 image/fig, image/jpeg, image/png MIME 타입과  fig,jpeg,png 확장자만 허용)

 

2. 업로드 파일을 저장하기 위한 전용 디렉터리를 별도 생성한 후 웹서버 설정을 통해 업로드 디렉토리에 있는 서버 사이드 스크립트 파일이 실행되지 않도록 설정하거나 직접 URL 호출을 차단하도록 설정

- httpd.conf 해당 디렉터리 섹션에 AllowOverride FileINfo 또는 AllowOverride All을 추가(htaccess 파일을 따른다는 의미)

- 파일 업로드 디렉터리(var/www/html/home/download/data)에 .htaccess 파일을 생성한 후 FilesMatch 지시자를 이용하여 *.ph, *.inc, *.lib 등의 파일에 대한 직접 URL호출을 차단(Deny from all) 설정

- AddType 지시자를 통하여 .html, htm, .php, .php3, ph4 등등의 파일을 text/html MIME 타입으로 재조정하여 스크립트가 실행되지 않도록 설정한다

 

 

- 윈도우 IIS 웹서버의 경우 위 이미지와 같이 파일 업로드 디렉터리의 실행 권한을 제거할 수 있다

 

 

3. 업로드 파일 크기 제한

- 아파치 설정 파일(httpd.conf) 해당 디렉터리 섹션의 LimitRequestBody 지시자를 이용하여 최대 업로드 크기를 제한

 

-------------------------------------

파일 다운로드 취약점

: 자료실과 같은 게시판에 파라미터를 조작하여 파일명 또는 파일경로를 조작하여 비인가된 파일을 다운받을 수 있는 취약점

* 유닉스/리눅스 상대경로  :  ../ (상위경로), ./ (현재경로)

* 윈도우 상대 경로  :  ..\ (상위경로), .\(현재경로)

- 파일 다운 경로를 조작하여 index.php 파일을 다운

 

대응방안

1. 사용자가 입력하는 파일경로와 이름에 대해 허용하는 경로 의외의 디렉터리와 파일에 접근할 수 없도록 처리

2. 경로조작 문자(./, ../, .\, ..\ ) 블랙리스트 기반 필터링하도록 웹 어플리케이션 소스파일을 작성하고 웹 방화벽 등 필터링이 가능한 보안장비를 운영 중이라면 필터링 룰셋(필터링 정책)을 적용

 

-------------------------------------

경로 추적/조작/순회(Path/Directory Traversal) 취약점

: 파일 또는 디렉토리 접근이 통제되지않아 중요한 파일과 데이터에 대한 접근 및 실행이 허용되는 취약점

: 웹 어플리케이션 루트 디렉토리를 벗어나 시스템의 주요 파일과 데이터에 접근

 

예시 : /etc/passwd 파일에 접근하려고 할때

../../etc/passwd

../../../etc/passwd

..%2F..%2Fetc%2Fpasswd

..%2F..%2F..%2Fetc%2Fpasswd

..%252F..%252Fetc%252Fpasswd

등 다양한 인코딩을 적용하여 경로 조작을 시도

* 요청 페이지에서 파라미터를 어떤 방식으로 디코딩하는지 알 수 없기 때문

 

 

대응방안

1. 사용자가 임의로 접근할 수 있는 최상위 디렉터리를 웹 루프 디렉터리로 설정하여 시스템 루트 디렉터리로 접근하지 못하도록 제한(가상의 root 리덱터리를 만들어서 불필요한 루트 디렉토리 접근을 차단 - chroot 기능)

2. 경로조작 문자(./, ../, .\, ..\ ) 블랙리스트 기반 필터링하도록 웹 어플리케이션 소스파일을 작성하고 웹 방화벽 등 필터링이 가능한 보안장비를 운영 중이라면 필터링 룰셋(필터링 정책)을 적용

(../를 빈문자로 치환할경우 ....//로 요청하면 우회가능)

 

-------------------------------------

파일 삽입(File Inclusion) 취약점

: 악성파일을 서버에 전달하여 해당 페이지를 통해 악성코드가 실행되도록 하는 취약점

 

- 종류

LFI (Local File Inclusion) : 현재 로컬 웹서버에 악성파일이 위치

ex) ../download/data/localfile.php

RFI (Remote File Inclusion) : 원격 웹서버에 악성파일이 위치해있고 URL을 통해 호출

ex) http://10.10.10.20/main/remotefile.php

 

PHP 파일 삽입 가능함수 : include(), require() 

: 지정한 파일을 현재 페이지에 포함시켜 실행시켜주는 함수

 

 

대응방안

1. 소스코드에 include/require 등의 함수가 존재하는지 검증

2. (RFI 대응방안) 외부사이트에 있는 악성 스크립트 파일이 URL 형태로 include되지 않도록 PHP 설정파일인 php.ini 파일에서 'allow_url_fopen = OFF' 설정한다. 오류 메시지도 노출되지 않게 'display_errors = OFF' 도 설정

 

-------------------------------------

URL/파라미터 변조 취약점

: URL/파라미터를 변조하는 공격으로 SQL Injection, XSS 등의 공격에 활용될 수 있다

 

ID값은 세션을 통해서 전달되어야 하는데 POST 방식으로 ID 파라미터값을 전달하면 이를 변조하여 다른 계정의 정보를 열람하거나 수정할 수 있다.

 

대응방안

1. 세션(session)에 있는 정보를 이용하여 사용자 로그인 후 id정보를 해당 세션에 저장, 이를 참고하여 회원 정보를 보여주도록 한다(Get/Post 방식의 파라미터 전달 방식은 웹 프락시 등의 툴을 통해 손쉽게 노출/변조가 가능하기 때문에 입력값에 대한 검증절차/서버 세션의 활용 등을 고려해야 한다)

 

-------------------------------------

불충분한 세션 관리 취약점

: 매번 동일한 세션ID(일정한 패턴)를 발급하거나 세션 타임아웃을 너무 길게 설정할 경우 공격자가 세션을 탈취하여 접근할 수 있는 충분한 시간이 주어진다

(적절한 세션 타임아웃 시간은 10분~30분)

(탈취한 세션 ID를 이용하여 다른 브라우저에서 로그인에 성공하는걸 HTTP 세션 하이재킹이라 한다)

 

판단기준

1. 세션값을 변조하여 로그인 시도, 다중 로그인 성공하면 취약

2. 로그인과 로그아웃을 반복하여 수집된 세션ID의 패턴 분석, 분석된 패턴을 이용한 세션ID로 로그인 성공 시 취약

 

대응방안

1. 세션ID는 로그인 시마다 추측할 수 없는 랜덤한 값으로 새롭게 발급

2. PHP 설정파일(php.ini)에 'session.gc_maxlifetime = 600'  세션 타임아웃 설정을 통해 자동 로그아웃 구현

 

-------------------------------------

정보누출 취약점

: 디폴트 에러 페이지에 의한 웹서버 정보 노출

 

: 중요정보를 주석구문에 포함시켜 의도하지 않게 정보를 누출

 

 

대응방안

1. 웹서버 설정 파일(httpd.conf)을 통해 사용자 정의 에러 페이지 생성

ErrorDocument 403 /home/security/error_page.php

ErrorDocument  404 /home/security/error_page.php

2. PHP 환경의 설정파일(php.ini) 'display_errors = off' 설정을 통해 에러메시지 미출력

 

-------------------------------------

XXE 인젝션 취약점(XML eXternal Entity)

: XML 파서(XML데이터를 프로그램 내 이용할수 있게 만들어주는 라이브러리)가 외부개체(반복적으로 사용되는 문자를 정의)를 참조하는 XML데이터를 처리할 때 공격자가 삽입한 공격 구문이 포함된 외부개체가 동작하여 서버 파일 접근, 불필요한 자원 사용, 인증 우회, 정보 노출 등이 발생할 수 있는 취약점

 

 

 

악용예시) 상대경로/절대경로로 시스템 내부 중요한 파일 접근(LFI 공격형태)

 

 

악용예시) 같은 네트워크에 있는 서버의 중요한 파일 접근(RFI 공격형태)

 

 

악용예시) lol개체들을 반복적으로 참조하도록 수성하여 해당 개체를 생성하는 과정에서 서버에 부하를 발생시키는 Dos 공격 - 일종의 XML Bomb 공격

 

 

대응방안

1. XML파서에서 외부 개체를 참조하는 기능을 사용하지 않도록 비활성화(실제로 필요없음)

2. 외부개체를 선언하는 DTD(DOCTYPE 태그)를 필터링(제거 또는 치환)

 

-------------------------------------

XPath / XQuery 인젝션 취약점

: XPath / XQuery 질의문에 대한 필터링이 제대로 이루어지지 않을 경우 인증우회, 데이터를 열람 할 수 있는 취약점: 동작방식은 SQL Injection과 동일

- 데이터베이스 질의문 조작 : SQL Injection

- LDAP 질의문 조작 : LDAP Injection

- XML 질의문 조작 : XPath / XQuery Injection

 

-------------------------------------

개발 보안 관리

: 웹 어플리케이션 개발 시 보안 강화 안내서 라인을 만들어 이를 준수하도록 해야 한다

 

- 개발 보안 안내서

1. 사용자에게 전달된 값(Hidden form 필드,파라미터)을 재사용할 경우 신뢰해서는 안 된다.

2. 최종 통제 메커니즘은 반드시 서버에서 수행되어야 한다.

(클라이언트 측에서 입력값을 검증하는건 쉽게 우회가 가능하기 때문에 서버에서 최종 점검이 반드시 필요)

3. 클라이언트에게 중요 정보를 전달하지 않는다
4. 중요 정보 전송시 POST 메소드 및 SSL(HTTPS)를 적용한다

5. 중요한 트랜젝션이 일어나는 프로세스에 사용자의 비밀번호를 재확인한다

(사용자 정보 변경 등 중요한 트랙젝션이 발생하는 경우 비밀번호를 재확인하는 절차를 추가하여 CSRF 같은 공격을 예방)

6. 중요 정보를 보여주는 페이지는 캐쉬를 사용하지 못하도록 설정한다

(중요 정보를 보여주는 페이지에 no-cache 설정을 하지 않을경우 로그아웃 후 뒤로가기 버튼을 사용해서 해당 내용을 볼 수 있는 위험이 존재)

(no-cache 설정은 해당 페이지 요청 시마다 매번 서버로부터 새롭게 전송받아 사용하도록 알리는 설정)

(no-cache 설정방법 : HTML HEAD부분에 아래 내용을 추가)

7. 적절한 방법으로 암호화한다

(자체 개발한 암호화 알고리즘이 아닌 공인된 암호화 알고리즘을 사용)

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

-------------------------------------