it-swarm-vi.com

Làm thế nào để quét Javascript cho mã độc?

Chúng tôi dự định cung cấp khả năng viết các tiện ích mở rộng dựa vào cộng đồng trong javascript cho ứng dụng web công cộng của chúng tôi và cho phép mọi người tùy chỉnh các phiên bản ứng dụng của họ. Vấn đề là giám sát chất lượng của các phần mở rộng.

Bạn muốn đề xuất gì để tự động hóa quá trình này?

Hoặc làm thế nào để quét Javascript cho mã độc?

Trong một vài từ, chúng tôi muốn có một số dịch vụ như phần mềm chống vi-rút sẽ quét trong các tiện ích mở rộng được tải lên trong thời gian thực vì độc hại. Và nếu nó phát hiện bất kỳ mã nghi ngờ nào, nó sẽ tạo ra một cảnh báo.

Bất kỳ gợi ý/lời khuyên đều được chào đón! Cảm ơn bạn.

22
Igor

Một cách tiếp cận sẽ là xác định API an toàn cho các tiện ích mở rộng để sử dụng, bằng cách khai báo các đối tượng triển khai API đó trong phạm vi thực thi cho tiện ích mở rộng. Sau đó, yêu cầu mã mở rộng phải được viết bằng phiên bản Javascript có hộp cát, vì vậy mã mở rộng chỉ có thể gọi các phương thức API an toàn mà bạn đã xác định và không có gì khác.

Vì vậy, nếu API của bạn bao gồm một đối tượng được lưu trữ trong một biến api, thì mã:

var x = api.frob();
x.bar();

sẽ được phép mở rộng mã, bởi vì api là một phần của API an toàn của bạn và các biến thể Javascript an toàn cho phép bạn gọi API tiếp xúc với mã mở rộng.

Tuy nhiên, mã:

document.createElement("img");

sẽ không được phép, vì document không phải là một phần của API an toàn của bạn.

Khi thiết kế API, đảm bảo rằng không có đối tượng bị lộ nào có các thuộc tính có thể được sử dụng độc hại. Để cung cấp quyền truy cập hạn chế vào tài nguyên, hãy sử dụng các bao đóng để tạo các hàm tham chiếu riêng tài nguyên đó.

Có một số dự án ngoài đó đã xác định phiên bản Javascript có hộp cát mà bạn có thể sử dụng cho mục đích này: SES , Caja , ADsafe , FBJS và những người khác. SES và Caja cho phép các nhà phát triển viết mã với ít hạn chế nhất: cảm giác rất giống với việc viết Javascript, với một vài hạn chế nhỏ (ví dụ: không eval, không with). ADsafe và FBJS yêu cầu nhà phát triển tìm hiểu một biến thể của Javascript. SES, ADsafe và FBJS có hiệu suất tốt nhất. SES yêu cầu hỗ trợ từ một công cụ Javascript rất gần đây và do đó không tương thích với một số trình duyệt web cũ hơn. Nếu mã mở rộng sẽ được thực thi ở phía máy chủ, thì SES có thể là lựa chọn tốt nhất, bởi vì bạn có thể đảm bảo công cụ Javascript của mình được cập nhật. Nếu tiện ích mở rộng sẽ được thực thi trên trình duyệt của người dùng, bạn có thể xem xét Caja nếu tiện ích mở rộng không quan trọng về hiệu năng hoặc ADsafe/FBJS nếu có.

9
JGWeissman

Không có cách nào tốt để quét Javascript cho mã độc. Bạn không thể làm điều đó. Vấn đề là có quá nhiều cách mà một nhà phát triển độc hại/lừa đảo có thể che giấu những thứ độc hại trong mã của họ và bạn sẽ không bao giờ có thể phát hiện ra tất cả.

Chống vi-rút không hữu ích ở đây. Bạn cần hiểu một chút về cách thức hoạt động của phần mềm chống vi-rút và những hạn chế của nó. Nói một cách đơn giản, đây là cách nó hoạt động. Nếu công ty chống vi-rút phát hiện vi-rút lây nhiễm nhiều máy, sau đó họ phân tích vi-rút, xác định chữ ký của vi-rút (ví dụ: đoạn trích mã của nó) và xây dựng phần mềm này vào động cơ của họ. Sau đó, nếu máy của bạn bị nhiễm một bản sao của bản sao cụ thể đó (chính xác là bản mà họ đã phân tích), thì phần mềm chống vi-rút sẽ phát hiện sự hiện diện của nó thông qua chữ ký này. Do đó, phần mềm chống vi-rút rất hữu ích chủ yếu chỉ chống lại vi-rút đã lan truyền rộng rãi. Phần mềm chống vi-rút hiện tại sẽ không phát hiện mã độc trong tiện ích mở rộng giả mạo cho ứng dụng web của bạn. Phần mềm chống vi-rút có một số cách sử dụng, nhưng về cơ bản nó vô dụng đối với kịch bản cụ thể của bạn.

Bạn cần chấp nhận rằng đây không phải là vấn đề bạn có thể giải quyết bằng cách quét mã. Vì vậy, bạn sẽ cần xem xét một số phương pháp khác. Lựa chọn của bạn là gì? Có một số:

  • Bạn có thể từ bỏ và nắm lấy sự hỗn loạn. Bạn có thể tạo một trang web công khai cho tiện ích mở rộng, cho phép người dùng xếp hạng tiện ích mở rộng và đăng/xem đánh giá. Bằng cách này, nếu nhà phát triển đăng một tiện ích mở rộng chất lượng thấp có lỗi hoặc làm hỏng mọi thứ, người dùng nhận thấy nó có thể đăng đánh giá tiêu cực. (Tất nhiên, nếu nhà phát triển độc hại và đăng một tiện ích mở rộng độc ác, không có gì đảm bảo rằng mọi người sẽ nhận thấy - nếu bạn may mắn, có thể một số người dùng sẽ nhận thấy mã độc bằng cách nào đó và báo cáo cho bạn, nhưng đó là giống như không ai có thể nhận ra. Đó là rủi ro mà bạn phải chịu.)

    Điều này được gọi là có một hệ thống mở rộng mở. Xem, ví dụ: Android Market hoặc Google Chrome Thư viện tiện ích mở rộng hoặc Userscripts.org (trang web tiện ích mở rộng Greasemonkey).

  • Bạn có thể thiết lập một số loại hệ thống đánh giá, nơi các chuyên gia xem xét từng tiện ích mở rộng trước khi được đăng (hoặc ngay sau khi được đăng) trên trang web mở rộng công khai. Nếu bạn chỉ muốn nắm bắt các vấn đề về chất lượng, có thể đủ để các chuyên gia cài đặt tiện ích mở rộng và kiểm tra nó, và có thể chạy một công cụ tìm lỗi chất lượng mã để quét các vấn đề phổ biến. Nếu bạn cũng muốn bắt các tiện ích mở rộng độc hại, người đánh giá sẽ cần phải là nhà phát triển có khả năng đọc mã và đọc qua từng dòng mở rộng; Điều này cực kỳ tẻ nhạt và tốn thời gian, nhưng thực sự không có lựa chọn nào tốt hơn.

    Điều này được gọi là có một hệ thống mở rộng giám tuyển. Xem, ví dụ: Apple iOS App Store hoặc trang web mở rộng Firefox (addons.mozilla.org) để biết một số ví dụ, mặc dù tôi tin rằng họ chỉ tập trung vào chất lượng mã và không phát hiện ra ác ý.

Bất kỳ cách tiếp cận nào bạn thực hiện, đều có một lợi thế đáng kể cho các tiện ích mở rộng được phục vụ từ một trang web mở rộng công khai duy nhất, nơi lưu trữ phiên bản có thẩm quyền của tiện ích mở rộng. Bạn có thể muốn thực hiện các bước khác nhau để khuyến khích người dùng cài đặt tiện ích mở rộng từ trang web đó và không khuyến khích họ cài đặt tiện ích mở rộng từ các trang web khác (ví dụ: mặc định tắt cài đặt tiện ích mở rộng từ các nguồn khác và yêu cầu người dùng nhấp vào để ủy quyền cho bất kỳ tên miền nào khác mà họ muốn cài đặt từ, giống như Firefox). Lợi ích là gì? Lợi ích là điều này đảm bảo rằng tất cả người dùng của bạn có cùng một bản sao của tiện ích mở rộng. Nó ngăn chặn các cuộc tấn công, ví dụ, nơi một trang web độc hại sử dụng một số tập lệnh để kiểm tra xem phiên bản trình duyệt của người dùng và người dùng đến từ đâu, và dựa vào đó, quyết định xem có nên cung cấp mã độc hay mã hợp pháp hay không - những kiểu tấn công đó tạo ra khó phát hiện ác ý hơn, vì vậy ngăn chặn chúng là một điều tốt. Nó cũng đảm bảo rằng người dùng nhận được lợi ích của đánh giá và xếp hạng.

Bạn cũng nên xem xét cẩn thận API nào được tiếp xúc với tiện ích mở rộng và API nào không. Bạn có thể xem xét chỉ hiển thị một tập hợp con của API cho các tiện ích mở rộng, do đó, các tiện ích mở rộng vốn đã bị giới hạn về những gì chúng có thể làm, như một cách để hạn chế thiệt hại. Chẳng hạn, trình duyệt Chrome cho phép các tiện ích mở rộng tương tác với DOM của trang web và trang web, nhưng các tiện ích mở rộng không được phép thực thi mã gốc (ví dụ: cài đặt và chạy .exe). Ngoài ra, bạn có thể cung cấp API cơ bản để tránh các API có rủi ro cao nhất và sau đó yêu cầu bất kỳ tiện ích mở rộng nào yêu cầu quyền truy cập nhiều hơn API cơ bản phải được sự chấp thuận của người kiểm duyệt trước khi chúng có thể được đăng trên trang web công cộng.

Một biện pháp bảo vệ khác có thể chống lại các phần mở rộng độc hại là giới thiệu một hệ thống cấp phép. Bạn xác định một tập các quyền. Phần mở rộng được yêu cầu để bao gồm một bảng kê khai, trong đó chỉ định bộ quyền mà nó cần. Khi người dùng cài đặt quyền, hệ thống sẽ hiển thị cho người dùng bộ quyền mà tiện ích mở rộng đang yêu cầu và những quyền đó ngụ ý gì (ví dụ: rủi ro bảo mật/quyền riêng tư mà họ đặt ra, quyền truy cập nào họ cấp cho tiện ích mở rộng), cho phép người dùng hoặc phê duyệt các quyền và tiến hành cài đặt hoặc từ chối các quyền và hủy cài đặt. Điều này cho phép người dùng kiểm soát và hiển thị nhiều hơn đối với các tiện ích mở rộng, giảm rủi ro của các tiện ích mở rộng có lỗi (vì hậu quả của lỗ hổng bảo mật trong tiện ích mở rộng hiện chỉ giới hạn ở các quyền mà nó yêu cầu, không phải tất cả các quyền) và có thể làm cho các tiện ích mở rộng độc hại trở nên rõ ràng hơn ( bởi vì họ cần yêu cầu một số quyền nhất định để làm hại). Xem, ví dụ: Android hoặc Google Chrome tiện ích mở rộng để biết ví dụ về loại điều này.

6
D.W.

(Đừng cố gắng đưa ra sơ đồ vệ sinh của riêng bạn. Với sự phức tạp của JavaScipt, vệ sinh nấu tại nhà có thể không an toàn. Sử dụng một giải pháp hiện có đã được xem xét kỹ lưỡng.)

Trình biên dịch Caja của Google là một công cụ để tạo HTML, CSS và JavaScript an toàn để nhúng vào trang web của bạn.

Nếu tôi nhớ chính xác, nó đã được sử dụng cho iGoogle, vì chỉ tách mã không đáng tin cậy thành iframes vẫn còn thiếu sót.

6
Bryan Field

Tôi không biết liệu điều này có thể được tự động hóa dễ dàng hay không và tôi đồng ý với @ jfriend00 và @slhck về khó khăn chung của việc sàng lọc thành công các Javascripts này. Điều đó đang được nói, có ít nhất một công cụ mà tôi biết về nỗ lực phát hiện các tập lệnh độc hại.

Công cụ này là Wepawet , được điều hành bởi Đại học California tại Santa Barbara. Nó được mô tả như vậy:

Wepawet là một khuôn khổ để phân tích các mối đe dọa dựa trên web. Wepawet có thể xác định xem việc truy cập một trang web có dẫn đến nỗ lực xâm phạm môi trường của khách truy cập hay không.

2
Andrew Lambert

IBM Appscan có một mô-đun phân tích mã tĩnh được gọi là " Trình phân tích bảo mật JavaScript (JSA) ". Nó chắc chắn KHÔNG miễn phí, nhưng nó cung cấp phản hồi về ý nghĩa bảo mật của mã Javascript.

Ngoài JSA, tôi không biết về bất kỳ công cụ phân tích mã tĩnh nào khác để tìm kiếm mối quan tâm về bảo mật, nhưng tôi rất thích tìm hiểu thêm. Có lẽ nếu JLint/JHint thêm một số chức năng bảo mật?

0
schroeder