CDN an toàn để cung cấp jQuery như thế nào?

Question

Chúng tôi xây dựng các trang web có khu vực công cộng (không bảo mật) và khu vực được bảo mật (được phân phối qua HTTPS) và chúng tôi sử dụng thư viện jQuery.

Gần đây tôi đã đề xuất chúng tôi sử dụng Google CDN để phân phối jQuery. Một số đồng nghiệp của tôi đã bày tỏ lo ngại về khía cạnh bảo mật của cách thức cung cấp các thư viện JavaScript này.

Ví dụ: họ đề cập đến trường hợp một người nào đó có thể chiếm đoạt máy chủ DNS và sau đó tiêm thư viện được sửa đổi độc hại, mở cửa cho các cuộc tấn công bảo mật khác nhau. Bây giờ, nếu hacker có thể tiêm mã độc hại thông qua Google CDN, thì có lẽ anh ta có thể làm tương tự nếu jQuery được phục vụ từ chính trang web đó, đúng không?

Dường như Google CDN hỗ trợ phân phát thư viện qua SSL.

Việc phân phát jQuery từ CDN có thực sự kém an toàn hơn sau đó phân phối nó từ chính máy chủ không? Mối đe dọa này nghiêm trọng như thế nào?

Answer 1

Một cách để giảm thiểu rủi ro là chạy một tổng kiểm tra đối với tệp được lấy từ Google và so sánh số đó với séc kiểm tra đã biết.

Để trả lời câu hỏi về việc liệu Google có thay đổi các tệp này theo bất kỳ cách nào hay không, nhân viên của Google Ben Lisbakken suggested comparing MD5 checksums của một tệp được Google cung cấp cho phiên bản kinh điển của cùng một tệp như được lấy từ trang chủ của người duy trì. Đọc bình luận tám trên trang liên kết cho ngữ cảnh.

Nếu bạn lo lắng về việc tấn công DNS, thì tất nhiên những mối quan tâm tương tự sẽ áp dụng cho tệp như được lấy từ trang web "gốc". Bạn cũng có thể không muốn bị phạt tốc độ khi chạy một kiểm tra đối với tệp jQuery trên mọi yêu cầu - trừ khi bạn vô cùng hoang tưởng. Và tất nhiên, làm như vậy sẽ loại bỏ tất cả các ưu điểm của việc sử dụng CDN.

Nhưng giả sử bạn chỉ hơi hoang tưởng, bạn có thể thử một cái gì đó như thế này:

• Hãy chắc chắn rằng bạn đang tham khảo một phiên bản độc đáo và cụ thể của tập tin jQuery từ Google. Ví dụ, làm điều này:

  http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js 
  

  và không này:

  http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js 
  

  Phiên bản thứ hai có thể trở lại 1.4.2 bây giờ, nhưng 1.4.3 vào ngày mai.Nếu bạn có một sự kết hợp của http và https nhu cầu, bạn có thể sử dụng các URL giao thức tương đối, như thế này:

  //ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js 
  

• Ban đầu tạo và lưu trữ checksum của riêng bạn cho tập tin này.

• Định kỳ lặp lại quy trình và đảm bảo rằng tổng kiểm tra mới khớp với quy trình cũ. Nếu không, hãy nghe klaxon.

Bạn có thể làm điều này theo lập trình, tất nhiên. Bạn quyết định khoảng thời gian nào có ý nghĩa. Mỗi phút? Mỗi năm? Bây giờ bạn có thể tạo ra một công tắc giết người tự động có độ nhạy bạn có thể điều chỉnh theo sở thích của bạn. Các "màn hình" thường xuyên chắc chắn không phải chạy đồng bộ trong ứng dụng mà bạn đang tìm kiếm để bảo đảm; có lẽ bạn chạy một ứng dụng tiện ích nhỏ trên cùng một máy chủ chỉ cho mục đích này.

Thật dễ dàng để kiểm tra: chỉ cần thay đổi băm được lưu trữ. Vì bạn đang tham chiếu một phiên bản tệp cụ thể, nút hoảng loạn sẽ không được nhấn với mọi cập nhật phiên bản nhỏ. Khi bạn muốn chuyển sang phiên bản mới của jQuery, hãy thay đổi URL AJAX API trên trang web của bạn và lưu trữ băm mới.

Answer 2

Khi đồng nghiệp của bạn chỉ ra, việc chiếm đoạt máy chủ DNS sẽ là vấn đề ở đây. Nó sẽ không được nếu bạn phục vụ các thư viện từ cùng một máy chủ như trang web của bạn. Tuy nhiên, nếu một người sử dụng HTTPS, có khả năng kẻ tấn công sẽ không có chứng chỉ hợp lệ trên trang web giả mạo. Tôi không biết các trình duyệt sẽ phản ứng như thế nào, nhưng tôi nghi ngờ họ sẽ gắn cờ trang web là không an toàn (vì một số phần của trang web không thể tin cậy) và hành động tương ứng.

Vì vậy, trong ngắn hạn; nếu CDN cũng được truy cập bằng HTTPS, sẽ không có rủi ro lớn.

Chỉnh sửa: Đồng thời xem xét vấn đề bảo mật được đề cập bởi Gert G.

Answer 3

Nếu niềm tin tồn tại trực tuyến sau đó Google là đáng tin cậy nhất ...

Không có nghi ngờ rằng Google CDN là an toàn, nhưng vấn đề luôn luôn đến từ kết nối Internet chất lượng/máy chủ của người dùng. Bằng cách này, nếu bạn bao gồm thư viện jQuery với tập lệnh trình tải API của Google, Google sẽ thêm một số mã theo dõi nhỏ vào thư viện JavaScript có sẵn của CDN (về + 4kb, xem trong Firebug) để giảm thiểu 20kb và nén Thư viện jQuery hơi nặng, cộng với tốc độ SSL dự kiến.

Dù sao Giảm bớt/nén/bộ nhớ đệm jQuery không phải là một vấn đề những ngày này, tôi đề nghị làm của riêng bạn ...

Answer 4

Được phục vụ jQuery từ CDN thực sự kém an toàn sau đó phục vụ nó từ máy chủ riêng của mình?

Có. Nếu đó là tài nguyên bên ngoài, thì luôn kém an toàn hơn. Làm thế nào bạn có thể chắc chắn rằng bạn biết những gì khách hàng của bạn đang thực sự nhận được nếu bạn không sở hữu mã nguồn? Và nếu bạn không quen thuộc với CloudBleed, bạn có thể muốn đọc trước khi tiếp tục.

Nếu bạn cần tải jQuery từ CDN bên ngoài vì lý do hiệu suất, hãy đảm bảo bạn đang sử dụng Tính toàn vẹn nguồn cấp dữ liệu. Thông tin thêm về SRI can be located trên MDN.

Cuối cùng, nếu tải jQuery một cách an toàn thông qua CDN là một mối quan tâm do hiệu suất trang web và tạo ra một Điểm không duy nhất (và nó sẽ là mối quan tâm nếu bạn quen thuộc với công việc của Steve Souders), bạn gần như chắc chắn tốt hơn từ một quan điểm an ninh và hiệu suất di chuyển tất cả các kịch bản của bạn trong nhà và tải chúng không đồng bộ song song bằng cách sử dụng Fetch Injection. Chỉ cần chắc chắn, nếu bạn làm, bạn đang tích cực trình duyệt bộ nhớ đệm. Và nếu bạn phục vụ khán giả toàn cầu, hãy đảm bảo rằng bạn đang cạnh bộ nhớ đệm những nội dung đó.