AI 지원 AuthZ 리뷰: Ory Kratos의 권한 경계 읽기

AI는 버그를 찾는 데는 서툴지만, 의구심을 불러일으키는 데는 탁월합니다.

보안 분야에서 AI가 할 수 있는 가장 비용이 적게 드는 일은 허위 보고를 쏟아내는 것입니다. 이것이 버그 바운티 프로그램들이 규칙을 일시 중단하거나 강화하고 있는 이유입니다.

저는 AI를 다르게 사용합니다. 저는 저의 AuthZ Smell Catalog를 기반으로 AI가 가설을 과도하게 생성하도록 합니다. 그런 다음, 제가 힘든 작업을 수행합니다. 제 역할은 그 가설들을 격파(kill)하는 것입니다.

성공적인 리뷰는 버그 목록이 아닙니다. 테스트를 통과하지 못한 아이디어들의 격파 테이블(kill table)입니다.

저는 Ory Kratos 소스 코드를 리뷰했습니다. Kratos는 ID 및 사용자 관리를 담당합니다. 여러 ID와 공개 API를 사용하기 때문에 고위험 영역입니다.

저는 다섯 가지 가설을 테스트했습니다:

  • H1: Admin API에 코드 레벨의 권한 부여가 없음.
  • H2: 교차 ID 또는 교차 테넌트 데이터 유출.
  • H3: 복구 흐름에서의 토큰 재사용.
  • H4: 설정 흐름에서의 ID 혼동.
  • H5: 요청 페이로드를 통한 테넌트 할당.

결과:

  • H1: 격파됨. 권한 부여는 코드 핸들러가 아닌 네트워크 경계에서 이루어집니다. 이는 설계 의도입니다.
  • H2: 격파됨. 중앙 데이터 액세스 계층이 테넌트 ID를 기준으로 모든 쿼리를 필터링합니다. 사용자는 이를 우회할 수 없습니다.
  • H3: 격파됨. 토큰은 일회용이며 유효 시간이 제한되어 있습니다.
  • H4: 격파됨. 흐름은 사용자 입력이 아닌 세션에 결합되어 있습니다.
  • H5: 격파됨. 테넌트 ID는 요청 본문이 아닌 시스템 컨텍스트에서 가져옵니다.

다섯 가지 가설을 투입했고, 발견된 취약점은 0건이었습니다. 이것이 성공적인 리뷰입니다.

보안 업무를 위한 두 가지 교훈:

  1. 배포 계층 보안은 보안이 누락된 것처럼 보일 수 있습니다. 보안 장치가 네트워크 레벨에 있다면, 코드는 무방비 상태처럼 보일 것입니다. 아키텍처를 확인하기 전까지는 보고하지 마십시오.

  2. 초크포인트(chokepoint)를 찾으십시오. 시스템이 데이터 계층에서 경계를 강제한다면, 개별 핸들러에는 별도의 체크가 필요하지 않습니다. "이 핸들러가 권한을 확인하는가?"라고 묻는 대신, "초크포인트를 거치지 않고 데이터에 접근할 수 있는 방법이 있는가?"라고 물으십시오.

AI를 사용하여 후보를 탈락시키십시오. 살아남은 것들을 검증하는 데는 인간을 사용하십시오. 가치는 탈락시키는 과정에 있습니다.

Source: https://dev.to/fdjedkdlsspec/ai-assisted-authz-review-reading-permission-boundaries-in-ory-kratos-31cg

Optional learning community: https://t.me/GyaanSetuAi