Làm thế nào dễ dàng để hack JavaScript (trong một trình duyệt)?

Câu hỏi của tôi phải làm với bảo mật JavaScript.

Hãy tưởng tượng một hệ thống xác thực trong đó bạn đang sử dụng khung JavaScript như Backbone hoặc AngularJS và bạn cần các điểm cuối an toàn. Đó không phải là vấn đề, vì máy chủ luôn có từ cuối cùng và sẽ kiểm tra xem bạn có được phép làm những gì bạn muốn không.

Nhưng nếu bạn cần một chút bảo mật mà không liên quan đến máy chủ thì sao? Điều đó có thể không?

Ví dụ: giả sử bạn có hệ thống định tuyến phía máy khách và bạn muốn một tuyến đường cụ thể được bảo vệ cho người dùng đăng nhập. Vì vậy, bạn ping máy chủ hỏi xem bạn có được phép truy cập các tuyến được bảo vệ không và bạn tiếp tục. Vấn đề là khi bạn ping máy chủ, bạn lưu trữ phản hồi trong một biến, vì vậy lần sau khi bạn đi đến một tuyến riêng, nó sẽ kiểm tra xem bạn đã đăng nhập chưa (không ping đến máy chủ) và tùy thuộc vào về phản ứng nó sẽ đi hay không.

Làm thế nào dễ dàng cho người dùng để sửa đổi biến đó và có được quyền truy cập?

Kiến thức bảo mật (và JavaScript) của tôi không tốt. Nhưng nếu một biến không nằm trong phạm vi toàn cầu và nằm trong phần riêng của mẫu mô-đun chỉ có getters chứ không có setters, ngay cả trong trường hợp đó, bạn có thể hack thứ đó không?

Vui lòng đọc câu trả lời của Joachim trước khi đọc bài này. Ông bao gồm các lý do chung đằng sau lỗ hổng phía khách hàng. Bây giờ, cho một gợi ý về cách bạn có thể khắc phục vấn đề này ...

Một lược đồ an toàn cho giao tiếp máy khách-máy chủ mà không phải xác thực với máy chủ theo cách thủ công trên mỗi yêu cầu:

Bạn vẫn để máy chủ có tiếng nói cuối cùng và máy chủ vẫn phải xác thực mọi thứ khách hàng nói, nhưng nó diễn ra trong suốt.

Giả sử giao thức HTTPS để ngăn chặn các cuộc tấn công trung gian (MITMA).

• Máy khách bắt tay với máy chủ lần đầu tiên và máy chủ tạo khóa chung cho máy khách và giữ khóa riêng bằng cách sử dụng sơ đồ mã hóa bất đối xứng. Máy khách lưu trữ khóa "công khai" của máy chủ trong bộ nhớ cục bộ, được mã hóa bằng mật khẩu an toàn mà bạn không lưu ở bất cứ đâu.

• Hiện tại khách hàng đang offline. Khách hàng muốn thực hiện các hành động đáng tin cậy. Máy khách nhập mật khẩu của mình và lấy khóa công khai của máy chủ.

• Bây giờ máy khách thực hiện các hành động dựa trên kiến ​​thức về dữ liệu đó và máy khách mã hóa mọi hành động mà nó thực hiện với khóa chung của máy chủ cho máy khách đó .

• Khi máy khách trực tuyến, máy khách sẽ gửi ID khách của nó và tất cả các hành động mà máy khách thực hiện được gửi đến máy chủ được mã hóa bằng khóa chung của máy chủ.

• Máy chủ giải mã các hành động và nếu chúng ở định dạng chính xác, nó tin tưởng rằng chúng có nguồn gốc từ máy khách.

Chú thích:

• Bạn không thể lưu trữ mật khẩu của khách hàng ở bất cứ đâu, nếu không, kẻ tấn công sẽ có thể lấy khóa và ký các hành động như của chính họ. Tính bảo mật của lược đồ này chỉ dựa vào tính toàn vẹn của khóa mà máy chủ tạo cho máy khách. Máy khách vẫn cần được xác thực với máy chủ khi yêu cầu khóa đó.

• Thực tế bạn vẫn dựa vào máy chủ để bảo mật chứ không phải máy khách. Mỗi hành động khách hàng thực hiện bạn phải xác nhận trên máy chủ.

• Có thể chạy các tập lệnh bên ngoài trong nhân viên web . Hãy ghi nhớ mọi yêu cầu JSONP mà bạn có bây giờ là vấn đề bảo mật lớn hơn nhiều. Bạn cần bảo vệ chìa khóa bằng mọi giá. Một khi bạn mất nó, kẻ tấn công có thể mạo danh người dùng.

• Điều này đáp ứng nhu cầu của bạn rằng 'không ping đến máy chủ' được thực hiện. Kẻ tấn công không thể bắt chước một yêu cầu HTTP với dữ liệu giả mạo nếu chúng không biết khóa.

• Câu trả lời của Joachim vẫn đúng . Thực tế, bạn vẫn đang thực hiện tất cả xác thực trên máy chủ . Điều duy nhất bạn đã lưu ở đây là nhu cầu xác thực mật khẩu với máy chủ mỗi lần. Bây giờ bạn chỉ cần liên quan đến máy chủ khi bạn muốn cam kết hoặc lấy dữ liệu cập nhật. Tất cả những gì chúng tôi đã làm ở đây là lưu một khóa đáng tin cậy ở phía máy khách và để máy khách xác nhận lại nó.

• Đây là một lược đồ khá phổ biến cho các ứng dụng trang đơn (ví dụ, với AngularJS).

• Tôi gọi khóa công khai của máy chủ là "công khai" vì điều đó có nghĩa là gì trong các chương trình như RSA , nhưng thực tế nó là thông tin nhạy cảm trong sơ đồ và cần được bảo vệ.

• Tôi sẽ không giữ mật khẩu ở bất cứ đâu trong bộ nhớ. Tôi sẽ khiến người dùng gửi mật khẩu 'ngoại tuyến' của mình mỗi khi anh ấy / cô ấy bắt đầu chạy mã ngoại tuyến.

• Đừng cuộn mật mã của riêng bạn - sử dụng một thư viện đã biết như Stanford để xác thực.

• Hãy xem lời khuyên này là như vậy . Trước khi bạn triển khai loại xác thực này trong một ứng dụng quan trọng trong kinh doanh trong thế giới thực, hãy tham khảo ý kiến ​​chuyên gia bảo mật . Đây là một vấn đề nghiêm trọng vừa đau đớn vừa dễ mắc sai lầm.

Điều quan trọng là không có tập lệnh nào khác có quyền truy cập vào trang. Điều này có nghĩa là bạn chỉ cho phép các tập lệnh bên ngoài với nhân viên web. Bạn không thể tin tưởng bất kỳ tập lệnh bên ngoài nào khác có thể chặn mật khẩu của bạn khi người dùng nhập nó.

Sử dụng promptvà không phải là trường mật khẩu nội tuyến nếu bạn không hoàn toàn chắc chắn và không trì hoãn việc thực thi nó (nghĩa là, nó không nên tồn tại đến điểm mà các sự kiện có quyền truy cập vào nó mà chỉ trong mã đồng bộ hóa). Và không thực sự lưu trữ mật khẩu trong một biến - một lần nữa, điều này chỉ hoạt động nếu bạn tin rằng máy tính của người dùng không bị xâm phạm (mặc dù điều đó hoàn toàn đúng khi xác thực với máy chủ).

Tôi muốn thêm một lần nữa rằng chúng tôi vẫn không tin tưởng khách hàng . Bạn không thể tin tưởng khách hàng một mình và tôi nghĩ rằng câu trả lời của Joachim đóng đinh nó. Chúng tôi chỉ đạt được sự thuận tiện khi không phải ping máy chủ trước khi bắt đầu làm việc.

Tài liệu liên quan:

• Chứng chỉ so với tên người dùng + mật khẩu .
• Tại sao chúng tôi không thể bảo mật thông qua phía khách hàng?
• Đừng cuộn tiền điện tử của riêng bạn.
• Thảo luận liên quan về việc làm cho JS an toàn cho các hoạt động của tiền điện tử

Thật đơn giản: bất kỳ cơ chế bảo mật nào phụ thuộc vào máy khách chỉ làm những gì bạn bảo nó làm có thể bị xâm phạm khi kẻ tấn công có quyền kiểm soát máy khách.

Bạn có thể kiểm tra bảo mật trên máy khách, nhưng chỉ hoạt động hiệu quả như một "bộ đệm" (để tránh thực hiện một chuyến đi khứ hồi đắt tiền đến máy chủ nếu khách hàng biết rằng câu trả lời sẽ là "không").

Nếu bạn muốn giữ thông tin từ một nhóm người dùng, hãy đảm bảo rằng ứng dụng khách của những người dùng đó không bao giờ có được thông tin đó. Nếu bạn gửi "dữ liệu bí mật" đó cùng với hướng dẫn "nhưng vui lòng không hiển thị nó", nó sẽ trở nên tầm thường để vô hiệu hóa mã kiểm tra yêu cầu đó.

Như bạn thấy, câu trả lời này không thực sự đề cập đến bất kỳ chi tiết cụ thể về JavaScript / Trình duyệt nào. Đó là bởi vì khái niệm này là giống nhau, bất kể khách hàng của bạn là gì. Nó không thực sự quan trọng đó là một ứng dụng khách béo (ứng dụng khách / máy chủ truyền thống), ứng dụng web trường học cũ hoặc ứng dụng một trang với JavaScript phía máy khách rộng rãi.

Khi dữ liệu của bạn rời khỏi máy chủ, bạn phải cho rằng kẻ tấn công có toàn quyền truy cập vào nó.

Có một câu nói trong cộng đồng chơi game: " Khách hàng nằm trong tay kẻ thù". Bất kỳ mã nào đang chạy bên ngoài khu vực được bảo mật như máy chủ đều dễ bị tấn công. Trong trường hợp cơ bản nhất, dễ bị tấn công ngay từ đầu. Đó là quyết định của khách hàng về việc thực sự chạy" mã bảo mật "của bạn và người dùng có thể chỉ "chọn không tham gia". Mặc dù với mã gốc, bạn có ít nhất một chức năng tự động lắp ráp và một lớp bảo vệ bổ sung bởi thực tế là kẻ tấn công cần phải là một lập trình viên giỏi để thao túng điều đó, nhưng JS thường không bị biến dạng và là văn bản thuần túy. Tất cả những gì bạn cần để thực hiện một cuộc tấn công là các công cụ nguyên thủy như máy chủ proxy và trình soạn thảo văn bản. Kẻ tấn công sẽ vẫn cần một mức độ giáo dục nhất định liên quan đến lập trình, nhưng cách dễ dàng hơn để sửa đổi tập lệnh bằng cách sử dụng bất kỳ đoạn văn bản nào hơn là tiêm mã vào một tệp thực thi.

Đây không phải là một câu hỏi về việc hack JavaScript. Nếu tôi muốn tấn công ứng dụng của bạn, tôi sẽ sử dụng proxy riêng cho phép tôi nắm bắt, sửa đổi và phát lại lưu lượng. Đề án bảo mật được đề xuất của bạn dường như không có bất kỳ sự bảo vệ nào chống lại điều đó.

Nói riêng về Angular:

Bảo vệ phía khách hàng tuyến không tồn tại. Ngay cả khi bạn 'ẩn' một nút để định tuyến đó, người dùng luôn có thể nhập nó vào, Angular sẽ khiếu nại, nhưng khách hàng có thể mã xung quanh đó.

Tại một số điểm, bộ điều khiển của bạn sẽ phải yêu cầu máy chủ của bạn cung cấp dữ liệu cần thiết để hiển thị chế độ xem, nếu người dùng không được phép truy cập dữ liệu đó, họ sẽ không nhận được dữ liệu đó vì bạn đã bảo vệ dữ liệu này ở phía máy chủ và ứng dụng Angular của bạn sẽ xử lý thích hợp 401.

Nếu bạn đang cố gắng bảo vệ dữ liệu thô, bạn không thể phía khách hàng, nếu bạn chỉ muốn một người dùng cụ thể chỉ có thể xem dữ liệu chung theo một cách nhất định, hãy tạo dữ liệu 'lượt xem' trên máy chủ thay vì gửi dữ liệu thô cho khách hàng và yêu cầu tổ chức lại nó (dù sao bạn cũng nên làm điều này vì lý do hiệu suất).

Lưu ý bên lề: không bao giờ có bất kỳ thứ gì nhạy cảm được tích hợp trong các mẫu xem mà Angular yêu cầu, đừng làm điều đó. Nếu vì một lý do điên rồ nào đó, bạn cần bảo vệ các mẫu xem đó ở phía máy chủ, giống như khi bạn thực hiện kết xuất phía máy chủ.