여름 방학 웹해킹 과제 (2번째)

과제 설명

본인이 만든 웹 사이트에 대한 취약점 점검 수행 

취약점 점검에 필요한 해킹 기초 지식은 구글링 및 자료 공유, 의견 공유를 통해 습득 
최소 기능별 1개 이상의 취약점 찾기 

취약점 보고서 작성 후 각자 블로그에 포스팅

 

웹 취약점 점검 항목(21개) ver.2019 + OWASP 2017 참조

1. 운영체제 명령 실행(=OS command Injection)

웹 서버에 존재하는 명령어 실행 가능 함수 인자를 조작하여 특정 명령어 실행이 가능한 취약점

웹 어플리케이션에서 system(), exec()와 같은 시스템 명령어를 실행 시킬 수 있는 함수를 제공하며 사용자 입력값에 대한 필터링이 제대로 이루어지지 않을 경우 공격자가 운영체제 시스템 명령어를 호출하여 백도어 설치나 관리자 권한 탈취 등 시스템 보안에 심각한 영향을 미칠 수 있는 취약점

 

*백도어: 정상적인 인증 절차를 거치지않고, 컴퓨터와의 암호 시스템 등에 접근할 수 있도록 하는 장치

설계자나 관리자에 의해 남겨진 시스템의 보안 허점을 말함, 일부로 남겨놓은 경우는 개발 단계에서의 테스트를 위해, 유지 보수 시의 효율성을 위해 특수 계정을 허용하는 것

 

대응방법:

1. 웹 서버의 권한을 관리자가 아닌 최소의 권한으로 설정 -> 명령실행의 결과를 최소화 

2. php.ini의 safe_mode=On

3. java에서는 Runtime.exe를 사용해야한다면 파라미터 값에 대한 검정 절차가 필수

 

참고:

https://whitesnake1004.tistory.com/42

1. 운영체제 명령 실행 취약점

웹해킹 스터디 8주차에 관련 내용 존재

2. SQL 인젝션

입력 폼에 악의적인 쿼리문을 삽입하여 DB정보, 타 사용자 권한 획득이 가능한 취약점

공격 목적 및 영향

1. 인증 우회 (AB : Auth Bypass)

로그인 폼(Form)을 대상으로 공격 수행, 정상적인 계정 정보 없이 로그인을 우회하여 인증 획득 가능

SQL 쿼리문의 true/false의 논리적 연산 오류를 이용하여 로그인 인증 쿼리문이 무조건 true값이 나오게 하여 인증을 무력화 하는 원리

2. 데이터 노출 (DD : Data Disclisure)

DB에서 조작된 쿼리가 실행되여, 기업의 개인정보나 기밀정보에 접근하여 데이터 획득, 변경, 그리고 테이블 삭제 가능

3. 원격명령 실행 (RCE : Remote Command Excute)

일부 데이터베이스 경우 확장 프로시저를 호출하여 원격으로 시스템 명령어를 수행할 수 있게함 -> 시스템 명령어를 실행할 수 있으면 해당 서버의 모든 자원에 접근하고 데이터 유출, 삭제 가능

 

SQL 인젝션이 가능한 조건(두 조건 모두 충족되어야함) -> 현재 대부분의 웹 어플리케이션은 모두 만족하고 있음

1. 웹 어플리케이션이 DB와 연동하고 있음

2. 외부 입력값이 DB 쿼리문으로 사용

 

공격 유형과 공격 기법

1. (일반적인) SQL Injection

 

1-1. 쿼리 조건 무력화 (where 구문 우회)

SQL에서는 Where 조건에 기술된 구문이 '참(true)'이 되는 범위만 쿼리 결과로 변환하는데 이 where 조건이 무조건 참이 되도록 쿼리를 조작하여 Where조건을 우회

방법

1. 주석을 의도적으로 삽입하여 where조건 무력화

2. 항상 참이 되도록 Boolean식을 구성하여 where조건 무력화

3. ; 으로 명령어를 연결하여 한 줄로 된 두개 이상의 명령어를 연속하여 기입 -> 테이블 삭제,수정 쿼리문 삽입

 

1-2.  고의적 에러 유발후 정보 획득

의도적으로 SQL 구문 에러를 유발하여 웹 애플리케이션이 내뱉은 오류 정보에 기반하여 유용한 정보를 알아 차리고 그 정보를 연속되는 또 다른 공격의 소재로 사용

1-3. 시스템 명령어 실행

 

2. Blind SQL Injection

쿼리 결과의 참/거짓으로부터 DB값을 유출해 내는 기법

 

2-1. Boolean-based Blind 공격

게시판 검색 기능을 참/거짓을 반환하는 요소로 사용하여 여기에 AND 조건으로 해커가 알고 싶은 쿼리 조건을 삽입해서 그 결과로부터 정보유출이 가능한 것이 Blind SQL 인젝션 공격 기법이며 이중에서도 AND 조건에 논리식을 대입하여 참/거짓 여부를 알아내는 방식을Boolean-based Blind 공격이라 함

 

2-2. Time-based Blind 공격

응답의 결과가 항상 동일하여 응답결과만으로는 참/거짓을 판별할 수 없는 경우 시간을 지연시키는 쿼리를 주입하여 응답 시간의 차이로 참/거짓 여부를 판별

 

대응방법

 

https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

SQL Injection Prevention - OWASP Cheat Sheet Series

https://m.mkexdev.net/427

[웹보안] SQL Injection

http://mkex.pe.kr/kims/bbs.php?table=Tbl_Lecture_Web&query=view&uid=33&p=1

> 점검결과 (양호)

sqlmap을 이용하여 기본적인 취약점 분석을 실행함 (로그인폼, 글 검색 부분등)

확실하지 않으나 양호함

 

참조:

쿠키값 확인법:https://bonggugu.tistory.com/21

브라우저별 쿠키 확인법 (크롬, 파이어폭스, IE11)

https://webhack.dynu.net/?idx=20161107.003

SQL 인젝션 공격도구 sqlmap의 간단한 사용법

3. XPath 인젝션 (관련 사항 없음)

XPath 쿼리문 구조를 임의로 변경하여 DB 정보 열람, 타 사용자 권한 획득이 가능한 취약점

데이터 베이스와 연동된 웹 어플리케이션에서 XPath 및 XQuery 질의문에 대한 필터링이 제대로 이루어지지 않을 경우 공격자가 입력이 가능한 폼(웹 브라우저 주소입력창 또는 로그인 폼등)에 조작된 질의문을 삽입하여 인증 우회를 통해 XML 문서로부터 인가되지 않은 데이터를 열람할 수 있는 취약점

 

좀더 쉽게 생각하면 XML을 DB라고 생각하고, XPath를 SQL이라고 생각하면 훨씬 간편함

 

XML 이란?

인터넷 웹 페이지를 만드는 HTML을 획기적으로 개선하여 만든 언어, 홈페이지 구축기능, 검색기능 등이 향상되었고, 웹 페이지의 추가와 작성이 편리해짐

XML은 데이터를 트리구조의 노드로 표현하며 사용자 정의로 데이터를 분류

Xpath란?

XML 문서의 특정 요소나 속성에 접근하기 위한 경로를 지정하는 언어

참조:

http://tcpschool.com/xml/intro

코딩교육 티씨피스쿨

https://tkdrms568.tistory.com/155

XML / XPATH 인젝션 - Login Form

https://whitesnake1004.tistory.com/122

3. XPath 인젝션 취약점

4. 디렉토리 인덱싱(=디렉토리 리스팅)

본 페이지의 파일이 존재하지 않을 때 자동적으로 디렉토리 리스트를 출력하는 취약점

웹 어플리케이션을 사용하고 있는 서버의 미흡한 설정으로 인해 인덱싱 기능이 활성화 되어 있을 경우, 공격자가 강제 브라우징을 통해 서버내의 모든 디렉터리 및 파일에 대해 인덱싱이 가능하여 웹 어플리케이션 및 서버의 주요 정보가 노출될수 있는 취약점

참조:

whitesnake1004.tistory.com/134

4. 디렉토리 인덱싱 취약점

> 점검결과 (양호)

5. 정보노출

웹 어플리케이션의 민감한 정보가 개발자의 부주의로 인해 노출되는 것으로 중요 정보(관리자 계정 및 테스트 계정 등)를 주석구문에 포함시켜 의도하지 않게 정보가 노출되는 취약점 또한 디폴트로 설정된 에러 페이지를 그대로 사용할 경우 시스템 내부 문제점을 자세하게 출력해주기 때문에 절대경로, 상태코드, 데이터베이스 종류, 질의문 등이 노출될 수 있으며 이밖에도 공격자가 검색엔진을 통하여 각종 개인 정보 및 서버 정보 등 해킹에 필요한 정보를 획득할 수 있음

파급효과:
개발 이력 노출, 테스트 및 관리자 계정 노출, 데이터베이스 정보 노출

대응 방안:

전체적인 통합 에러 페이지를 작성한 후 모든 에러코드에 대해 통합 에러 페이지로 리다이렉트 되도록 설정하여 공격자가 서버정보 및 에러코드를 수집할 수 없도록 설정해야 함

> 취약점 분석

nikto를 활용한 웹 취약점 스케닝 검사 결과

출처: 

nikto 사용법: https://blog.z3alous.xyz/206

web server 취약점 스캐너 nikto :)

mysql connection을 보기 위해 만들어논 부분인데 이것도 취약점이 될 수 있을 것 같다.

6. 악성콘텐츠

정상적인 컨텐츠 대신에 악성 컨텐츠를 주입하여 사용자에게 악의적인 영향을 미치는 취약점

웹 어플리케이션에서 사용자 입력 값에 대한 필터링이 제대로 이루어지지 않을 경우 공격자가 악성콘텐츠를 삽입할 수 있으며, 악성콘텐츠가 삽입된 페이지에 접속한 사용자는 악성코드 유포 사이트가 자동으로 호출되어 악성코드에 감염될 수 있는 취약점

악성콘텐츠는 SQL 인젝션, Cross Site Scripting, 파일 업로드를 통한 페이지 위변조 기법 등을 통해 삽입이 가능하므로 해당 취약점을 반드시 제거하여 악성콘텐츠 삽입이 불가능 하도록 조치가 필요함

 

대응 방안

악성 콘텐츠를 삽입하려면 기본적으로 sql 인젝션, XSS, 파일 업로드 취약점을 이용하기 때문에, 이러한 취약점들이 없도록 해야함 또한 악성콘텐츠 삽입 방법은 알려지지 않은 소프트 웨어 취약사항으로 발생하기 때문에 자주 확인해 봐야 함

7. 크로스사이트 스크립트(XSS)

 - 웹 사이트를 통해 다른 최종 사용자의 클라이언트에서 임의의 스크립트가 실행되는 취약점

 - 애플리케이션이 올바른 유효성 검사 또는 필터링 처리 없이 새 웹 페이지에 신뢰할 수 없는 데이터를 포함하거나, 자바스크립트와 HTML을 생성하는 브라우저 API를 활용한 사용자 제공 데이터로 기존 웹페이지를 업데이트할 때 발생합니다. XSS는 피해자의 브라우저에서 공격자에 의해 스크립트를 실행시켜 사용자 세션을 탈취할 수 있게 만들고, 웹 사이트를 변조시키고, 악성 사이트로 리다이렉션할 수 있도록 허용합니다.

 

XSS 공격 종류

  - Stored XSS (저장형 XSS)

    * 공격자가 취약한 웹서버에 악성 스크립트를 저장하면 희생자가 해당 자료를 요청할 떄 해당 악성 스크립트가 삽입된 응답 페이지가 전달되어 클라이언트 측에서 동작하는 방식

 

  - Reflected XSS (반사형 XSS)

    * 외부에 있는 악성 스크립트가 희생자 액션에 의해 취약한 웹서버로 전달되고, 웹서버의 응답 페이지에 해당 악성 스크립트가 삽입되어 희생자 측에서 동작하는 방식

 

  - DOM based XSS (DOM 기반 XSS)

    * 희생자의 웹 브라우저에서 응답 페이지에 포함된 정상적인 스크립트가 동작하면서 DOM 객체를 실행할 때 URL 등에 포함된 악성 스크립트가 동작하는 방식이다. 응답 페이지에 관계없이 웹 브라우저에서 발생

 

참조:

https://4rgos.tistory.com/1

> 취약점 분석

저번에 정리했던 것처럼 기본적인 script 문자 필터링을 통해 다음과 같은 결과를 얻을 수 있었다.

replace("", "&nbsp;").replace("<", "&lt;").replace(">", "&gt;").replace("\n", "<br>")와 같이 특정 문자를 필터링하는 형식이므로 아래의 링크에 나와있는 것처럼 문자 필터링을 우회하는 방법을 사용해 보았다.

https://4rgos.tistory.com/18

xss (Cross Site Scripting)

css에 의해 띄어쓰기가 된 것 처럼 보이는 줄 알 았으나 실제로 각 문자 사이에 공백이 들어가는 형식으로 저장되고 있는 오류가 존재 했다(보드, 코멘트 부분) 

다른 부분(로그인폼, 검색폼)에서는 취약점이 발견되지 않았다

 

하지만 nikto를 활용한 웹 취약점 스케닝 검사 결과에서 XSS header가 감지되지 않다고 나온 것 처럼 더 복잡한 공격에 취약할 것으로 예상됨

HTML Purifier와 같은 필터링 라이브러리를 활용하여 해결하는 것도 하나의 방법으로 보임( 단 처리속도가 느려짐)

 

보통 게시판 등에서 HTML 태그를 허용해야하는 경우, HTML 태그 화이트리스트를 선정 후, 해당 태그만 허용하는 방식을 적용한다고 한다.

 

참조:

https://link2me.tistory.com/1655

Cross-Site Scripting (XSS) 방지

8. 약한 문자열 강도(브루트포스)

비밀번호 조합규칙(영문, 숫자, 특수문자 등)이 충분하지 않아 추측 가능한 취약점

 '억지 기법(무차별 대입해 억지로 문제를 푸는)'이라 해석되며 특정 암호를 풀기 위해 임의의 문자의 조합을 하나씩 대입해 보는 공격 기법으로 암호를 사용하는 모든 곳에 행해질 수 있으며 그 대상으로는 암호가 걸린 파일, SSH 접속, FTP 접속, 웹사이트 회원 로그인 등이 있다.

 

대응방안

더 자세하게 설명

https://m.mkexdev.net/426

[웹보안] 브루트 포스(BRUTE FORCE) 공격

> 취약점 분석

Burp Suite를 사용하여 자동화 공격을 실행

 알파벳, 숫자, 특수문자를 포함 8-20자여서 그런지 양호함

단 로그인 횟수 제한을 걸어놓는게 좋을 것 같음

9. 불충분한 인증 및 인가

웹 어플리케이션에서 사용자 인증 및 접근제한 미흡으로 불법 접근 및 조작이 가능한 취약점

웹 어플리케이션에서 개인정보 수정 페이지나 통합 로그인(SSO)과 같은 곳에서 사용자 인증이 미흡(아이디로 인증)할 경우 공격자가 파라미터로 전달되는 값을 수정하여 사용자 도용 및 개인정보 노출 문제가 발생할 수 있는 취약점 또한 관리자 권한을 가지고 있는 페이지에 대해 접근 제한을 설정하지 않았을 경우 공격자가 해당 페이지로 접근하여 조작이 가능한 문제가 발생 할 수 있음

 

파급효과:

개인정보 노출, 사용자 인증 우회, 사용자 및 관리자 권한 도용, 관리자 권한 획득

> 점검 결과 (양호)

10. 취약한 패스워드 복구(관련 사항 없음)

취약한 패스워드 복구로직을 통해 다른 사용자의 패스워드를 획득, 변경할 수 있는 취약점

웹 어플리케이션에 존재하는 비밀번호 찾기 기능 또는 관리자에 의한 임시 비밀번호 발급 시 사용자 인증이 미흡하거나 비밀번호를 화면에 즉시 출력할 경우 공격자가 불법적으로 다른 사용자의 비밀번호를 획득, 변경, 복구 할 수 있는 취약점

 

파급효과:

사용자 패스워드 노출

 

대응 방안:

사용자 비밀번호 찾기 시 데이터베이스에 저장되어 있는 사용자 정보와 입력한 사용자 정보가 일치하는지 비교하는 인증 구문을 적용해야 하며, 인증 후 발급되는 임시 비밀번호의 경우 웹 페이지에 노출 시키지 않고 사용자의 이메일 또는 SMS를 통해 전송되도록 설정해야 함

11. 불충분한 세션 관리

단순 숫자 증가 방법 등의 취약한 특정 세션의 ID를 예측하여 세션을 가로채거나 중복 접속을 허용하는 경우 타 사용자의 세션을 획득하여 권한 획득 할 수 있는 취약점

웹 어플리케이션에서 사용자가 로그인을 할 경우 매번 동일한 세션 ID(일정한 패턴이 존재)를 발급하거나 세션 타임아웃을 너무 길게 설정하였을 경우 공격자가 다른 사용자의 세션을 재사용 하여 해당 사용자의 권한을 탈취할 수 있는 취약점

 

파급효과:

사용자 권한 획득

 

대응 방안:

로그인 한 사용자들의 정보를 저장하는 별도의 변수를 지정하여 로그인 시 사용자의 아이디와 세션 값을 저장하여 추후에 발생되는 세션 요청에 대해 저장소의 값과 비교하여 저장소에 존재하는 사용자라면 중복 로그인으로 판단하여 로그인이 불가능 하도록 관리가 필요함

 

로그인 페이지 이외에 세션 변조를 통한 중복 로그인 방지를 위해서는 사용자의 IP주소 및 토큰 값을 별도로 저장하여 추후에 발생되는 요청에 대해 검증이 필요함

 

세션 타임아웃 설정을 통해 일정 시간 동안 움직임이 없을 경우 자동으로 로그아웃 되도록 설정하는 것을 권장함

> 점검 결과 (양호)

12. 크로스사이트 리퀘스트 변조(CSRF)

로그온 한 사용자 브라우저로 하여금 사용자의 세션 쿠키와 기타 인증 정보를 포함하는 위조된 HTTP 요청을 취약한 웹 어플리케이션에 전송하는 취약점

웹 어플리케이션에서 정상적인 경로를 통한 요청과 비정상적인 경로를 통한 요청을 서버가 구분하지 못할 경우 공격자가 스크립트 구문을 이용하여 정상적인 사용자로 하여금 조작된 요청을 전송 하도록 하여 게시판 설정 변경 및 자동 댓글, 회원 등급 변경 등의 문제가 발생할 수 있는 취약점

크로스 사이트 리퀘스트 변조의 경우 공격을 당한 사용자의 권한을 그대로 사용하게 되므로 사용자의 권한 수준에 따라 그 피해범위가 달라질 수 있음

 

파급효과:

사용자 권한 도용, 사용자 정보 변경

 

대응방안:

1. 로그인 성공 시 로그인 처리와 함께 토큰을 생성하여 세션에 저장

2. 웹 페이지 호출 시 URL을 통해서 토큰 전송

3. URL을 통해서 전송된 토큰과 세션에 저장된 토큰을 비교

 

크로스 사이트 리퀘스트 변조의 경우 웹 어플리케이션에 존재하는 모든 HTTP 요청 내에 예측할 수 없는 임의의 토큰을 추가하여 정상적인 요청과 비정상적인 요청을 판별하는 것을 권장하며 추가적으로 XSS 와 공격 방식이 유사하므로 “크로스 사이트 스크립트(XSS)” 대응방안을 참고하여 XSS 취약점을 제거하는 것을 권장함

 

참조:

https://hack-cracker.tistory.com/253

크로스 사이트 리퀘스트 변조(CSRF)

13. 자동화 공격

정해진 프로세스에 자동화된 공격을 수행함으로써 수많은 프로세스가 진행되는 취약점

웹 어플리케이션 운영 시 특정 프로세스에 대한 접근시도 횟수 제한을 설정하지 않을 경우 공격자가 자동화 툴 및 봇을 활용하여 일분에 수백 번의 접근을 시도 할 수 있으며 특정 프로세스를 반복 수행함으로써 자동으로 수많은 프로세스(DoS, 무차별 대입 기법 등)가 진행되어 시스템 성능에 영향을 미칠 수 있는 취약점

 

파급효과:

시스템 과부하, 웹 서비스 중지, 사용자 계정 탈취

 

대응방안

- 특정 시간 내 동일 프로세스가 반복 실행되지 않도록 시간제한을 설정해야 하며, 자동화 공격에 의한 시스템 과부하를 방지하기 위해 다량의 패킷이 유입될 경우 해당 접속을 차단하는 것을 권장함

- 캡챠를 사용할 경우 서버에 요청하는 사용자가 실제 사람인지, 컴퓨터 프로그램인지 구별 할 수 있기 때문에, 이를 회원 가입 및 로그인 등 프로세스에 적용 시 자동화 도구를 통한 공격을 방어할 수 있음

 

※ 캡챠란?

실제 사람인지, 컴퓨터 프로그램인지를 구별하기 위한 방법으로 사람이 쉽게 인식할 수 있는 임의의 문자와 숫자를 그림으로 변환하여 제시하고 제시된 문자는 왜곡되거나 덧칠되어 기계가 자동으로 읽기 어려운 상태로 만드는 것이 특징임

> 취약점 분석

이것처럼 단시간에 많은 글을 쓰는 것이 가능하다. 이는 DoS공격을 가능하게 하며 이는 취약점으로 작용한다.

Burp Suite를 이용한 공격도 가능하다.

https://jinseok12.tistory.com/90

자동화 공격(AU)

아래의 방법으로 대응할 수 있다.

1.      데이터 등록이 일회성이 될 수 있도록 별도의 확인 값을 추가

2.      자동화 공격이 시작될 때 패킷이 증가하는 것이 감지하고 이를 통해 방어할 수 있는 IDS/IPS 시스템을 구축

14. 파일업로드

파일 업로드 기능을 이용하여 시스템 명령어를 실행할 수 있는 파일을 업로드 하는 취약점

- 파일 업로드 기능이 존재하는 웹 어플리케이션에서 확장자 필터링이 제대로 이루어지지 않았을 경우 공격자가 악성 스크립트 파일(웹쉘)을 업로드하여 해당 웹쉘을 통해 원격에서 시스템을 제어할 수 있는 취약점을 말한다.

-공격자는 취약점을 이용하여 시스템 명령 수행 등 시스템을 제어할 수 있으며 웹 페이지 변조 등의 공격도 수행할 수 있다.

 

참조

https://beomsu33.tistory.com/180

> 취약점 분석

확장자가 .jpg와 .png만 업로드 가능하도록 코드를 작성하였으나 다른 확장자도 올라가는 것으로 확인

이는 확장자 검사가 따로 되지 않고 있다는 의미로 asp, php와 같은 파일들을 업로드하여 정보를 빼내는 것이 가능하므로 취약하다고 할 수 있다.

웹해킹 6주차에서 실습한 것처럼 png파일에 코드를 삽입하여 올려보았으나 공격을 성공하진 못했음(능력 부족)

15. 경로추적 및 파일다운로드

다운로드 함수 인자를 조작하여 서버에 존재하는 파일 다운로드 가능한 취약점

개요 파일 다운로드 기능이 존재하는 웹 어플리케이션에서 파일 다운로드 시 파일의 경로 및 파일명을 파라미터로 받아 처리하는 경우 파일에 대한 접근 권한이 설정되어 있지 않다면 공격자가 파라미터를 조작하여 환경설정 파일, 웹 소스코드 파일, 데이터베이스 연동 파일 등을 다운 받을 수 있는 취약점 경로추적의 경우 인증되지 않은 사용자가 시스템에 접근하여 중요한 파일을 읽거나 권한 없는 기능 등을 수행할 수 있는 취약점

 

파급효과:

서버 주요파일 노출, 소스코드 직접 다운로드, 데이터베이스 정보노출

> 취약점 분석

파일 다운로드가 되지 않는 오류가 존재... 뭐지... 강제로 취약점을 막아주고 있다...

16. 관리자페이지 노출 (관련 사항 없음)

단순한 관리자 페이지 이름, 설정, 설계상 오류등 관리자 메뉴에 직접 접근할 수 있는 취약점

웹 어플리케이션의 전반적인 기능 설정 및 회원 관리를 할 수 있는 관리자페이지가 추측 가능한 형태로 구성되어 있을 경우 공격자가 관리자페이지에 쉽게 접근을 할 수 있으며 무차별 대입 공격을 통하여 관리자 권한을 획득할 수 있는 취약점

 

파급효과:

회원 정보 조작 및 유출

17. 위치공개 (관련사항 없음)

임시파일, 백업파일 등에 접근이 가능하여 핵심 정보가 노출될 수 있는 취약점

개발 과정 또는 소스코드를 수정하였을 경우 백업파일, 로그파일, 압축파일과 같은 파일이 자동적으로 생성되어 웹 어플리케이션 상에 노출될 경우 공격자가 유추 후 직접 접근을 요청하여 핵심정보를 획득할 수 있는 취약점

 

파급효과:

시스템 관련 정보노출, 소스코드 노출

18. 데이터 평문전송

서버와 클아이언트 간 통신 시 암호화 하여 전송을 하지 않아 중요 정보 등이 노출되는 취약점

로그인 또는 실명인증 시 민감한 데이터(개인 식별번호, 계정정보 등)가 평문으로 통신채널을 통해 송수신 될 경우 공격자가 감청(스니핑)을 통해 다른 사용자의 민감한 데이터를 획득 할 수 있는 취약점

 

파급효과:

사용자 개인정보 노출

 

대응방안:

사용자가 입력한 개인정보(또는 중요 데이터)에 대해 암호화를 적용하여 송수신 할 경우, 공격자가 중간에 데이터를 감청하더라도 암호화된 데이터를 복호화 할 수 없기 때문에 데이터의 기밀성을 유지할 수 있음 

보안 서버 적용 : 서버와 클라이언트 통신 시 중요정보가 사용되는 구간에 SSL 등 암호화 통신을 적용

 

※ SSL(Secure Sockets Layer)이란?

웹 서버 인증, 서버 인증이라 불리는 프로토콜을 말하며, 클라이언트와 서버 간 통신에서 정보를 암호화하기 때문에 공격자의 감청으로 정보가 유출되더라도 정보의 내용을 보호할 수 있게 해 주는 보안 솔루션을 말함

>점검 결과 (양호)

19. 쿠키 변조

보호되지 않는 쿠키를 사용하여 값 변조를 통한 사용자 위자 및 권한 상승 등이 가능한 취약점

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

 

파급효과:

사용자 인증 우회, 권한 상승

 

대응방안:

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

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

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

점검 결과 (양호)

20. 웹 서비스 메소드 설정 공격

PUT, DELETE 등의 메소드를 악용하여 악성 파일(웹쉘) 업로드가 가능한 취약점

웹 어플리케이션에서 일반적으로 사용하는 GET, POST 메소드 이외의 PUT, DELETE, COPY, MOVE 등의 불필요한 메소드를 허용하였을 경우 공격자가 이를 이용하여 웹 서버에 파일을 생성하거나 삭제 및 수정이 가능한 취약점

 

파급효과:

임의의 파일 삭제 및 업로드, 시스템 장악

 

대응 방안:

GET, POST를 제외한 불필요 메소드를 비활성화 시키는 것을 권장함

$CATALINA_HOME(톰캣 홈 디렉터리)/conf/web.xml 파일의 필드 내에 위와 같은 설정을 추가하여 악의적으로 이용할 수 있는 메소드를 차단해야 함

참조:

https://blog.naver.com/lascomco/221207930956

[ 보안 취약점 진단 ] 웹 서비스 메소드 설정 공격 - HTTP Methods

관련영상:

https://www.youtube.com/watch?time_continue=149&v=s7ge24gLv0c&feature=emb_logo

> 취약점 분석

필요하지 않은 메소드를 사용 중이므로 위 예제와 같은 조치를 취함

21. URL/파라미터 변조

URL, 파라미터의 값을 검증하지 않아 특정 사용자의 권한 획득이 가능한 취약점

웹 어플리케이션 상에 존재하는 모든 실행경로에 대해서 접근제어를 검사하지 않거나 미흡한 경우 공격자가 접근 가능한 실행경로를 통해 사용자의 정보를 유출 하거나 일시적인 권한 상승이 가능한 취약점

URL/파라미터 변조의 경우 불충분한 인증 및 인가 취약점과 유사하지만 프로세스 검증을 우회하는 것 이외에 사용자 입력 값에 대한 검증 누락이 발생하는 모든 상황을 포함하고 있으므로 SQL 인젝션, 불충분한 인증 및 인가, 크로스 사이트 스크립트(XSS) 공격에 활용될 수 있음

 

파급효과:

사용자 권한 획득, 인증 우회, 홈페이지 장악

 

대응방안:

웹 어플리케이션에서 제공하는 정보와 기능을 역할에 따라 배분함으로써 사용자가 변경할 수 있는 데이터의 노출을 최소화하는 것이 필요하며, 서버로 전송된 사용자 입력 값의 경우 세션 및 데이터베이스와 비교를 하여 데이터가 변조되었는지 검증할 수 있는 과정을 구현해야 함

 

흠 끝에 가서 날려먹어서 작성하는데 너무 힘들었다. 역시 저장을 생활화 하는 삶을 살아야겠다.

취약점 점검을 옳게 진행했다고 보기 어려울 것 같다. 뭔가 하면 할 수록 툴키디가 된 느낌이었다.