Chúng tôi tấn công! 23+ thực tiễn tốt nhất về bảo mật của Node.js

Chúng tôi tấn công! 23+ thực tiễn tốt nhất về bảo mật của Node.js

Sưu tầm, giám tuyển và viết bởi: Yoni Goldberg, Kyle Martin và Bruno Scheufler

Người đánh giá công nghệ: Liran Tal (Nhóm làm việc bảo mật Node.js)

Chào mừng bạn đến với danh sách toàn diện về các thực tiễn tốt nhất về bảo mật của Node.js, tóm tắt và quản lý các bài viết và bài đăng trên blog được xếp hạng hàng đầu

Vài từ trước khi chúng ta bắt đầu

Các cuộc tấn công web bùng nổ những ngày này khi an ninh đến trước sân khấu. Chúng tôi đã tổng hợp hơn 23 thực tiễn tốt nhất về bảo mật của Node.js (+40 thực tiễn bảo mật chung khác) từ tất cả các bài viết được xếp hạng hàng đầu trên toàn cầu. Công việc ở đây là một phần của kho lưu trữ GitHub thực hành tốt nhất của Node.js chứa hơn 80 thực tiễn Node.js. Lưu ý: Nhiều mục có liên kết đọc thêm đến một chi tiết về chủ đề với ví dụ mã và thông tin hữu ích khác.

Nhận thực hành tốt nhất hàng tuần thông qua nguồn cấp dữ liệu Twitter của chúng tôi

1. Ôm các quy tắc bảo mật kẻ nói dối

TL; DR: Sử dụng các plugin kẻ nói dối liên quan đến bảo mật như eslint-plugin-security để nắm bắt các lỗ hổng bảo mật và các vấn đề càng sớm càng tốt - trong khi chúng được mã hóa. Điều này có thể giúp nắm bắt các điểm yếu bảo mật như sử dụng eval, gọi quy trình con hoặc nhập mô-đun bằng một chuỗi không theo chuỗi (ví dụ: đầu vào của người dùng). Nhấp vào ‘Đọc thêm các phần bên dưới để xem các ví dụ mã sẽ bị bắt bởi một kẻ nói dối bảo mật

Mặt khác: Những gì có thể là một điểm yếu bảo mật đơn giản trong quá trình phát triển trở thành một vấn đề lớn trong sản xuất. Ngoài ra, dự án có thể không tuân theo các thực tiễn bảo mật mã nhất quán, dẫn đến các lỗ hổng được giới thiệu hoặc các bí mật nhạy cảm được đưa vào kho lưu trữ từ xa

Đọc thêm: Quy tắc Linter

Linting doesn chỉ phải là một công cụ để thực thi các quy tắc phạm vi về khoảng trắng, dấu chấm phẩy hoặc câu lệnh eval. ESLint cung cấp một khung mạnh mẽ để loại bỏ một loạt các mẫu nguy hiểm tiềm tàng trong mã của bạn (biểu thức chính quy, xác thực đầu vào, v.v.). Tôi nghĩ rằng nó cung cấp một công cụ mới mạnh mẽ mà các nhà phát triển JavaScript có ý thức bảo mật xem xét. (Adam Baldwin)
Thêm trích dẫn và ví dụ mã ở đây

2. Hạn chế các yêu cầu đồng thời sử dụng phần mềm trung gian

TL; DR: Các cuộc tấn công DOS rất phổ biến và tương đối dễ thực hiện. Thực hiện giới hạn tốc độ bằng cách sử dụng một dịch vụ bên ngoài như bộ cân bằng tải đám mây, tường lửa đám mây, nginx, gói linh hoạt giới hạn tốc độ hoặc (đối với các ứng dụng nhỏ hơn và ít quan trọng hơn), giới hạn tốc độ trung bình (ví dụ: giới hạn tốc độ nhanh)

Mặt khác: Một ứng dụng có thể bị tấn công dẫn đến việc từ chối dịch vụ trong đó người dùng thực nhận dịch vụ xuống cấp hoặc không khả dụng.

Đọc thêm: Thực hiện giới hạn tỷ lệ

3. Trích xuất bí mật từ các tệp cấu hình hoặc sử dụng các gói để mã hóa chúng

TL; DR: Không bao giờ lưu trữ bí mật văn bản thuần túy trong các tệp cấu hình hoặc mã nguồn. Thay vào đó, hãy sử dụng các hệ thống quản lý bí mật như các sản phẩm Vault, Bí mật Kubernetes / Docker hoặc sử dụng các biến môi trường. Kết quả cuối cùng, các bí mật được lưu trữ trong kiểm soát nguồn phải được mã hóa và quản lý (các phím lăn, hết hạn, kiểm toán, v.v.). Sử dụng móc khóa trước / cam kết để tránh vô tình thực hiện các bí mật

Mặt khác: Kiểm soát nguồn, ngay cả đối với các kho riêng, có thể bị nhầm lẫn được công khai, tại thời điểm đó, tất cả các bí mật được phơi bày. Truy cập để kiểm soát nguồn cho một bên ngoài sẽ vô tình cung cấp quyền truy cập vào các hệ thống liên quan (cơ sở dữ liệu, apis, dịch vụ, v.v.).

Đọc thêm: Quản lý bí mật

4. Ngăn chặn lỗ hổng tiêm truy vấn với các thư viện ORM / ODM

TL; DR: Để ngăn chặn việc tiêm SQL / NoQuery và các cuộc tấn công độc hại khác, hãy luôn sử dụng ORM / ODM hoặc thư viện cơ sở dữ liệu để thoát dữ liệu hoặc hỗ trợ các truy vấn được tham số hóa có tên hoặc được lập chỉ mục và chăm sóc xác thực đầu vào của người dùng cho các loại dự kiến. Không bao giờ chỉ sử dụng chuỗi mẫu JavaScript hoặc nối chuỗi để đưa các giá trị vào các truy vấn vì điều này sẽ mở ứng dụng của bạn tới một loạt các lỗ hổng. Tất cả các thư viện truy cập dữ liệu Node.js có uy tín (ví dụ: Sequelize, Knex, mongoose) đã tích hợp bảo vệ chống lại các cuộc tấn công tiêm chích

Mặt khác: Đầu vào của người dùng không được xác thực hoặc không được xác thực có thể dẫn đến việc tiêm toán tử khi làm việc với MongoDB cho NoQuery và không sử dụng hệ thống vệ sinh phù hợp hoặc ORM sẽ dễ dàng cho phép các cuộc tấn công tiêm nhiễm SQL, tạo ra lỗ hổng lớn.

Đọc thêm: Ngăn chặn truy vấn bằng thư viện ORM / ODM

Đánh giá cao nỗ lực? Hãy đánh dấu sao dự án của chúng tôi trên GitHub

5. Tránh các cuộc tấn công DOS bằng cách cài đặt rõ ràng khi quá trình bị sập

TL; DR: Quá trình Node sẽ sập khi không xử lý lỗi. Nhiều thực tiễn tốt nhất thậm chí khuyên bạn nên thoát ngay cả khi đã bắt lỗi và xử lý. Ví dụ, Express sẽ gặp sự cố với bất kỳ lỗi không đồng bộ nào - trừ khi bạn bao bọc các tuyến đường bằng một mệnh đề bắt. Điều này mở ra một điểm tấn công rất ngọt ngào cho những kẻ tấn công nhận ra những gì đầu vào làm cho quá trình sụp đổ và liên tục gửi cùng một yêu cầu. Không có biện pháp khắc phục ngay lập tức cho vấn đề này nhưng một số kỹ thuật có thể giảm bớt nỗi đau: Cảnh báo với mức độ nghiêm trọng bất cứ khi nào một quá trình gặp sự cố do lỗi không được xử lý, xác thực đầu vào và tránh làm hỏng quá trình do đầu vào của người dùng không hợp lệ, bao bọc tất cả các tuyến bằng cách bắt và xem xét không gặp sự cố khi một lỗi xuất phát trong một yêu cầu (trái ngược với những gì xảy ra trên toàn cầu)

Mặt khác: Đây chỉ là một phỏng đoán có giáo dục: được cung cấp nhiều ứng dụng Node.js, nếu chúng ta thử chuyển một thân JSON trống cho tất cả các yêu cầu POST - một số ít ứng dụng sẽ gặp sự cố. Tại thời điểm đó, chúng tôi chỉ có thể lặp lại việc gửi cùng một yêu cầu để gỡ xuống các ứng dụng một cách dễ dàng

6. Điều chỉnh các tiêu đề phản hồi HTTP để tăng cường bảo mật

TL; DR: Ứng dụng của bạn nên sử dụng các tiêu đề an toàn để ngăn chặn kẻ tấn công sử dụng các cuộc tấn công phổ biến như tập lệnh chéo trang (XSS), nhấp chuột và các cuộc tấn công độc hại khác. Đây có thể được cấu hình dễ dàng bằng cách sử dụng các mô-đun như mũ bảo hiểm.

Mặt khác: Kẻ tấn công có thể thực hiện các cuộc tấn công trực tiếp vào người dùng ứng dụng của bạn, dẫn đến các lỗ hổng bảo mật lớn

Đọc thêm: Sử dụng các tiêu đề an toàn trong ứng dụng của bạn

7. Thường xuyên và tự động kiểm tra các phụ thuộc dễ bị tổn thương

TL; DR: Với hệ sinh thái npm, thông thường có nhiều phụ thuộc cho một dự án. Phụ thuộc phải luôn được kiểm tra vì các lỗ hổng mới được tìm thấy. Sử dụng các công cụ như kiểm toán npm, nsp hoặc snyk để theo dõi, giám sát và vá các phụ thuộc dễ bị tổn thương. Tích hợp các công cụ này với thiết lập CI của bạn để bạn có được sự phụ thuộc dễ bị tổn thương trước khi đưa nó vào sản xuất.

Mặt khác: Kẻ tấn công có thể phát hiện khung web của bạn và tấn công tất cả các lỗ hổng đã biết của nó.

Đọc thêm: Bảo mật phụ thuộc

8. Tránh sử dụng thư viện mật mã Node.js để xử lý mật khẩu, hãy sử dụng Bcrypt

TL; DR: Mật khẩu hoặc bí mật (khóa API) nên được lưu trữ bằng cách sử dụng hàm băm + muối an toàn như bcrypt, đó là lựa chọn ưu tiên so với triển khai JavaScript vì lý do hiệu suất và bảo mật.

Mặt khác: Mật khẩu hoặc bí mật được duy trì mà không sử dụng chức năng bảo mật sẽ dễ bị tấn công cưỡng bức và từ điển sẽ dẫn đến việc tiết lộ cuối cùng.

Đọc thêm: Sử dụng Bcrypt

9. Thoát đầu ra HTML, JS và CSS

TL; DR: Dữ liệu không đáng tin cậy được gửi xuống trình duyệt có thể được thực thi thay vì chỉ được hiển thị, điều này thường được gọi là một cuộc tấn công tập lệnh chéo trang (XSS). Giảm thiểu điều này bằng cách sử dụng các thư viện chuyên dụng đánh dấu rõ ràng dữ liệu là nội dung thuần túy sẽ không bao giờ được thực thi (nghĩa là mã hóa, thoát)

Mặt khác: Kẻ tấn công có thể lưu trữ mã JavaScript độc hại trong DB của bạn, sau đó sẽ được gửi cho khách hàng nghèo

Đọc thêm: Thoát đầu ra

10. Xác thực các lược đồ JSON đến

TL; DR: Xác thực tải trọng cơ thể của các yêu cầu đến và đảm bảo nó đáp ứng các yêu cầu, thất bại nhanh nếu không thực hiện. Để tránh mã hóa xác thực tẻ nhạt trong mỗi tuyến, bạn có thể sử dụng các lược đồ xác thực dựa trên JSON nhẹ như jsonschema hoặc joi

Mặt khác: Cách tiếp cận rộng lượng và dễ dãi của bạn làm tăng đáng kể bề mặt tấn công và khuyến khích kẻ tấn công thử nhiều đầu vào cho đến khi chúng tìm thấy sự kết hợp nào đó để đánh sập ứng dụng

Đọc thêm: Xác thực các lược đồ JSON đến

11. Hỗ trợ danh sách đen mã thông báo JWT

TL; DR: Khi sử dụng mã thông báo JWT (ví dụ: với Passport.js), theo mặc định, không có cơ chế nào để thu hồi quyền truy cập từ các mã thông báo được cấp. Khi bạn phát hiện ra một số hoạt động độc hại của người dùng, ở đó, không có cách nào ngăn họ truy cập hệ thống miễn là họ giữ mã thông báo hợp lệ. Giảm thiểu điều này bằng cách triển khai danh sách đen các mã thông báo không đáng tin cậy được xác thực theo từng yêu cầu.

Mặt khác: Mã thông báo đã hết hạn hoặc bị đặt sai vị trí có thể được sử dụng độc hại bởi bên thứ ba để truy cập ứng dụng và mạo danh chủ sở hữu mã thông báo.

Đọc thêm: Danh sách đen JWTs

12. Ngăn chặn các cuộc tấn công vũ phu chống lại ủy quyền

TL; DR: Một kỹ thuật đơn giản và mạnh mẽ là hạn chế các nỗ lực ủy quyền bằng hai số liệu:

  1. Đầu tiên là số lần thử thất bại liên tiếp bởi cùng một địa chỉ ID / tên và địa chỉ IP duy nhất của người dùng.
  2. Thứ hai là số lần thử thất bại từ một địa chỉ IP trong một khoảng thời gian dài. Ví dụ: chặn một địa chỉ IP nếu nó thực hiện 100 lần thất bại trong một ngày.

Mặt khác: Kẻ tấn công có thể đưa ra các nỗ lực mật khẩu tự động không giới hạn để có quyền truy cập vào các tài khoản đặc quyền trên một ứng dụng

Đọc thêm: Giới hạn tỷ lệ đăng nhập

13. Chạy Node.js với tư cách là người dùng không root

TL; DR: Có một kịch bản phổ biến trong đó Node.js chạy như một người dùng root với quyền không giới hạn. Ví dụ, đây là hành vi mặc định trong các container Docker. Nó khuyên bạn nên tạo một người dùng không phải root và nướng nó vào hình ảnh Docker (ví dụ được đưa ra dưới đây) hoặc chạy quy trình trên người dùng này Thay mặt bằng cách gọi container với tên người dùng cờ -u

Mặt khác: Kẻ tấn công quản lý để chạy tập lệnh trên máy chủ sẽ nhận được sức mạnh vô hạn đối với máy cục bộ (ví dụ: thay đổi lưu lượng truy cập iptable và định tuyến lại máy chủ của mình)

Đọc thêm: Chạy Node.js với tư cách là người dùng không root

14. Giới hạn kích thước tải trọng bằng cách sử dụng proxy ngược hoặc phần mềm trung gian

TL; DR: Tải trọng cơ thể càng lớn thì luồng xử lý đơn của bạn càng khó xử lý. Đây là cơ hội cho những kẻ tấn công đưa máy chủ đến đầu gối của họ mà không cần số lượng yêu cầu rất lớn (các cuộc tấn công DOS / DDOS). Giảm thiểu điều này giới hạn kích thước cơ thể của các yêu cầu đến trên cạnh (ví dụ: tường lửa, ELB) hoặc bằng cách định cấu hình trình phân tích cú pháp cơ thể nhanh để chỉ chấp nhận tải trọng kích thước nhỏ

Mặt khác: Ứng dụng của bạn sẽ phải xử lý các yêu cầu lớn, không thể xử lý công việc quan trọng khác mà nó phải hoàn thành, dẫn đến hệ lụy hiệu năng và lỗ hổng đối với các cuộc tấn công của DOS

Đọc thêm: Giới hạn kích thước tải trọng

Nhận thực hành tốt nhất hàng tuần thông qua nguồn cấp dữ liệu Twitter của chúng tôi

15. Tránh các tuyên bố eval JavaScript

TL; DR: eval là xấu vì nó cho phép thực thi mã JavaScript tùy chỉnh trong thời gian chạy. Đây không chỉ là mối quan tâm về hiệu suất mà còn là mối quan tâm bảo mật quan trọng do mã JavaScript độc hại có thể có nguồn gốc từ đầu vào của người dùng. Một tính năng ngôn ngữ khác nên tránh là hàm tạo mới. setTimeout và setInterval cũng không bao giờ được chuyển qua mã JavaScript động.

Mặt khác: Mã JavaScript độc hại tìm đường vào văn bản được truyền vào eval hoặc các chức năng ngôn ngữ JavaScript đánh giá thời gian thực khác và sẽ có quyền truy cập đầy đủ vào các quyền JavaScript trên trang. Lỗ hổng này thường được biểu hiện dưới dạng một cuộc tấn công XSS.

Đọc thêm: Tránh các tuyên bố eval JavaScript

16. Ngăn chặn RegEx độc ác làm quá tải thực thi luồng đơn của bạn

TL; DR: Biểu thức chính quy, trong khi tiện dụng, gây ra mối đe dọa thực sự cho các ứng dụng JavaScript nói chung và nền tảng Node.js nói riêng. Một đầu vào của người dùng cho văn bản phù hợp có thể yêu cầu số lượng chu kỳ CPU vượt trội để xử lý. Xử lý RegEx có thể không hiệu quả đến mức một yêu cầu xác thực 10 từ có thể chặn toàn bộ vòng lặp sự kiện trong 6 giây và đặt CPU lên . Vì lý do đó, hãy ưu tiên các gói xác thực của bên thứ ba như validator.js thay vì viết các mẫu Regex của riêng bạn hoặc sử dụng regex an toàn để phát hiện các mẫu regex dễ bị tổn thương

Mặt khác: Các biểu thức chính được viết kém có thể dễ bị tấn công DoS biểu thức chính quy sẽ chặn hoàn toàn vòng lặp sự kiện. Ví dụ: gói khoảnh khắc phổ biến được tìm thấy dễ bị tổn thương với việc sử dụng RegEx độc hại vào tháng 11 năm 2017

Đọc thêm: Ngăn chặn RegEx độc hại

17. Tránh tải mô-đun bằng một biến

TL; DR: Tránh yêu cầu / nhập tệp khác với đường dẫn được cung cấp dưới dạng tham số do lo ngại rằng tệp có thể có nguồn gốc từ đầu vào của người dùng. Quy tắc này có thể được mở rộng để truy cập các tệp nói chung (ví dụ: fs.readFile ()) hoặc truy cập tài nguyên nhạy cảm khác với các biến động có nguồn gốc từ đầu vào của người dùng. Kẻ nói dối Eslint-plugin-bảo mật có thể bắt được các mẫu như vậy và cảnh báo sớm

Mặt khác: Đầu vào người dùng độc hại có thể tìm đường đến một tham số được sử dụng để yêu cầu các tệp bị giả mạo, ví dụ: tệp đã tải lên trước đó trên hệ thống tệp hoặc truy cập các tệp hệ thống hiện có.

Đọc thêm: Tải mô-đun an toàn

18. Chạy mã không an toàn trong hộp cát

TL; DR: Khi được giao nhiệm vụ chạy mã bên ngoài được cung cấp tại thời gian chạy (ví dụ: plugin), hãy sử dụng bất kỳ loại môi trường thực thi ‘sandbox nào để cách ly và bảo vệ mã chính chống lại plugin. Điều này có thể đạt được bằng cách sử dụng một quy trình chuyên dụng (ví dụ: cluster.fork ()), môi trường không có máy chủ hoặc các gói npm chuyên dụng hoạt động như một hộp cát

Mặt khác: Một plugin có thể tấn công thông qua vô số tùy chọn như vòng lặp vô hạn, quá tải bộ nhớ và truy cập vào các biến môi trường quá trình nhạy cảm

Đọc thêm: Chạy mã không an toàn trong hộp cát

19. Cẩn thận hơn khi làm việc với các quy trình con

TL; DR: Tránh sử dụng các quy trình con khi có thể và xác nhận và vệ sinh đầu vào để giảm thiểu các cuộc tấn công tiêm vỏ nếu bạn vẫn phải thực hiện. Thích sử dụng child_ process.execFile, theo định nghĩa sẽ chỉ thực thi một lệnh duy nhất với một tập các thuộc tính và sẽ không cho phép mở rộng tham số shell.

Mặt khác: Việc sử dụng các quy trình con ngây thơ có thể dẫn đến thực thi lệnh từ xa hoặc các cuộc tấn công tiêm vỏ do đầu vào của người dùng độc hại được chuyển đến một lệnh hệ thống không được xác nhận.

Đọc thêm: Hãy thận trọng khi làm việc với các quy trình con

20. Ẩn chi tiết lỗi từ khách hàng

TL; DR: Trình xử lý lỗi thể hiện tích hợp ẩn các chi tiết lỗi theo mặc định. Tuy nhiên, rất có thể là cơ hội để bạn triển khai logic xử lý lỗi của riêng mình với các đối tượng Lỗi tùy chỉnh (được nhiều người coi là cách thực hành tốt nhất). Nếu bạn làm như vậy, đảm bảo không trả lại toàn bộ đối tượng Lỗi cho máy khách, có thể chứa một số chi tiết ứng dụng nhạy cảm

Mặt khác: Các chi tiết ứng dụng nhạy cảm như đường dẫn tệp máy chủ, mô-đun bên thứ ba đang sử dụng và các luồng công việc nội bộ khác của ứng dụng có thể bị kẻ tấn công khai thác, có thể bị rò rỉ từ thông tin tìm thấy trong dấu vết ngăn xếp

Đọc thêm: Ẩn chi tiết lỗi từ khách hàng

21. Cấu hình 2FA cho npm hoặc Sợi

TL; DR: Bất kỳ bước nào trong chuỗi phát triển nên được bảo vệ bằng MFA (xác thực đa yếu tố), npm / Sợi là cơ hội tuyệt vời cho những kẻ tấn công có thể có được mật khẩu của nhà phát triển. Sử dụng thông tin xác thực của nhà phát triển, kẻ tấn công có thể tiêm mã độc vào các thư viện được cài đặt rộng rãi trên các dự án và dịch vụ. Thậm chí có thể trên web nếu xuất bản ở nơi công cộng. Việc kích hoạt xác thực 2 yếu tố trong npm sẽ không có cơ hội cho kẻ tấn công thay đổi mã gói của bạn.

Mặt khác: Bạn đã nghe nói về nhà phát triển eslint, người đã mật khẩu bị tấn công?

22. Sửa đổi cài đặt phần mềm trung gian phiên

TL; DR: Mỗi khung web và công nghệ có những điểm yếu đã biết - nói với kẻ tấn công rằng khung web nào chúng tôi sử dụng là một trợ giúp tuyệt vời cho chúng. Sử dụng cài đặt mặc định cho phần mềm trung gian phiên có thể khiến ứng dụng của bạn bị tấn công chiếm quyền theo mô-đun và khung cụ thể theo cách tương tự như tiêu đề X-Powered-By. Hãy thử ẩn bất cứ thứ gì xác định và tiết lộ ngăn xếp công nghệ của bạn (Ví dụ: Node.js, express)

Mặt khác: Cookies có thể được gửi qua các kết nối không an toàn và kẻ tấn công có thể sử dụng nhận dạng phiên để xác định khung cơ bản của ứng dụng web, cũng như các lỗ hổng dành riêng cho mô-đun

Đọc thêm: Bảo mật cookie và phiên

23. Tránh các cuộc tấn công DOS bằng cách cài đặt rõ ràng khi một quy trình bị sập

TL; DR: Quá trình Node sẽ sập khi không xử lý lỗi. Nhiều thực tiễn tốt nhất thậm chí khuyên bạn nên thoát ngay cả khi đã bắt lỗi và xử lý. Ví dụ, Express sẽ gặp sự cố với bất kỳ lỗi không đồng bộ nào - trừ khi bạn bao bọc các tuyến đường bằng một mệnh đề bắt. Điều này mở ra một điểm tấn công rất ngọt ngào cho những kẻ tấn công nhận ra những gì đầu vào làm cho quá trình sụp đổ và liên tục gửi cùng một yêu cầu. Không có biện pháp khắc phục ngay lập tức cho vấn đề này nhưng một số kỹ thuật có thể giảm bớt nỗi đau: Cảnh báo với mức độ nghiêm trọng bất cứ khi nào một quá trình gặp sự cố do lỗi không được xử lý, xác thực đầu vào và tránh làm hỏng quá trình do đầu vào của người dùng không hợp lệ, bao bọc tất cả các tuyến bằng cách bắt và xem xét không gặp sự cố khi một lỗi xuất phát trong một yêu cầu (trái ngược với những gì xảy ra trên toàn cầu)

Mặt khác: Đây chỉ là một phỏng đoán có giáo dục: được cung cấp nhiều ứng dụng Node.js, nếu chúng ta thử chuyển một thân JSON trống cho tất cả các yêu cầu POST - một số ít ứng dụng sẽ gặp sự cố. Tại thời điểm đó, chúng tôi chỉ có thể lặp lại việc gửi cùng một yêu cầu để gỡ xuống các ứng dụng một cách dễ dàng.

24. Ngăn chặn chuyển hướng không an toàn

TL; DR: Chuyển hướng không xác thực đầu vào của người dùng có thể cho phép kẻ tấn công khởi chạy các hành vi lừa đảo, đánh cắp thông tin đăng nhập của người dùng và thực hiện các hành động độc hại khác.

Mặt khác: Nếu kẻ tấn công phát hiện ra rằng bạn không xác thực đầu vào bên ngoài, do người dùng cung cấp, họ có thể khai thác lỗ hổng này bằng cách đăng các liên kết được chế tạo đặc biệt trên các diễn đàn, phương tiện truyền thông xã hội và các địa điểm công cộng khác để khiến người dùng nhấp vào nó.

Đọc thêm: Ngăn chặn chuyển hướng không an toàn

25. Tránh xuất bản bí mật lên sổ đăng ký npm

TL; DR: Cần thận trọng để tránh nguy cơ vô tình xuất bản bí mật cho các cơ quan đăng ký npm công khai. Một tập tin .npmignore có thể được sử dụng để liệt kê các tập tin hoặc thư mục cụ thể hoặc mảng tập tin trong pack.json có thể hoạt động như một danh sách trắng.

Mặt khác: Các khóa API, mật khẩu hoặc các bí mật khác trong dự án của bạn bị mở để lạm dụng bởi bất kỳ ai đi qua chúng, điều này có thể dẫn đến tổn thất tài chính, mạo danh và các rủi ro khác.

Đọc thêm: Tránh xuất bản bí mật

Đánh giá cao nỗ lực? Hãy đánh dấu sao dự án của chúng tôi trên GitHub

26. Danh sách 40 lời khuyên bảo mật chung (không liên quan cụ thể đến Node.js)

Những viên đạn sau đây là những biện pháp bảo mật nổi tiếng và quan trọng cần được áp dụng trong mọi ứng dụng. Vì chúng không nhất thiết liên quan đến Node.js và được triển khai tương tự bất kể khung ứng dụng - chúng tôi đưa chúng vào đây như một phụ lục. Các mục được nhóm theo phân loại OWASP của họ. Một mẫu bao gồm các điểm sau:

  • Yêu cầu MFA / 2FA cho tài khoản root
  • Xoay mật khẩu và khóa truy cập thường xuyên, bao gồm cả khóa SSH
  • Áp dụng các chính sách mật khẩu mạnh, cho cả ops và quản lý người dùng trong ứng dụng, xem khuyến nghị mật khẩu OWASP
  • Không giao hàng hoặc triển khai với bất kỳ thông tin mặc định nào, đặc biệt đối với người dùng quản trị viên
  • Chỉ sử dụng các phương thức xác thực tiêu chuẩn như OAuth, OpenID, v.v. - tránh xác thực cơ bản
  • Giới hạn tỷ lệ xác thực: Không cho phép nhiều hơn các lần đăng nhập X (bao gồm khôi phục mật khẩu, v.v.) trong khoảng thời gian Y phút
  • Khi đăng nhập thất bại, donith cho người dùng biết liệu xác minh tên người dùng hoặc mật khẩu không thành công, chỉ cần trả về một lỗi xác thực phổ biến
  • Cân nhắc sử dụng hệ thống quản lý người dùng tập trung để tránh quản lý nhiều tài khoản cho mỗi nhân viên (ví dụ: GitHub, AWS, Jenkins, v.v.) và để hưởng lợi từ hệ thống quản lý người dùng được thử nghiệm trong trận chiến

Danh sách đầy đủ 40 lời khuyên bảo mật chung có thể được tìm thấy trong kho thực hành tốt nhất chính thức của Node.js!

Đọc thêm: 40 Lời khuyên bảo mật chung

Đọc tốt khác:

  • Thực hành tốt nhất về sản xuất Node.js - Yoni Goldberg
  • Tổng quan về bảo mật của Node.js - Gergely Nemeth
  • Thực hành tốt nhất về bảo mật - Express chính thức
  • YouTube: Lộ trình bảo mật của Node.js - Mike Samuel

Tác giả - về chúng tôi

  • Yoni Goldberg - Chuyên gia tư vấn của Node.js, phục vụ khách hàng tại Mỹ, Châu Âu và Israel
  • Kyle Martin - Nhà phát triển Full Stack có trụ sở tại New Zealand
  • Bruno Scheufler - Nhà phát triển web đầy đủ và đam mê Node.js
Đánh giá cao nỗ lực? Vỗ tay ở phía dưới (tối đa 50 lần) có thể làm cho ngày của chúng ta