• Hacky_AI - Sast

해커가 좋아하는 인증

• 김민곤, 정민석 님

• 화햇스쿨

• OAuth 깊이 이해함. → 취약점 발견

• OAuth 관련 보안 위협을 조기에 발견하여 안전한 인증/인가 환경에 기여

  • 인증 (Authenticaion) : 나 임을 증명
  • 인가 : 권한 부여

• 과거 - ID/pw → 쿠키, 세션

• 현재 - SSO 로그인 → SNS 기반 로그인 → OAuth 기반 프로토콜로 이루어져 있음

• OAuth : 확장성

  • 확장성이 좋음. OIDC 등과 함께 사용
  • 유연한 서비스 통합 → 연동 지원(구글, 네이버 등)
  • 사용자 인증 정보 보호 → 어플리케이션이 크게 다루지 않아서 보안위협 최소화
  • 개발과정에서의 실수로 인한 보안 취협을 초래할 수 있음. → 복잡한 흐름은 취약점으로 이루어 짐
  • 토큰 발행 문제 → 사용자의 권한 부여(인가 토큰, 토큰 전달 행위)
  • 구글, 사용자 모두 발행..

• 토큰을 직접 발급받는다 → Example 서비스에서 토큰 검증이 부족하다면, 토큰 주입을 통해 인증 우회, 계정 탈퇴

• Implict Grant Type - URL, 히스토리, 로그 등에 저장될 수 있고, 의도치 않게 토큰이 노출된 위험

• 유효기간 전까지는 공격자가 악용가능함

• Implict Grant type은 OAuth2.1에서 제거됨

• Authorization Code Grant Type

  • 인가코드 발급, 제출에서 달라짐 → 1회용
  • 피해자의 계정에서 로그인된 상태라면 → 공격자 인가링크 포함된 걸 공격자 AUthorization 제출
    • 피해자 Authorization 계정 - 공격자 구글 계정 연동
    • open Ridirection으로 인가 코드 탈취

• PKCE :

  • 인가코드 : 토큰교환수단
  • 유효성 검증.. → PKC
  • Code_challenge == method(Code Verifier)
  • challenge와 method를 구글에 제출 → PKC 중간자 공겨 방어
  • Misconfiguration
  • PKCE 정보 누락한 요청을 허용하면 → 안전하지 않은 방식으로 회귀할 수 있음

• PKCE 강제성 필요

• 안전한 인증, 인가 환경에 기여함.

  • 어떤 부분이 안전하지 않는가
  • 버그바운티 플랫폼 대상 대규모 점검 수행
  • 자동화 도구 제작 → 탐지 시작
    • 기존 자동화 도구의 한계 → 수동 로그인 과정 진행, 제한적인 취약성 탐지, ,기능 확장 어려움
    • 개선 → AI를 활용한 로그인 자동화, 폭넓은 취약성 탐지, 확장성 고려 설계
    • 도메인 리스트 수집 → LLM으로 브라우저를 제어하여 로그인 페이지 탐섹 → proxy 도구 이용해 실시간 요청 분석 및 OAuth 취약서 탐지 →
    • Browser USe : 오픈소스 도구 → 프롬포트 입력하면 AI가 브라우저를 조작함.
    • 표준 프로토콜 보안 고려사항, 개발과정에서 쉽게 실수할 만한 취약성, 파급력 높은 취약성
  • 기존도구 : grant type, state 파라미터 유무
  • AI 프롬포트 기반은 디버깅 어려움.
  • Agent 역할을 분담.. - 멀티 Agent로 해결