한) expressjs.com/ko/advanced/best-practice-security.html
영) expressjs.com/en/advanced/best-practice-security.html
Don’t use deprecated or vulnerable versions of Express
express 2, 3 버전은 관리가 되지 않으니 사용하지 말고 최소 4 이상 버전을 사요하기를 권장하고 있습니다.
Use TLS (better than SSL)
앱이 민감한 데이터를 다루거나 전송하는 경우에는 전송 계층 보안(TLS)을 사용하여 연결 및 데이터를 보호해야 한다. TLS는 데이터를 클라이언트로부터 서버로 전송하기 전에 데이터를 암호화하여 몇가지 해킹을 방지한다.
당연히 client 단에서 server 쪽으로 axios든 fetch든 사용해서 정보를 넘기는 와중 패킷 가로채기 및 중간자 공격을 당할 수 있다. 이를 방지하기 위한 수단으로 TLS를 사용하는 것이 좋다. SSL 인증서를 통해 암호화를 종종 사용해보았는데 TLS는 SSL보다 더 업그레이드 된 버전이라고 한다.
TLS is a standard closely related to SSL 3.0, and is sometimes referred to as "SSL 3.1". TLS supersedes SSL 2.0 and should be used in new development. Beginning with Windows 10, version 1607 and Windows Server 2016, SSL 2.0 has been removed and is no longer supported.
(msdn.microsoft.com/en-us/library/windows/desktop/aa380515(v=vs.85).aspx)
Express 문서에서는 TLS를 위해 Nginx 사용을 권장하고 있다. Nginx 및 다른 서버에서 TLS를 구성하는 방법에 대해서는 여기를 참고해보자. (wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
참고로 cineps에서는 이미 TLS를 사용하고 있다.
Helmet 사용
Helmet은 Express.js 사용시 Http 헤더 설정을 자동으로 바꾸어주어 잘 알려진 몇가지 앱의 취약성으로 부터 앱을 보호 할 수 있는 패키지입니다.
- csp는 Content-Security-Policy 헤더를 설정하여 XSS(Cross-site scripting) 공격 및 기타 교차 사이트 인젝션을 예방합니다.
- hidePoweredBy는 X-Powered-By 헤더를 제거합니다.
- hsts는 서버에 대한 안전한(SSL/TLS를 통한 HTTP) 연결을 적용하는 Strict-Transport-Security 헤더를 설정합니다.
- ieNoOpen은 IE8 이상에 대해 X-Download-Options를 설정합니다.
- noCache는 Cache-Control 및 Pragma 헤더를 설정하여 클라이언트 측에서 캐싱을 사용하지 않도록 합니다.
- noSniff는 X-Content-Type-Options 를 설정하여, 선언된 콘텐츠 유형으로부터 벗어난 응답에 대한 브라우저의 MIME 가로채기를 방지합니다.
- frameguard는 X-Frame-Options 헤더를 설정하여 clickjacking에 대한 보호를 제공합니다.
- xssFilter는 X-XSS-Protection을 설정하여 대부분의 최신 웹 브라우저에서 XSS(Cross-site scripting) 필터를 사용하도록 합니다.
만약 helmet을 사용하지 않더라도 최소한 x-powerd-by를 사용하지 않기를 권장합니다.
app.disable('x-powered-by')
request 객체의 header 부분을 살펴보면 x-powered-by를 통해서 Express로 백엔드가 구성되어 있는 것을 확인할 수 있고, 이는 해커가 Express의 취약점만 알아내면 코더의 서비스를 공격할 수 있는 힌트를 주게 되는 것입니다.
headers: {
'x-powered-by': 'Express',
'access-control-allow-origin': '*',
'content-type': 'application/json; charset=utf-8',
'content-length': '1321',
쿠키를 안전하게 사용하기
이 부분은 방대하기 때문에 공식문서를 첨부하는 것으로 갈음하겠습니다.
expressjs.com/en/advanced/best-practice-security.html
brutal force 공격 방지하기
엔드포인트가 보호되지 않고 부차별적으로 대입됨으로서 문제를 발생시킬 수 있다. 특히 로그인 엔드포인트에서 그러하다.
express 문서는 다음과 같은 기준을 만족할 때 인증 시도를 차단하라고 알려주고 있다.
- 첫 번째는 동일한 사용자 이름 및 IP 주소에 의한 연속 실패 횟수가 많아질 때. (어떤 유저 정보가 탈취당해 다수의 해커가 해당 유저로 로그인하기 위해 brutal force를 쓰는 예)
- 두 번째는 오랜 기간 동안 IP 주소에서 실패한 시도 횟수입니다. 예를 들어, 하루에 100 번 실패하면 IP 주소를 차단합니다. (전문 해커가 유저 정보 탈취를 위해 brutal force를 하는 예)
rate-limiter-flexible 패키지는이 기술을 쉽고 빠르게 만드는 도구를 제공합니다. 문서에서 무차별 대입 보호의 예를 찾을 수 있습니다.
종속성 안전 확인
매번 패키지 설치할 때마다 어디가 위험하고, audit로 강화하라는 경고문구가 뜨는 것을 확인할 수 있다. 해주면 된다.
npm run audit
그 외에 유명한 웹 취약성 대비하기
이 부분은 필자가 Web Hack을 공부하면서 점차 적용해나가야 할 부분이다.
아래 포스트에 정리한대로 공부해나갈 예정이다.
'Node, Nest, Deno > 🚀 Node.js (+ Express)' 카테고리의 다른 글
node.js 서비스 로그 관리 : pm2 log management (0) | 2021.01.11 |
---|---|
nginx(reverse-proxy), node에서 이미지 업로드 중 request entity too large 에러 (0) | 2020.12.08 |
동기 I/O 와 비동기 I/O 의 성능 차이 + Node.js를 쓸 이유가 없다? (0) | 2020.11.22 |
Row level Node : js의 동작 방식부터 libuv와 event loop까지 (2) | 2020.11.18 |
중앙 집중식 API 에러 핸들링 (탑레벨 fetching handler를 만들어라) (0) | 2020.09.17 |