버프 스위트 취약점 대응, 기록

 

로컬에서 환경을 구축한 뒤

칼리의 여러 툴을 사용해 보고 있다
이번에는 버프 스위트를 사용중인데
그에 대한 개념정립 구간이다

 

버프스위트
브라우저를 사용해 타갯의 정보를 수집할 수 있다
목표는 수집된 정보를 응용해 보안의 빈틈을 찾는것에 도움을 주는것

 

예를들어

로그인 상태에서 특정 작업 요청에 대한 정보를 얻는다

해당 작업을 로그인이 아닌 환경에서 시도한다
성공시 :

특정작업이 유저권한 없이 동작하는 이슈를 찾을 수 있다
실패시 :

해당 작업이 유저정보를 체크 하며 동작한다 / 그렇다면 해당 인증정보를 바꿔 시도해본다

 

이런 방식으로 사용해볼 예정인데
내가만든 사이트기 때문에 파노라마처럼 스쳐지나가는 몇몇 메서드가 있다
어떤 기능은 당연히 특정 페이지의 버튼에만 해당 요청이 있기 때문에
당연히 있을 수 밖에 없는 예외처리만 구현 해놨다거나

회원 체크를 모든 기능에 붙혀놓지는 않았기 때문에
중요한 어떤 기능에 변조된 파라미터로 요청이 성립 되어버릴 수 있을거라 생각했다
이번이 이러한 부분을 개선해볼수 있는 기회가 될것 같다
취약점 분석을 하지않았을때 보이지않던 부분이 보이기 시작한다

할일이 매우 많겠다

서비스 소스와 버프스위트를 통해 취약점이라고 추측되어 시도해볼 부분을 리스트업 해봤다

BOAL: 특정 객체의 권한을 잘못 검증해 해당 데이터에 접근 해버릴 수 있는 상태

특별한 수법이 아닌 서비스 시스템 규칙상 설계미스로 인해 발생하는 취약점

CSRF: 이미 인증된 사용자정보를 사용해 사용자가 원치않는 작업을 수행하는 사이트를 응용하는 공격 기법

 

TODO:

---

1. 타사용자의 플리에 카드 추가 시도

• POST /submitYoutubeLink 요청에서 playlistIdx를 변조해
  다른 사용자의 플레이리스트에 내 카드가 추가되는지 확인하기
• 원래는 로그인만이 아니라 해당 playlist가 현재 세션 사용자 소유인지 서버가 검증해야 한다

Broken Access Control / Authorization flaw (접근제어 회피 / 인증 회피)

막기 위해서는 playlistIdx를 그대로 신뢰하지 말고
서버에서 세션 사용자 기준으로 플리의 권한과 비교 해야 함

https://pushvalue.tistory.com/107

버프스위트를 사용한 취약점 탐색 (BOLA)

대응 완료

---

2. 세션 사용자와 다른 특정 계정을 탈퇴시키는 시도

• POST /resign 요청에서 로그인한 A의 세션은 유지한 채 회원 탈퇴기능에 B 계정 값으로 바꿔 요청 하여
  A 세션으로 B 계정 탈퇴가 가능한지 확인하기
• 원래는 요청 본문의 계정정보가 아니라
  현재 로그인한 세션 주체와 탈퇴 대상이 일치하는지 서버가 비교해야 함

Broken Access Control / Authorization flaw (접근제어 회피 / 인증 회피)

막기 위해서는 탈퇴 대상정보를 세션 사용자 본인으로 고정하거나
세션 사용자와 요청 대상 일치 여부를 검증해야 함

 

https://pushvalue.tistory.com/108

버프 스위트를 사용한 인증, 인가 우회 취약점 대응

이번작업은 정상동작범주로 결론

---

3. CSRF 없이 플레이리스트 생성 시도

• POST /createplaylist 요청을 Burp에서 재전송하면서 (파라미터를 변경해서 요청)
  CSRF token 없이 요청이 그대로 처리되는지
  Origin/Referer를 제거하거나 외부 값으로 바꿔도 성공하는지 확인해야함
• 원래는 사용자가 로그인되어 있더라도 정상적인 same-site 요청인지 CSRF token 등으로 검증해야 함

CSRF

CSRF token 검증 도입 

Spring Security / CSRF token (스택 선택)도입 해야 한다

 

https://pushvalue.tistory.com/109

버프스위트 CSRF 취약점 탐색,대응 기록

대응완료

---

4. CSRF 없이 카드 추가 시도

• POST /submitYoutubeLink 요청에 CSRF token 없이도 카드 추가가 성공하는지
  Origin/Referer 없이도 반영되는지 확인 해야 함
• 원래는 상태를 변경하는 POST 요청에 대해 CSRF token 검증이 있어야 한다고 한다

CSRF

엔드포인트가 다르지만 3번과 같은경우임으로 같은 방법 적용으로 한번에 대응함

---

5. GET 요청만으로 플레이리스트 삭제 시도

• GET /deletePlaylist/{playlistIdx} 요청을 직접 재전송하는 작업을 통해, 단순 GET 요청만으로 삭제가 수행되는지 확인할 수 있다.
• 삭제처럼 상태를 변경하는 기능은 GET이 아니라 POST/DELETE 로만 처리되어야 한다.

CSRF + Unsafe HTTP Method

막기 위해서는 삭제 기능을 POST/DELETE로 변경하고, 동시에 CSRF 보호를 적용해야 할 것으로 추정한다.

---

6. GET 요청만으로 카드 삭제 시도

• GET /deleteCard/{cardIdx} 요청을 직접 재전송해서, GET만으로 카드 삭제가 가능한지 확인할 수 있다.
• 타인 카드 삭제가 안 되더라도, 본인 자산을 외부 페이지 유도로 삭제하게 만들 수 있으면 여전히 문제다.

CSRF + Unsafe HTTP Method 

5번과 같은 경우

---

7. GET 요청만으로 로그아웃 유도 시도

• GET /logout 요청을 Burp나 외부 링크 형태로 재현해, 사용자 의사와 무관하게 로그아웃이 가능한지 확인할 수 있다.
• 영향도는 계정삭제나 권한상승보다 낮지만, 서비스 사용 방해가 가능하다.

Logout CSRF 또는 Unsafe HTTP Method 

막기 위해서는 로그아웃을 POST로 바꾸고, CSRF 보호를 적용해야 할 것으로 추정한다.

5번과 같은경우

---

8. 회원가입 시 userIdx 같은 식별자 주입 시도

• POST /join 요청에 원래 폼에 없는 userIdx=1 같은 필드를 추가
  신규 가입이 아니라 기존 계정에 영향이 가는지 확인

 Mass Assignment / Over-posting

막기 위해서는 DTO에 클라이언트가 넘기면 안 되는 필드 제거, 혹은 저장 직전 서버에서 민감 필드 강제 초기화가 필요할 것으로 추정한다.

---

9. Actuator 엔드포인트 직접 호출

• /actuator, /actuator/health, /actuator/prometheus 같은 URL을 직접 호출해, 인증 없이 시스템 상태/메트릭이 노출되는지 확인할 수 있다.
• 실제로 열려 있으면 공격자가 서비스 구조, 상태, 메트릭을 수집할 수 있다.

Sensitive Endpoint Exposure / Information Disclosure 

막기 위해서는 Actuator exposure 제한, 인증 적용, 또는 외부 비노출 설정이 필요할 것으로 추정한다.

 

 

 

 

이렇게 리스트업 작업을 해봤다
툴과 AI를  사용한다고 해도 취약점이 딸깍 하고 나오지는 않는다
기본적으로 해당 사이트의 유저플로우를 모두 경험해봐야 하고
각 요청당 어떤 데이터를 사용하는지 체크해야 했다

 

공격자의 입장에서 서비스를 파악하는 과정에서

서버구축시 고려하지않았던 부분이 많이 나왔다

시야가 넓어지는 계기가 될것같다