JavaScript 생태계에 대한 공급망 공격 방지

공급망 공격은 JavaScript 생태계에 큰 문제입니다. 이 짧은 게시물에서는 브라우저 내부와 브라우저 외부 모두에서 모든 JavaScript 런타임에서 구현할 수 있는 간단한 보안 조치를 개략적으로 설명하겠습니다. 이를 통해 오늘날 JavaScript 생태계를 괴롭히는 대부분의 공급망 공격을 방지할 수 있습니다.

문제: 권한 상속

최근 웹사이트가 해킹된 사건은 다음과 같습니다.

• 연구원들은 Polyfill 공급망 공격을 모방 도박 사이트의 거대한 네트워크와 연결합니다

문제의 핵심은 JavaScript 모듈이 이를 호출한 애플리케이션이나 모듈의 권한을 상속한다는 것입니다. 이는 브라우저 내 런타임과 브라우저 외부 런타임 모두에서 문제가 됩니다.

이 문제는 애플리케이션이 의존하는 모듈 버전이 애플리케이션 작성자가 모르는 사이에 변경될 수 있다는 사실로 인해 더욱 복잡해집니다. 따라서 모든 종속성의 코드를 철저하게 검토했더라도(그 자체로 엄청난 노력이 필요함) 종속성 버전이 잠겨 있지 않으면 이러한 노력은 헛수고가 될 것입니다.

버전을 잠그고 semver 기반 종속성을 사용하는 것은 어떨까요? 글쎄요, 이는 주로 모듈 게시자가 버그 수정을 게시하는 경우 수정된 코드를 사용하는 것이 더 낫기 때문입니다. 그리고 이것이 esm.sh와 같은 JavaScript CDN이 semvers를 지원하는 큰 이유 중 하나입니다.

? 웹사이트가 영향을 받는 방식

웹 브라우저는 샌드박스 실행 환경이므로 웹사이트에서 가져온 타사 JavaScript 모듈(3JM)이 최종 사용자의 기기에 손상을 줄 수 없습니다.

그럼에도 불구하고 3JM은 웹사이트의 동의 없이 장치의 컴퓨팅 리소스를 사용하고 비트코인 ​​채굴 등을 위한 네트워크 요청을 발행할 수 있습니다.

? 브라우저 외부 JavaScript 애플리케이션이 미치는 영향

Deno와 같은 일부 브라우저 외부 런타임은 JavaScript/TypeScript 애플리케이션에 부여되는 권한을 제한하는 조치를 구현합니다. 그러나 이러한 조치는 다음과 같은 이유로 부족합니다.

• Deno와 같은 권한 시스템이 시행되더라도 JS 모듈은 제한 없이 호출자의 권한을 상속할 수 있습니다. 즉, 애플리케이션에 전체 쓰기 권한이 있는 경우 컴퓨팅 리소스를 제외한 모든 리소스에 액세스할 수 없는 이메일 주소 검사기가 OS 사용자 모르게 사용자 파일을 삭제할 수 있습니다.
• 애플리케이션은 OS 사용자의 전체 권한으로 실행되는 경우가 많습니다. 예를 들어 MDRB와 같은 도구에서 실행되는 코드의 경우 현재 실행 중인 코드에 대한 권한을 제한하는 것은 불가능합니다.

현재 솔루션

현재 보안 팀은 NPM과 같이 잘 알려진 레지스트리에 게시된 모듈에서 취약점을 찾기 위해 자동화된 프로세스를 마련했습니다. 이 보안 조치에는 몇 가지 단점이 있습니다.

• 게시된 모든 알려진 모듈의 모든 버전을 검색하는 것은 엄청나게 리소스 집약적입니다.
• 실제 사용 가능한 모든 모듈이 스캔되었다는 보장은 없습니다.

? 해결 방법: 모듈별 권한

이러한 문제를 해결하기 위해 JS/TS 애플리케이션이 현재 작동하는 방식과 역호환되는 새로운 모듈별 권한 시스템을 제안합니다.

여기에는 각 애플리케이션과 모듈이 deno.json / deno.jsonc / package.json 파일에서 선언할 수 있는 새로운 선택적 권한 구성이 포함됩니다. 권한은 두 부분으로 구성됩니다:

• Permissions.self — 애플리케이션이나 모듈이 해당 종속 항목에 필요한 권한을 선언하는 곳입니다.
• Permissions.imports — 애플리케이션이나 모듈이 종속성에 할당하기로 동의한 권한을 선언하는 곳입니다. 이는 각 종속성이 요구할 수 있는 권한의 상위 집합입니다.

JS/TS 런타임에서 권한을 사용하는 방법은 다음과 같습니다.

• 애플리케이션이나 모듈이 M 모듈을 가져올 때 런타임은 M의Permissions.self가 가져오기 도구가 M. 그렇지 않은 경우 가져오기에서 오류(예: PermissionError)가 발생합니다.
모듈이나 애플리케이션이 허용되지 않는 작업을 시도하는 경우에도 런타임 오류(예: PermissionError)가 발생합니다. 이 런타임 오류는 애플리케이션을 중단하지 않고도 포착하여 처리할 수 있습니다.

권한의 값은 다음과 같습니다.

{
  "self": {
    "read":  {"allow": [], "deny": []},
    "write": {"allow": [], "deny": []},
    "net":   {"allow": [], "deny": []},
    "env":   {"allow": [], "deny": []},
    "run":   {"allow": [], "deny": []}
  },

  "imports": {
    "jsr:@org/module@1.0.0": {
      "read":  {"allow": [], "deny": []},
      "write": {"allow": [], "deny": []},
      "net":   {"allow": [], "deny": []},
      "env":   {"allow": [], "deny": []},
      "run":   {"allow": [], "deny": []}
    },
    "https://cdn.example/org/module@1.0.0": {
      "read":  {"allow": [], "deny": []},
      "write": {"allow": [], "deny": []},
      "net":   {"allow": [], "deny": []},
      "env":   {"allow": [], "deny": []},
      "run":   {"allow": [], "deny": []}
    },
    "[default]": {
      "read":  {"allow": [], "deny": []},
      "write": {"allow": [], "deny": []},
      "net":   {"allow": [], "deny": []},
      "env":   {"allow": [], "deny": []},
      "run":   {"allow": [], "deny": []}
    }
  }
}

현재 솔루션과 비교하여 제가 제안하는 솔루션은 몇 가지 장점이 있습니다.

• 경량 — 게시된 모듈은 스캔할 필요가 없습니다.
• 철저함 — 런타임에 권한이 적용되므로 올바른 JS/TS 엔진을 사용하면 알 수 없는 모듈이라도 문제를 겪을 수 없습니다.

매우 간단해 보입니다. JS/TS 언어에는 수정이 필요하지 않습니다. 그리고 권한 구성이 없으면 애플리케이션과 해당 종속성 그래프가 모두 명령줄 인수에서 제공한 권한을 갖는 현재 상황으로 돌아갑니다.

위 내용은 JavaScript 생태계에 대한 공급망 공격 방지의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!