보안 모범 사례

의도

이 문서는 현재의 위협 모델을 확장하고 Node.js 애플리케이션을 안전하게 보호하는 방법에 대한 광범위한 지침을 제공하는 것을 목표로 합니다.

문서 내용

• 모범 사례: 모범 사례를 간결하게 요약하여 볼 수 있는 방법입니다. 이 이슈 또는 이 가이드라인을 시작점으로 사용할 수 있습니다. 이 문서는 Node.js에 특화되어 있으며, 광범위한 내용을 찾고 있다면 OSSF 모범 사례를 고려해야 합니다.
• 공격 설명: 위협 모델에서 언급하는 공격에 대한 설명을 코드 예시(가능한 경우)와 함께 이해하기 쉬운 영어로 설명하고 문서화합니다.
• 타사 라이브러리: 위협(오타 공격, 악성 패키지 등)과 노드 모듈 종속성 등에 관한 모범 사례를 정의합니다.

위협 목록

HTTP 서버 서비스 거부 (CWE-400)

이는 들어오는 HTTP 요청을 처리하는 방식 때문에 애플리케이션이 설계된 목적에 사용할 수 없게 되는 공격입니다. 이러한 요청은 악의적인 공격자가 의도적으로 조작할 필요는 없습니다. 잘못 구성되거나 버그가 있는 클라이언트도 서버에 서비스 거부를 초래하는 요청 패턴을 보낼 수 있습니다.

HTTP 요청은 Node.js HTTP 서버에서 수신되어 등록된 요청 핸들러를 통해 애플리케이션 코드로 전달됩니다. 서버는 요청 본문의 내용을 구문 분석하지 않습니다. 따라서 요청 핸들러로 전달된 후 본문 내용으로 인해 발생하는 DoS는 Node.js 자체의 취약점이 아닙니다. 애플리케이션 코드가 올바르게 처리해야 할 책임이 있기 때문입니다.

웹 서버가 소켓 오류를 올바르게 처리하는지 확인해야 합니다. 예를 들어 오류 처리기 없이 서버를 생성하면 DoS에 취약해집니다.

import net from 'node:net'
const server = net.createServer(socket => {
  // socket.on('error', console.error) // 서버 충돌을 방지합니다.
  socket.write('Echo server\r\n')
  socket.pipe(socket)
})
server.listen(5000, '0.0.0.0')

잘못된 요청이 수행되면 서버가 충돌할 수 있습니다.

요청 내용으로 인해 발생하지 않는 DoS 공격의 예는 Slowloris입니다. 이 공격에서는 HTTP 요청을 한 번에 하나씩 천천히 조각화하여 보냅니다. 전체 요청이 전달될 때까지 서버는 진행 중인 요청에 전용 리소스를 유지합니다. 이러한 요청이 동시에 충분히 많이 전송되면 동시 연결 수가 최대치에 도달하여 서비스 거부가 발생합니다. 이 공격은 요청 내용이 아니라 서버로 전송되는 요청의 타이밍과 패턴에 의존합니다.

완화 방법

• 역방향 프록시를 사용하여 요청을 수신하고 Node.js 애플리케이션으로 전달합니다. 역방향 프록시는 캐싱, 로드 밸런싱, IP 블랙리스트 등을 제공하여 DoS 공격이 효과적일 가능성을 줄일 수 있습니다.
• 서버 시간 초과를 올바르게 구성하여 유휴 상태이거나 요청이 너무 느리게 도착하는 연결을 끊을 수 있습니다. http.Server의 여러 시간 초과, 특히 headersTimeout, requestTimeout, timeout 및 keepAliveTimeout을 참조하십시오.
• 호스트당 및 전체적으로 열린 소켓 수를 제한합니다. http 문서, 특히 agent.maxSockets, agent.maxTotalSockets, agent.maxFreeSockets 및 server.maxRequestsPerSocket을 참조하십시오.

DNS 재바인딩(CWE-346)

이것은 --inspect 스위치를 사용하여 디버깅 검사기를 활성화한 상태로 실행되는 Node.js 애플리케이션을 대상으로 할 수 있는 공격입니다.

웹 브라우저에서 열린 웹사이트는 WebSocket 및 HTTP 요청을 할 수 있으므로 로컬에서 실행 중인 디버깅 검사기를 대상으로 할 수 있습니다. 이것은 일반적으로 최신 브라우저에서 구현하는 동일 출처 정책에 의해 방지됩니다. 이 정책은 스크립트가 다른 출처에서 리소스에 접근하는 것을 금지합니다. 즉, 악성 웹사이트가 로컬 IP 주소에서 요청한 데이터를 읽을 수 없습니다.

그러나 DNS 재바인딩을 통해 공격자는 요청의 출처를 일시적으로 제어하여 로컬 IP 주소에서 시작된 것처럼 보이게 할 수 있습니다. 이는 웹사이트와 IP 주소를 확인하는 데 사용되는 DNS 서버를 모두 제어함으로써 수행됩니다. 자세한 내용은 DNS 재바인딩 위키를 참조하십시오.

완화 방법

• process.on(‘SIGUSR1’, …) 리스너를 연결하여 SIGUSR1 신호에서 검사기를 비활성화합니다.
• 프로덕션 환경에서 검사기 프로토콜을 실행하지 마십시오.

권한 없는 행위자에 대한 민감한 정보 노출(CWE-552)

패키지 게시 중에 현재 디렉토리에 포함된 모든 파일과 폴더가 npm 레지스트리로 푸시됩니다.

.npmignore 및 .gitignore로 차단 목록을 정의하거나 package.json에서 허용 목록을 정의하여 이 동작을 제어하는 몇 가지 메커니즘이 있습니다.

완화 방법

• npm publish --dry-run을 사용하여 게시할 모든 파일 목록을 확인합니다. 패키지를 게시하기 전에 내용을 검토해야 합니다.
• .gitignore 및 .npmignore와 같은 무시 파일을 만들고 유지 관리하는 것도 중요합니다. 이러한 파일을 통해 게시하지 않아야 할 파일/폴더를 지정할 수 있습니다. package.json의 files 속성은 반대 작업인 허용된 목록을 허용합니다.
• 노출된 경우 패키지 게시 취소를 수행해야 합니다.

HTTP 요청 밀수 (CWE-444)

이것은 두 개의 HTTP 서버(일반적으로 프록시와 Node.js 애플리케이션)를 포함하는 공격입니다. 클라이언트는 프런트엔드 서버(프록시)를 먼저 거친 다음 백엔드 서버(애플리케이션)로 리디렉션되는 HTTP 요청을 보냅니다. 프런트엔드와 백엔드가 모호한 HTTP 요청을 다르게 해석할 때 공격자가 프런트엔드에서는 보이지 않지만 백엔드에서는 보이는 악성 메시지를 보내 프록시 서버를 효과적으로 "밀수"할 가능성이 있습니다.

자세한 설명과 예는 CWE-444를 참조하십시오.

이 공격은 Node.js가 HTTP 요청을 (임의의) HTTP 서버와 다르게 해석하는 데 달려 있기 때문에 성공적인 공격은 Node.js, 프런트엔드 서버 또는 둘 다의 취약점으로 인해 발생할 수 있습니다. Node.js가 요청을 해석하는 방식이 HTTP 사양(RFC7230 참조)과 일치하면 Node.js의 취약점으로 간주되지 않습니다.

완화 방법

• HTTP 서버를 만들 때 insecureHTTPParser 옵션을 사용하지 마십시오.
• 모호한 요청을 정규화하도록 프런트엔드 서버를 구성하십시오.
• Node.js와 선택한 프런트엔드 서버 모두에서 새로운 HTTP 요청 밀수 취약성을 지속적으로 모니터링하십시오.
• 가능하면 엔드 투 엔드 HTTP/2를 사용하고 HTTP 다운그레이드를 비활성화하십시오.

타이밍 공격을 통한 정보 노출 (CWE-208)

이는 공격자가 예를 들어 애플리케이션이 요청에 응답하는 데 걸리는 시간을 측정하여 잠재적으로 민감한 정보를 학습할 수 있게 하는 공격입니다. 이 공격은 Node.js에만 국한된 것이 아니며 거의 모든 런타임을 대상으로 할 수 있습니다.

애플리케이션이 타이밍에 민감한 작업(예: 분기)에서 비밀을 사용할 때마다 공격이 가능합니다. 일반적인 애플리케이션에서 인증 처리를 고려해 보십시오. 여기서 기본 인증 방법에는 자격 증명으로 이메일과 비밀번호가 포함됩니다. 사용자 정보는 사용자가 이상적으로 DBMS에서 제공한 입력에서 검색됩니다. 사용자 정보를 검색하면 비밀번호가 데이터베이스에서 검색된 사용자 정보와 비교됩니다. 내장된 문자열 비교를 사용하면 동일한 길이의 값에 대해 더 오랜 시간이 걸립니다. 이 비교는 허용 가능한 양만큼 실행될 때 요청의 응답 시간이 의도치 않게 증가합니다. 요청 응답 시간을 비교하여 공격자는 많은 수의 요청에서 비밀번호의 길이와 값을 추측할 수 있습니다.

완화 방법

• crypto API는 상수 시간 알고리즘을 사용하여 실제 및 예상 민감한 값을 비교하는 함수 timingSafeEqual을 노출합니다.
• 비밀번호 비교를 위해 네이티브 crypto 모듈에서도 사용할 수 있는 scrypt를 사용할 수 있습니다.
• 일반적으로 가변 시간 작업에서 비밀 사용을 피하십시오. 여기에는 비밀에 대한 분기가 포함되며, 공격자가 동일한 인프라(예: 동일한 클라우드 머신)에 공동으로 배치될 수 있는 경우 비밀을 메모리 인덱스로 사용하는 것이 포함됩니다. JavaScript에서 상수 시간 코드를 작성하는 것은 어렵습니다(부분적으로는 JIT 때문). crypto 애플리케이션의 경우 내장 crypto API 또는 WebAssembly(네이티브로 구현되지 않은 알고리즘의 경우)를 사용하십시오.

악성 제3자 모듈 (CWE-1357)

현재 Node.js에서 모든 패키지는 네트워크 액세스와 같은 강력한 리소스에 액세스할 수 있습니다. 또한 파일 시스템에 액세스할 수 있으므로 모든 데이터를 어디든 보낼 수 있습니다.

노드 프로세스에서 실행되는 모든 코드는 eval()(또는 이와 동등한 것)을 사용하여 추가적인 임의 코드를 로드하고 실행할 수 있는 기능을 가지고 있습니다. 파일 시스템 쓰기 액세스 권한이 있는 모든 코드는 로드되는 새 파일 또는 기존 파일에 작성하여 동일한 결과를 얻을 수 있습니다.

Node.js에는 로드된 리소스를 신뢰할 수 없거나 신뢰할 수 있는 것으로 선언하는 실험적¹ 정책 메커니즘이 있습니다. 그러나 이 정책은 기본적으로 활성화되어 있지 않습니다. 일반적인 워크플로 또는 npm 스크립트를 사용하여 종속성 버전을 고정하고 취약성에 대한 자동 검사를 실행해야 합니다. 패키지를 설치하기 전에 이 패키지가 유지 관리되고 있으며 예상한 모든 내용이 포함되어 있는지 확인하십시오. GitHub 소스 코드가 게시된 코드와 항상 동일한 것은 아니므로 node_modules에서 유효성을 검사하십시오.

공급망 공격

Node.js 애플리케이션에 대한 공급망 공격은 직접 또는 전이적인 종속성 중 하나가 손상되었을 때 발생합니다. 이는 애플리케이션이 종속성 사양에 대해 너무 느슨하거나(원치 않는 업데이트 허용) 사양에 일반적인 오타가 있는 경우( 타이포스쿼팅에 취약함) 발생할 수 있습니다.

업스트림 패키지를 제어하는 공격자는 악성 코드가 포함된 새 버전을 게시할 수 있습니다. Node.js 애플리케이션이 사용할 수 있는 안전한 버전에 엄격하지 않고 해당 패키지에 의존하는 경우 패키지가 자동으로 최신 악성 버전으로 업데이트되어 애플리케이션을 손상시킬 수 있습니다.

package.json 파일에 지정된 종속성은 정확한 버전 번호 또는 범위를 가질 수 있습니다. 그러나 종속성을 정확한 버전에 고정할 때 전이 종속성은 자체적으로 고정되지 않습니다. 이렇게 하면 애플리케이션이 원치 않거나 예상치 못한 업데이트에 취약해집니다.

가능한 공격 벡터:

• 타이포스쿼팅 공격
• 잠금 파일 포이즈닝
• 손상된 유지 관리자
• 악성 패키지
• 종속성 혼동

완화 방법

• --ignore-scripts를 사용하여 npm이 임의의 스크립트를 실행하는 것을 방지합니다.
  • 또한 npm config set ignore-scripts true를 사용하여 전역적으로 비활성화할 수 있습니다.
• 종속성 버전을 범위이거나 변경 가능한 소스의 버전이 아닌 특정 불변 버전에 고정합니다.
• 모든 종속성(직접 및 전이적)을 고정하는 잠금 파일을 사용합니다.
  • 잠금 파일 포이즈닝에 대한 완화를 사용합니다.
• npm-audit와 같은 도구를 사용하여 CI를 통해 새로운 취약점에 대한 검사를 자동화합니다.
  • Socket과 같은 도구를 사용하여 정적 분석으로 패키지를 분석하여 네트워크 또는 파일 시스템 액세스와 같은 위험한 동작을 찾을 수 있습니다.
• npm install 대신 npm ci를 사용합니다. 이렇게 하면 잠금 파일이 적용되므로 잠금 파일과 package.json 파일 간의 불일치가 오류를 유발합니다(package.json을 우선하여 잠금 파일을 무시하는 대신).
• package.json 파일에서 종속성 이름의 오류/오타를 주의 깊게 확인합니다.

메모리 접근 위반 (CWE-284)

메모리 기반 또는 힙 기반 공격은 메모리 관리 오류와 악용 가능한 메모리 할당자의 조합에 따라 달라집니다. 모든 런타임과 마찬가지로 Node.js도 공유 머신에서 프로젝트를 실행하는 경우 이러한 공격에 취약합니다. 포인터 오버런 및 언더런으로 인해 중요한 정보가 유출되는 것을 방지하는 데 안전한 힙을 사용하는 것이 유용합니다.

안타깝게도 Windows에서는 안전한 힙을 사용할 수 없습니다. 자세한 내용은 Node.js 보안 힙 문서에서 확인할 수 있습니다.

완화

• 할당된 최대 바이트 크기인 n을 사용하여 애플리케이션에 따라 --secure-heap=n을 사용합니다.
• 공유 머신에서 프로덕션 앱을 실행하지 마십시오.

몽키 패칭 (CWE-349)

몽키 패칭은 기존 동작을 변경하기 위해 런타임에 속성을 수정하는 것을 의미합니다. 예:

// eslint-disable-next-line no-extend-native
Array.prototype.push = function (item) {
  // 글로벌 [].push 재정의
}

완화

--frozen-intrinsics 플래그는 실험적¹ 고정 내장 기능을 활성화합니다. 즉, 모든 내장 JavaScript 객체와 함수가 재귀적으로 고정됩니다. 따라서 다음 스니펫은 Array.prototype.push의 기본 동작을 재정의하지 않습니다.

// eslint-disable-next-line no-extend-native
Array.prototype.push = function (item) {
  // 글로벌 [].push 재정의
}
// Uncaught:
// TypeError <Object <Object <[Object: null prototype] {}>>>:
// 객체의 읽기 전용 속성 'push'에 할당할 수 없습니다.

그러나 globalThis를 사용하여 새 전역 변수를 정의하고 기존 전역 변수를 대체할 수 있다는 점을 언급하는 것이 중요합니다.

globalThis.foo = 3; foo; // 새 전역 변수를 정의할 수 있습니다. 3
globalThis.Array = 4; Array; // 그러나 기존 전역 변수를 대체할 수도 있습니다. 4

따라서 Object.freeze(globalThis)를 사용하여 전역 변수가 대체되지 않도록 보장할 수 있습니다.

프로토타입 오염 공격 (CWE-1321)

프로토타입 오염은 내장 프로토타입에서 상속된 _proto, _constructor, prototype 및 기타 속성 사용을 남용하여 JavaScript 언어 항목에 속성을 수정하거나 주입할 수 있는 가능성을 의미합니다.

const a = { a: 1, b: 2 }
const data = JSON.parse('{"__proto__": { "polluted": true}}')
const c = Object.assign({}, a, data)
console.log(c.polluted) // true
// 잠재적인 DoS
const data2 = JSON.parse('{"__proto__": null}')
const d = Object.assign(a, data2)
d.hasOwnProperty('b') // 포착되지 않은 TypeError: d.hasOwnProperty는 함수가 아닙니다.

이는 JavaScript 언어에서 상속된 잠재적인 취약점입니다.

예시

• CVE-2022-21824 (Node.js)
• CVE-2018-3721 (타사 라이브러리: Lodash)

완화책

• 안전하지 않은 재귀 병합을 피하십시오. CVE-2018-16487을 참조하십시오.
• 외부/신뢰할 수 없는 요청에 대한 JSON 스키마 유효성 검사를 구현하십시오.
• Object.create(null)을 사용하여 프로토타입 없이 객체를 생성하십시오.
• 프로토타입 동결: Object.freeze(MyObject.prototype).
• --disable-proto 플래그를 사용하여 Object.prototype.__proto__ 속성을 비활성화하십시오.
• Object.hasOwn(obj, keyFromObj)을 사용하여 프로토타입이 아닌 객체에 직접 속성이 있는지 확인하십시오.
• Object.prototype의 메서드 사용을 피하십시오.

제어되지 않는 검색 경로 요소 (CWE-427)

Node.js는 모듈 해결 알고리즘에 따라 모듈을 로드합니다. 따라서 모듈이 요청(require)되는 디렉터리가 신뢰할 수 있다고 가정합니다.

즉, 다음 응용 프로그램 동작이 예상됩니다. 다음 디렉터리 구조를 가정합니다.

• app/
  • server.js
  • auth.js
  • auth

server.js가 require('./auth')를 사용하면 모듈 해결 알고리즘에 따라 auth.js 대신 auth를 로드합니다.

완화책

실험적¹ 무결성 검사를 사용한 정책 메커니즘을 사용하면 위의 위협을 피할 수 있습니다. 위에 설명된 디렉터리의 경우 다음 policy.json을 사용할 수 있습니다.

{
  "resources": {
    "./app/auth.js": {
      "integrity": "sha256-iuGZ6SFVFpMuHUcJciQTIKpIyaQVigMZlvg9Lx66HV8="
    },
    "./app/server.js": {
      "dependencies": {
        "./auth": "./app/auth.js"
      },
      "integrity": "sha256-NPtLCQ0ntPPWgfVEgX46ryTNpdvTWdQPoZO3kHo0bKI="
    }
  }
}

따라서 auth 모듈을 요구할 때 시스템은 무결성을 검증하고 예상되는 무결성과 일치하지 않으면 오류를 발생시킵니다.

» node --experimental-policy=policy.json app/server.js
node:internal/policy/sri:65
      throw new ERR_SRI_PARSE(str, str[prevIndex], prevIndex);
      ^
SyntaxError [ERR_SRI_PARSE]: Subresource Integrity string "sha256-iuGZ6SFVFpMuHUcJciQTIKpIyaQVigMZlvg9Lx66HV8=%" had an unexpected "%" at position 51
    at new NodeError (node:internal/errors:393:5)
    at Object.parse (node:internal/policy/sri:65:13)
    at processEntry (node:internal/policy/manifest:581:38)
    at Manifest.assertIntegrity (node:internal/policy/manifest:588:32)
    at Module._compile (node:internal/modules/cjs/loader:1119:21)
    at Module._extensions..js (node:internal/modules/cjs/loader:1213:10)
    at Module.load (node:internal/modules/cjs/loader:1037:32)
    at Module._load (node:internal/modules/cjs/loader:878:12)
    at Module.require (node:internal/modules/cjs/loader:1061:19)
    at require (node:internal/modules/cjs/helpers:99:18) {
  code: 'ERR_SRI_PARSE'
}

정책 변경을 피하기 위해 항상 --policy-integrity를 사용하는 것이 좋습니다.

프로덕션 환경에서의 실험적 기능

프로덕션 환경에서 실험적 기능을 사용하는 것은 권장되지 않습니다. 실험적 기능은 필요한 경우 호환성이 깨지는 변경 사항이 발생할 수 있으며, 기능이 안전하게 안정적이지 않습니다. 그렇지만, 피드백은 매우 감사하게 생각합니다.

OpenSSF 도구

OpenSSF는 특히 npm 패키지를 게시할 계획인 경우 매우 유용할 수 있는 여러 이니셔티브를 주도하고 있습니다. 이러한 이니셔티브에는 다음이 포함됩니다.

• OpenSSF 스코어카드 스코어카드는 일련의 자동화된 보안 위험 검사를 사용하여 오픈 소스 프로젝트를 평가합니다. 이를 사용하여 코드 기반의 취약성 및 종속성을 사전에 평가하고 취약성 수용에 대해 정보에 입각한 결정을 내릴 수 있습니다.
• OpenSSF 모범 사례 배지 프로그램 프로젝트는 각 모범 사례를 준수하는 방법을 설명하여 자발적으로 자체 인증할 수 있습니다. 이를 통해 프로젝트에 추가할 수 있는 배지가 생성됩니다.