3일간 진행한 버그 헌팅 실습 훈련 후기

 

 

1) 사이트 직접 사용하기

 

2) 취약점은 대상 도메인에서 찾되 관련 도메인까지 포함해서 사용하기 (버프 볼 때도 마찬가지)

 

3) 사이트에 어떤 자원이 있는지 체크

 

4) 자원이 어떻게 악용될 것인지 생각

 

5) 악용하기 위해 사용할 기능, 페이지, 페이로드 등 생각 (시나리오)

 

6) 시나리오가 실제로 공격에 성공함을 증명해야함

 

7) 대응: "어떤 페이지에서 어떤 요소가 문제가 되어 어떤 코드가 추가되어야 한다"처럼 자세히 접근해야함

 

8) 발견한 취약점의 원인과 대응 방법은 긴밀한 연관이 있음

 

9) 원인과 대응 방법이 같으면 중복 취약점으로 취급

(긴가민가하면 걍 잘 알만한 분께 여쭙기. 모르고 지나가는게 오히려 손해.)

 

10) 보고서.. 잘.. 쓰면 비슷한 취약점도 더 좋게 쳐줌

(잘: 자세하지만 간결하게)

 

11) 버그 바운티 write up 많이 보면 아주 좋을 듯.

(검색 키워드: bug bounty write up(walkthrough), bug hunting write up(walkthrough), bug hunting report 등)

 

 

---

 

 

1) 일희일비하면 힘듦..

 

2) 사이트 자원을 적극적으로.. 적!극!적으로 누려봐야함

 

3) 사이트에 취약점이 없다는 건 개발측이 사용자를 극도로 의심한다든가 확장할 필요가 없는 리소스를 가진 경우이지 않을까 싶음. 사이트에 취약점이 있다는 사실은 이 세상에 나도 있지만 쟤도 있는 것처럼 당연한 현상이니 개발사 내에 시큐어 코딩 팀을 꾸릴 상황이 못 된다면 버그 바운티같은 프로젝트를 활용하는 게 좋아 보임. 정보 보안뿐만 아니라 효율면에서도! (**물론 이건 아주 지극히 막연히 경험이 많지 않은 지금의 나의 주관적인 의견.) 

 

 

 

 

 

 

여러가지로 슬프지만.. 그래도 역시 가길 잘함.

거기 간 거 아주 좋은 선택이었다, 과거의 나야. b