Node.js

Security Best Practices 문서가 있어 읽어보았다. 신기한 내용만 추려보자면, Information Exposure through Timing Attacks (CWE-208) 값을 단순 비교(a === b)할 때, 문자열을 앞에서부터 한글자씩 비교하게 되면서 발생하는 시간차를 이용한다는 것 같다. 대체 뭘까 궁금해서 ChatGPT에게 설명을 요청해 받아낸 내용- - 서버가 클라이언트가 보낸 비밀(비밀번호, 토큰 등) 을 처리할 때 처리 시간이 입력값에 따라 달라지면 공격자가 여러 요청을 보내 응답시간을 통계적으로 비교하여 내부 비밀의 일부 정보를 유추할 수 있습니다. - 예: 문자열 단순 비교 (===)는 앞부분부터 비교를 하고 첫 불일치에서 바로 반환되므로 접두사가 맞을수록(비교가 길게 지속될수록) 응답 시간이 길어지는 경향이 있습니다. 공격자는 한 글자씩 맞춰가며(브루트포스/차례대로) 시간이 더 긴 입력을 고르면 정답에 가까운 문자임을 추측할 수 있습니다. - 특히 동일한 서버(혹은 같은 호스트)에서 타이밍 잡기가 쉬운 환경(공유 호스트, 로컬 네트워크, VM co-resident 등)에서는 성공 확률이 높습니다. - 또 한 가지 실수: 사용자가 없을 때와 있을 때 처리 시간을 달리하면(예: DB 조회 후 곧바로 실패 반환 vs 존재하면 해시 비교) 사용자 존재 여부 자체를 노출시킬 수 있습니다. 이를 이용한 정보 수집도 위험합니다. GPT가 제시해준 해결책 - 길이가 고정된(또는 비교 전에 고정 길이로 변환한) 바이너리 값들을 비교하고, crypto.timingSafeEqual을 사용해 비교한다. - 비밀번호는 평문이 아니라 KDF(scrypt, bcrypt, argon2 등) 로 처리한 고정 길이 해시(또는 키)를 저장하고 비교한다. - 사용자 존재 여부에 따라 처리 시간을 달리하지 않도록 — 사용자가 없을 때도 동일한 KDF 연산(더미 값)이나 timing-safe 비교를 수행해 시간 차를 줄인다. - 비교 전에 반드시 두 버퍼 길이가 같은지 확인(다르면 길이를 맞추거나 실패 처리) — timingSafeEqual은 길이가 다르면 예외가 날 수 있음. - 브랜칭(조건문)으로 비밀값을 분기하지 않도록 주의. Prototype Pollution Attacks (CWE-1321) javascript 내장 객체의 prototype 내용물을 바꿔치는 과정에 문제가 될 수 있었나보다. lodash에만 해도 CVE에 관련 취약점이 이미 몇 건 씩이나 보고되어 있다. 당연히 바뀔수있는 값 아닌가? 생각했는데, GPT가 아래와같은 사례일수 있다고 알려주었다. 공격자가 {"__proto__": {"isAdmin": true}}를 보내면 결과적으로 Object.prototype.isAdmin === true가 되고, 애플리케이션이 if (user.isAdmin) 같은 체크를 하면 공격자가 권한을 획득할 수 있습니다.

node.js의 —max-old-space-size 기본 값 확인 $ node > v8.getHeapStatistics() { total_heap_size: 6578176, total_heap_size_executable: 262144, total_physical_size: 6815744, total_available_size: 2193448312, used_heap_size: 5277544, heap_size_limit: 2197815296, malloced_memory: 163968, peak_malloced_memory: 172528, does_zap_garbage: 0, number_of_native_contexts: 2, number_of_detached_contexts: 0, total_global_handles_size: 8192, used_global_handles_size: 3040, external_memory: 2269138 } 기본값이 2GB인 것으로 확인함. 참고: https://stackoverflow.com/questions/48387040/how-do-i-determine-the-correct-max-old-space-size-for-node-js 수정 node.js 공식문서의 추천에 따르면, 서버 메모리 2GB 당 1536MB로 설정하라고 한다. pm2의 ecosystem 파일에 옵션을 추가하기위해, 파일을 아래와 같이 변경. { ... node_args: '--max-old-space-size=1536', ... }

환경변수 수정 후, 수정된 변수로 pm2를 다시 띄움 ** 주의할 점 ecosystem.config.js 내부에 설정값 (예를들면, "error_file" 값)을 수정한 후, 위 방법으로 재시작만 한다면 변경된 설정값이 적용되지 않는다. (모든 설정이 그런지, 로그 관련만 그런지는 모르겠다) 변경된 설정을 적용하려면, 기존 인스턴스를 정지&삭제 후 재시작해야 적용되었다. $ pm2 stop {{name}} $ pm2 delete {{name}} $ pm2 start ecosystem.config.js —only {{phase}} 적용된 환경변수 목록 조회 restart 카운트 초기화 pm2 프로세스를 죽였다 살리기(app 상태 유지)

Opensearch에 bulk요청을 할 때, timeout이 발생한다. 왜인지 알수 없어 주위에 물어보니, 보통 커넥터에 요청 데이터의 크기 제한이 있고(ES 클라이언트에선 http.max_content_length 옵션으로 설정하나보다), 그것보다 큰 데이터 요청을 보내면 타임아웃이 날 때가 있다고 한다. opensearch는 어떻게 되는지 찾아보니, 인스턴스 타입별 미리 정해진 네트워크 용량 제한이 있다고 한다. 지독한놈들.. es index작업이나 bulk에서 이유모를 timeout이 발생한다면, 사용중인 instance의 타입과 타입별 용량제한을 확인해보자.