Rủi ro bảo mật Javascript?

Question

Những rủi ro khi sử dụng Javascript là gì và cách tránh chúng?

Answer 1

Một trong những lỗi phổ biến nhất là HTML injection, cho phép các bên thứ ba chèn JavaScript vào ngữ cảnh bảo mật của bạn. Điều đó cho phép kẻ tấn công kiểm soát những gì người dùng thực hiện trên trang web của bạn, hoàn toàn phá vỡ bảo mật tài khoản.

Mặc dù đã có một số tiến trình chậm cố gắng để các tác giả web nhớ các chuỗi mã hóa HTML chúng xuất ra các trang web ở phía máy chủ (ví dụ: htmlspecialchars trong PHP), một thế hệ webapps mới đang sử dụng cùng một chuỗi câm -concatenation hacks để tạo ra nội dung ở phía máy khách sử dụng JavaScript:

somediv.innerHTML= '<p>Hello, '+name+'</p>'; 

thường sử dụng jQuery:

$('table').append('<tr title="'+row.title+'"><td>'+row.description+'</td></tr>'); 

Đây chỉ là dễ bị tổn thương như tiêm HTML server-side và tác giả thực sự cần phải dừng lại buildin g nội dung theo cách này. Bạn có thể nội dung văn bản HTML mã hóa ở phía khách hàng, nhưng vì JS không có một built-in HTML encoder bạn phải làm điều đó cho mình:

function encodeHTML(s) { 
    return s.replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/"/g, '&quot;'); 
} 

somediv.innerHTML= '<p>Hello, '+encodeHTML(name)+'</p>'; 

Tuy nhiên nó thường là tốt hơn để sử dụng các phương pháp DOM sẵn có và tài sản mà lọai trừ nhu cầu cho thoát:

var p= document.createElement('p'); 
p.appendChild(document.createTextNode('Hello, '+name); 

và với jQuery sử dụng attr(), text() và tạo ra các phím tắt:

$('table').append(
    $('<tr>', {title: row.title}).append(
     $('<td>', {text: row.description}) 
    ) 
); 

Answer 2

Javascript chạy ở phía máy khách để rủi ro lớn nhất là cho khách hàng. Ví dụ về rủi ro là cookie của họ có thể bị đánh cắp để người dùng khác có thể mạo danh họ. Phương pháp tấn công phổ biến là inject Javascript vào trang thông qua gửi biểu mẫu. Để ngăn chặn điều này, bạn nên đảm bảo rằng bạn luôn thoát đúng cách đầu ra HTML.

Bảo mật bên máy chủ của bạn phải không phải phụ thuộc vào tính bảo mật của Javascript. Bạn nên giả định rằng kẻ tấn công của bạn có thể và sẽ thay đổi HTML/CSS/Javascript trên các trang của bạn để cố gắng xem thông tin không hiển thị bình thường và họ sẽ gửi dữ liệu đến máy chủ của bạn mà không thể gửi qua giao diện bình thường . Để bảo vệ chống lại điều này, bạn nên luôn luôn xác nhận tất cả các đầu vào của người dùng - coi đó là dữ liệu hoàn toàn không đáng tin cậy. Đừng dựa vào các giả định về nội dung mà người dùng của bạn sẽ gửi cho bạn - luôn kiểm tra rõ ràng các giả định bạn yêu cầu là đúng sự thật.

Answer 3

Không có rủi ro. Chỉ có thể có lỗi của lập trình viên. Một lỗi mà tôi có thể nghĩ đến là quên các tham số mã hóa url được gửi đến máy chủ và nó nhận được các giá trị sai. Nhưng rủi ro bảo mật thực sự là ở mã phía máy chủ, chứ không phải javascript.

Answer 4

Johann-Peter Hartmann gần đây đã tổ chức một buổi nói chuyện tuyệt vời về bảo mật Javascript. Đó là một chủ đề nóng thực sự, đặc biệt là kể từ khi các ứng dụng đơn trang đang trở nên phổ biến hơn. Xem các trang trình bày của anh ấy tại slideshare. Các trang trình bày bằng tiếng Đức - theo như tôi biết chưa có bản dịch tiếng Anh nào.