WEB 취약점진단시 업무 스케쥴링

- 2024.12.23 -

 

[노잼 간단한 이야기]

회사에 일을 하다보니 개인 정기 업무 말고도 수도 없이 많은 업무들이 몰아친다.

나 같은 신입급은 1개 2개 정도의 업무라면 (한손바닥 정도의 개수) 잘 관리 할 수 있을지 모르지만

 

3,4개 정도를 가지고 일을 하다가 지난번에 했던 이행진단 요청등이 몰려오면

자연스럽게 6,7개의 업무가 추가가 된다.

물론, 당일에 해야하는 업무는 아닌것들도 몇몇개 있다.

 

이경우 우선순위를 정해서 가장 급한것들을 선별해 처리하면 되는 일인데

이게 참 여러개 일이 합쳐지고 쌓이다보면 쫌쫌따리 늘어나지가 않는다.

 

지난주만 해도 그런게 분명 3,4개의 업무로 내 뇌는 풀로드 상태였는데

연달아 이행과 추가 확인 요청, 혹은 회신했는데 담당자가 내 자산아니오~ 하는 경우가 있었다.

이렇게 되면 내가 가진것보다 2배~3배가까이 할일이 늘어나 버린다.

 

나름 정리하려고 적어둔 바탕화면의 스티커메모장에 있는 일들이

처리되지 못하고 결국 쌓이게된다.

이러다 보니 팀 분위기도 해치게 되고

(결국 내가 못한건 다른 선임근무자들이 떠넘겨져서 하게 되니까..)

 

이는 나의 평판으로 돌아왔던 것 같다.

그래서 주말내내 생각해봤다.

웹 정기진단이나 개발진단을 할때면 보통 3일, 길게는 5일정도를 가져가는데

일자별로, 시간별로(오전/오후) 스케줄링을 하면 그 할당된 일에 좀 더 깊이 파지 않을까.

 

나같은경우는 웹 진단을 시작하면 일단 가장 찾기 시작한게

에러페이지, 활성화된 메소드확인, XSS. 그리고 된다면 파일 업로드 이다.

 

다른건 안중에도 없고 늘 이런것들을 우선시 했던것 같다.

그러다보니 디테일함이 떨어졌고 취약점을 잡아도

다른 곳에서 현실적으로 위험한 취약점이 나오기도 했다.

 

같은 팀에서 지금은 내 뒷자리에 있는 리더님이 물었다.

" 이거 WEB은 뭐에요? "

" DBMS는? "

" 여기 파라미터도 한번 봤을까 싶네? "
" XSS는 여기에만 되는거에요? 여기도 게시판이 있어서 "

 

헉 스러운 질문들..

WEB이야 에러페이지를 통해서 디폴트라면 확인을 했겠지만

DBMS가 뭐고 파라미터도 꼼꼼하게 보지 못했다.

자신있게 다 했다고 했지만 근자감이였던것..

 

이런 취약점들은 쌩 신입을 가져다 앉혀놓고 해도

누구나 찾을 수 있고 나는 내 년차에 맞는 디테일함이 필요했던 것이다.

 

부끄러웠다.

난 그동안 뭘했는가?

그리고, 그저 중요 취약점을 찾으면 다인줄 알았던가.

 

주말간 고민 끝에

내가 하는 업무 프로세스를 조금 정형화 해보기로 했다.

순서와 절차, Step by Step으로 정리해두면

나중에 어떤것들을 어디까지 디테일하게 보았는지 확인할 수 있을 것 같았다.

 

나처럼 5년이내의 신입이라면,

웹 진단하라고 하면 그냥 무지성으로 돌려받는다면

내가 꼼꼼함이 조금 부족하다면

다음 내 관리 스케줄링을 따라보는것도 좋은 방법이 될 것이다.

---

 

1일차: 웹 취약점 진단

오전 (0900~1130)

1.     프로젝트 이해 및 환경 설정

-      웹 어플리케이션 정보 수집

URL, 주요 기능, 인증 방식 등 (별첨 참조)

2.     리콘 및 정보 수집

-      도메인 스캐닝, 서브 도메인 탐색, WHOIS 조회 등

-      기술 스택, 서버 정보 파악

 

오후(1300~1800)

1.     취약점 점검 – 자동화 검사

-      도구를 활용하여 초기 스캔 실행(XSS, SQLi 등 일반 취약점 확인)

-      발견된 취약점 정리 및 초기 분석

2.     취약점 점검 – 수동 검사

-      수동으로 주요 취약점 확인 (비즈니스 로직 취약점, 권한 상승 등)

-      위험도가 높은 취약점에 집중.

 

 

2일차: 웹 취약점 진단

오전 (0900~1130)

1.     취약점 분석 및 재현

-      전일 발견된 취약점 재현 및 심층 분석

-      재현 가능성을 문서화(스크린샷 및 재현 절차 기록)

2.     영향도 평가 및 우선순위 설정

-      취약점 위험도를 기반으로 우선순위 설정(예:CVSS 기준)

 

오후(1300~1800)

1.     보고서 초안 작성

-      보고서 기본 구조 작성(개요, 진단 대상, 취약점 목록, 영향도)

-      취약점 상세 정보, 재현 방법, 대응방안 포함

2.     보고서 검토 및 정리

-      오탈자 및 논리적 오류 검토

-      담당자 이해를 돕기 위한 추가 자료 준비

 

 

3일차: 웹 취약점 진단

오전 (0900~1130)

1.     보고서 최종 검토

-      상급자 또는 동료에게 피드백 요청 및 반영

-      최종 보고서 형태로 정리

2.     담당자 회신 준비

-      주요 취약점 요약 및 대응 방안 강조

-      회신 시 필요한 자료 준비

 

오후(1300~1800)

1.     담당자 회신 및 Q&A 대응

-      담당자에게 보고서 전달 및 주요 내용 설명.

-      질문 또는 추가 요청 사향 대응.

2.     후속 작업 정리 및 기록 보관

-      진단 관련 모든 자료 보관

-      차후 개선 방안 및 피드백 기록

 

별첨

1일차 웹 정보 수집 시 포함될 추가 항목

1. URL 및 경로 구조
2. 주요 기능 및 사용자 흐름
3. 인증 및 권한 구조
4. HTTP/HTTPS 요청 및 응답
5. 애플리케이션 기술 스택
6. 클라이언트-서버 상호작용
7. 세션 관리
8. 입력 필드와 데이터 처리
9. 파일 업로드 및 다운로드
10. 에러 처리 및 디버깅 정보
11. 외부 연동 서비스
12. 취약점에 영향을 줄 수 있는 설정

 

상세 사항은 아래 첨부파일 확인

 

---

i. 정리 양식(예시)

1일차

[1일차 오전] 도메인 스캐닝 결과

- 주요 도메인: example.com

- 발견된 서브도메인:

  1. admin.example.com

  2. api.example.com

  3. dev.example.com

 

[기술 스택 정보]

- 웹 서버: Nginx 1.21.6

- 언어 및 프레임워크: Python (Django 4.0)

- 데이터베이스: PostgreSQL 13

 

[1일차 오후] 발견된 취약점

- XSS (Cross-Site Scripting):

  - URL: https://example.com/search?q=<script>alert(1)</script>

  - 영향: 사용자 브라우저에서 임의의 스크립트 실행 가능.

  - 스크린샷: [첨부 이미지]

 

- SQL Injection:

  - URL: https://example.com/login

  - 취약한 파라미터: 'username'

  - PoC (Proof of Concept): ' OR 1=1 --

 

 

ii. 정리 양식

2일차

[2일차 오전] 취약점 재현 기록

- 취약점: XSS (Cross-Site Scripting)

- 재현 방법:

  1. 브라우저에서 URL 입력: https://example.com/search?q=<script>alert(1)</script>

  2. 실행 결과: 경고창 표시됨.

- 조치 방안:

  - 입력값에 대한 HTML 인코딩 처리.

  - CSP(Content Security Policy) 설정 추가.

 

- 취약점: SQL Injection

  - 재현 방법:

    1. POST 요청으로 'username' 필드에 `' OR 1=1 --` 입력.

    2. 인증 없이 관리자 계정으로 로그인됨.

  - 조치 방안:

    - Prepared Statement 또는 ORM 사용.

    - 입력값 검증 및 필터링 추가. 

오후는 초안작성

 

 iii. 정리 양식

3일차

[3일차 오전] 주요 전달 사항 요약

- 취약점 개수: 5개

  1. XSS: 2개

  2. SQL Injection: 1개

  3. 기타: 디렉토리 리스팅, HTTP 보안 헤더 미설정

- 주요 조치 방안:

  1. XSS: 입력값 필터링 및 CSP 설정.

  2. SQL Injection: Prepared Statement 사용.

  3. HTTP 보안 헤더: Strict-Transport-Security 설정.

 

[3일차 오후] 담당자 회신 및 기록
- 주요 질의응답:
  1. Q: SQL Injection에 대한 구체적인 수정 코드 예시가 있는가?
     A: Python/Django 기준 Prepared Statement 코드 예시 제공.
  
  2. Q: 보안 헤더 설정이 어렵다면 최소한 어떤 헤더를 추가해야 하는가?
     A: X-Frame-Options와 Content-Security-Policy 권장.

---

[1일차 체크리스트]
- [ ] 도메인 스캐닝 및 서브도메인 탐색
- [ ] 기술 스택 정보 수집
- [ ] 주요 기능과 흐름 확인 (로그인, 관리자 페이지 등)
- [ ] 자동화 스캔 결과 정리
- [ ] 수동 점검 및 취약점 초기 분석

[2일차 체크리스트]
- [ ] 취약점 재현 기록 및 PoC 문서화
- [ ] 취약점 영향 평가 및 CVSS 계산
- [ ] 보고서 초안 작성

[3일차 체크리스트]
- [ ] 보고서 최종 검토
- [ ] 담당자 회신 자료 준비
- [ ] 후속 작업 요청사항 정리

웹 취약점진단 스케줄링.pdf

0.21MB