Công cụ dành cho nhà phát triển · Máy tính hàm băm SHA
Tính toàn vẹn của nguồn phụ: Cách trình duyệt sử dụng SHA-384 để kiểm tra tập lệnh
· Lý lịch
sha-256 base64 browser-apis bảo vệ
Thuộc tính toàn vẹn cho phép trình duyệt từ chối tập lệnh CDN có byte đã thay đổi. Bài đăng này giải thích định dạng của thuộc tính, tại sao SHA-384 trong base64 là lựa chọn phổ biến và những gì SRI không thể bảo vệ.
CDN có thể phục vụ mọi thứ — rủi ro chuỗi cung ứng SRI được thiết kế cho
Thẻ tập lệnh trên trang web có thể mang thuộc tính toàn vẹn: `<script src="https://cdn.example.com/lib.js" integrity="sha384-..."></script>`. Giá trị toàn vẹn là bản tóm tắt mật mã của các byte của tập lệnh. Khi trình duyệt tải xuống tập lệnh, nó sẽ tính toán tổng hợp các byte nhận được và so sánh với thuộc tính toàn vẹn. Nếu chúng khớp nhau thì tập lệnh sẽ được tải. Nếu chúng không khớp, trình duyệt sẽ từ chối tải nó và báo lỗi trong bảng điều khiển. Điều này bảo vệ khỏi việc CDN cung cấp mã đã sửa đổi bị xâm phạm hoặc chống lại kẻ tấn công mạng chặn và thay đổi phản hồi.
Tính toàn vẹn của nguồn phụ (SRI) là đặc tả W3C áp dụng cho tập lệnh và biểu định kiểu. Đây là sự đảm bảo bằng mật mã duy nhất mà trình duyệt có thể thực hiện về nội dung của tài nguyên có nguồn gốc chéo: các byte phải khớp với thông báo hoặc tài nguyên sẽ bị từ chối. Điều này không chứng minh được ai đã tạo ra tài nguyên, chỉ có điều nó không thay đổi kể từ khi tính toán thông báo. Đối với tài nguyên được cung cấp trên HTTPS từ CDN có uy tín, thông báo cung cấp biện pháp bảo vệ khỏi việc CDN bị xâm phạm hoặc phân phối cụ thể nội dung đã lưu trong bộ nhớ đệm cũ cho bạn.
Thuộc tính toàn vẹn - tiền tố thuật toán, dấu gạch nối, thông báo base64 và hỗ trợ nhiều hàm băm
Thuộc tính toàn vẹn có định dạng cụ thể: tên thuật toán, dấu gạch nối, thông báo trong base64. Ví dụ: `integrity="sha384-JZDdQnrrAMe+sxxpn47in+PwhkxrCrt4SNvt+xWqV3zPJUkeFF0Qq/wNtuvNqPP5"`. Tên thuật toán có thể là SHA-256, SHA-384 hoặc SHA-512. Base64 là mã hóa, không phải thập lục phân; đây là sự lựa chọn có chủ ý theo đặc tả SRI. Base64 nhỏ gọn hơn hex (ngắn hơn khoảng 33% cho cùng một thông báo), điều này quan trọng khi nhúng vào các thuộc tính HTML. Dấu gạch nối tách tên thuật toán khỏi thông báo. Nhiều giá trị toàn vẹn có thể được liệt kê, phân tách bằng dấu cách: nếu bất kỳ giá trị nào trong số chúng khớp nhau thì tài nguyên sẽ được chấp nhận.
Tại sao SHA-384? Thông số SRI cho phép SHA-256, SHA-384 và SHA-512. SHA-384 đã trở thành mặc định của cộng đồng vì nó cung cấp số dư size/security. SHA-256 nhỏ hơn (32 bytes, 44 ký tự trong base64) nhưng SHA-384 rộng hơn (48 bytes, 64 ký tự trong base64) và không tăng kích thước thuộc tính một cách đáng kể so với SHA-256. SHA-512 có sẵn nhưng hiếm khi được sử dụng vì thông báo lớn hơn của nó dường như không cần thiết cho trường hợp sử dụng này. Lựa chọn SHA-384 mang tính lịch sử và thực dụng, không phản ánh các đặc tính bảo mật vượt trội (cả ba đều mạnh về mặt mật mã cho mục đích này).
SHA-384 được cung cấp và sản xuất vật liệu base64 theo yêu cầu; ưu tiên của cộng đồng không được suy ra từ công cụ
Mã hóa Base64 trong SRI là base64 tiêu chuẩn, không phải base64url. Base64 tiêu chuẩn sử dụng các ký tự + và /, hợp lệ trong các thuộc tính HTML mà không cần mã hóa phần trăm, mặc dù chúng có ý nghĩa đặc biệt trong URL và dữ liệu biểu mẫu. Định dạng SRI được thiết kế cho các thuộc tính HTML chứ không phải URL, vì vậy base64 tiêu chuẩn là phù hợp. Nếu bạn đang xây dựng một giá trị toàn vẹn bằng tay, bạn tính toán thông báo SHA-384 (một chuỗi byte), sau đó mã hóa các byte đó thành base64 tiêu chuẩn, sau đó thêm `sha384-` vào trước và dán vào thuộc tính toàn vẹn.
Trình duyệt thực hiện các bước ngược lại tương tự: trích xuất base64 từ thuộc tính tính toàn vẹn, giải mã thành byte để khôi phục thông báo tóm tắt, tính toán SHA-384 của các byte tập lệnh đã tải xuống và so sánh hai giá trị thông báo. Chúng phải khớp chính xác; sự khác biệt một bit trong bản tóm tắt sẽ gây ra sự từ chối. Không có sự khớp mờ hoặc tín dụng một phần: tính toàn vẹn là nhị phân.
Hành vi SRI có nguồn gốc chéo yêu cầu tài liệu trình duyệt ngoài công cụ tính hàm băm này
SRI yêu cầu CORS trên các phản hồi có nguồn gốc chéo. Nếu bạn tải tập lệnh từ nguồn khác, máy chủ phải phản hồi bằng `Access-Control-Allow-Origin: *` hoặc tiêu đề nguồn cụ thể bao gồm tiêu đề của bạn. Nếu không có tiêu đề CORS, trình duyệt không thể kiểm tra SRI, vì nếu không có CORS, trình duyệt không thể xác nhận rằng nội dung phản hồi khớp với nội dung mà máy chủ dự định gửi. Tiêu đề CORS là tuyên bố của máy chủ rằng phản hồi này an toàn để kiểm tra; SRI là kiểm tra của bạn xem các byte có đúng không. Cùng nhau, chúng tạo thành một cam kết về chuỗi cung ứng: máy chủ cho phép bạn xác minh nội dung và bạn cũng làm như vậy.
Nếu tập lệnh nhiều nguồn gốc thiếu tiêu đề CORS và có thuộc tính toàn vẹn thì trình duyệt sẽ tải xuống tập lệnh đó (nếu tập lệnh từ nguồn đó được CSP của trang web cho phép), nhưng nó sẽ không xác minh tính toàn vẹn. Tập lệnh sẽ được tải như thể không có thuộc tính toàn vẹn. Đây không phải là lỗi của SRI; đó là ranh giới bảo mật: bạn không thể xác minh phản hồi mà bạn không thể đọc được.
Điều gì xảy ra khi không khớp — trình duyệt chặn tài nguyên và báo cáo trong bảng điều khiển
Khi trình duyệt phát hiện sự không khớp về tính toàn vẹn, nó sẽ từ chối thực thi tập lệnh và ghi thông báo vào bảng điều khiển trình duyệt. Thông báo thường đặt tên cho URL, hàm băm dự kiến và hàm băm được tính toán. Lỗi mang tính nguyên tử: tài nguyên được tải nguyên trạng hoặc bị từ chối hoàn toàn. Không có tải một phần hoặc dự phòng. Nếu một trang web dựa vào tập lệnh đó và bị từ chối thì trang web đó có thể bị hỏng. Điều này là có chủ ý: việc cung cấp sai mã còn tệ hơn việc không cung cấp mã và các lỗi thầm lặng khiến các cuộc tấn công tồn tại vô thời hạn.
Việc kiểm tra thiết lập SRI rất đơn giản: mở bảng điều khiển của trình duyệt, tải trang và tìm thông báo về sự không khớp về tính toàn vẹn. Nếu bạn thấy không khớp, hãy so sánh hàm băm được tính toán hiển thị trong bảng điều khiển với hàm băm trong thuộc tính tính toàn vẹn của bạn. Nếu chúng không khớp, hãy tính toán lại: tập lệnh có thể đã được cập nhật và bạn cần một bản tóm tắt mới.
Ví dụ đã hoạt động - tính toán thông báo cho tập lệnh và định dạng tập lệnh đó thành giá trị toàn vẹn, bao gồm bước base64
Việc tính toán thông báo SRI theo cách thủ công chỉ yêu cầu byte tập lệnh và công cụ băm. Tải xuống tập lệnh, dán tập lệnh vào máy tính băm ToolAcre SHA, chọn SHA-384, sao chép đầu ra base64 (không phải hex), thêm `sha384-` vào trước và dán vào thuộc tính tính toàn vẹn. Nếu script có dung lượng lớn thì dùng Curl hoặc wget để lưu vào tệp rồi đọc tệp sẽ nhanh hơn là dán. Đối với các tập lệnh nội tuyến (trong thẻ `<script>` trong HTML thay vì từ URL), SRI không áp dụng được; các tập lệnh nội tuyến luôn được tin cậy theo định nghĩa. SRI dành cho tài nguyên bên ngoài.
Một ví dụ hoạt động: giả sử bạn muốn tải jQuery từ CDN bằng SRI. Tìm tập lệnh URL, tải xuống (hoặc sử dụng cuộn tròn để tìm nạp), dán byte vào máy tính hoặc sử dụng `sha384sum` trên dòng lệnh, lấy thông báo SHA-384 làm cơ sở64 và định dạng là `sha384-[base64-digest]`. Dán vào thuộc tính toàn vẹn của thẻ script. Tải trang và xác minh không có lỗi bảng điều khiển nào xuất hiện.
Điều này không bao gồm những gì — các tập lệnh thay đổi có chủ ý và các trang web như ToolAcre không tải tập lệnh bên ngoài nào cả và do đó không có gì để ghim
SRI không bảo vệ khỏi tất cả các cuộc tấn công vào chuỗi cung ứng. Nó bảo vệ chống lại sự thay đổi byte sau khi tính toán thông báo, nhưng không chống lại việc thông báo được tính toán từ mã bị xâm phạm ngay từ đầu. Nếu CDN bị xâm phạm trước khi bạn tính toán thông báo, SRI không thể giúp được gì. Bản tóm tắt chỉ đáng tin cậy như nguồn mà bạn tính toán nó. Để đảm bảo tối đa, hãy tính toán các thông báo từ nguồn ban đầu (ví dụ: bản phát hành GitHub của thư viện) và sử dụng các thông báo đó khi tải từ CDN. Bản tóm tắt trở thành một cam kết từ người bảo trì thông qua quá trình phát hành.
SRI cũng không bảo vệ chống lại mạng bị xâm phạm tại thời điểm bạn tính toán thông báo hoặc chống lại máy phát triển bị xâm phạm. Nó chỉ bảo vệ chống lại những thay đổi đối với tập lệnh trong khoảng thời gian từ khi thông báo được tạo cho đến khi trình duyệt tải tập lệnh. Để đảm bảo liên tục, một số hoạt động triển khai sử dụng tính năng ký phát hành ngoài SRI: bản phát hành được ký bằng khóa của người bảo trì, bạn xác minh chữ ký, tính toán thông báo từ các byte đã được xác minh và sử dụng thông báo đó trong SRI.
Bài viết này không khẳng định khoảng không quảng cáo tập lệnh bên ngoài trên toàn trang web của ToolAcre từ các nguồn băm
Máy tính băm ToolAcre SHA phát ra trực tiếp thông báo trong base64 tiêu chuẩn (dưới dạng đầu ra `base64` từ hàm `toBase64()`). Để chuyển đổi sang định dạng SRI, hãy thêm tên thuật toán và dấu gạch nối: `sha256-`, `sha384-` hoặc `sha512-`. Máy tính không tự động áp dụng tiền tố đó vì hàm băm xuất hiện trong nhiều ngữ cảnh (git, Docker, npm, URL) trong đó tên thuật toán tách biệt hoặc được mã hóa khác nhau. Ranh giới rất rõ ràng: máy tính băm văn bản UTF-8 mà bạn dán chứ không phải tệp hoặc khóa nhị phân. Nó xuất ra cả hex và base64. Bạn chọn sử dụng dựa trên ngữ cảnh của bạn. Đối với SRI, thông số kỹ thuật yêu cầu base64. Đối với git và các công cụ khác, hex là thông thường. Đối với npm và Go, base64 được sử dụng. Lựa chọn mã hóa là của bạn; các byte thông báo giống nhau.
SRI vẫn là một trong số ít hoạt động kiểm tra mật mã mà trình duyệt có thể thực hiện phía máy khách mà không cần có cơ quan tập trung. Máy tính tự phân tích bằng một công cụ đáng tin cậy như máy tính SHA của ToolAcre và xác minh chúng dựa trên các tài nguyên đã tải là một cách dễ tiếp cận để tăng cường trang web trước các cuộc tấn công chuỗi cung ứng nhất định. Việc bảo vệ chỉ tốt như việc tiêu hóa; tính toán lại sau mỗi lần cập nhật tài nguyên bên ngoài và kiểm tra xem trình duyệt có tải tập lệnh mà không từ chối nó hay không.