2011-05-31 39 views
12

Như đã thấy trong GitHub's blog, họ đã triển khai tính năng HTML5's JavaScript pushState để duyệt cây (dành cho trình duyệt hiện đại), mang theo điều hướng AJAX without Hash Bangs.Làm thế nào để pushState bảo vệ chống lại các giả mạo nội dung tiềm năng?

Mã này rất đơn giản:

$('#slider a').click(function() { 
    history.pushState({ path: this.path }, '', this.href) 
    $.get(this.href, function(data) { 
    $('#slider').slideTo(data) 
    }) 
    return false 
}) 

này khá thanh lịch cho phép họ:

  1. Yêu cầu chỉ là nội dung mới thông qua AJAX thay vì một trang đầy đủ
  2. Animate quá trình chuyển đổi
  3. thay đổi URL trình duyệt (không chỉ là #, như Twitter không — twitter.com/stackexchangetwitter.com/#!/stackexchange)

Câu hỏi của tôi là, làm thế nào để ngăn chặn hoạt Javascript chống lại việc sử dụng pushState bởi một trang web bắt chước khác, kết quả là có sức thuyết phục phishing attack?

Ít nhất có vẻ như tên miền không thể thay đổi được, nhưng còn nhiều đường dẫn trong một trang, có thể bởi nhiều nhà cung cấp nội dung không liên quan và không đáng tin cậy thì sao? Có thể một con đường (I.E. /joe) về cơ bản bắt chước một mã khác (pushState /jane) và cung cấp nội dung giả định, với mục đích độc hại không?

Trả lời

9

Sự hiểu biết của tôi là điều này hoàn toàn phù hợp với Same Origin Policy điều chỉnh XMLHttpRequest, đặt cookie và các chức năng khác của trình duyệt. Giả định là nếu nó trên cùng một miền + giao thức + cổng, đó là một nguồn đáng tin cậy. Thông thường, với tư cách là nhà phát triển web, đó là những gì bạn muốn (và cần) để tập lệnh AJAX hoạt động và cookie của bạn có thể đọc được trên toàn bộ trang web của bạn. Nếu bạn đang chạy một trang web nơi người dùng có thể đăng nội dung, đó là công việc của bạn, không phải của trình duyệt, để đảm bảo rằng họ không thể lừa đảo hoặc khóa các khách truy cập của nhau.

Dưới đây là một số chi tiết detail on what the FireFox folks are thinking about pushState - có vẻ như đây không phải là vấn đề đối với họ. Có một cuộc thảo luận khác về một số possible pushState security hole here, nhưng đó là một mối quan tâm khác, về việc có thể ẩn một chuỗi truy vấn độc hại ở cuối URL của người khác.

2

Như nrabinowitz đã tuyên bố và theo nhiều thuật ngữ của giáo dân: nó bị giới hạn ở cùng một miền, giống như cuộc gọi và cookie ajax. Vì vậy, nó hoàn toàn an toàn - mặc dù một chút lén lút cho người dùng cuối.

hệ (nhà phát triển) đã làm điều này mãi mãi với thẻ băm mãi mãi nhưng nó tốt hơn vì:

  1. Có vẻ sạch hơn.
  2. Khi xem lại liên kết sâu, bạn thực sự có thể hiển thị dữ liệu html thực để hỗ trợ những thứ như SEO và Biểu đồ mở của Facebook (cả gửi trình thu thập dữ liệu đến trang html của bạn).
  3. Máy chủ không có quyền truy cập vào dữ liệu thẻ băm, do đó bạn không thấy dữ liệu đó trong nhật ký máy chủ của mình để máy chủ hỗ trợ một số phân tích.
  4. Nó giúp khắc phục các vấn đề về thẻ băm. Ví dụ: tôi đã viết lại Nginx để chuyển hướng người dùng truy cập ứng dụng của tôi đến cùng một url https.Nó hoạt động trong tất cả các trình duyệt nhưng Safari sẽ chuyển hướng bạn đến miền mà không có hàm băm (quá khó chịu!)
Các vấn đề liên quan