Tài chính phi tập trung các lỗ hổng bảo mật phổ biến và biện pháp phòng ngừa
Gần đây, một chuyên gia an ninh đã chia sẻ một bài học về an ninh Tài chính phi tập trung cho các thành viên trong cộng đồng. Ông đã điểm lại những sự kiện an ninh nghiêm trọng mà ngành Web3 đã gặp phải trong hơn một năm qua, thảo luận về nguyên nhân xảy ra những sự kiện này cũng như cách tránh chúng, tổng hợp các lỗ hổng an ninh phổ biến của hợp đồng thông minh và các biện pháp phòng ngừa, đồng thời đưa ra một số lời khuyên về an ninh cho các dự án và người dùng thông thường.
Các loại lỗ hổng DeFi phổ biến bao gồm cho vay chớp nhoáng, thao túng giá, vấn đề quyền hạn hàm, gọi bên ngoài tùy ý, vấn đề hàm fallback, lỗ hổng logic kinh doanh, rò rỉ khóa riêng, và tấn công tái nhập. Dưới đây sẽ đi sâu vào ba loại là cho vay chớp nhoáng, thao túng giá và tấn công tái nhập.
Cho vay chớp nhoáng
Vay chớp nhoáng bản thân là một sự đổi mới trong Tài chính phi tập trung, nhưng khi bị hacker lợi dụng, họ có thể vay được một lượng lớn vốn mà không cần chi phí, sau khi thực hiện xong việc chênh lệch giá thì trả lại, chỉ cần trả một khoản phí Gas nhỏ để thu được lợi nhuận khổng lồ.
Trong hai năm qua, vấn đề vay chớp nhoáng xảy ra thường xuyên. Một số dự án có vẻ mang lại lợi nhuận cao, nhưng thực tế trình độ của các bên phát triển dự án rất khác nhau. Ngay cả khi mã nguồn không có lỗ hổng, vẫn có thể tồn tại vấn đề về logic. Ví dụ, có những dự án sẽ phát thưởng dựa trên số lượng token mà người nắm giữ có vào một thời điểm cố định, nhưng lại bị kẻ tấn công lợi dụng vay chớp nhoáng để mua một lượng lớn token, khiến họ nhận được phần lớn phần thưởng khi phát thưởng. Cũng có một số dự án tính giá dựa trên token, có thể bị ảnh hưởng giá bởi vay chớp nhoáng. Các bên phát triển dự án nên nâng cao cảnh giác đối với những vấn đề này.
Kiểm soát giá
Vấn đề thao túng giá cả có mối quan hệ chặt chẽ với vay chớp nhoáng, chủ yếu có hai loại:
Sử dụng dữ liệu bên thứ ba để tính giá, nhưng cách sử dụng không đúng hoặc thiếu kiểm tra dẫn đến giá bị thao túng một cách ác ý.
Sử dụng số lượng token của một số địa chỉ làm biến số tính toán, và số dư token của những địa chỉ này có thể được tăng hoặc giảm tạm thời.
Tấn công tái nhập
Một trong những nguy hiểm chính khi gọi hợp đồng bên ngoài là chúng có thể chiếm quyền kiểm soát luồng điều khiển và thực hiện các thay đổi không lường trước được đối với dữ liệu.
Đối với các hợp đồng khác nhau, có nhiều cách để thực hiện tấn công tái nhập, có thể kết hợp các hàm khác nhau của hợp đồng hoặc hàm của nhiều hợp đồng khác nhau để hoàn thành tấn công tái nhập, vì vậy khi giải quyết vấn đề tái nhập cần chú ý:
Không chỉ ngăn chặn vấn đề gọi lại của một hàm duy nhất
Tuân theo mô hình Checks-Effects-Interactions trong lập trình
Sử dụng modifier chống gọi lại đã được kiểm chứng theo thời gian
Điều đáng sợ nhất là tự mình tạo ra bánh xe, cần gì cũng tự viết. Trong lĩnh vực này có rất nhiều thực tiễn an toàn tốt nhất, chúng ta chỉ cần sử dụng chúng, hoàn toàn không cần phải tự tạo ra bánh xe. Khi bạn tạo ra một bánh xe, nó chưa được xác minh đầy đủ, lúc này xác suất gặp vấn đề rõ ràng lớn hơn nhiều so với việc sử dụng một cái đã được kiểm chứng lâu dài.
Đề xuất an toàn
Mẹo an toàn cho dự án
Phát triển hợp đồng tuân theo các thực hành an toàn tốt nhất.
Hợp đồng có thể nâng cấp, tạm dừng: Nhiều cuộc tấn công không phải chỉ chuyển toàn bộ tiền một lần, mà là thực hiện qua nhiều giao dịch, nếu có cơ chế giám sát tương đối hoàn chỉnh, có thể phát hiện ra. Sau khi phát hiện, nếu hợp đồng có thể tạm dừng, có thể giảm thiểu thiệt hại một cách hiệu quả.
Sử dụng khóa thời gian: Nếu có khóa thời gian, giả sử là trong vòng 48 giờ, trong thời gian này, nhiều người có thể phát hiện ra rằng người tạo ra đã cập nhật một phương pháp mint mà tất cả mọi người đều có thể sử dụng, những người theo dõi sẽ biết rằng dự án có thể đã bị hack, có thể thông báo cho dự án để thay đổi, ngay cả khi đã thông báo thì cũng không ai quản lý, ít nhất có thể rút phần tiền của mình ra trước, đảm bảo rằng lợi nhuận của mình không bị thiệt hại. Vì vậy, nếu một dự án không có khóa thời gian, về lý thuyết sẽ làm tăng xác suất gặp vấn đề.
Tăng cường đầu tư vào an toàn, xây dựng hệ thống an toàn hoàn chỉnh: An toàn không phải là một điểm, cũng không phải là một đường, an toàn là một hệ thống. Đừng nghĩ rằng với tư cách là bên dự án, hợp đồng đã được nhiều công ty kiểm toán thì không có vấn đề gì, cần phải xem xét các rủi ro có thể dẫn đến mất mát tài chính. Cần cố gắng thực hiện mô hình rủi ro, và sau đó dần dần loại bỏ phần lớn rủi ro, phần rủi ro còn lại cũng là rủi ro có thể chấp nhận, trong phạm vi có thể chịu đựng. An toàn và hiệu quả không thể đồng thời đạt được, cần phải có sự đánh đổi nhất định. Nhưng nếu hoàn toàn không quan tâm đến an toàn, không đầu tư vào an toàn, thì bị tấn công là điều rất bình thường.
Nâng cao nhận thức về an ninh của tất cả nhân viên: Nâng cao nhận thức về an ninh không cần nhiều kỹ thuật. Trong bối cảnh lớn này, chỉ cần hỏi thêm một chút về lý do và suy nghĩ thêm một chút là có thể tránh được nhiều vấn đề.
Ngăn ngừa hành vi xấu bên trong, đồng thời nâng cao hiệu quả và tăng cường kiểm soát rủi ro: chẳng hạn như chủ sở hữu hợp đồng là ký đơn hay ký đa, có sử dụng khóa thời gian hay không, đều cần được xem xét.
An toàn khi giới thiệu bên thứ ba: Là một phần trong hệ sinh thái, các bên dự án đều có những đối tác trên và dưới. Về mặt an toàn, có một nguyên tắc "mặc định là các đối tác trên và dưới đều không an toàn". Dù là đối tác trên hay dưới, đều cần phải kiểm tra. Đối với bên thứ ba, chúng ta rất khó kiểm soát, rủi ro an toàn thực sự rất lớn, vì vậy cần phải rất chú ý đến việc giới thiệu bên thứ ba. Hợp đồng là mã nguồn mở, có thể được giới thiệu, gọi đến; nếu hợp đồng không phải mã nguồn mở, thì tuyệt đối không được phép trích dẫn.
Người dùng/LP làm thế nào để xác định hợp đồng thông minh có an toàn hay không?
Đối với người dùng bình thường, việc đánh giá dự án có an toàn hay không chủ yếu dựa trên sáu điểm sau:
Hợp đồng có mã nguồn mở không: Tất cả các dự án không có mã nguồn mở, chúng tôi tuyệt đối không chạm vào, vì chúng tôi không thể biết hợp đồng được viết như thế nào.
Chủ sở hữu có sử dụng ký đa không, ký đa có phi tập trung không: Nếu không sử dụng ký đa, chúng tôi không thể xác định logic và nội dung kinh doanh của dự án, một khi xảy ra sự cố an ninh, không thể xác định có phải do hacker gây ra hay không. Ngay cả khi sử dụng ký đa, cũng cần phải xem xét xem ký đa có thực sự phi tập trung hay không.
Tình hình giao dịch của hợp đồng hiện có: đặc biệt trên thị trường có nhiều dự án lừa đảo bằng cách giả mạo, có thể tạo ra một hợp đồng khá giống nhau, lúc này chúng ta cần xem xét thời gian triển khai hợp đồng, số lần tương tác, v.v., tất cả những điều này đều là tiêu chí để đánh giá xem hợp đồng có an toàn hay không.
Hợp đồng có phải là hợp đồng đại diện không, có thể nâng cấp không, có thời gian khóa không: Nếu hợp đồng hoàn toàn không thể nâng cấp, thì quá cứng nhắc, vẫn khuyên rằng hợp đồng của dự án nên có thể nâng cấp. Tuy nhiên, việc nâng cấp cần có phương pháp, khi có nội dung nâng cấp hoặc thay đổi tham số quan trọng, cần có một thời gian khóa, cần cho mọi người một khoảng thời gian để đánh giá việc nâng cấp thực sự có hại hay có lợi cho người dùng, đây cũng là một cách công khai và minh bạch.
Hợp đồng có được nhiều tổ chức kiểm toán chấp nhận ( không nên mù quáng tin tưởng các công ty kiểm toán ), Quyền hạn của Owner có quá lớn không: trước tiên không nên chỉ tin tưởng một công ty kiểm toán, vì các công ty kiểm toán khác nhau, các kiểm toán viên khác nhau, góc nhìn về vấn đề là khác nhau. Thứ hai, cần xem xét quyền hạn của Owner có quá lớn không. Quyền hạn của Owner trong một dự án bình thường chắc chắn phải có thể kiểm soát được, như vậy sẽ không có quá nhiều hoạt động nguy hiểm, và các hoạt động cũng sẽ được thực hiện bằng cách dùng thời gian khóa, để người dùng biết hoạt động đang thực hiện là gì.
Lưu ý về oracle: Nếu dự án sử dụng oracle hàng đầu trên thị trường, hầu như sẽ không có vấn đề lớn, nhưng nếu sử dụng oracle tự xây dựng, hoặc những oracle mà chỉ cần cầm cố một số token nào đó để cung cấp giá, thì cần phải chú ý. Khi phát hiện oracle có thể gặp một số vấn đề, hoặc có khả năng bị thao túng, thì dù lợi nhuận của dự án có cao đến đâu cũng không nên tham gia.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
9 thích
Phần thưởng
9
5
Chia sẻ
Bình luận
0/400
BrokeBeans
· 07-22 12:06
Kệ, khoản vay nhanh này kiếm được nhiều quá, tiếc là tôi không biết...
Xem bản gốcTrả lời0
LayerZeroHero
· 07-22 06:59
Lại một khoản vay nhanh bị để ý? Không có gì bất ngờ.
Xem bản gốcTrả lời0
P2ENotWorking
· 07-19 19:46
Muốn kiếm tiền thì phải biết cách phòng ngừa lỗ hổng chứ.
Phân tích các lỗ hổng bảo mật phổ biến trong Tài chính phi tập trung: Khoản vay nhanh, thao túng giá và phòng ngừa tấn công tái nhập.
Tài chính phi tập trung các lỗ hổng bảo mật phổ biến và biện pháp phòng ngừa
Gần đây, một chuyên gia an ninh đã chia sẻ một bài học về an ninh Tài chính phi tập trung cho các thành viên trong cộng đồng. Ông đã điểm lại những sự kiện an ninh nghiêm trọng mà ngành Web3 đã gặp phải trong hơn một năm qua, thảo luận về nguyên nhân xảy ra những sự kiện này cũng như cách tránh chúng, tổng hợp các lỗ hổng an ninh phổ biến của hợp đồng thông minh và các biện pháp phòng ngừa, đồng thời đưa ra một số lời khuyên về an ninh cho các dự án và người dùng thông thường.
Các loại lỗ hổng DeFi phổ biến bao gồm cho vay chớp nhoáng, thao túng giá, vấn đề quyền hạn hàm, gọi bên ngoài tùy ý, vấn đề hàm fallback, lỗ hổng logic kinh doanh, rò rỉ khóa riêng, và tấn công tái nhập. Dưới đây sẽ đi sâu vào ba loại là cho vay chớp nhoáng, thao túng giá và tấn công tái nhập.
Cho vay chớp nhoáng
Vay chớp nhoáng bản thân là một sự đổi mới trong Tài chính phi tập trung, nhưng khi bị hacker lợi dụng, họ có thể vay được một lượng lớn vốn mà không cần chi phí, sau khi thực hiện xong việc chênh lệch giá thì trả lại, chỉ cần trả một khoản phí Gas nhỏ để thu được lợi nhuận khổng lồ.
Trong hai năm qua, vấn đề vay chớp nhoáng xảy ra thường xuyên. Một số dự án có vẻ mang lại lợi nhuận cao, nhưng thực tế trình độ của các bên phát triển dự án rất khác nhau. Ngay cả khi mã nguồn không có lỗ hổng, vẫn có thể tồn tại vấn đề về logic. Ví dụ, có những dự án sẽ phát thưởng dựa trên số lượng token mà người nắm giữ có vào một thời điểm cố định, nhưng lại bị kẻ tấn công lợi dụng vay chớp nhoáng để mua một lượng lớn token, khiến họ nhận được phần lớn phần thưởng khi phát thưởng. Cũng có một số dự án tính giá dựa trên token, có thể bị ảnh hưởng giá bởi vay chớp nhoáng. Các bên phát triển dự án nên nâng cao cảnh giác đối với những vấn đề này.
Kiểm soát giá
Vấn đề thao túng giá cả có mối quan hệ chặt chẽ với vay chớp nhoáng, chủ yếu có hai loại:
Sử dụng dữ liệu bên thứ ba để tính giá, nhưng cách sử dụng không đúng hoặc thiếu kiểm tra dẫn đến giá bị thao túng một cách ác ý.
Sử dụng số lượng token của một số địa chỉ làm biến số tính toán, và số dư token của những địa chỉ này có thể được tăng hoặc giảm tạm thời.
Tấn công tái nhập
Một trong những nguy hiểm chính khi gọi hợp đồng bên ngoài là chúng có thể chiếm quyền kiểm soát luồng điều khiển và thực hiện các thay đổi không lường trước được đối với dữ liệu.
Đối với các hợp đồng khác nhau, có nhiều cách để thực hiện tấn công tái nhập, có thể kết hợp các hàm khác nhau của hợp đồng hoặc hàm của nhiều hợp đồng khác nhau để hoàn thành tấn công tái nhập, vì vậy khi giải quyết vấn đề tái nhập cần chú ý:
Không chỉ ngăn chặn vấn đề gọi lại của một hàm duy nhất
Tuân theo mô hình Checks-Effects-Interactions trong lập trình
Sử dụng modifier chống gọi lại đã được kiểm chứng theo thời gian
Điều đáng sợ nhất là tự mình tạo ra bánh xe, cần gì cũng tự viết. Trong lĩnh vực này có rất nhiều thực tiễn an toàn tốt nhất, chúng ta chỉ cần sử dụng chúng, hoàn toàn không cần phải tự tạo ra bánh xe. Khi bạn tạo ra một bánh xe, nó chưa được xác minh đầy đủ, lúc này xác suất gặp vấn đề rõ ràng lớn hơn nhiều so với việc sử dụng một cái đã được kiểm chứng lâu dài.
Đề xuất an toàn
Mẹo an toàn cho dự án
Phát triển hợp đồng tuân theo các thực hành an toàn tốt nhất.
Hợp đồng có thể nâng cấp, tạm dừng: Nhiều cuộc tấn công không phải chỉ chuyển toàn bộ tiền một lần, mà là thực hiện qua nhiều giao dịch, nếu có cơ chế giám sát tương đối hoàn chỉnh, có thể phát hiện ra. Sau khi phát hiện, nếu hợp đồng có thể tạm dừng, có thể giảm thiểu thiệt hại một cách hiệu quả.
Sử dụng khóa thời gian: Nếu có khóa thời gian, giả sử là trong vòng 48 giờ, trong thời gian này, nhiều người có thể phát hiện ra rằng người tạo ra đã cập nhật một phương pháp mint mà tất cả mọi người đều có thể sử dụng, những người theo dõi sẽ biết rằng dự án có thể đã bị hack, có thể thông báo cho dự án để thay đổi, ngay cả khi đã thông báo thì cũng không ai quản lý, ít nhất có thể rút phần tiền của mình ra trước, đảm bảo rằng lợi nhuận của mình không bị thiệt hại. Vì vậy, nếu một dự án không có khóa thời gian, về lý thuyết sẽ làm tăng xác suất gặp vấn đề.
Tăng cường đầu tư vào an toàn, xây dựng hệ thống an toàn hoàn chỉnh: An toàn không phải là một điểm, cũng không phải là một đường, an toàn là một hệ thống. Đừng nghĩ rằng với tư cách là bên dự án, hợp đồng đã được nhiều công ty kiểm toán thì không có vấn đề gì, cần phải xem xét các rủi ro có thể dẫn đến mất mát tài chính. Cần cố gắng thực hiện mô hình rủi ro, và sau đó dần dần loại bỏ phần lớn rủi ro, phần rủi ro còn lại cũng là rủi ro có thể chấp nhận, trong phạm vi có thể chịu đựng. An toàn và hiệu quả không thể đồng thời đạt được, cần phải có sự đánh đổi nhất định. Nhưng nếu hoàn toàn không quan tâm đến an toàn, không đầu tư vào an toàn, thì bị tấn công là điều rất bình thường.
Nâng cao nhận thức về an ninh của tất cả nhân viên: Nâng cao nhận thức về an ninh không cần nhiều kỹ thuật. Trong bối cảnh lớn này, chỉ cần hỏi thêm một chút về lý do và suy nghĩ thêm một chút là có thể tránh được nhiều vấn đề.
Ngăn ngừa hành vi xấu bên trong, đồng thời nâng cao hiệu quả và tăng cường kiểm soát rủi ro: chẳng hạn như chủ sở hữu hợp đồng là ký đơn hay ký đa, có sử dụng khóa thời gian hay không, đều cần được xem xét.
An toàn khi giới thiệu bên thứ ba: Là một phần trong hệ sinh thái, các bên dự án đều có những đối tác trên và dưới. Về mặt an toàn, có một nguyên tắc "mặc định là các đối tác trên và dưới đều không an toàn". Dù là đối tác trên hay dưới, đều cần phải kiểm tra. Đối với bên thứ ba, chúng ta rất khó kiểm soát, rủi ro an toàn thực sự rất lớn, vì vậy cần phải rất chú ý đến việc giới thiệu bên thứ ba. Hợp đồng là mã nguồn mở, có thể được giới thiệu, gọi đến; nếu hợp đồng không phải mã nguồn mở, thì tuyệt đối không được phép trích dẫn.
Người dùng/LP làm thế nào để xác định hợp đồng thông minh có an toàn hay không?
Đối với người dùng bình thường, việc đánh giá dự án có an toàn hay không chủ yếu dựa trên sáu điểm sau:
Hợp đồng có mã nguồn mở không: Tất cả các dự án không có mã nguồn mở, chúng tôi tuyệt đối không chạm vào, vì chúng tôi không thể biết hợp đồng được viết như thế nào.
Chủ sở hữu có sử dụng ký đa không, ký đa có phi tập trung không: Nếu không sử dụng ký đa, chúng tôi không thể xác định logic và nội dung kinh doanh của dự án, một khi xảy ra sự cố an ninh, không thể xác định có phải do hacker gây ra hay không. Ngay cả khi sử dụng ký đa, cũng cần phải xem xét xem ký đa có thực sự phi tập trung hay không.
Tình hình giao dịch của hợp đồng hiện có: đặc biệt trên thị trường có nhiều dự án lừa đảo bằng cách giả mạo, có thể tạo ra một hợp đồng khá giống nhau, lúc này chúng ta cần xem xét thời gian triển khai hợp đồng, số lần tương tác, v.v., tất cả những điều này đều là tiêu chí để đánh giá xem hợp đồng có an toàn hay không.
Hợp đồng có phải là hợp đồng đại diện không, có thể nâng cấp không, có thời gian khóa không: Nếu hợp đồng hoàn toàn không thể nâng cấp, thì quá cứng nhắc, vẫn khuyên rằng hợp đồng của dự án nên có thể nâng cấp. Tuy nhiên, việc nâng cấp cần có phương pháp, khi có nội dung nâng cấp hoặc thay đổi tham số quan trọng, cần có một thời gian khóa, cần cho mọi người một khoảng thời gian để đánh giá việc nâng cấp thực sự có hại hay có lợi cho người dùng, đây cũng là một cách công khai và minh bạch.
Hợp đồng có được nhiều tổ chức kiểm toán chấp nhận ( không nên mù quáng tin tưởng các công ty kiểm toán ), Quyền hạn của Owner có quá lớn không: trước tiên không nên chỉ tin tưởng một công ty kiểm toán, vì các công ty kiểm toán khác nhau, các kiểm toán viên khác nhau, góc nhìn về vấn đề là khác nhau. Thứ hai, cần xem xét quyền hạn của Owner có quá lớn không. Quyền hạn của Owner trong một dự án bình thường chắc chắn phải có thể kiểm soát được, như vậy sẽ không có quá nhiều hoạt động nguy hiểm, và các hoạt động cũng sẽ được thực hiện bằng cách dùng thời gian khóa, để người dùng biết hoạt động đang thực hiện là gì.
Lưu ý về oracle: Nếu dự án sử dụng oracle hàng đầu trên thị trường, hầu như sẽ không có vấn đề lớn, nhưng nếu sử dụng oracle tự xây dựng, hoặc những oracle mà chỉ cần cầm cố một số token nào đó để cung cấp giá, thì cần phải chú ý. Khi phát hiện oracle có thể gặp một số vấn đề, hoặc có khả năng bị thao túng, thì dù lợi nhuận của dự án có cao đến đâu cũng không nên tham gia.