Mã hóa phía khách hàng: Làm thế nào để ngăn chặn việc sử dụng độc hại?

Trong vài năm qua, xu hướng cho các ứng dụng phía máy khách (trình duyệt) đã thực sự bắt đầu.

Đối với dự án mới nhất của tôi, tôi đã quyết định thử và di chuyển theo thời gian và viết một ứng dụng phía khách hàng.

Một phần của ứng dụng này liên quan đến việc gửi email giao dịch cho người dùng (ví dụ: xác thực đăng ký, email đặt lại mật khẩu, v.v.). Tôi đang sử dụng API của bên thứ ba để gửi email.

Thông thường tôi sẽ có ứng dụng của mình chạy trên một máy chủ. Tôi sẽ gọi API của bên thứ ba từ mã trên máy chủ của mình.

Chạy một ứng dụng phía máy khách có nghĩa là điều này bây giờ cần phải xảy ra trên trình duyệt của người dùng. API của bên thứ ba cung cấp các tệp JavaScript cần thiết để đạt được điều này.

Vấn đề rõ ràng đầu tiên tôi có thể thấy là tôi cần sử dụng khóa API. Điều này thường sẽ được lưu trữ an toàn trên máy chủ của tôi, nhưng bây giờ có lẽ tôi sẽ cần cung cấp khóa này cho trình duyệt máy khách.

Giả sử tôi có thể giải quyết vấn đề này, vấn đề tiếp theo là điều gì ngăn người dùng am hiểu công nghệ tải công cụ nhà phát triển JavaScript trên trình duyệt và sử dụng API email dù họ thích, thay vì tuân thủ bất kỳ quy tắc nào tôi đã đặt trong ứng dụng .

Tôi đoán câu hỏi chung của tôi là - làm thế nào chúng ta có thể ngăn chặn việc sử dụng độc hại ứng dụng phía khách hàng?

Bạn không thể, và càng nhiều người hiểu điều này, và họ càng hiểu sâu hơn, thì càng tốt cho thế giới.

Mã chạy trên thiết bị dưới sự kiểm soát của người dùng không thể được kiểm soát. Điện thoại thông minh có thể được bẻ khóa. Hộp set-top có thể bị nứt. Các trình duyệt thông thường thậm chí không cố gắng ngăn truy cập vào mã JavaScript. Nếu bạn có thứ gì đó đáng để ăn cắp hoặc lạm dụng, một kẻ tấn công quyết tâm sẽ có thể làm điều đó trừ khi bạn xác nhận mọi thứ bạn trân trọng phía máy chủ.

Obfuscation là rất ít giúp đỡ; loại đối thủ bạn sẽ thu hút ngay khi mọi thứ liên quan đến tài chính từ xa đọc ngôn ngữ lắp ráp như quảng cáo rao vặt. Mã hóa không thể giúp bạn, bởi vì thiết bị bảo vệ khóa là cùng một thiết bị bạn phải giả sử bị bẻ khóa. Có nhiều biện pháp đối phó khác, dường như rõ ràng không hoạt động, vì những lý do tương tự.

Thật không may, đây là một sự thật rất bất tiện. Thế giới đầy những nhà khai thác thời gian nhỏ và lớn, những người nghĩ rằng họ bằng cách nào đó có thể khắc phục được sự đổ vỡ cơ bản của niềm tin từ xa, đơn giản là vì sẽ rất tuyệt nếu chúng ta có thể giả định rằng mã của chúng ta sẽ chạy theo cách chúng ta giả định. Và vâng, nó sẽ làm mọi thứ dễ dàng hơn nhiều đến nỗi nó thậm chí không hài hước. Nhưng mong muốn không làm cho nó trở nên như vậy, và hy vọng chống lại hy vọng rằng bạn là một cookie thông minh có thể tránh được sự khó chịu sẽ chỉ đốt cháy bạn và khách hàng của bạn. Do đó, hãy suy nghĩ rằng Internet là lãnh thổ của kẻ thù, bao gồm chi phí tăng thêm trong ước tính của bạn và bạn sẽ ổn.

Điều đó nói rằng, tất nhiên có một thứ như phòng thủ theo chiều sâu. Làm xáo trộn JavaScript của bạn không loại bỏ một kẻ tấn công xác định, nhưng nó có thể loại bỏ một số kẻ tấn công ít xác định hơn. Nếu tài sản của bạn đủ giá trị để bảo vệ, nhưng không phải bằng bất cứ giá nào, bất kỳ biện pháp nào trong số đó có thể bổ sung giá trị kinh doanh cho hệ thống của bạn; nó không thể hoàn hảo Miễn là bạn nhận thức đầy đủ về sự đánh đổi mà bạn đang thực hiện, đó có thể là một chiến lược hợp lý.

Quy tắc ở đây là:

Làm mọi thứ phía máy khách không ảnh hưởng đến bất kỳ ai khác nếu người dùng ngăn chặn nó. Đặc biệt, điều đó có nghĩa là hiệu ứng đồ họa.

Thực hiện mọi thứ phía máy chủ cần được bảo mật và chỉ gửi các sự kiện UI từ máy khách (ví dụ: máy khách chỉ nói "người dùng đã nhấn nút Mua" trong khi máy chủ thực sự thực hiện giao dịch). Đặc biệt, điều đó có nghĩa là giao dịch tài chính.

Đây chính xác là trường hợp làm cho nó trở thành một ứng dụng hoàn toàn phía khách hàng là không phù hợp.

Bạn có thể thực hiện logic và xác thực cơ bản của biểu mẫu phía máy khách (bạn vẫn phải xác nhận lại trên máy chủ, vì ai đó có thể cố gắng giả mạo yêu cầu) để cải thiện khả năng phản hồi, bạn có thể thực hiện các yêu cầu HTTP từ JavaScript truyền dữ liệu ở đó và quay lại JSON tránh gửi lại trang trí trang và những thứ tương tự, nhưng nếu bản thân giao dịch cần được xác thực và ủy quyền, thì nó vẫn sẽ xảy ra trên máy chủ.

Đoạn giữa của bạn là trung tâm của vấn đề:

Chạy một ứng dụng phía máy khách có nghĩa là điều này bây giờ cần phải xảy ra trên trình duyệt của người dùng. API của bên thứ ba cung cấp các tệp js cần thiết để đạt được điều này.

Tại sao ứng dụng phía máy khách có nghĩa là bạn không thể có công việc phía máy chủ? Việc thúc đẩy lập trình phía máy khách không phải là loại bỏ các máy chủ, mà là tận dụng các công nghệ mới hơn mà cuối cùng các trình duyệt hỗ trợ để tạo giao diện người dùng tốt hơn.

Đối với .jstệp bạn nhận được, bạn có chắc chắn nó dành cho trình duyệt không? Nó có thể là một thư viện node.js?

Chúng ta hãy lùi lại từ đây và xem xét mức độ cao hơn .. chúng ta sẽ .. Eudora hay triển vọng (một ứng dụng phía khách hàng, thậm chí không cần trình duyệt) có bao giờ gây tổn thất tài chính cho bất kỳ công ty nào không? Không. Bất cứ ai cũng có thể viết thư cho API POP / SMTP và là khách hàng. Nhưng không mất máy chủ. Máy chủ không giới hạn hành động của máy khách, tính toán, lưu trữ, nhiệt độ, kích thước đĩa, kích thước ram, giám sát DPI, GPU, FPU yada yada của máy khách nhưng chỉ định chính xác những gì nó sẽ trả lời và không hơn thế nữa. Bạn đã bao giờ nghe nói về việc rút tiền nhanh chóng hoặc MS-Money được sử dụng để chuyển sang ngân hàng chưa?

Ứng dụng trình duyệt của bạn (tức là phía khách hàng) có thể sử dụng cùng một kiến ​​trúc.

1. Bạn xây dựng máy chủ của mình bằng API (mà BTW, luôn nắm bắt được các dẫn xuất của GET POST Head, v.v.).
2. Trên máy chủ, đảm bảo rằng API chỉ nói chuyện với một máy khách được xác thực và xác minh danh tính cho mỗi cuộc gọi.
3. Sau đó, bạn không quan tâm khách hàng là ai.
4. Và sau đó, bạn không quan tâm nếu đó là trình duyệt, thiết bị đã bẻ khóa, kính Google, DOS 3.1 hay Nexus hoàn toàn mới trong tay của một ông cố công nghệ vĩ đại, người đã du hành thời gian đến 2014 và đã bỏ lỡ tất cả công nghệ đang tràn ngập cuộc sống của chúng ta trong 15 thập kỷ qua.
5. Bây giờ bạn có thể bắt đầu tải mọi thứ khác cho phía khách hàng.

Xà phòng

@KilianFoth nêu lên một điểm nhận thức quan trọng đối với những người ngây thơ và liều lĩnh, chủ yếu là những người đọc các tiêu đề mọi lúc nhưng không bao giờ nghĩ rằng nó sẽ xảy ra với ứng dụng của họ, mã của họ, chủ nhân của họ, khách hàng của họ, tài khoản ngân hàng của họ. Thậm chí, những người sử dụng lao động của họ (đặc biệt là CTO) còn cho phép các ứng dụng thoát ra ngoài để lộ bất kỳ hệ thống nào tiếp xúc không được kiểm soát / không kiểm soát. Tuy nhiên tôi luôn bối rối về việc dường như "chúng ta không bao giờ học".

Xà phòng

Vì vậy, để tóm tắt. Tạo một API phía máy chủ vững chắc và chặt chẽ. Giảm tải mọi thứ khác cho khách hàng dựa trên bất cứ điều gì khách hàng có thể xử lý.

Tôi cho rằng bạn thực sự không thể. Nếu bạn sẵn sàng gửi dữ liệu cho khách hàng, bạn phải hy vọng rằng nó sẽ bị lạm dụng - tuy nhiên có thể. Ví dụ của bạn về khóa API là minh họa cho điểm và tôi sẽ không bao gồm điều đó trong JS phía máy khách của bạn - nó sẽ bị đánh cắp và lạm dụng.

Bạn chắc chắn sẽ vẫn cần một số lượng mã máy chủ để giữ an toàn. Thậm chí một cái gì đó đơn giản như chỉ lấy dữ liệu liên quan đến người dùng đã đăng nhập. Xác thực đó không thể được thực hiện phía khách hàng hoặc một lần nữa, bạn sẽ bị lợi dụng và dữ liệu của bạn không an toàn.

Tôi sẽ luôn xem trải nghiệm phía máy khách JS là một bổ sung cho mã máy chủ. Xác thực trên máy khách cung cấp trải nghiệm người dùng tốt, nhưng nếu bạn không xác minh rằng dữ liệu POST trên máy chủ nhận cũng vậy, bạn sẽ tự mở để tấn công. Bất cứ điều gì từ khách hàng nên được coi là nghi ngờ.

Nó khá đơn giản, thực sự. Giả sử rằng máy tính khách và tất cả phần mềm chạy trên nó đều nằm dưới sự kiểm soát hoàn toàn của một tin tặc độc hại thông minh.

Điều đó có nghĩa là bất kỳ thông tin nào bạn gửi từ máy chủ đến máy khách sẽ bị kẻ độc hại biết đến, do đó bạn phải đảm bảo không gửi thông tin nào đến máy khách có thể được sử dụng để tấn công máy chủ hoặc doanh nghiệp của bạn.

Điều đó cũng có nghĩa là mọi thứ được gửi từ máy khách đến máy chủ đều do tin tặc độc hại tạo ra, vì vậy mã máy chủ của bạn phải đảm bảo rằng không có gì khách hàng có thể gửi sẽ có khả năng tấn công thành công máy chủ của bạn.

Phải thừa nhận rằng việc triển khai là một vấn đề, nhưng điều quan trọng là thái độ tinh thần, giả định rằng "khách hàng" mà bạn nghĩ rằng máy chủ của bạn đang nói chuyện không phải là khách hàng mà là một kẻ tấn công tích cực.

(Bạn cũng cần cho rằng người dùng là một conman thông minh, người sẽ cố gắng tấn công các phương thức kinh doanh của bạn, nhưng điều đó không liên quan gì đến lập trình phía khách hàng).

Theo tôi, ứng dụng phía khách hàng chủ yếu là về UI. Ví dụ, tất cả hệ thống UI của bạn sẽ được gửi một lần đến máy khách và sau đó máy khách sẽ làm bất cứ điều gì nó muốn với nó.

Thông thường tôi sẽ có ứng dụng của mình chạy trên một máy chủ. Tôi sẽ gọi API của bên thứ ba từ mã trên máy chủ của mình.

Chạy một ứng dụng phía máy khách có nghĩa là điều này bây giờ cần phải xảy ra trên trình duyệt của người dùng. API của bên thứ ba cung cấp các tệp JavaScript cần thiết để đạt được điều này.

Nếu bạn có Khóa API, thì nó không có ý định hoạt động ở phía máy khách. Nếu bạn cung cấp Khóa API ở phía máy khách, thì bất kỳ ai cũng có quyền truy cập vào nó và sau đó có thể sử dụng nó cho mục đích riêng của mình. Lưu trữ và sử dụng phía máy chủ khi máy khách cần, sau đó gửi kết quả bằng Ajax / WebSockets.

Giống như nếu ngân hàng của bạn nói: "Chà, tôi sẽ đặt mật khẩu của phía máy khách cơ sở dữ liệu chính để khách hàng có thể tự yêu cầu và anh ta sẽ không làm phiền máy chủ của chúng tôi nữa."