Tại sao Google trả trước while(1);các phản hồi JSON (riêng tư) của họ?

Ví dụ: đây là phản hồi trong khi bật và tắt lịch trong Lịch Google :

while (1);
[
  ['u', [
    ['smsSentFlag', 'false'],
    ['hideInvitations', 'false'],
    ['remindOnRespondedEventsOnly', 'true'],
    ['hideInvitations_remindOnRespondedEventsOnly', 'false_true'],
    ['Calendar ID stripped for privacy', 'false'],
    ['smsVerifiedFlag', 'true']
  ]]
]

Tôi cho rằng điều này là để ngăn mọi người thực hiện eval()nó, nhưng tất cả những gì bạn thực sự phải làm là thay thế whilevà sau đó bạn sẽ được thiết lập. Tôi cho rằng phòng ngừa tệ nạn là đảm bảo mọi người viết mã phân tích cú pháp JSON an toàn.

Tôi cũng đã thấy điều này được sử dụng ở một vài nơi khác, nhưng với Google (Thư, Lịch, Danh bạ, v.v.) Thật kỳ lạ, thay vào đó, Google Docs bắt đầu bằng &&&START&&&và Liên hệ Google dường như bắt đầu bằng while(1); &&&START&&&.

Những gì đang xảy ra ở đây?

Nó ngăn chặn việc chiếm quyền điều khiển JSON , một vấn đề bảo mật JSON chính được khắc phục chính thức trong tất cả các trình duyệt chính kể từ năm 2011 với ECMAScript 5.

Ví dụ có thể xảy ra: giả sử Google có một URL giống như mail.google.com/json?action=inboxtrả về 50 tin nhắn đầu tiên trong hộp thư đến của bạn ở định dạng JSON. Các trang web độc ác trên các tên miền khác không thể thực hiện các yêu cầu AJAX để có được dữ liệu này do chính sách cùng nguồn gốc, nhưng chúng có thể bao gồm URL thông qua <script>thẻ. URL được truy cập bằng cookie của bạn và bằng cách ghi đè phương thức trình tạo hoặc trình truy cập mảng toàn cục, họ có thể có một phương thức được gọi bất cứ khi nào thuộc tính đối tượng (mảng hoặc hàm băm) được đặt, cho phép chúng đọc nội dung JSON.

Các while(1);hoặc &&&BLAH&&&ngăn chặn điều này: một yêu cầu AJAX tại mail.google.comsẽ có quyền truy cập đầy đủ đến nội dung văn bản, và có thể tước nó đi. Nhưng <script>việc chèn thẻ thực thi JavaScript một cách mù quáng mà không xử lý, dẫn đến một vòng lặp vô hạn hoặc lỗi cú pháp.

Điều này không giải quyết vấn đề giả mạo yêu cầu chéo trang web .

Nó ngăn tiết lộ phản hồi thông qua việc chiếm quyền điều khiển JSON.

Về lý thuyết, nội dung của các phản hồi HTTP được bảo vệ bởi Chính sách nguồn gốc giống nhau: các trang từ một tên miền không thể nhận được bất kỳ mẩu thông tin nào từ các trang trên tên miền khác (trừ khi được cho phép rõ ràng).

Kẻ tấn công có thể yêu cầu các trang trên các tên miền khác thay mặt bạn, ví dụ: bằng cách sử dụng một <script src=...>hoặc<img> thẻ thẻ, nhưng nó không thể nhận được bất kỳ thông tin nào về kết quả (tiêu đề, nội dung).

Do đó, nếu bạn truy cập trang của kẻ tấn công, nó không thể đọc email của bạn từ gmail.com.

Ngoại trừ khi sử dụng thẻ script để yêu cầu nội dung JSON, JSON được thực thi dưới dạng Javascript trong môi trường do kẻ tấn công kiểm soát. Nếu kẻ tấn công có thể thay thế hàm tạo Array hoặc Object hoặc một số phương thức khác được sử dụng trong quá trình xây dựng đối tượng, mọi thứ trong JSON sẽ chuyển qua mã của kẻ tấn công và được tiết lộ.

Lưu ý rằng điều này xảy ra tại thời điểm JSON được thực thi dưới dạng Javascript, chứ không phải tại thời điểm nó được phân tích cú pháp.

Có nhiều biện pháp đối phó:

Đảm bảo JSON không bao giờ thực thi

Bằng cách đặt một while(1);câu lệnh trước dữ liệu JSON, Google đảm bảo rằng dữ liệu JSON không bao giờ được thực thi dưới dạng Javascript.

Chỉ một trang hợp pháp mới có thể lấy toàn bộ nội dung, loại bỏ while(1);và phân tích phần còn lại dưới dạng JSON.

Những điều như for(;;);đã được nhìn thấy tại Facebook chẳng hạn, với kết quả tương tự.

Đảm bảo JSON không hợp lệ Javascript

Tương tự, việc thêm các mã thông báo không hợp lệ trước JSON, như &&&START&&&, đảm bảo rằng nó không bao giờ được thực thi.

Luôn trả lại JSON với một đối tượng ở bên ngoài

Đây là OWASPcách được khuyến nghị để bảo vệ khỏi việc chiếm quyền điều khiển JSON và là cách ít xâm phạm hơn.

Tương tự như các biện pháp đối phó trước đây, nó đảm bảo rằng JSON không bao giờ được thực thi dưới dạng Javascript.

Một đối tượng JSON hợp lệ, khi không được bao quanh bởi bất kỳ thứ gì, không hợp lệ trong Javascript:

eval('{"foo":"bar"}')
// SyntaxError: Unexpected token :

Tuy nhiên, đây là JSON hợp lệ:

JSON.parse('{"foo":"bar"}')
// Object {foo: "bar"}

Vì vậy, hãy đảm bảo bạn luôn trả về một Đối tượng ở mức cao nhất của phản hồi, đảm bảo rằng JSON không phải là Javascript hợp lệ, trong khi vẫn là JSON hợp lệ.

Theo ghi nhận của @hvd trong các bình luận, đối tượng trống {}là Javascript hợp lệ và việc biết đối tượng trống có thể là thông tin có giá trị.

So sánh các phương pháp trên

Cách OWASP ít xâm phạm hơn, vì nó không cần thay đổi thư viện khách và chuyển JSON hợp lệ. Tuy nhiên, không chắc là các lỗi trình duyệt trong quá khứ hay tương lai có thể đánh bại điều này hay không. Theo ghi nhận của @oriadam, không rõ liệu dữ liệu có thể bị rò rỉ trong lỗi phân tích cú pháp thông qua xử lý lỗi hay không (ví dụ: window.onerror).

Cách của Google yêu cầu thư viện máy khách hỗ trợ thư viện tự động hóa và có thể được coi là an toàn hơn đối với các lỗi trình duyệt.

Cả hai phương pháp đều yêu cầu thay đổi phía máy chủ để tránh các nhà phát triển vô tình gửi JSON dễ bị tổn thương.

Điều này là để đảm bảo một số trang web khác không thể thực hiện các thủ đoạn khó chịu để cố lấy cắp dữ liệu của bạn. Ví dụ: bằng cách thay thế hàm tạo mảng , sau đó bao gồm URL JSON này thông qua <script>thẻ, trang web bên thứ ba độc hại có thể đánh cắp dữ liệu từ phản hồi JSON. Bằng cách đặt một while(1);ở đầu, kịch bản sẽ treo thay thế.

Mặt khác, một yêu cầu cùng trang web sử dụng XHR và một trình phân tích cú pháp JSON riêng biệt, có thể dễ dàng bỏ qua while(1);tiền tố.

Điều đó sẽ gây khó khăn cho bên thứ ba khi chèn phản hồi JSON vào tài liệu HTML bằng <script>thẻ. Hãy nhớ rằng <script>thẻ được miễn từ Chính sách xuất xứ tương tự .

Lưu ý : kể từ năm 2019, nhiều lỗ hổng cũ dẫn đến các biện pháp phòng ngừa được thảo luận trong câu hỏi này không còn là vấn đề trong các trình duyệt hiện đại. Tôi sẽ để lại câu trả lời dưới đây như một sự tò mò lịch sử, nhưng thực sự toàn bộ chủ đề đã thay đổi hoàn toàn kể từ năm 2010 (!!) khi điều này được hỏi.

Nó ngăn không cho nó được sử dụng làm mục tiêu của một <script>thẻ đơn giản . (Chà, điều đó không ngăn cản được, nhưng điều đó làm cho nó khó chịu.) Theo cách đó, những kẻ xấu không thể đặt thẻ script đó vào trang web của riêng chúng và dựa vào một phiên hoạt động để có thể tìm nạp nội dung của bạn.

chỉnh sửa - lưu ý nhận xét (và các câu trả lời khác). Vấn đề này đã làm với lật đổ được xây dựng cơ sở vật chất, đặc biệt là Objectvà Arraynhà xây dựng. Chúng có thể được thay đổi sao cho JSON vô hại, khi được phân tích cú pháp, có thể kích hoạt mã kẻ tấn công.

Do <script>thẻ được miễn trừ khỏi Chính sách xuất xứ tương tự, đây là một điều cần thiết về bảo mật trong thế giới web, nên while(1)khi được thêm vào phản hồi JSON sẽ ngăn chặn việc sử dụng sai mục đích trong <script>thẻ.

Sau khi xác thực được thực hiện, bảo vệ chiếm quyền điều khiển JSON có thể có nhiều dạng khác nhau. Google nối thêm (1) vào dữ liệu JSON của họ, để nếu có bất kỳ tập lệnh độc hại nào đánh giá nó, tập lệnh độc hại sẽ đi vào một vòng lặp vô hạn.

Tham khảo: Sách dạy thử nghiệm bảo mật web: Các kỹ thuật có hệ thống để tìm ra vấn đề nhanh