Bảo mật smart contract: Checklist đơn giản trong phát triển web3
Nhiều vụ tấn công xảy ra với các dự án web3 sẽ có thể ngăn chặn được bằng việc tập trung hơn vào bảo mật smart contract.
Thông thường, những kẻ tấn công tìm thấy và khai thác nhiều điểm thiếu sót trong chuỗi cung ứng phát triển phần mềm (software development supply chain) - một loạt các bước để phát hành phần mềm ra thế giới, từ thiết kế đến triển khai và bảo trì. Nếu các giao thức phù hợp và các phương pháp tốt nhất được được xác định từ trước, chúng tôi tin rằng sẽ có ít sự cố bảo mật hơn xảy ra.
Mục đích của bài này là phác thảo các nguyên tắc cơ bản về bảo mật mà các nhà xây dựng, nhà phát triển và nhóm bảo mật web3 phải xem xét khi thiết kế, phát triển và duy trì một hệ thống smart contract an toàn. Nội dung được trình bày dưới đây thảo luận về tám loại bảo mật cốt lõi cần cân nhắc- từ mô hình hóa mối đe dọa đến chuẩn bị ứng phó khẩn cấp - cần được thực hiện trong suốt vòng đời phát triển phần mềm.
Trước khi bắt đầu xem xét về bảo mật smart contract, điều quan trọng là phải hiểu các giai đoạn phát triển của một chuỗi cung ứng phần mềm an toàn, có thể được mô tả trong năm giai đoạn sau:
A) Thiết kế: Nhà phát triển mô tả các tính năng và hoạt động mong muốn của hệ thống, bao gồm các chuẩn mực quan trọng và các thuộc tính bất biến .
B) Phát triển: Nhà phát triển viết code hệ thống.
C) Kiểm tra & Đánh giá: Nhà phát triển tập hợp tất cả các modules lại với nhau trong một môi trường kiểm tra và đánh giá chúng về tính đúng đắn, quy mô và các yếu tố khác.
D) Triển khai: Nhà phát triển đưa hệ thống vào hoạt động chính thức.
E) Duy trì: Nhà phát triển đánh giá và sửa đổi hệ thống để đảm bảo rằng nó đang thực hiện các chức năng đã định.
Với nền tảng vòng đời cơ bản này, bây giờ chúng ta hãy đi sâu vào các cân nhắc về bảo mật smart contract ảnh hưởng đến từng bước. Hình dưới đây ánh xạ những điểm cần cân nhắc đối với các giai đoạn phát triển liên quan của chúng. Lưu ý một số bước trong chuỗi cung ứng có nhiều cân nhắc về bảo mật:
Nhưng vòng đời phát triển phần mềm, được trình bày một cách tuyến tính ở trên, không nhất thiết phải luôn đi theo một con đường tuyến tính: Các danh mục có thể chồng chéo hoặc mở rộng sang các giai đoạn bổ sung trong thực tế. Các bước có thể được lặp lại cho mỗi lần phát hành. Và một số tác vụ - chẳng hạn như kiểm tra và đánh giá bảo mật - có thể cần được thực hiện xuyên suốt.
Mặc dù các bước trong vòng đời phần mềm và các cân nhắc bảo mật tương ứng được mô tả ở trên cung cấp cơ sở hữu ích để thúc đẩy bảo mật smart contract, chúng tôi sẽ xem xét chúng chi tiết hơn bên dưới. Các câu hỏi chính giúp cho việc hiểu, áp dụng và chia sẻ các phương pháp tốt nhất này trở nên đơn giản và cụ thể nhất có thể là what, why và how.
(A) Giai đoạn thiết kế
# 1: Xem xét mô hình các mối đe dọa và thiết kế bảo mật
What: Điều quan trọng là phải thực hiện một phương pháp rõ ràng về xác định và độ ưu tiên của các mối đe dọa tiềm ẩn đối với hệ thống ngay từ đầu của vòng đời phát triển - các nhà phát triển smart contract nên xác định bất kỳ biện pháp kiểm soát bảo mật nào cần thực hiện trong quá trình phát triển cũng như bất kỳ mối đe dọa nào cần được kiểm tra thử nghiệm, đánh giá và giám sát. Tất cả các giả định về bảo mật, bao gồm cả mức độ tinh vi dự kiến của kẻ tấn công và các phương tiện kinh tế, cần được xác định và trình bày rõ ràng trong giai đoạn thiết kế.
Why: Mặc dù rất có thể các nhà phát triển chỉ tập trung vào các mục đích sử dụng của smart contract hoặc giao thức, nhưng sự tập trung duy nhất này có thể khiến họ bỏ qua những điểm mù mà những kẻ tấn công có thể và sẽ khai thác.
How: Thực hiện theo các phương pháp lập mô hình các mối đe dọa đã biết. Nếu một nhóm phát triển không có chuyên gia về bảo mật (in-house security expertise), thì nhóm đó nên thuê các nhà tư vấn bảo mật sớm trong giai đoạn thiết kế. Áp dụng tư duy “kẻ tấn công” khi thiết kế hệ thống và cho rằng bất kỳ cá nhân, máy móc hoặc dịch vụ nào cũng có thể bị xâm phạm một cách hợp lý.
(B) Giai đoạn phát triển
# 2: Cân nhắc quản trị và kiểm soát truy cập
What: Triển khai việc kiểm soát truy cập sẽ hạn chế khả năng gọi các chức năng đặc biệt thực hiện các tác vụ quản trị - chẳng hạn như nâng cấp hợp đồng và cài đặt các thông số đặc biệt - cho các tài khoản đặc quyền và smart contract. Tuân theo “nguyên tắc ít đặc quyền nhất”: mỗi tác nhân chỉ nên có số lượng quyền truy cập tối thiểu được yêu cầu.
Why: Việc duy trì các giao thức thông qua các quy trình nâng cấp và quản trị cho phép các nhà phát triển cải thiện giao thức bằng cách thêm các tính năng mới, vá các vấn đề bảo mật và giải quyết các điều kiện thay đổi. Nếu khả năng thực hiện nâng cấp không được kiểm soát thích hợp, điều này có thể tạo thành một lỗ hổng bảo mật nghiêm trọng.
How: Thiết lập ví đa chữ ký (multisig) hoặc DAO contract sẽ thay mặt cộng đồng quản lý các thay đổi một cách minh bạch. Các thay đổi phải trải qua một quá trình xem xét kỹ lưỡng, cùng với mốc thời gian - việc ban hành cố ý bị trì hoãn với khả năng bị hủy bỏ - để đảm bảo rằng chúng có thể được xác minh về tính đúng đắn và được khôi phục trong trường hợp có một cuộc tấn công quản trị (governance attack) . Đảm bảo rằng các khóa đặc quyền (privileged keys) được lưu trữ và truy cập an toàn trong ví tự giám sát hoặc dịch vụ giám sát an toàn.
# 3: Xem xét các mẫu và tích hợp (templates and integrations) có thể sử dụng lại, hiệu quả đáng tin cậy
What: Bất cứ khi nào có thể, hãy sử dụng các tiêu chuẩn smart contract hiện có (ví dụ: OpenZeppelin Contract ) và đánh giá các giả định bảo mật của việc tích hợp giao thức mà bạn có thể cần thực hiện với các giao thức hiện có.
Why: Việc sử dụng các tiêu chuẩn và triển khai đã được thực nghiệm có hiệu quả, được cộng đồng kiểm tra, đánh giá sẽ là một bước tiến dài trong việc giảm thiểu rủi ro bảo mật. Đánh giá rủi ro của việc tích hợp giao thức giúp bạn phát triển các hạng mục kiểm tra bảo mật để bảo vệ khỏi các cuộc tấn công vào các thành phần bên ngoài như thao túng oracle (oracle manipulation).
How: Nhập các thư viện và giao diện hợp đồng đáng tin cậy đã được kiểm tra tính bảo mật; toàn bộ các khía cạnh của tiền mã hoá và web3 là sử dụng mã nguồn mở, tái sử dụng và khả năng tổng hợp! Đảm bảo tài liệu hoá các phụ thuộc hợp đồng của bạn và các phiên bản của chúng trong codebase và giảm thiểu code footprint của bạn ở những nơi có thể; ví dụ: nhập các submodules cụ thể của các dự án lớn thay vì tất cả mọi thứ. Hiểu rõ về sự phơi nhiễm để bạn có thể theo dõi các cuộc tấn công vào chuỗi cung ứng. Sử dụng các giao diện chính thức để gọi các giao thức bên ngoài và đảm bảo tính đến các rủi ro tích hợp tiềm ẩn. Theo dõi các bản cập nhật và các rò rỉ bảo mật từ các hợp đồng bạn đã sử dụng lại.
(C) Giai đoạn kiểm tra và xem xét
# 4: Xem xét các thử nghiệm và tài liệu
What: Tạo tài liệu rõ ràng, toàn diện về code và thiết lập bộ kiểm thử nhanh, kỹ lưỡng, dễ chạy. Nếu có thể, hãy thiết lập môi trường thử nghiệm trên testnet hoặc thông qua mô phỏng mainnet để thử nghiệm sâu hơn.
Why: Viết ra các giả định cho các hành vi có thể xảy ra trong nội dung hoàn chỉnh của mã nguồn (codebase) giúp đảm bảo rằng các rủi ro trong các mô hình mối đe dọa đang được giải quyết và người dùng cũng như các chuyên gia đánh giá bên ngoài hiểu được ý định của nhóm phát triển. Tạo một bộ kiểm thử cho code giúp chứng minh - hoặc bác bỏ - các giả định phát triển và khuyến khích suy nghĩ sâu hơn về các mô hình mối đe dọa. Bộ kiểm thử này nên bao gồm các thử nghiệm về thiết kế cơ chế kiểm tra tokenomics của một dự án trong các tình huống khắc nghiệt của thị trường , cùng với kiểm tra các thành phần riêng lẻ (unit testing) và thử nghiệm tích hợp (integration tests).
How: Triển khai framework kiểm thử - đã biết và trình kiểm tra bảo mật - chẳng hạn như Hardhat, Mythril, Slither, Truffle, v.v. - cung cấp các kỹ thuật kiểm tra khác nhau, chẳng hạn như fuzzing, kiểm tra tài sản hoặc thậm chí xác minh chính thức (formal verification). Tài liệu hoá lại code của bạn - một cách chuyên sâu - bằng cách sử dụng các nhận xét của NatSpec để chỉ định hiệu ứng phụ, tham số và giá trị trả về. Tạo tài liệu trực tiếp bằng cách sử dụng các công cụ tạo tài liệu cùng với giải thích thiết kế cấp cao.
# 5: Xem xét các đánh giá nội bộ và đánh giá bảo mật (security audits)
What: Dành thời gian để tìm lỗi thông qua cả đánh giá code từ cả bên trong và bên ngoài.
Why: Việc từ bỏ phát triển tính năng để tập trung vào các mối quan tâm về bảo mật mang lại cho các nhà phát triển thời gian để tìm ra các vấn đề có thể bị che khuất. Đánh giá bên ngoài có thể đặc biệt hữu ích trong việc này, vì chúng có thể mang lại những quan điểm khách quan và kiến thức chuyên môn mà nhóm phát triển không có.
How: Vào thời điểm thích hợp trong quá trình phát triển dự án, hãy lên lịch đóng băng tính năng để có thời gian đánh giá nội bộ, sau đó là đánh giá từ bên ngoài. Điều này sẽ diễn ra trước khi triển khai và nâng cấp trực tiếp. Xem các hướng dẫn từ ConsenSys , Nascent , OpenZeppelin và Trail of Bits, những hướng dẫn này cung cấp cho các nhà phát triển checklist cần cân nhắc - bao gồm cả thời gian - cho bất kỳ ai chuẩn bị đánh giá. Cũng cần đảm bảo xem xét các giao dịch triển khai (deployment transactions) để đảm bảo chúng sử dụng phiên code đã được audit và có các tham số thích hợp, đặc biệt là khi nâng cấp phần mềm.
Giai đoạn triển khai (D) & bảo trì (E)
# 6: Cân nhắc khuyến khích sự tham gia của cộng đồng hacker mũ trắng
What: Tạo các chương trình khuyến khích sự tham gia của cộng đồng trong việc cải thiện bảo mật trên cơ sở mã nguồn mở. Một cách để làm điều này là chính sách phần thưởng phát hiện lỗi. Một cách khác là khuyến khích cộng đồng phát triển các bot phát hiện giám sát giao thức (protocol-monitoring detection bots).
Why: Các nhóm phát triển có thể được hưởng lợi rất nhiều từ việc khai thác nguồn kiến thức và kinh nghiệm rộng lớn hơn. (Một lần nữa, đây cũng là điểm mà mã nguồn mở giúp ích cho tiền mã hoá.) Đáng chú ý, các chương trình như vậy có thể giúp tạo ra sự nhiệt tình cho một dự án, về cơ bản biến cộng đồng và các hacker mũ trắng thành những người truyền giáo. Họ cũng có thể giúp biến những kẻ tấn công trở thành tài sản bảo mật bằng cách cung cấp các con đường để hacker trở thành defender.
How: Sử dụng các nền tảng tiền thưởng phát hiện lỗi (chẳng hạn như Code4rena, HackenProof, Immunefi hoặc Secureum) để tài trợ cho các hệ thống tiền thưởng với phần thưởng dựa trên mức độ nghiêm trọng nhằm khuyến khích các hacker có kỹ năng tiết lộ lỗ hổng bảo mật một cách an toàn. [Tiết lộ đầy đủ, một số đồng tác giả của bài đăng này làm việc cho Forta , có mạng lưới cung cấp cấu trúc khuyến khích mã hóa để tạo các bot phi tập trung giám sát bảo mật chất lượng cao.] Các nhóm phát triển có thể khuyến khích cộng đồng giao thức (protocols’ communities) của họ tận dụng lợi thế của cả phương pháp tiếp cận truyền thống và web3-native để khuyến khích chính sách tiền thưởng phát hiện lỗi và để những người tham gia có khả năng gia tăng lợi nhuận bằng cách tăng cường bảo mật để giành chiến thắng win/win cho cả 2 bên.
# 7: Cân nhắc giám sát thời gian thực
What: Triển khai các hệ thống giám sát các smart contract và các thành phần hoạt động quan trọng như oracles và cầu nối, đồng thời báo cáo hoạt động đáng ngờ cho nhóm phát triển và cộng đồng dựa trên các mô hình mối đe dọa đã biết.
Why: Việc phát hiện sớm các vấn đề cho phép một nhóm phản hồi nhanh chóng với các hoạt động khai thác lỗ hổng và lỗi, có khả năng ngăn chặn hoặc giảm thiểu bất kỳ thiệt hại nào. Điều này có vẻ hiển nhiên nhưng có thể bị bỏ qua trong việc lập kế hoạch.
How: Sử dụng các nền tảng giám sát hoặc các nút phân tán để chạy các bot giám sát các sự kiện smart contract theo thời gian thực. Triển khai dashboard và thông báo cảnh báo cho các nhóm phát triển và cộng đồng rộng lớn hơn nếu cần.
# 8: Xem xét các hoạt động ứng phó sự cố và khẩn cấp
What: Sử dụng các công cụ và quy trình cho phép phản hồi ngay lập tức trong trường hợp có bất kỳ vấn đề bảo mật nào.
Why: Ngay cả với các biện pháp bảo vệ trước khi triển khai tốt nhất, các smart contract và các thành phần quan trọng, chẳng hạn như oracles và cầu nối, vẫn có thể gặp sự cố trực tiếp. Việc có nhân viên tận tâm, quy trình rõ ràng và tự động hóa phù hợp đảm bảo rằng các sự cố có thể được điều tra nhanh chóng - và giải quyết nhanh nhất có thể.
How: Chuẩn bị cho tình huống xấu nhất bằng cách lập kế hoạch cách ứng phó với các sự cố hoặc trường hợp khẩn cấp và tự động hóa khả năng ứng phó ở mức độ lớn nhất có thể. Điều này bao gồm việc chỉ định trách nhiệm điều tra và phản hồi cho nhân viên có năng lực có thể được liên hệ công khai về các vấn đề bảo mật thông qua danh sách địa chỉ mail bảo mật phân tán (distributed security mailing list - một nhóm các địa chỉ email có trong danh sách với một địa chỉ email chung. Khi người dùng gửi đến một Email này, họ đang gửi tin nhắn đến tất cả những tài khoản Email trong danh sách), hướng dẫn trong code repository hoặc trong smart contract. Dựa trên các mô hình mối đe dọa của giao thức, phát triển một tập hợp các quy trình có thể bao gồm các cuộc diễn tập kịch bản và thời gian phản ứng dự kiến để thực hiện các hành động khẩn cấp. Cân nhắc tích hợp tự động hóa vào ứng phó sự cố, ví dụ: các công cụ có thể thâm nhập và hoạt động dựa trên các sự kiện từ bot Forta.
Các cân nhắc về bảo mật phải là một phần không thể thiếu trong quá trình phát triển thành công - không chỉ là một phần bổ sung hay tính năng bổ sung.
Mặc dù khuôn khổ bài này chia sẻ một số hướng dẫn nhanh cho những giao thức và ứng dụng xây dựng web3 nhằm thúc đẩy bảo mật trong suốt quá trình phát triển, nhưng một bài viết ngắn không thể nào có thể cung cấp đầy đủ về tất cả các khía cạnh của bảo mật smart contract. Các nhóm thiếu chuyên môn về bảo mật nên liên hệ với các chuyên gia bảo mật web3 đủ điều kiện, những người có thể hỗ trợ họ áp dụng các hướng dẫn chung ở trên cho các tình huống cụ thể của họ. Nhưng trên tất cả, hãy nhớ rằng bảo mật không bao giờ chỉ là việc đánh dấu tick các ô trong checklist kiểm tra đơn giản để quản lý sự phức tạp; mà nó sẽ luôn là một tập hợp các phương pháp tốt nhất liên tục, không bao giờ kết thúc. Chúng tôi vẫn đang bắt đầu thiết lập các phương pháp tốt nhất này, vì vậy, bây giờ là lúc để cộng tác tạo và chia sẻ chúng, ở mọi cấp độ cho tất cả các nhà phát triển.
Biên tập bởi Robert Hackett @rhhackett
Andy Beal là trưởng nhóm hệ sinh thái tại Forta. Từng giúp quản lý hoạt động thực hành blockchain của EY.
Nassim Eddequiouaq là giám đốc bảo mật thông tin của A16z Crypto. Từng làm việc tại Facebook, Anchorage và Docker.
Riyaz Faizullabhoy là giám đốc công nghệ của tiền mã hoá A16z. Từng làm việc tại Facebook, Anchorage và Docker.
Christian Seifert là nhà nghiên cứu tại Forta. Trước đây, ông đã có 14 năm làm việc về bảo mật web tại Microsoft.
Các góc nhìn trên đây là quan điểm của cá nhân ở AH Capital Management, LLC (“A16z”) được trích dẫn và không phải là quan điểm của A16z hoặc các chi nhánh của A16z. Một số thông tin nhất định trong đây đã được lấy từ các nguồn của bên thứ ba, bao gồm từ các công ty danh mục đầu tư của các quỹ do A16z quản lý. Mặc dù lấy từ các nguồn được cho là đáng tin cậy, A16z đã không xác minh độc lập thông tin đó và không đưa ra tuyên bố nào về tính chính xác lâu dài của thông tin hoặc tính thích hợp của nó đối với một tình huống nhất định. Ngoài ra, nội dung này có thể bao gồm các quảng cáo của bên thứ ba; A16z đã không xem xét các quảng cáo đó và không xác nhận bất kỳ nội dung quảng cáo nào có trong đó.
Nội dung này chỉ được cung cấp cho mục đích thông tin và không nên được dựa vào như lời khuyên về pháp lý, kinh doanh, đầu tư hoặc thuế. Bạn nên tham khảo ý kiến của các cố vấn của riêng mình về những vấn đề đó. Các tham chiếu đến bất kỳ mã chứng khoán hoặc tài sản kỹ thuật số nào chỉ dành cho mục đích minh họa và không cấu thành khuyến nghị đầu tư hoặc đề nghị cung cấp dịch vụ tư vấn đầu tư. Hơn nữa, nội dung này không hướng đến cũng như không nhằm mục đích sử dụng bởi bất kỳ nhà đầu tư hoặc nhà đầu tư tiềm năng nào và không được dựa vào bất kỳ trường hợp nào khi đưa ra quyết định đầu tư vào bất kỳ quỹ nào do A16z quản lý. (Đề nghị đầu tư vào quỹ A16z sẽ chỉ được thực hiện bởi bản ghi nhớ phát hành riêng lẻ, thỏa thuận đăng ký và các tài liệu liên quan khác về bất kỳ quỹ nào như vậy và cần được đọc toàn bộ.) Bất kỳ khoản đầu tư hoặc công ty danh mục đầu tư nào được đề cập, được đề cập hoặc mô tả không phải là đại diện cho tất cả các khoản đầu tư vào các khoản do a16z quản lý và không có gì đảm bảo rằng các khoản đầu tư đó sẽ sinh lời hoặc các khoản đầu tư khác được thực hiện trong tương lai sẽ có các đặc điểm hoặc kết quả tương tự. Danh sách các khoản đầu tư được thực hiện bởi các quỹ do Andreessen Horowitz quản lý (không bao gồm các khoản đầu tư mà tổ chức phát hành không cho phép a16z tiết lộ công khai cũng như các khoản đầu tư không thông báo vào tài sản kỹ thuật số được giao dịch công khai) có tại https://a16z.com/investments/.
Các biểu đồ và đồ thị được cung cấp bên trong chỉ nhằm mục đích cung cấp thông tin và không nên dựa vào khi đưa ra bất kỳ quyết định đầu tư nào. Hiệu suất trong quá khứ không cho thấy kết quả trong tương lai. Nội dung chỉ nói kể từ ngày được chỉ định. Mọi dự đoán, ước tính, dự báo, mục tiêu, triển vọng và / hoặc ý kiến thể hiện trong các tài liệu này có thể thay đổi mà không cần thông báo trước và có thể khác hoặc trái ngược với ý kiến của người khác. Vui lòng xem https://a16z.com/disclosures để biết thêm thông tin quan trọng.
Link bài gốc của Andy Beal, Nassim Eddequiouaq, Riyaz Faizullabhoy và Christian Seifert
Dịch bởi Minh Tuan. Biên tập và đăng tải bởi Paven Do.
If You love the post, you may wish to donate for this special charity: https://www.carryforwardvietnam.org/donate/
Nếu bạn thích bài viết, bạn có thể đóng góp cho dự án từ thiện: https://www.carryforwardvietnam.org/donate/