Lời nói đầuMô hình bảo mật cơ bản của các ứng dụng web đang đối mặt với một thách thức nghiêm trọng: làm thế nào người dùng có thể tin tưởng rằng mã JavaScript đang chạy trong trình duyệt của họ không bị giả mạo? Câu hỏi này trở nên đặc biệt cấp bách đối với các dịch vụ nhắn tin được mã hóa từ đầu đến cuối và các ứng dụng tài chính, nơi tính toàn vẹn của mã là tối quan trọng. Trong khi các ứng dụng gốc được hưởng lợi từ cơ chế ký xác thực trên cửa hàng ứng dụng, các ứng dụng web từ trước đến nay vẫn thiếu các biện pháp bảo vệ tương đương, tạo ra cái mà các chuyên gia bảo mật gọi là vấn đề mật mã JavaScript. Các đề xuất gần đây về tiêu chuẩn toàn vẹn ứng dụng web đang tạo ra cuộc thảo luận sôi nổi giữa các nhà phát triển và nhà nghiên cứu bảo mật về việc liệu cuối cùng chúng ta có thể mang các đảm bảo bảo mật ở cấp độ ứng dụng gốc lên web hay không.
 |
|---|
| Một bài đăng blog thảo luận về tầm quan trọng của việc cải thiện bảo mật JavaScript trên web |
Vấn đề Cốt lõi với Bảo mật Ứng dụng Web
Vấn đề cơ bản làm ảnh hưởng đến bảo mật ứng dụng web bắt nguồn từ tính chất động của việc phân phối mã. Không giống như các ứng dụng di động gốc được ký mã hóa và phân phối thông qua cửa hàng ứng dụng, các ứng dụng web được cung cấp mới mỗi lần truy cập, tạo ra nhiều vectơ tấn công. Một máy chủ bị xâm phạm có thể cung cấp mã độc cho người dùng cụ thể dựa trên địa chỉ IP, vị trí địa lý hoặc thậm chí là cookie theo dõi của họ. Điều này làm suy yếu chính nền tảng của mã hóa từ đầu đến cuối, như một bình luận viên đã nhận xét:
Vấn đề kinh điển với nhắn tin E2EE trên web là mục đích của E2EE là bạn không cần phải tin tưởng máy chủ để không đọc tin nhắn của bạn, nhưng nếu bạn đang sử dụng một máy khách web, bạn phải tin tưởng máy chủ sẽ cung cấp cho bạn JS mà nó sẽ không chỉ gửi văn bản thuần túy của tin nhắn của bạn cho quản trị viên.
Điều này tạo ra một tình huống nghịch lý khi người dùng phải tin tưởng chính thực thể mà họ đang cố gắng bảo vệ mình. Vấn đề mở rộng ra ngoài ý định độc hại - ngay cả các máy chủ đáng tin cậy nhưng bị xâm phạm cũng có thể vô tình cung cấp mã bị giả mạo, hoàn toàn bỏ qua bất kỳ mã hóa nào từ phía máy khách.
Các Thách Thức Bảo Mật Chính Đối Với Ứng Dụng Web
Việc phân phối mã động tạo điều kiện cho các cuộc tấn công có mục tiêu Không có cơ chế tương đương với việc ký ứng dụng gốc Sự xâm phạm máy chủ hoàn toàn làm suy yếu bảo mật phía client Các giải pháp hiện tại chỉ cung cấp khả năng bảo vệ một phần *Khoảng trống về tính minh bạch và khả năng kiểm toán so với ứng dụng gốc
 |
|---|
| Sơ đồ minh họa quy trình bằng chứng bao hàm và các bước xác minh liên quan đến bảo mật ứng dụng web |
Các Giải pháp Hiện có và Hạn chế của Chúng
Các tính năng bảo mật web hiện tại như Tính toàn vẹn Tài nguyên Phụ (SRI) cung cấp các giải pháp một phần nhưng không đáp ứng được sự bảo vệ toàn diện. SRI cho phép các nhà phát triển chỉ định các hàm băm mật mã cho các tài nguyên bên ngoài như tập lệnh và biểu định kiểu, cho phép trình duyệt xác minh tính toàn vẹn của chúng trước khi thực thi. Tuy nhiên, SRI có những hạn chế đáng kể - nó không bao gồm tài liệu HTML chính, yêu cầu quản lý hàm băm thủ công và trở nên không thực tế đối với các ứng dụng lớn, thường xuyên được cập nhật. Một nhà phát triển chỉ ra rằng nếu máy chủ của bạn bị xâm phạm thì mọi thứ đã kết thúc, ngay cả khi nhà xuất bản không có ý định xấu, làm nổi bật cách SRI không giải quyết được kịch bản máy chủ bị xâm phạm gốc rễ.
Cuộc thảo luận tiết lộ những lo ngại sâu sắc hơn về các mô hình cửa hàng ứng dụng hiện có. Như một bình luận viên đã quan sát về Google Play: Tất cả các ứng dụng được tạo từ năm 2021 phải sử dụng Tính năng Ký Ứng dụng Google Play, có nghĩa là Google nắm giữ các khóa được sử dụng để ký ứng dụng. Định dạng Android App Bundle có nghĩa là các phiên bản ứng dụng hoàn toàn khác nhau được phân phối tùy thuộc vào loại thiết bị, vùng, v.v. Có 0 tính minh bạch về điều này cho người dùng cuối. Điều này cho thấy rằng ngay cả việc phân phối ứng dụng gốc cũng có các vấn đề về tính minh bạch cần được giải quyết.
So sánh các Giải pháp Toàn vẹn Web Hiện tại
| Giải pháp | Điểm mạnh | Hạn chế |
|---|---|---|
| Subresource Integrity (SRI) | Tích hợp sẵn trong trình duyệt, triển khai đơn giản | Không bao phủ tài liệu HTML, quản lý hash thủ công |
| App Store Signing | Mô hình đã được chứng minh cho ứng dụng gốc | Khóa do nền tảng kiểm soát, tính minh bạch hạn chế |
| Proposed Integrity Manifests | Bao phủ toàn diện, minh bạch | Triển khai phức tạp, yêu cầu xây dựng mới |
| Content-Addressable Storage | Đảm bảo mật mã hóa, phi tập trung | Không được hỗ trợ nguyên bản, thách thức cập nhật |
 |
|---|
| Biểu diễn trực quan của chuỗi băm thể hiện mối quan hệ giữa các điểm dữ liệu trong bảo mật ứng dụng web |
Cuộc Tranh luận về Tính minh bạch và Ký mã
Một căng thẳng trung tâm trong cuộc thảo luận cộng đồng xoay quanh việc liệu nhật ký minh bạch hay ký mã nên tạo thành nền tảng của bảo mật ứng dụng web. Những người ủng hộ tính minh bạch lập luận rằng nhật ký có thể kiểm tra công khai của tất cả các lần triển khai mã tạo ra một bản ghi không thể đảo ngược có thể phát hiện các vụ xâm phạm, trong khi những người ủng hộ ký mã nhấn mạnh tầm quan trọng của nguồn gốc mật mã. Thực tế có lẽ đòi hỏi cả hai cách tiếp cận phối hợp với nhau.
Một bình luận kỹ thuật đã nêu bật sự phụ thuộc lẫn nhau: Tính minh bạch là điều then chốt, và ký mã cần được xây dựng trên đó. Giả sử bạn có ký mã và không có tính minh bạch. Trang web của bạn có một cách nào đó để báo hiệu cho trình duyệt kiểm tra chữ ký mã dưới một khóa công khai nhất định. Giả sử bây giờ trang web của bạn bị xâm phạm. Điều gì ngăn chặn kẻ tấn công thay đổi khóa công khai và ký lại dưới khóa công khai mới? Thông tin chi tiết này tiết lộ cách tính minh bạch cung cấp nền tảng cần thiết để làm cho việc ký mã có hiệu quả chống lại các vụ xâm phạm máy chủ.
Các Thách thức Triển khai Thực tế
Các nhà phát triển đã nêu lên nhiều mối quan ngại thực tế về việc triển khai các biện pháp bảo mật này. Sự phức tạp của việc tích hợp vào các quy trình xây dựng hiện có, tác động đến hiệu suất và khả năng phá vỡ chức năng trình duyệt hiện có thường xuyên được đề cập. Một nhà phát triển bày tỏ sự hoài nghi về cách tiếp cận dựa trên bản kê khai được đề xuất: Tôi sẽ ghét phải tích hợp điều này vào quy trình xây dựng của mình, cho thấy rằng việc áp dụng sẽ phụ thuộc nhiều vào trải nghiệm của nhà phát triển và các công cụ.
Cuộc thảo luận cũng chạm đến các câu hỏi kiến trúc cơ bản hơn. Như một bình luận viên đã lưu ý: Tại sao phải tạo một bản đồ các hàm băm tương ứng với các url tệp mà con người có thể đọc được, khi chúng ta có thể liên kết trực tiếp đến các hàm băm? Điều này đề cập đến các hệ thống lưu trữ có thể định địa chỉ nội dung như IPFS, gợi ý rằng những thay đổi kiến trúc triệt để hơn có thể cung cấp các giải pháp dài hạn tốt hơn là gắn thêm xác minh tính toàn vẹn vào cơ sở hạ tầng web hiện có.
Con đường Phía trước cho Bảo mật Web
Sự đồng thuận của cộng đồng cho thấy không có một giải pháp duy nhất nào sẽ giải quyết đầy đủ các vấn đề tin cậy của web, mà thay vào đó, một sự kết hợp của các cách tiếp cận sẽ là cần thiết. Nhật ký minh bạch, ký mã, lưu trữ có thể định địa chỉ nội dung và các nguyên thủy bảo mật trình duyệt được cải thiện đều có vai trò của chúng. Điều rõ ràng từ cuộc thảo luận là cái giá phải trả rất cao - khi các ứng dụng web xử lý dữ liệu nhạy cảm ngày càng nhiều, nhu cầu về các cơ chế toàn vẹn mã đáng tin cậy trở nên cấp thiết hơn.
Cộng đồng kỹ thuật dường như thống nhất về tầm quan trọng của việc giải quyết vấn đề này, ngay cả khi tranh luận về các cách tiếp cận cụ thể. Như một nhà phát triển đã tóm tắt: Tính minh bạch nhị phân cho phép bạn lý giải về khả năng kiểm tra của JavaScript đang được phân phối đến trình duyệt web của bạn. Đây là bước quan trọng đầu tiên hướng tới một giải pháp cho bài đăng blog 'JavaScript Cryptography Considered Harmful'. Sự công nhận này rằng chúng ta đang đối phó với một hạn chế kiến trúc cơ bản chứ không phải là một khoảng trống tính năng đơn giản nhấn mạnh lý do tại sao cuộc thảo luận này quan trọng đối với tương lai của bảo mật web.
Kết luận
Cuộc thảo luận sôi nổi xung quanh các tiêu chuẩn toàn vẹn ứng dụng web cho thấy cả tính cấp bách của vấn đề và sự phức tạp của các giải pháp tiềm năng. Trong khi các cuộc tranh luận kỹ thuật tiếp tục về các cách tiếp cận triển khai tốt nhất, có một sự đồng thuận rõ ràng rằng tình hình hiện tại là không thể chấp nhận được đối với các ứng dụng nhạy cảm về bảo mật. Con đường phía trước có thể sẽ liên quan đến các giải pháp kết hợp kết hợp nhật ký minh bạch, ký mật mã và có thể là lưu trữ có thể định địa chỉ nội dung. Điều chắc chắn là khi các ứng dụng web tiếp tục xử lý dữ liệu người dùng ngày càng nhạy cảm, việc thiết lập niềm tin vào mã đang chạy trong trình duyệt của chúng ta sẽ vẫn là một thách thức quan trọng đòi hỏi sự hợp tác liên tục giữa các nhà cung cấp trình duyệt, nhà nghiên cứu bảo mật và nhà phát triển ứng dụng. Sự tham gia của cộng đồng với các đề xuất này chứng minh cả tầm quan trọng của vấn đề và quyết tâm tập thể để tìm ra các giải pháp khả thi.
Tham khảo: Improving the trustworthiness of Javascript on the Web