Salesforce Aura 데이터 유출, AuraInspector로 분석하기

해당 블로그의 원문은 2026년 1월 13일 Google Cloud 블로그(영문)에 게재되었습니다. 

작성자: Amine Ismail, Anirudha Kanodia

소개 

Aura란 무엇인가?

{"actions":[{"id":"123;a","descriptor":"serviceComponent://ui.force.components.controllers.hostConfig.HostConfigController/ACTION$getConfigData","callingDescriptor":"UNKNOWN","params":{}}]}

응답 예시는 그림 1에 나와 있습니다.

Aura를 사용하여 데이터를 검색하는 방법

Aura를 이용한 데이터 검색

하지만 이 일반적인 접근 방식에는 제약이 있습니다. Salesforce는 사용자가 한 번에 최대 2,000개의 레코드만 검색하도록 허용합니다. 일부 객체에는 수천 개의 레코드가 있을 수 있으므로, 이 방식으로는 검색할 수 있는 레코드 수가 제한됩니다. 설정 오류의 전체적인 영향을 입증하기 위해서는 종종 이 제한을 극복할 필요가 있습니다.

테스트 결과, 이 메서드에서 sortBy 매개변수를 사용할 수 있다는 것이 밝혀졌습니다. 이 매개변수는 정렬 순서를 변경함으로써 2,000개 레코드 제한으로 인해 처음에는 접근할 수 없었던 추가 레코드를 검색할 수 있게 해주기 때문에 유용합니다. 또한, 필드 이름 앞에 - 문자를 추가하여 모든 매개변수에 대해 오름차순 또는 내림차순 정렬 순서를 얻을 수 있습니다. 다음은 sortBy 매개변수를 활용하는 Aura 메시지의 예시입니다.

{"actions":[{"id":"123;a","descriptor":"serviceComponent://ui.force.components.controllers.lists.selectableListDataProvider.SelectableListDataProviderController/ACTION$getItems","callingDescriptor":"UNKNOWN","params":{"entityNameOrId":"FUZZ","layoutType":"FULL","pageSize":100,"currentPage":0,"useTimeout":false,"getCount":false,"enableRowActions":false,"sortBy":"<ArbitraryField>"}}]}

이름(Name) 필드가 내림차순으로 정렬된 응답은 그림 3에 표시되어 있습니다.

기본 제공되는 Salesforce 객체의 경우, 기본적으로 사용할 수 있는 여러 필드가 있습니다. 사용자 지정 객체에는 사용자 지정 필드 외에도, 필터링에 사용할 수 있는 CreatedBy나 LastModifiedBy와 같은 몇 가지 기본 필드가 있습니다. 다양한 필드를 기준으로 필터링하면 훨씬 더 많은 수의 레코드를 쉽게 검색할 수 있습니다. 더 많은 레코드를 검색하는 것은 보안 연구원이 Salesforce 관리자에게 잠재적인 영향의 심각성을 입증하는 데 도움이 됩니다.

액션 벌킹 (Action Bulking)

성능을 최적화하고 네트워크 트래픽을 최소화하기 위해, Salesforce Aura 프레임워크는 "박스카링(boxcar'ing)"이라고 알려진 메커니즘을 사용합니다. 이 프레임워크는 사용자가 시작하는 개별 서버 측 액션마다 별도의 HTTP 요청을 보내는 대신, 클라이언트 측에서 이러한 액션들을 큐(queue)에 쌓아 둡니다. 그리고 이벤트 루프가 끝날 때, 큐에 쌓인 여러 Aura 액션을 단일 목록으로 묶어 하나의 POST 요청으로 서버에 전송합니다.

이 기술을 사용하지 않으면, 레코드와 객체의 수에 따라 레코드를 검색하는 데 상당한 수의 요청이 필요할 수 있습니다. 이와 관련하여 Salesforce는 이 기술을 사용하여 한 번의 요청에 최대 250개의 액션을 허용합니다. 하지만 너무 많은 액션을 보내면 Content-Length 응답(요청 크기 제한)으로 인해 요청이 실패할 수 있습니다. 따라서 Mandiant는 요청당 100개의 액션으로 제한할 것을 권장합니다. 다음 예시에서는 UserFavorite 객체와 ProcessInstanceNode 객체의 레코드를 모두 검색하기 위해 두 개의 액션이 일괄 처리(bulked)됩니다.

{"actions":[{"id":"UserFavorite","descriptor":"serviceComponent://ui.force.components.controllers.lists.selectableListDataProvider.SelectableListDataProviderController/ACTION$getItems","callingDescriptor":"UNKNOWN","params":{"entityNameOrId":"UserFavorite","layoutType":"FULL","pageSize":100,"currentPage":0,"useTimeout":false,"getCount":true,"enableRowActions":false}},{"id":"ProcessInstanceNode","descriptor":"serviceComponent://ui.force.components.controllers.lists.selectableListDataProvider.SelectableListDataProviderController/ACTION$getItems","callingDescriptor":"UNKNOWN","params":{"entityNameOrId":"ProcessInstanceNode","layoutType":"FULL","pageSize":100,"currentPage":0,"useTimeout":false,"getCount":true,"enableRowActions":false}}]}

이 작업을 수많은 액션에 대해 수동으로 수행하는 것은 번거로울 수 있습니다. 이 기능은 잘못 구성된 객체를 식별하는 프로세스의 속도를 높이기 위해 AuraInspector 도구에 통합되었습니다.

레코드 목록 (Record Lists)

비교적 덜 알려진 구성 요소는 Salesforce의 레코드 목록(Record Lists)입니다. 이 구성 요소는 이름에서 알 수 있듯이, 사용자가 접근 권한을 가진 객체와 연관된 레코드 목록을 사용자 인터페이스에 제공합니다. 객체에 대한 접근 제어는 여전히 레코드 목록에서 볼 수 있는 레코드를 관리하지만, 접근 제어가 잘못 구성된 경우 사용자가 특정 객체의 레코드 목록에 접근하도록 허용할 수 있습니다.

ui.force.components.controllers.lists.listViewPickerDataProvider.ListViewPickerDataProviderController/ACTION$getInitialListViews Aura 메서드를 사용하면 특정 객체에 연관된 레코드 목록 구성 요소가 첨부되어 있는지 확인할 수 있습니다. 이때 Aura 메시지는 다음과 같이 나타납니다.

{"actions":[{"id":"1086;a","descriptor":"serviceComponent://ui.force.components.controllers.lists.listViewPickerDataProvider.ListViewPickerDataProviderController/ACTION$getInitialListViews","callingDescriptor":"UNKNOWN","params":{"scope":"FUZZ","maxMruResults":10,"maxAllResults":20},"storable":true}]}

만약 그림 4와 같이 응답에 리스트 뷰의 배열이 포함되어 있다면, 레코드 목록(Record List)이 존재할 가능성이 높습니다.

이 응답은 해당 객체에 연관된 레코드 목록(Record List) 구성 요소가 있으며, 여기에 접근할 수 있다는 것을 의미합니다. 접근이 허용된 경우, /s/recordlist/<object>/Default 경로로 이동하기만 하면 레코드 목록이 표시됩니다. 레코드 목록의 예시는 그림 5에서 볼 수 있습니다. 또한, 이 인터페이스를 통해 기존 레코드를 생성하거나 수정하는 기능이 제공될 수도 있습니다.

홈 URL (Home URLs)

홈 URL은 브라우저에서 직접 접속할 수 있는 URL입니다. Mandiant 연구원들은 여러 차례 이 URL들을 통해 Salesforce 인스턴스에 설치된 서드파티(third-party) 모듈의 관리 또는 설정 패널에 접근할 수 있었습니다. 인증된 사용자는 다음과 같이 ui.communities.components.aura.components.communitySetup.cmc.CMCAppController/ACTION$getAppBootstrapData Aura 메서드를 사용하여 이러한 URL들을 검색할 수 있습니다.

{"actions":[{"id":"1086;a","descriptor":"serviceComponent://ui.communities.components.aura.components.communitySetup.cmc.CMCAppController/ACTION$getAppBootstrapData","callingDescriptor":"UNKNOWN","params":{}}]}

반환된 JSON 응답에서 apiNameToObjectHomeUrls라는 이름의 객체에 URL 목록이 포함되어 있습니다. 다음 단계는 각 URL로 직접 이동하여 접근 권한을 확인하고, 해당 콘텐츠가 정말 접근 가능해야 하는지를 평가하는 것입니다. 이는 흥미로운 발견으로 이어질 수 있는 간단한 과정입니다. 사용 예시는 그림 6에 나와 있습니다.

이전의 한 보안 컨설팅 중에, Mandiant는 이 방법을 통해 인증되지 않은 모든 사용자가 접근할 수 있는 Spark 인스턴스 관리 대시보드를 발견했습니다. 그림 7에서 볼 수 있듯이, 이 대시보드는 다양한 관리 기능을 제공했습니다.

이 기술을 사용하면 Salesforce 관리자는 인증되지 않았거나 권한이 낮은 사용자가 접근해서는 안 되는 페이지를 식별할 수 있습니다. 마켓플레이스 애플리케이션을 설치할 때 일부 페이지가 자동으로 생성되므로 이러한 페이지들을 수동으로 추적하는 것은 번거로울 수 있습니다.

셀프 등록 (Self-Registration)

지난 몇 년간, Salesforce는 게스트 계정에 대한 기본 보안을 강화해왔습니다. 이로 인해, 인증된 계정을 보유하는 것은 인증되지 않은 사용자가 접근할 수 없는 레코드에 대한 접근 권한을 부여할 수 있으므로 더욱 가치가 높아졌습니다.

인스턴스에 대한 인증된 접근을 방지하는 한 가지 해결책은 셀프 등록을 막는 것입니다. 셀프 등록은 인스턴스 설정을 변경하여 쉽게 비활성화할 수 있습니다. 하지만 Mandiant는 로그인 페이지에서 셀프 등록 페이지 링크는 제거되었지만, 셀프 등록 기능 자체는 비활성화되지 않은 사례를 발견했습니다. Salesforce는 이 문제가 해결되었다고 확인했습니다.

셀프 등록 상태와 URL을 노출하는 Aura 메서드는 공격자의 관점에서 매우 가치가 높습니다. LoginFormController 컨트롤러의 getIsSelfRegistrationEnabled 및 getSelfRegistrationUrl 메서드를 다음과 같이 사용하여 이 정보를 가져올 수 있습니다.

{"actions":[{"id":"1","descriptor":"apex://applauncher.LoginFormController/ACTION$getIsSelfRegistrationEnabled","callingDescriptor":"UHNKNOWN"},{"id":"2","descriptor":"apex://applauncher.LoginFormController/ACTION$getSelfRegistrationUrl","callingDescriptor":"UHNKNOWN"}]}

이를 통해 셀프 등록 페이지를 찾기 위해 무차별 대입 공격(brute forcing)을 할 필요가 없어지며, 단 한 번의 요청만으로도 충분합니다. AuraInspector 도구는 셀프 등록 기능이 활성화되어 있는지 확인하고 연구원에게 알려줍니다. 이 기능의 목표는 Salesforce 관리자가 외부 관점에서 셀프 등록의 활성화 여부를 판단할 수 있도록 돕는 것입니다.

GraphQL: 2,000개 레코드 제한을 넘어서

그러나 이러한 문서의 부재가 이 기능의 사용을 막지는 못했습니다. REST API 문서를 검토한 후, Mandiant는 GraphQL Aura 컨트롤러의 정보를 검색하기 위한 유효한 요청을 구성해냈습니다. 더욱이, 이 컨트롤러는 기본적으로 인증되지 않은 사용자도 사용할 수 있었습니다. 기존의 알려진 방법 대신 GraphQL을 사용하면 다음과 같은 여러 이점을 얻을 수 있습니다.

• 객체의 레코드 및 정보에 대한 표준화된 검색 방식

• 개선된 페이지네이션(pagination) 기능으로 객체에 연결된 모든 레코드 검색 가능

• 필드 이름 검색을 용이하게 하는 내장된 인트로스펙션(introspection) 기능

• 뮤테이션(mutations) 지원으로 객체에 대한 쓰기 권한 테스트 가속화

데이터 검색 관점에서 핵심적인 이점은 2,000개 레코드 제한에 구애받지 않고 객체에 연결된 모든 레코드를 검색할 수 있다는 것입니다. Salesforce는 이것이 취약점이 아니라고 확인했습니다. GraphQL은 기본 객체 권한을 존중하며, 객체 접근이 올바르게 구성되어 있는 한 추가적인 접근 권한을 제공하지 않습니다. 하지만, 설정이 잘못된 경우에는 공격자가 잘못 구성된 객체의 모든 레코드에 접근하는 것을 돕습니다. 기본 Aura 컨트롤러를 사용하여 레코드를 검색할 때 2,000개 이상의 레코드를 검색하는 유일한 방법은 정렬 필터를 사용하는 것인데, 이는 항상 일관된 결과를 제공하지는 않습니다. GraphQL 컨트롤러를 사용하면 가능한 최대 레코드 수를 일관되게 검색할 수 있습니다. 2,000개 이상의 레코드를 검색하는 다른 옵션으로는 SOAP 및 REST API가 있지만, 권한이 없는 사용자는 거의 접근할 수 없습니다.

GraphQL 컨트롤러의 한 가지 한계는 사용자 인터페이스 API(UIAPI)에서 지원하는 객체의 레코드만 검색할 수 있다는 점입니다. 관련 Salesforce GraphQL API 문서에 설명된 바와 같이, "사용자 인터페이스 API는 모든 사용자 지정 객체, 외부 객체 및 다수의 표준 객체를 지원"하므로 대부분의 객체가 여기에 포함됩니다.

GraphQL Aura 컨트롤러 자체에 대한 문서가 없기 때문에 API 문서가 참조 자료로 사용되었습니다. API 문서는 GraphQL API 엔드포인트와 상호 작용하기 위해 다음 예시를 제공합니다.

curl "https://{MyDomainName}[.my.salesforce.com/services/data/v64.0/graphql](https://.my.salesforce.com/services/data/v64.0/graphql)" \
  -X POST \
  -H "content-type: application/json" \
  -d '{
  "query": "query accounts { uiapi { query { Account { edges { node { Name { value } } } } } } }"
}

{"actions":[{"id":"GraphQL","descriptor":"aura://RecordUiController/ACTION$executeGraphQL","callingDescriptor":"markup://forceCommunity:richText","params":{"queryInput":{"operationName":"accounts","query":"query+accounts+{uiapi+{query+{Account+{edges+{node+{+Name+{+value+}}}totalCount,pageInfo{endCursor,hasNextPage,hasPreviousPage}}}}}","variables":{}}},"version":"64.0","storable":true}]}

쿼리한 필드와 함께 레코드들이 반환되며, 커서(cursor)를 포함하는 pageInfo 객체도 함께 제공됩니다. 이 커서를 사용하면 다음 레코드들을 검색할 수 있습니다. 앞서 언급된 예시에서는 가독성을 위해 단 하나의 레코드만 검색했지만, first 매개변수를 2000으로 설정하여 2,000개 레코드 단위로 일괄 처리할 수 있습니다. 그런 다음 커서는 그림 11과 같이 사용할 수 있습니다.

여기서 커서(cursor)는 마지막으로 검색된 레코드를 가리키는 Base64 인코딩 문자열이므로, 직접 쉽게 구성할 수 있습니다. 2,000개 레코드 단위로 묶어서 처리할 때, 2,000번째부터 4,000번째까지의 항목을 검색하기 위한 메시지는 다음과 같습니다.

message={"actions":[{"id":"GraphQL","descriptor":"aura://RecordUiController/ACTION$executeGraphQL","callingDescriptor":"markup://forceCommunity:richText","params":{"queryInput":{"operationName":"accounts","query":"query+accounts+{uiapi+{query+{Contact(first:2000,after:\"djE6MTk5OQ==\"){edges+{node+{+Name+{+value+}}}totalCount,pageInfo{endCursor,hasNextPage,hasPreviousPage}}}}}","variables":{}}},"version":"64.0","storable":true}]}

이 예시에서 after 매개변수에 설정된 커서는 v1:1999를 Base64로 인코딩한 값입니다. 이는 Salesforce에게 1999번째 항목 이후의 아이템들을 검색하라고 지시합니다. 쿼리는 고급 필터링이나 조인(join) 연산을 포함하여 특정 레코드를 검색하는 등 훨씬 더 복잡해질 수 있습니다. 하나의 쿼리에서 여러 객체를 동시에 검색할 수도 있습니다. 여기서 자세히 다루지는 않았지만, GraphQL 컨트롤러는 뮤테이션(mutation) 쿼리를 사용하여 레코드를 업데이트, 생성, 삭제하는 데에도 사용될 수 있습니다. 이를 통해 인증되지 않은 사용자도 API 접근 없이 복잡한 쿼리와 작업을 수행할 수 있습니다.

해결 방안

이 블로그 게시물에서 설명된 모든 문제는 근본적으로 객체 및 필드의 잘못된 설정에서 비롯됩니다. Salesforce 관리자는 이러한 문제를 해결하기 위해 다음과 같은 조치를 취해야 합니다.

• 게스트 사용자 권한 감사: 정기적으로 인증되지 않은 게스트 사용자 프로필을 검토하고 최소 권한의 원칙을 적용하십시오. 게스트 사용자 객체 보안을 위해 Salesforce 보안 모범 사례를 따르십시오. 게스트 사용자가 외부에 공개되는 기능에 필요한 특정 객체와 필드에 대해서만 읽기 접근 권한을 갖도록 해야 합니다.

• 인증된 사용자의 개인 데이터 보호: 공유 규칙과 조직 전체 기본값을 검토하여, 인증된 사용자가 명시적으로 권한이 부여된 레코드와 객체에만 접근할 수 있도록 하십시오.

• 셀프 등록 비활성화: 불필요한 경우, 셀프 등록 기능을 비활성화하여 허가되지 않은 계정 생성을 방지하십시오.

• Salesforce 보안 모범 사례 준수: Salesforce에서 제공하는 보안 상태 확인 도구 사용을 포함하여, 보안 권장 사항을 구현하십시오.

Salesforce는 객체 공유 규칙, 필드 보안, 로깅, 실시간 이벤트 모니터링 등을 올바르게 구성하는 방법을 상세히 설명하는 포괄적인 보안 가이드를 제공합니다.

올인원(All-in-One) 도구: AuraInspector

이러한 잘못된 설정을 발견하는 데 도움을 주기 위해 Mandiant는 AuraInspector를 출시합니다. 이 도구는 본 게시물에서 설명된 기술을 자동화하여 잠재적인 취약점을 식별하는 데 도움을 줍니다. Mandiant는 또한 레코드 추출 기능을 갖춘 내부 버전의 도구를 개발했습니다. 하지만 오용을 방지하기 위해 데이터 추출 기능은 공개 릴리스에 포함되지 않았습니다. 도구의 옵션과 기능은 그림 12에 나와 있습니다.

AuraInspector 도구는 또한 다음과 같은 유용한 컨텍스트 정보를 자동으로 발견하려고 시도합니다.

• Aura 엔드포인트: 추가 테스트를 위해 Aura 엔드포인트를 자동으로 식별합니다.

• 홈 및 레코드 목록 URL: 홈페이지 및 레코드 목록으로 연결되는 직접 URL을 검색하여, 사용자의 이동 경로와 접근 가능한 데이터 뷰에 대한 통찰력을 제공합니다.

• 셀프 등록 상태: 셀프 등록 기능의 활성화 여부를 확인하고, 활성화된 경우 셀프 등록 URL을 제공합니다.

이 도구로 수행되는 모든 작업은 데이터를 읽는 것으로 엄격히 제한되므로, 대상 Salesforce 인스턴스에 영향을 주거나 수정하지 않습니다. AuraInspector는 지금 바로 다운로드할 수 있습니다.

Salesforce 인스턴스 탐지

Salesforce Experience Cloud 애플리케이션은 종종 Aura 엔드포인트에 명시적인 요청을 보내지만, 애플리케이션의 통합이 더 미묘하게 이루어지는 상황도 있습니다. Mandiant는 대용량 자바스크립트(JavaScript) 파일에 숨겨진 Salesforce Experience Cloud 애플리케이션에 대한 참조를 자주 발견합니다. 다음과 같은 Salesforce 도메인에 대한 참조를 찾아보는 것이 좋습니다.

• *.vf.force.com

• *.my.salesforce-sites.com

• *.my.salesforce.com

metadata:
    language: v2-beta
    name: "Hidden Salesforce app detected"
    description: "Salesforce app might be used by some functionality of the application"
    tags: "passive"
    author: "Mandiant"

given response then
    if ".my.site.com" in {latest.response} or ".vf.force.com" in {latest.response} or ".my.salesforce-sites.com" in {latest.response} or ".my.salesforce.com" in {latest.response} then
        report issue:
            severity: info
            confidence: certain
            detail: "Backend Salesforce app detected"
            remediation: "Validate whether the app belongs to the org and check for potential misconfigurations"
    end if

이는 기본적인 템플릿이며, 다른 관련 패턴을 사용하여 Salesforce 인스턴스를 더 잘 식별할 수 있도록 추가로 미세 조정할 수 있다는 점에 유의하십시오.

다음은 잠재적인 Salesforce 인스턴스의 Aura 엔드포인트에 대한 POST 요청과 관련된 Google SecOps 내 이벤트를 식별하는 데 도움이 되는 대표적인 UDM 쿼리입니다.

target.url = /\/aura$/ AND 
network.http.response_code = 200 AND 
network.http.method = "POST"

이는 기본적인 UDM 쿼리이며, 다른 관련 패턴을 사용하여 Salesforce 인스턴스를 더 잘 식별할 수 있도록 추가로 미세 조정할 수 있다는 점에 유의하십시오.

Mandiant 서비스

Mandiant 컨설팅은 조직이 Salesforce 환경을 감사하고 강력한 접근 제어를 구현하는 데 도움을 줄 수 있습니다. 저희 전문가들은 잘못된 설정을 식별하고, 보안 태세를 검증하며, 민감한 데이터를 보호하기 위한 모범 사례 준수를 보장할 수 있습니다.

감사의 말