Lời tựa:

Lời tựa:

Các vấn đề bảo mật chuỗi chéo thường xuyên xảy ra gần đây đã thu hút sự chú ý rộng rãi từ thị trường.Bài viết này hy vọng sẽ bắt đầu từ góc độ thiết kế sản phẩm và cho người đọc biết lý do tại sao có quá nhiều vấn đề bảo mật sản phẩm trên đường đua này. Cần phải tuyên bố rằng các vấn đề được chỉ ra trong bài viết không tồn tại trong mọi dự án. Hầu hết các vấn đề đã được thiết kế với các chiến lược đối phó phù hợp. Mục đích chính là hy vọng nhiều người có thể hiểu được sự phức tạp của đường đua này.

tiêu đề phụ

01. Giải pháp xuyên chuỗi luôn thay đổi

Báo cáo nghiên cứu trước đây đã thực sự giải thích cho mọi người một số loại giải pháp chuỗi thông tin khác nhau, bất kể bài thuyết trình cuối cùng là gì, từ góc độ thiết kế sản phẩm, chỉ có chuỗi bên (chuỗi bên theo nghĩa rộng, trong văn bản) Phát biểu của rollup, nó cũng có thể được tóm tắt thành ba cơ chế: chuỗi bên, khóa thời gian băm và công chứng.

(1) Chuỗi bên

Trong số ba sơ đồ, sơ đồ sidechain có tính bảo mật cao nhất, chẳng hạn như các parachains rollup và polkadot khác nhau. Bảo mật được chia sẻ giữa chuỗi chính và chuỗi bên. Tuy nhiên, sơ đồ sidechain thường yêu cầu chuỗi ban đầu và chuỗi mục tiêu phải đẳng cấu, do đó, có ít trường hợp áp dụng hơn rất nhiều. Đây cũng là lý do tại sao Vitalik đồng ý với đa chuỗi, nhưng không phải chuỗi chéo, vì có quá nhiều vấn đề với các giải pháp chuỗi chéo không thể chia sẻ bảo mật.

(2) Khóa thời gian băm

Giải pháp này tuyên bố là giải pháp xuyên chuỗi hỗn hợp ngang hàng phi tập trung nhất, nhưng chi phí cao và thời gian chờ đợi của người dùng quá lâu, dẫn đến tỷ lệ chấp nhận hiện tại không cao. Và khi chúng tôi vẫn cần một bên thứ ba đóng vai trò là nút trung gian để trao đổi tiền tệ, chúng tôi cũng cần cái gọi là lớp đồng thuận trung gian để đáp ứng các yêu cầu về bảo mật và phân cấp.

(3) Cơ chế công chứng

Đây là giải pháp cầu nối chéo không đồng nhất được sử dụng phổ biến nhất hiện nay, hầu hết các sản phẩm trên thị trường về cơ bản đều có nguồn gốc giống nhau, nhìn từ góc độ thiết kế sản phẩm hầu như không có sự khác biệt. Sự khác biệt chính có thể tập trung vào phương pháp và các bước xác minh thông tin, thuật toán đồng thuận của công chứng viên, thuật toán chữ ký của ví ký quỹ, v.v. Không có nhiều khác biệt về trải nghiệm người dùng và độ an toàn. Do đó, từ quan điểm bảo mật, các rủi ro bảo mật gặp phải cũng có nhiều đặc điểm chung.

tiêu đề phụ

02. Luồng logic sản phẩm của cơ chế công chứng

Trước khi hiểu các rủi ro khác nhau mà cơ chế công chứng phải đối mặt, chúng ta cần hiểu logic thiết kế của loại giải pháp này từ quan điểm sản phẩm.

(1) Giới thiệu tóm tắt

Mô tả hình ảnh

Quy trình xuyên chuỗi đơn giản nhất

(2) Khó khăn trong thiết kế

Sẽ có nhiều vấn đề trong việc này, vấn đề lớn nhất là việc quản lý ví đa chữ ký, vì ETH chuyển từ Ethereum sang Fantom là một khoản tiền gửi và nếu người dùng A muốn chuyển ngược lại thì sẽ liên quan đến vấn đề rút tiền.

Việc phân cấp và bảo mật tiền gửi và rút tiền đã trở thành khó khăn lớn nhất.

1. Ai sẽ quản lý tiền? 2. Ai sẽ khởi xướng? 3. Ai sẽ giám sát giao dịch? 4. Làm sao để xác nhận người dùng đã chuyển tiền vào? 5. Làm thế nào để xác nhận rằng tiền của người dùng thực sự là chính người dùng muốn rút? 6. Làm thế nào để ngăn chặn các cuộc tấn công lặp lại? 7. Làm thế nào để gửi lại một giao dịch không thành công? 8. Tôi phải làm gì nếu người quản lý nhiều chữ ký làm điều ác? 9. Tôi nên làm gì nếu có thời gian chết?

Tôi không dám nghĩ tới, càng nghĩ càng cảm thấy phức tạp. Công nghệ cầu nối chuỗi chéo không chỉ liên quan đến đa chữ ký mà còn liên quan đến phát hành tài sản, giám sát chuỗi chéo, xác minh không đồng bộ và thậm chí cần phát hành lớp đồng thuận trung gian độc lập (chuỗi mới).

Do đó, để đơn giản hóa hơn nữa khó khăn cho người dùng hiểu, tôi sẽ chia toàn bộ quy trình xuyên chuỗi thành hai phần: gửi và rút tiền. Để giúp bạn hiểu rõ hơn.

(3) Hoàn thiện hơn nữa quy trình

1. Đặt cọc

Trước hết, tôi xin tuyên bố rằng quy trình được vẽ trong hình bên dưới chỉ là kế hoạch thiết kế do tôi suy luận mà không có sự tranh luận cẩn thận. Mục đích là để khám phá các vấn đề bảo mật có thể xảy ra trong logic thiết kế và không thể áp dụng nó như một kế hoạch hoàn thiện. Đó là Tất cả đều nhảm nhí.

Như thể hiện trong hình: một giao dịch gửi tiền từ chuỗi ban đầu sang chuỗi mục tiêu về nguyên tắc sẽ bao gồm các bước sau:

(1) Người dùng nạp tiền vào địa chỉ lưu trữ

(2) Sau khi người nghe giám sát giao dịch, BP (nút đồng thuận cũng là quản trị viên đa chữ ký) sẽ bắt đầu giao dịch

(3) Hợp đồng xác minh tính chính xác của chữ ký BP

(4) Có cơ chế chịu lỗi nút hay không

(5) Nếu không có cuộc gọi lại, nếu có, hãy nạp lại địa chỉ chuỗi đích theo mối quan hệ của địa chỉ được ánh xạ

(6) BP xác nhận giao dịch nạp tiền

(7) Chuyển mã thông báo ánh xạ tới địa chỉ của người dùng trên chuỗi mục tiêu sau khi chuyển qua Byzantium

Cần lưu ý rằng quy trình này nhằm mục đích thảo luận về các chuỗi chéo không đồng nhất nói chung, do đó, so với anyswap và các giải pháp khác, một bước bổ sung được thêm vào để cho phép người dùng liên kết các mối quan hệ địa chỉ trên lớp đồng thuận trung gian. Điều này chủ yếu là do các cách khác nhau để đính kèm thông tin vào các giao dịch chuỗi không đồng nhất khác nhau, để giải quyết nó một cách thống nhất, tốt hơn hết là để người dùng ràng buộc mối quan hệ ánh xạ trước. Nếu bạn đang xử lý các giao dịch trên chuỗi EVM, bạn không cần bước này, chỉ cần đính kèm địa chỉ của chuỗi mục tiêu khi bạn bắt đầu giao dịch.

Quay lại chủ đề, có thể thấy từ quy trình trên, bắt đầu từ bước thứ hai, bạn sẽ gặp phải nhiều vấn đề xác minh logic và các vấn đề xử lý trong các tình huống khác nhau.

Logic xác minh chính bao gồm:

(1) Sau khi lắng nghe giao dịch, hãy xác minh ánh xạ tài sản được bắt đầu và chuyển sang giao dịch chuỗi mục tiêu của người dùng A

(2) Bắt đầu giao dịch chuỗi mục tiêu và xác minh kết quả giao dịch Tất nhiên, ngoài logic xác minh được rút ra trong quy trình của tôi, nó cũng nên bao gồm việc xác minh các vấn đề nạp tiền giả và các vấn đề xử lý đặc biệt cần được thực hiện khi gọi khác nhau mã thông báo. Để tóm tắt rõ hơn các mối nguy hiểm an toàn tiềm ẩn có thể phát sinh trong tương lai, chúng ta hãy tiếp tục tìm hiểu quy trình rút tiền.

2. Rút tiền

Quá trình được thể hiện bằng việc rút tiền xu là logic trao đổi tài sản chuỗi mục tiêu trở lại tài sản chuỗi ban đầu. Điều quan trọng cần lưu ý là nhiều mã thông báo hiện có nhiều phiên bản chuỗi, có nghĩa là nhiều mã thông báo trên nhiều chuỗi sở hữu mã thông báo gốc. Do đó, một số dự án cầu thường thiết lập nhóm tài sản. Trong trường hợp có đủ quỹ, người dùng sẽ không cảm thấy sự tồn tại của các tài sản được ánh xạ như anyDAI mà thay thế trực tiếp chúng bằng mã thông báo của phiên bản chuỗi mục tiêu, nhưng điều này không ảnh hưởng đến logic tổng thể. Vì vậy, phân tích tiếp tục.

Như thể hiện trong hình, quá trình giao dịch từ chuỗi mục tiêu sang chuỗi ban đầu như sau: (1) Người dùng bắt đầu giao dịch (chuyển cùng một lượng tài sản được ánh xạ vào ví ký quỹ trên chuỗi mục tiêu) (2 ) Xác minh danh tính của BP. Một BP bắt đầu yêu cầu rút tiền xu (3) xác nhận quyền và chữ ký rút tiền xu (4) hoàn thành yêu cầu rút tiền xu trên chuỗi ban đầu sau khi vượt qua Byzantium và chuyển tiền từ ví ký quỹ của chuỗi ban đầu cho người dùng A (5) nếu có một nút ở giữa Các vấn đề như lỗi xác minh hoặc thời gian ngừng hoạt động cần được khôi phục và bắt đầu lại. Từ quy trình trên, có thể thấy logic xác minh chính liên quan trong đó là: (1) xác minh quyền bắt đầu và chữ ký (2) cơ chế chịu lỗi sau khi xảy ra sự cố

(4) Rủi ro bảo mật

1. Vấn đề bảo mật trong logic thiết kế

Sau khi hiểu kỹ hơn về thiết kế của cầu xuyên chuỗi, chúng ta có thể thấy rằng có rất nhiều thách thức trong logic thiết kế của cầu xuyên chuỗi. Tóm lại, có ba vấn đề chính (các trường hợp bị đánh cắp có liên quan được đánh dấu tại cuối câu hỏi)

(1) Đặt cọc

a) Có lỗ hổng trong thẩm quyền của hợp đồng nạp xu, dẫn đến việc chuyển trực tiếp số tiền đã nạp. Đây là một vấn đề ngớ ngẩn mà hầu như tất cả các dự án hợp đồng sẽ gặp phải, b) vấn đề nạp tiền giả, một số dự án chưa xác minh tính xác thực của Mã thông báo chuỗi chéo, dẫn đến fakeTOKEN -> realTOKEN (anyswap), thành thật mà nói, đây cũng là một chút ngu ngốc. d) Vấn đề nạp tiền giả, ETH và các tài sản bản địa khác khác với hợp đồng ERC20, nhiều cuộc tấn công là do xử lý ETH không đúng cách, dẫn đến fakeETH -> realETH, đó là lý do tại sao các tài sản được bao bọc như WETH lại phổ biến. (thorchain) c) Mặc dù các Token khác nhau đều là tiêu chuẩn ERC20, nhưng các phương thức triển khai cụ thể khác nhau hoặc có các logic bổ sung (rebase, dự phòng, v.v.), nhà phát triển đã không nghiên cứu kỹ khi điều chỉnh, chẳng hạn như ( WETH, PERI, OMT, WBNB, MATIC, AVAX), v.v. sẽ gọi chức năng dự phòng tùy chỉnh của người gửi để thực hiện các hoạt động bổ sung sau khi quá trình chuyển hoàn tất, điều này làm tăng độ phức tạp của phán đoán cầu nối chuỗi chéo (anyswap 2022.1.18)

(2) Truyền tin nhắn xuyên chuỗi

Sau khi quá trình nạp tiền của chuỗi a hoàn tất và trước khi tài sản của chuỗi b đến tài khoản, cầu nối chuỗi chéo được xử lý giống như một hệ thống chuỗi khối độc lập, yêu cầu cơ chế đồng thuận, thường sử dụng dpos và tất cả những điều sau đây giả sử sử dụng dpos Các vấn đề cần được xem xét, nhưng tôi nghi ngờ rằng tất cả các nút đều thuộc về phía dự án và có nguy cơ tập trung hóa ngay từ đầu. a) Để giám sát các thông báo gửi tiền xu, ai sẽ là người đầu tiên bắt đầu đề xuất xử lý chuỗi chéo một cách ngẫu nhiên? Hay thay phiên nhau? Hoặc theo thứ tự của các khối được tạo bởi lớp đồng thuận trung gian? b) Làm thế nào để nhiều công chứng viên xác minh tính chính xác của tiền gửi? Nếu tất cả các nguồn dữ liệu đều từ các nhà cung cấp dữ liệu như infura, thì infura là một điểm rủi ro duy nhất. Điều an toàn nhất là duy trì các nút của riêng họ, việc này tốn rất nhiều chi phí. c) Làm thế nào để xác nhận rằng quá trình xử lý chuỗi chéo đã hoàn tất (b đã được ghi có), có một số tình huống chưa được xử lý. , nhưng xác minh & đồng thuận không thành công iii. Xác minh cầu được thông qua, nhưng không có giao dịch nào được thực hiện trên chuỗi b iv. Có một giao dịch trên chuỗi b, nhưng không thành công (không đủ tiền hoặc các trường hợp khác)

(3) Vấn đề xác minh đa chữ ký

Hầu hết các khu vực bị ảnh hưởng nặng nề nhất với các vấn đề thường xuyên xảy ra là các vấn đề về logic mã a) 3/5 chữ ký, tôi chỉ xây dựng các chữ ký không có trong danh sách đa chữ ký, cũng được coi là +1 (chainswap). b) Vấn đề tập trung hóa, mang danh nghĩa đa chữ ký, thực chất nằm trong tay bên dự án, rủi ro tập trung hóa rất lớn c) Phương thức xác thực chữ ký, mô hình phát triển trên các chuỗi khác nhau dẫn đến những thiếu sót khó tránh khỏi khi các nhà phát triển kết nối , ví dụ về lỗ sâu: Chức năng chữ ký xác minh trên solana là một chức năng trong hợp đồng hệ thống. Thông thường, hợp đồng hệ thống nên được gọi và địa chỉ của hợp đồng hệ thống phải được viết trong mã. Họ chuyển địa chỉ của hợp đồng hệ thống như một tham số ở đây.Tin tặc Khi rút tiền, một địa chỉ hợp đồng hệ thống giả mạo đã được thông qua và việc xác minh chữ ký đã bị bỏ qua và tiền được rút một cách suôn sẻ.

(4) Hoàn tiền

a) Như đã thảo luận trong (2)-c, có nhiều khả năng xảy ra trạng thái chuỗi chéo. Trong mọi trường hợp, cần cung cấp cho người dùng phương thức hoàn tiền. Ví dụ: khi anyswap gửi tiền, trước tiên nó sẽ gửi bất kỳ Token nào, và sau đó gửi anyToken cho người dùng trên chuỗi mục tiêu, sau đó ghi anyToken của chuỗi nguồn. Mục đích của việc này là bất kể vấn đề ở đâu, người dùng có thể đại diện cho tài sản mà anh ta nắm giữ bằng cách giữ anyToken. Có 3 chuỗi (nguồn, đích, cầu nối chuỗi chéo) và 4 tài sản (Mã thông báo gốc/bất kỳToken nào trên chuỗi nguồn và chuỗi đích) trong quá trình này, rất dễ xảy ra các vấn đề về logic mã. b) Thorchain bị rò rỉ vào ngày 23 tháng 7 năm 2021. Tin tặc đã sử dụng các vấn đề logic mã để tạo ra một lượng lớn tiền nạp giả, cầu nối chuỗi không xử lý được nên đã nhập logic hoàn trả, dẫn đến việc tin tặc nhận được một khoản tiền hoàn trả khổng lồ.

2. Các rủi ro bảo mật khác

Nhưng các vấn đề có thể được hiển thị thông qua quy trình logic chỉ là các vấn đề logic nghiệp vụ, không phải tất cả chúng. Từ quan điểm bảo mật, chúng ta cũng nên xem xét ba rủi ro khác

(1) Rủi ro hệ thống

Ví dụ: ký gửi của chuỗi ban đầu thành công ngay từ đầu, sau đó quay trở lại, đây là một vấn đề rất lớn. V Chúa đã thảo luận rằng tài sản được chuyển từ Solana sang Ethereum. Nhưng ví dụ, lớp 2, chia sẻ bảo mật với Ethereum, chẳng hạn như rollup, sẽ không gặp vấn đề này.

(2) Rủi ro từ phía trước

a) Các URL giả mạo, chẳng hạn như oxdao.fi 0xdao.fi oxdai.fi, v.v. b) Tấn công Xss, tức là tấn công bằng kịch bản chéo trang, là một cuộc tấn công chèn mã, chẳng hạn như www.xxxx.finance/?params= hackercode12345, mặc dù URL thực sự là trang web chính thức, nhưng trang web mang mã của hacker, nếu người phát triển front-end không chú ý đến việc ngăn chặn xss, mã này sẽ được thực thi trên trang, khiến người dùng ủy quyền cho giao dịch chuyển nhượng của hacker để ký.Do đó, không mở các liên kết từ các nguồn không xác định. c) Tấn công dịch vụ chéo trang Cors.Theo chính sách cùng nguồn gốc nghiêm ngặt, các trình duyệt chỉ được phép tải nội dung từ trang này, nghĩa là tất cả nội dung hiển thị trên trang www.xxxx.finance và giao diện được gọi phải đến từ xxxx .Tên miền tài chính, nhưng hầu hết các dự án hiện tại đều cho phép gọi chéo trang, tức là phần đầu của xxxx có thể gọi giao diện hoán đổi nhanh và ngược lại, điều này mang lại sự thuận tiện cho quá trình phát triển nhưng cũng mang lại rủi ro. xxxx.finance đã lưu trữ một số dữ liệu nhạy cảm trong bộ đệm của trình duyệt, sau đó tôi đã truy cập một trang web độc hại. Nếu chính sách cùng nguồn gốc của xxxx không bị hạn chế, trang web độc hại này có thể tự do lấy dữ liệu được lưu trữ trong bộ đệm của xxxx.

(3) Rủi ro của các chức năng bổ sung

tiêu đề phụ

03. Phần kết

1. Mục đích của báo cáo này là giúp người dùng hiểu rõ hơn về các rủi ro bảo mật của các cầu nối chuỗi chéo và nó không phải là biểu hiện ác ý về mức độ dễ bị tấn công của các cầu nối chuỗi chéo.

2. Giải pháp bắc cầu xuyên chuỗi của cơ chế công chứng là giải pháp có trải nghiệm tốt nhất, phạm vi áp dụng rộng nhất và chi phí thấp nhất ít nhất cho đến thời điểm hiện tại. Và bất kỳ sản phẩm nào cũng sẽ trải qua quá trình từ sơ khai đến trưởng thành và các cuộc tấn công vào các sản phẩm blockchain thường là "các vấn đề logic". Những câu hỏi này chắc chắn sẽ trở nên tốt hơn theo thời gian và kinh nghiệm.

Quét mã QR để tham gia cộng đồng Các vấn đề về sản phẩm, vui lòng theo dõi Twitter cá nhân của Jackson để thảo luận @0xOar

Giới thiệu về SeerLabs:

SeerLabs (Prophet Labs) là một tổ chức hàng đầu ở châu Á tập trung vào ươm tạo thị trường blockchain. Chúng tôi có các khái niệm tiếp thị tiên tiến toàn cầu và các hacker tăng trưởng, đồng thời cam kết giúp các bên dự án và công ty khởi nghiệp đạt được tốc độ tăng trưởng nhanh như chớp. Tham gia ươm tạo thành công hơn 30 dự án như Ploygon (MATIC), HoDooi.com, DIA, Paralink, Swingby, XEND Finance, BOSON, v.v.

tham gia với chúng tôi:

Twitter: https://twitter.com/seerlabs_crypto

Truyền thông về sản phẩm: https://twitter.com/0xOar

Email hợp tác: sharon@seerlabs.io

Cảnh báo rủi ro: Tài sản kỹ thuật số là mục tiêu đầu tư có rủi ro cao. Công chúng nói chung được yêu cầu xem xét chuỗi khối một cách hợp lý, nâng cao nhận thức về rủi ro và thiết lập các khái niệm tiền tệ và khái niệm đầu tư chính xác.