Authentication Spidering in ZAP
최근 ZAP의 Auth(Authentication, Authorization) 관련 기능과 세션에 대한 부분을 파헤치고 있습니다. 제가 잘 모르고 사용하지 않았던 기능들인데, 알고나니 지금까지 약간 답답하게 일했던 제가 부끄러워지네요.
오늘은 이러한 부분들 중 하나인 Authentication Spidering에 대한 이야기를 하려고 합니다. 그럼 시작하죠 🤩
Add Cookie vs Authentication
보통 인증정보를 포함하여 웹 페이지를 탐색하는 경우 열려있는 웹 브라우저에서 로그인 후 페이지를 탐색합니다. 이는 ZAP과 Burp 모두 비슷한 형태로 진행하고, Spidering 으로 자동화 탐색을 진행하는 경우 ZAP은 Replacer, Burp는 Match and Replace를 통해 인증 쿠키를 추가하여 Spidering 합니다.
이러한 방식은 하나의 HTTP 세션의 정보를 기반으로 Spidering 하기에는 편리하지만, 중도에 쿠키가 만료되거나 logout 등의 페이지를 접근해서 명시적 로그아웃이 되는 경우에 제대로 Spidering 하지 못하는 경우가 존재합니다. 또한 여러 계정의 정보를 기반으로 Spidering 하기에는 적합하지 않죠.
Authentication Spidering을 진행하게 되면 ZAP 또는 Burp가 Spidering 단계에서 세션의 유효성을 체크하고, 지정된 처리 과정에 따라서 알아서 로그인하면서 진행하기 때문에 쿠키 만료에 대한 리스크가 줄어들게 됩니다.
또한 ZAP은 여러 세션을 제공하기 때문에 여러 계정정보를 기반으로 동시에 Spidering 도 진행할 수 있습니다. 이는 지난번 글인 Access Control Testing에서도 유용하게 사용될 수 있죠.
그럼 각 도구에서 Auth 기반의 Spidering을 하는 방법에 대해 알아보죠.
Authentication Spidering
Context(Scope) 설정에서 Authentication 부분에서 인증 방법을 정의합니다. form 기반으로 적용해볼게요. 간단한 예시로 Starbucks의 로그인 페이지로 진행해봅시다.
Set Authentication
우선 Authentication mehtod를 Form-based Authentication으로 지정한 후 아래 configure 정보를 채워줍니다.
| Name | Description | |
|---|---|---|
| Authentication | Login Form Target URL | 로그인 Form에서 바라보는 Target URL입니다. (실제 POST 등의 요청이 발생하는 구간) |
| URL to GET Login Page | 로그인 Form이 존재하는 URL입니다. (일반적으로 로그인 페이지) | |
| Login Request POST Data | POST Body를 포맷에 맞춰 작성합니다. | |
| Username and Password Parameters | 위 Body에서 User와 Password로 사용할 필드를 지정합니다. 이는 User 탭에서 여러 사용자를 등록할 때 정보가 매핑되어 사용됩니다. | |
| Verification | Verification Strategy | 인증 상태를 체크하는 방법을 의미합니다. 매번 Req/Res에서 검증할 수도 있고 제가 세팅한 것과 같이 특정 URL을 주기적으로 접근하여 체크할 수도 있습니다. * Check Every Request * Check Every Response * Check Every Request/Response * Poll the Specified URL (주기적으로 특정 URL 접근) |
| Regex pattern used to identify Logged In messages | Poll the Specified URL을 사용한 경우 로그인 상태 식별하기 위한 정규식입니다. | |
| Regex pattern used to identify Logged Out messages | Poll the Specified URL을 사용한 경우 비 로그인 상태를 식별하기 위한 정규식입니다. | |
| Poll Frequncy | 해당 URL을 접근할 주기입니다. | |
| Poll Request POST Data | 해당 URL 접근 시 POST Data가 있는 경우 추가합니다. | |
| Additional Poll Request Headers | 해당 URL 접근 시 Custom Header가 필요하다면 추가합니다. |
Starbucks를 예시로 보면 이렇습니다.
- Target URL: /interface/loginMember.do
- Login Page: /login/login.do
- POST Body: user_id=&user_pwd=&captcha=
- Logged in pattern: result_code: “SUCCESS”
- Logged out pattern: result_code: “FAIL”
- Poll URL: /interface/checkLogin.do
각각 항목에 맞게 데이터를 채워줍시다.
Set Users
User 탭에서 사용자를 추가합니다. 이 때 username과 password는 위에서 매핑한 파라미터로 들어가기 때문에 혹시나 username/password 형태가 아니더라도, 이를 감안하여 추가하면 됩니다.
Spidering with User
이제 Spidering 시 팝업에서 Context와 User를 지정하여 Spidering을 진행합시다.
이제 인증 과정을 포함하여 Spidering을 진행하며 History에서도 로그인 시도와 이를 통해 얻은 Cookie를 기반으로 스캐닝하는 것을 볼 수 있습니다.
ZAP은 위 과정에서 Login을 시도하고, Poll URL로 접근해서 로그인 성공 여부를 체크한 후 성공인 경우 해당 정보를 기반으로 Spidering을 진행하게 됩니다. 그래서 아래와 같이 로그인 사용자만 확인할 수 있는 페이지도 Spidering 되는 것을 확인할 수 있습니다.
Conclusion
Authentication Spiering은 점검할 Endpoint를 찾는데 있어서 정말 중요한 부분입니다. 대부분의 버그바운티 헌터들은 현업 보안 엔지니어와는 다르게 Recon에 굉장히 많은 시간을 투자하는데, 이는 이러한 Endpoint들이 각각의 취약점, 연계되어 큰 보안 이슈를 만들 수 있기 때문이죠. 그래서 Spidering 작업도 굉장히 꼼꼼히 진행해야 한다고 생각합니다.
(물론 보안 엔지니어도 같지만, 어쨌던 회사에서 일하는 엔지니어는 완전한 Black Box Testing은 아니니깐요)
마지막으로 ZAP은 정말 알면 알수록 매력적인 도구인 것 같습니다. 예전에는 무조건 최신 기술에 대한 지원과 확장 기능 때문에 BurpSuite가 좋다고 생각했었는데, 이는 충분히 개인의 스킬과 다른 Cli 도구 등으로 커버할 수 있는 부분이라 잘 커스텀하고, 스킬을 다듬는다면 개인적으론 ZAP이 더 좋은 도구라고 보이네요.
(Burp BE의 쿠키 추가 미지원만 봐도……. 🤬 물론 최근에 추가됬데요 😇 )