웹 취약점 진단 관련 끄적임

웹 취약점 진단 관련한 끄적임

---

1. 단순 정보 노출

---

단순 정보 노출 취약점은 말 그대로 민감한 정보가 노출되는 것으로 개발 과정의 코멘트 (소스 코드 내 주석) 또는
에러 메시지 등에서 의도하지 않은 정보가 노출되는 취약점을 의미한다.

판단기준은 아래와 같다.

1. 에러 페이지에 웹 서버 또는 WAS 버전 정보, 절대경로, 에러메시지 노출
2. HTML 소스보기를 통해 확인시, 주석 형태로 남아있는 테스트용 아이디/패스워드, 관리자 페이지 URL 정보 존재할 경우
3. HTTP 헤더를 통한 서버관련 정보 노출

등과 같은 기준으로 취약 상태를 판단하며 파악할 수 있다.

실제 존재하는 페이지에서 어플리케이션명을 없애고 폴더명만 기재하여 접속해보고, 어플리케이션명에 1을 적고 접속해보면 403, 404 등의 HTTP Status Code값을 통해 페이지 존재 여부를 확인할 수 있다.

ex) http://www.~~~.com/test/

ex) http://www.~~~.com/test/1

이렇게 불필요하게 존재하는 디폴트 페이지 노출을 통해 시스템 정보가 노출될 수 있고, 관리자 페이지 등을 이용하여 관리자
권한이 노출될 수도 있으며, 상용 데이터의 디폴트 업로드 페이지 등을 이용하여 웹 쉘 업로드 등의 2차 피해가 발생할 수 있다.

2. 중요 정보 노출

---

중요정보 평문 전송

• 중요정보 평문 전송 취약점이란, "사용자 또는 시스템의 중요정보가 포함된 데이터를 평문으로 송수신할 경우, 통신채널
  스니핑을 통해 인가되지 않은 사용자에게 민감한 데이터가 노출될 수 있는 보안 약점"을 의미한다.

네트워크 통신은 그 어느 때보다 발달하고, 서비스 이용을 위해 필수불가결적으로 사용해야 하는 수단이다.
이 때, 개인정보 또는 인증정보 등의 사용자 중요정보 및 시스템 중요정보를 평문으로 전송할 경우, 공격자에게 민감한 정보가 노출될 수 있는 위험이 존재한다.

Web상에서 서버와의 Interaction을 위해서는 서로가 정보를 주고받을 수 있도록 도와주는 통신규약 즉, 프로토콜이 필요하다.

이러한 기능을 하는 프로토콜이 HTTP(Hyper Text Transfer Protocol)이며 HTTP의 GET, POST 메소드를 통해 데이터를 서버에게 전송한다.

데이터 전송에 사용되는 Method는 보안과 별반 관계가 없다.

데이터 전송에 사용된 메소드가 GET이냐, POST냐는 중요한 요소가 아니며, http를 이용했으면 암호화를 했어야 헀고,
평문으로 데이터를 전송했어야 했다면 HTTP의 보안 강화 버전인 https 프로토콜을 채택하였어야 안전한 것이다.

즉, http랑은 아무 상관없다, 그냥 평문으로 전송한 것이 핵심이다.

cf) HTTPS

HTTPS프로토콜을 SSL(Secure Socket Layer)와 같은 의미로 이해하고 있는 경우가 많다.

이는 마치 웹과 인터넷을 같은 의미로 이해하는 것과 동일한 맥락이다. 결론적으로 이야기하면 웹이 인터넷 위에서
돌아가는 서비스 중 하나인 것 처럼, HTTPS또한 SSL프로토콜 위에서 돌아가는 프로토콜이다.

HTTPS란, SSL이나 TLS프로토콜을 통해 세션 데이터를 암호화한다.

HTTPS를 이용하는 웹 서비스는 proxy 를 사용하여도 내부 컨텐츠를 확인할 수 없다.
내용을 보기 위해선 암호를 풀어야하는데, 풀기 위한 암호는 웹 서버만이 갖고있다.
또한, 그걸 임의로 풀려면 애초에 브라우저에게 본인이 해독할 수 있는 암호키를 전달해야 하고, 이건 신용할 수 있는 정식 인증서가 없으므로 웹 브라우저가 경고를 할 수 있다.

웹 어플리케이션 운영 시 사용자 인증 방식 중 하나인 쿠키를 공격자가 벼조하여 다른 사용자로 전환하거나 권한 상승의 위험이 존재한다. 클라이언트 측에 저장되는 쿠키는 그 특성상 변조 위험에 노출되어 있으나 활용 분야가 다양하고 구현이 쉽다는 이유로 인하여 현재까지 많이 사용되고 있다.

따라서, 민감정보를 전송할 시에는 안전하게 암호화해서 전송을 진행해야 하며, 쿠키에 포함된 중요정보 또한 암호화하여 전송하는것이 바람직하다.

쿠키에 중요정보가 포함 될 경우, 공격자가 사용자의 중요한 정보를 변조하거나 획득할 수 있는 위험이 있으므로 웹 어플리케이션 운영 시 가급적 쿠키 방식 대신 세션 방식을 사용하는 것을 권장하며 부득이하게 쿠키를 사용해야 할 경우, SEED, 3DES, AES 등과 같은 공인된 암호화 알고리즘을 사용하여 암호화를 적용시켜야 한다.

CF) 세션 방식

세션 방식은 접속자 별로 세션을 생성하여 사용자의 정보를 각각 지정할 수 있도록 하는 오브젝트로써, 페이지의
접근을 허가 또는 금지하거나 사용자 별 정보를 저장할 때 많이 사용한다.

따라서, 클라이언트의 자원을 사용하는 쿠키보다 서버의 자원을 사용하므로 세션이 보안성 측면에서 우수하므로 웹 어플리케이션 개선 및 구축시 세션 방식 사용을 권장한다.

중요정보 평문 저장

---

• 패스워드 정보/ 개인정보/ 인증정보/ 금융정보 등과 같은 중요정보를 암호화하지 않고 평문으로 저장할 시 발생하는 취약점.

• 저장된 중요정보 파일이나 DB정보가 유출될 경우, 중요정보 및 민감정보가 유출되어 기업의 피해를 초래할 수 있음.

이를 보안하기 위해, 개인정보 또는 민감정보 저장시에는 암호화 이후 저장한다.

또한, 중요정보를 읽거나 쓸 경우에는 권한 검증을 통해 인가된 사용자인지 검증한다.

CF) 진단방법

1. 로그인 처리 시 암호화 로직을 사용하는지 검증
2. 중요정보에 불필요한 참조 존재여부 확인
3. 중요정보를 임시변수에 저장 시 사용 후 초기화를 진행하는지 확인

파일 다운로드

---

홈페이지 상에서 다운받을수 있는 파일 (ex: jsp, php, php3, cgi...etc)등의 프로그램에서 입력되는 경로를 검증하지 않는
경우 임의의 문자 (../../.. etc) 또는 주요 파일명 입력을 통해 웹 서버의 홈 디렉터리를 벗어나는 임의의 위치에 존재하는 파일을 열람하거나 다운받는 것이 가능한 취약점을 의미한다.

진단방법

1. 게시판 또는 공지사항, 자료실과 같은 파일을 다운로드 기능을 제공하는 페이지 여부 조사

2. 다음과 같이 파일 다운로드를 시도한다.

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

   ../../../../winnt/win.ini

   ../../../../boot.ini

   ../../../wp-config.php

   등등

3. 아래와 같이 인코딩을 적용하여 해당 파일 내용이 표시되는지 여부를 확인한다.

• ..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd -> "URL" 인코딩 적용

• nullByte 인젝션 시도

  • ../../../../../etc/passwd%0a.jpg

• 정상 디렉터리 파일을 먼저 입력한 이후 탐색 문자열 입력

  • ../was/tomcat/image/../../../../etc/passwd

Tip)

윈도우즈는 대소문자를 구분하지 않으나, 리눅스의 경우 대소문자를 구분한다.

이를 구분하여 진단 대상 서버가 윈도우즈 기반인지 리눅스 기반인지 알아낼 수 있다.

즉, 대문자로 바꿔도 다운로드가 그대로 진행된다면 이는 윈도우즈 기반이라는 것이다.

또한, jsp, php를 사용할 경우 리눅스일 가능성이 높다.