it-swarm-vi.com

Đảm bảo API cho truy cập di động

Tôi đã xây dựng API REST/JSON đẹp được các công ty khác (khách hàng của chúng tôi) sử dụng làm dịch vụ B2B. Mỗi khách hàng của chúng tôi có một cặp tên người dùng/mật khẩu và chúng tôi cũng thực hiện HTTPS và xác thực IP nguồn yêu cầu để phục vụ. Sử dụng dịch vụ tốn tiền và khách hàng được lập hóa đơn hàng tháng cho việc sử dụng dịch vụ của mình.

Giờ đây, một số khách hàng đang xây dựng các ứng dụng di động mà họ cung cấp cho người dùng của họ (B2C - người dùng cuối). Không phải tất cả những người dùng cuối dịch vụ này của chúng tôi đều có máy chủ và họ muốn sử dụng dịch vụ trực tiếp từ điện thoại thông minh (về mặt kỹ thuật không phải là vấn đề lớn là JSON/REST).

Vấn đề là tôi không chắc làm thế nào để bảo vệ dịch vụ chống gian lận. Điều gì sẽ ngăn nhà phát triển bên thứ ba tháo rời một trong các ứng dụng di động của khách hàng và sao chép tên người dùng/mật khẩu/bất kỳ thông tin bảo mật nào và sử dụng thông tin đó trong ứng dụng của anh ta? Điều đó sẽ cho phép anh ta tiêu thụ dịch vụ và tính phí sử dụng cho một trong những khách hàng hợp pháp của chúng tôi!

Tôi khá chắc chắn rằng không có giải pháp tiền điện tử hoàn hảo cho vấn đề này trừ khi người dùng cuối được ủy quyền xác thực với một số máy chủ. Nhưng đó không phải là luôn luôn như vậy.

Như một phương sách cuối cùng, tôi đoán rằng tôi có thể phân phối một thư viện bị xáo trộn cho Android/IPhone, ít nhất sẽ mang lại ảo tưởng về bảo mật ...

EDIT (làm rõ) :

Hãy để tôi cố gắng đơn giản hóa kịch bản.

  1. Tôi có một máy chủ web không thể hack được, phục vụ API JSON REST API.
  2. Các máy khách di động truy cập API của tôi trực tiếp. IP của họ không thể được xác nhận. Họ đang chạy một hệ điều hành tiêu chuẩn (Android/IOS).
  3. Không có máy chủ khác liên quan.
  4. Tôi không thể truy cập IMEI của điện thoại (nó được coi là riêng tư), điều này cũng không giúp ích gì cho tôi vì tôi không biết người dùng cuối.
  5. Có một số ứng dụng di động hợp pháp như vậy, được phát triển bởi các công ty khác nhau truy cập API của chúng tôi.
  6. Bảo mật hiện tại (tên người dùng/mật khẩu) có thể dễ dàng bị hack bởi công ty lừa đảo. Công ty lừa đảo cho biết đã tháo rời một ứng dụng di động hợp pháp và sao chép tên người dùng/mật khẩu vào ứng dụng bất hợp pháp của họ. Họ phân phối ứng dụng này và lợi nhuận (việc sử dụng API được tính cho công ty mà họ đã đánh cắp thông tin đăng nhập).

Điều này có thể được dừng lại?

16
Tal Weiss

Câu hỏi của bạn là "Điều này có thể dừng lại được không?", Nhưng tôi có cảm giác rằng mọi thứ quan trọng về hệ thống không thể/sẽ không thực sự được thay đổi.

Nếu tôi hiểu chính xác, bạn đang hỏi (đơn giản hóa):

Tôi có nhiều khách hàng chia sẻ cùng tên người dùng và mật khẩu. Tôi có thể ngừng lạm dụng?

Câu trả lời cho điều đó là không. Bạn phải quyết định xem bạn có đủ khả năng để bỏ qua vấn đề hay không, hoặc thực hiện các giải pháp chính xác.

Nếu bạn thực sự muốn làm điều này đúng cách, hãy xem xét triển khai một cái gì đó như OAuth, để bạn có thể phân phối chính xác các mã xác thực riêng biệt cho người dùng cuối, liên kết chúng với khách hàng của bạn để thanh toán, thu hồi quyền truy cập, v.v.

-

Ít nhất bạn nên làm là cho phép khách hàng của bạn (các công ty) chọn sử dụng chương trình xác thực tốt hơn. Vì vậy, ví dụ: bạn tạo API để họ yêu cầu (và thu hồi) các mã thông báo truy cập riêng cho người dùng cuối của họ.

  • Công ty A yêu cầu mã thông báo từ máy chủ của họ (điều này được bắt đầu bởi ứng dụng của họ nói với họ "hãy cho tôi mã thông báo")
  • Bạn trả lại mã thông báo N, ghi lại những gì công ty được đính kèm
  • Nếu ứng dụng của Công ty A kết nối với dịch vụ của bạn, nó sẽ gửi mã thông báo N chứ không phải tên người dùng/mật khẩu
  • Công ty A có thể thông báo cho dịch vụ của bạn "thu hồi mã thông báo N" và các yêu cầu xa hơn với mã thông báo đó sẽ không được phục vụ bởi dịch vụ của bạn. Nhưng, nếu mã thông báo bị thu hồi, nó sẽ không khiến tất cả các ứng dụng khách không thể sử dụng được.

Nếu một công ty không muốn làm điều này, họ vẫn có thể tiếp tục kết nối bằng tên người dùng/mật khẩu của mình, nhưng họ sẽ chịu trách nhiệm hoàn toàn cho tất cả việc sử dụng.

Vấn đề là bạn không thể thực sự khiến khách hàng của mình phải chịu trách nhiệm về việc rò rỉ thông tin đăng nhập (điều không thể làm trong kịch bản ứng dụng di động) nếu họ không có cách nào khác để sử dụng dịch vụ.

7
Joel L

Vì vậy, tôi hy vọng tôi có điều này đúng. Bạn muốn một cách an toàn để xác nhận danh tính của khách hàng bằng khóa API hợp lệ? Tôi nghĩ rằng việc lưu trữ khóa API một cách an toàn phần lớn chịu trách nhiệm đối với công ty đã phát triển ứng dụng chứ không phải công ty của bạn.

Bạn sẽ cần mã hóa và làm mờ khóa để bảo vệ nó khỏi tin tặc thông thường nhưng tôi không nghĩ bạn sẽ có thể ngăn chặn một tin tặc xác định. Bạn có thể thực hiện một chút tin tặc để làm cho việc gỡ lỗi nhị phân trở nên khó khăn hơn, điều này có thể làm giảm khả năng ứng dụng của bạn trôi nổi trên internet. Tuy nhiên, đây không phải là bảo mật tuyệt đối và trừ khi công ty của bạn đang phát triển các ứng dụng nội bộ, làm thế nào bạn có thể thực thi các biện pháp đó?

Vì vậy, như một câu trả lời cho kịch bản của bạn, không, tôi không nghĩ rằng nó có thể được dừng lại một cách hiệu quả mà không gây bất lợi cho trải nghiệm người dùng. Bạn có thể giáo dục các công ty bằng cách sử dụng API của mình - ném một cuốn sổ tay nhỏ cho họ và đảm bảo rằng rõ ràng là họ trách nhiệm giữ an toàn của họ khóa api an toàn.

Cuối cùng, bạn cũng có thể thực hiện một số tính năng giảm thiểu. Ví dụ:

  1. Cho phép các công ty xác định giới hạn cứng của riêng họ. Giả sử công ty A biết rằng tháng trước họ đã tải xuống N ứng dụng và do đó muốn giới hạn quyền truy cập của họ vào API của bạn đối với các yêu cầu X mỗi ngày hoặc giờ.
  2. Giám sát bất kỳ đột biến trong yêu cầu cho mỗi công ty trong khoảng thời gian.
  3. Xác định một bước của các thủ tục sẽ xảy ra đối với các hoạt động lừa đảo tiềm năng.
  4. Khóa lại, khóa lại và khóa lại.

Mục tiêu của sự thất bại (nó xảy ra tốt nhất) là để giảm thiểu thiệt hại.

Chúc may mắn.

6
Kurt

Bạn có quyền hoài nghi về việc khách hàng của bạn nhúng tên người dùng/mật khẩu của họ vào một ứng dụng di động mà họ trao cho tất cả người dùng của họ. Như bạn đã xác định chính xác, sẽ dễ dàng cho một số kẻ tấn công tháo rời ứng dụng di động đó, rút ​​tên người dùng/mật khẩu khỏi ứng dụng di động và sử dụng nó trong ứng dụng của riêng họ. Thật không may, khách hàng của bạn là người quyết định có nên làm điều đó hay không, nhưng chi phí được áp dụng cho bạn. Vì vậy, đây là một ngoại lệ, và bạn sẽ cần một số cách để làm cho chi phí và rủi ro và các ưu đãi được liên kết tốt hơn. Tôi có một số gợi ý dưới đây về cách làm điều đó.

Nói chung, tôi thấy hai giải pháp hợp lý cho việc này:

  • Chuyển rủi ro. Đối với mỗi khách hàng, áp đặt giới hạn số lượng yêu cầu bạn sẽ chấp nhận từ khách hàng đó. Nói với khách hàng rằng họ có trách nhiệm giữ an toàn tên người dùng/mật khẩu của mình, rằng tất cả các yêu cầu đến bằng tên người dùng/mật khẩu này sẽ được tính theo giới hạn của họ và nếu có quá nhiều yêu cầu đến, tài khoản của họ có thể bị vô hiệu hóa. Nói với họ rằng nếu họ nhúng tên người dùng/mật khẩu của họ vào một ứng dụng di động, sẽ có nguy cơ ai đó bất chính có thể đánh cắp tên người dùng/mật khẩu và sử dụng nó để thực hiện nhiều yêu cầu, khiến tài khoản của họ bị vô hiệu hóa và ứng dụng di động của họ ngừng hoạt động . Hãy để họ quyết định xem họ có muốn mạo hiểm hay không.

  • Yêu cầu theo hợp đồng. Nói với khách hàng của bạn rằng họ bị cấm chia sẻ tên người dùng/mật khẩu của họ với người khác và họ không được phép nhúng tên người dùng/mật khẩu của mình vào các ứng dụng mà người khác có thể tải xuống. Nói với họ rằng nếu bạn phát hiện bất kỳ vi phạm chính sách này, tài khoản của họ có thể bị vô hiệu hóa và họ có thể được lập hóa đơn cho bất kỳ chi phí nào mà điều này áp dụng cho máy chủ của bạn.

    Nếu khách hàng của bạn muốn tạo một ứng dụng di động, hãy nói với khách hàng của bạn rằng, thay vì nhúng tên người dùng/mật khẩu của họ vào ứng dụng di động, họ nên ủy quyền những yêu cầu như vậy cho máy chủ của họ. Nói cách khác, khách hàng nên thiết lập một máy chủ biết tên người dùng/mật khẩu của khách hàng, nhưng tên người dùng/mật khẩu này không nên được nhúng trong ứng dụng di động. Ứng dụng di động của khách hàng sẽ xác thực với máy chủ của khách hàng, gửi yêu cầu đến máy chủ và sau đó máy chủ sẽ chuyển tiếp yêu cầu đến bạn và chuyển phản hồi trở lại ứng dụng di động. Máy chủ của họ phải xác thực người dùng cuối (ví dụ: yêu cầu mỗi người dùng cuối của ứng dụng di động tạo tài khoản trên máy chủ của họ, với tên người dùng/mật khẩu của riêng họ). Máy chủ của họ nên áp đặt giới hạn băng thông trên cơ sở cho mỗi người dùng và vô hiệu hóa tài khoản của bất kỳ người dùng cuối nào vượt quá các giới hạn đó.

Bạn cũng có thể cho phép khách hàng lựa chọn giữa hai tùy chọn sau: ví dụ: giữa tài khoản băng thông hạn chế (có chuyển rủi ro) hoặc tài khoản băng thông không giới hạn (với yêu cầu không nhúng tên người dùng/mật khẩu vào các ứng dụng có thể truy cập được cho người khác ).

Tôi hy vọng điều này có ý nghĩa. Điều này có thể hơi khó hiểu, bởi vì có ba bên - bạn, khách hàng của bạn và người dùng cuối của khách hàng của bạn - mỗi bên có sở thích riêng và mối quan tâm. Tôi hy vọng tôi đã phân biệt đầy đủ giữa cả ba.

3
D.W.

Bảo mật dữ liệu của bạn khi truyền bằng SSL đã bao trùm cuộc tấn công trung gian. Mật khẩu được mã hóa cứng trong mã nguồn dù sao cũng không phải là một cách thực hành an toàn. Bạn không nên quan tâm đến địa chỉ IP của người dùng hoặc IMEI. Chúng ta đừng nói về việc theo dõi và cố gắng sửa chữa mọi thứ ngay từ đầu.

Giống như bạn đã nói, bạn đang sử dụng REST. Vài điều sẽ giúp bạn ra ngoài, tôi hy vọng.

  1. Xác thực người dùng từ phía máy chủ. Duy trì quản lý phiên nghiêm ngặt để nó không thể bị giả mạo. Kiểm tra OWASP cho điều này.
  2. Làm một bài kiểm tra fuzz cho API của bạn. ReST được biết đến với một vài lỗ hổng. Vui lòng khám phá chúng trên Internet và tìm hiểu hầu hết các lỗi đã biết trong ReST. Vá những vấn đề đó cho API của bạn.
  3. Điều SSL của bạn là tốt khi nó bảo vệ dữ liệu của bạn ở giữa.

Đừng lo lắng về mã nguồn của bạn. Nó có thể bị gạt ra bằng mọi cách nhưng không sao. Các chức năng chính của bạn sẽ được chạy trên máy chủ và chỉ chuyển các phản hồi cho khách hàng. Giữ tất cả những điều tốt đẹp về phía máy chủ.

1
mojo

Một trong những vấn đề tôi nghĩ bạn sẽ gặp phải trên mặt trận di động là xác thực địa chỉ IP. Thông thường, các địa chỉ IP di động được chỉ định bởi telco sẽ được ghi vào lưới. IP lưới sẽ làm cho cơ chế xác thực IP được thông qua ở phía máy chủ không sử dụng.

Để triển khai giải pháp trên Android và Iphone; tôi nghĩ cách tiếp cận nên là:

  1. Yêu cầu xác thực máy chủ khách trong chế độ SSL cũng được mở rộng để xác thực chứng chỉ ứng dụng khách. Ý tôi là cho phép cả máy khách và máy chủ đều sử dụng chứng chỉ để thiết lập phiên SSL an toàn.
  2. Cung cấp PFX/P12 chứa chứng chỉ ứng dụng khách (di động) theo cách yêu cầu PIN và kết hợp số IMEI và IMSI. Cách này sẽ trở nên khó khăn cho kẻ tấn công để từ chối cùng phiên.
  3. Có một số AI được triển khai trên máy chủ phát hiện hai hoặc nhiều phiên đồng thời được bắt đầu bằng cùng một chứng chỉ ứng dụng khách, điều này sẽ cho bạn biết rằng một số thỏa hiệp đã xảy ra và máy chủ có thể lập tức đưa vào danh sách đen hoặc thu hồi chứng chỉ để sử dụng tiếp.

Tôi tin rằng mặc dù chúng tôi đã thảo luận về môi trường di động; ngoài xác thực IP, các rủi ro cũng có trong môi trường PC. Trong tương lai, bạn có thể chấp nhận hoặc chuyển sang triển khai dựa trên chữ ký và chứng chỉ ứng dụng khách trên môi trường PC nếu bạn gặp phải một số vấn đề thanh toán sai do khách hàng nêu ra.

1
Mohit Sethi

Gian lận là vauge và không thể được giải quyết chỉ bằng cách triển khai kỹ thuật, nhưng nếu bạn đã triển khai xác thực và khóa IP leo thang, thì không có gì phải lo lắng. Bạn cũng không được cung cấp thông tin xác thực cho khách hàng của mình (B2B). Hãy để tôi giải thích tại sao và làm thế nào.

Từ sự hiểu biết của tôi về những gì bạn đã viết, các khái niệm và triển khai bảo mật cơ bản đến trung bình đã được áp dụng liên quan đến phía B2B (YOUCOMPANY - YOUCLIENT). Điều đó thật tốt. Xác thực IP, SSL/TLS, Người dùng/Đạt, v.v ... Bây giờ, bạn lo ngại rằng thông tin xác thực API được khách hàng của bạn sử dụng để cung cấp ứng dụng di động cho người dùng cuối có thể bị lỗi theo cách mà người dùng cuối bên thứ 3 sẽ tận dụng những thông tin đăng nhập nếu ứng dụng di động của khách hàng của bạn đã bị khai thác theo một cách nào đó.

Về cơ bản, nó có một loạt các lớp bảo mật. Câu hỏi là làm thế nào công ty của bạn đã thiết kế và thực hiện các lớp này?

  1. Máy chủ API JSON/REST của bạn phải chứa thông tin xác thực của bạn. Nếu bạn đang cung cấp dịch vụ và yêu cầu kết nối với nhà cung cấp/nhà cung cấp mạng thì những thông tin đó cũng có thể được tìm thấy ở đây. Bạn có hiểu ý tôi.

  2. Không cấp cho YOUCLIENT quyền truy cập trực tiếp vào MÁY CHỦ API JSON/REST. Thay vào đó, bạn cần một Máy chủ nhảy sẽ đóng vai trò là Máy chủ lưu trữ cho môi trường đáng tin cậy, máy chủ API từ nơi ứng dụng JSON/REST của bạn cư trú sẽ xác thực CHỈ với máy chủ này bằng cách sử dụng xác thực/khóa địa chỉ IP. Xác thực máy chủ đến máy chủ bằng IP hoặc cặp khóa công khai/riêng tư. Theo ý của bạn những gì để sử dụng.

Máy chủ này cũng sẽ hoạt động như một dịch vụ web chứa một tập hợp tên người dùng/mật khẩu, sau đó ánh xạ chính nó vào một tệp cấu hình và chuyển yêu cầu đến MÁY CHỦ API JSON/REST. Bây giờ, BẢN TIN CỦA BẠN nên có quyền truy cập vào máy chủ này trên cơ sở xác thực/khóa IP và được bảo vệ bằng HTTPS. Khái niệm này là không có thông tin xác thực/người dùng thực tế nào có thể được tìm thấy ở đây ngoại trừ khóa/bí mật ánh xạ tới API SERVER.

  1. YourCLIENT có thể có một triển khai bảo mật từ bên trong của họ đến người dùng cuối. Nó có thể ở dạng cặp khóa công khai/riêng tư PKI cho nhà phát triển hoặc 2FA cho người dùng thông thường. YOUCLIENT nên thực hiện các bước này, không phải công ty của bạn.

Bây giờ, ví dụ, một nhà phát triển bên thứ 3 (người dùng cuối) đã khai thác lỗ hổng trên ứng dụng di động được tạo bởi một trong NHỮNG NGƯỜI BẠN và nhận được thông tin đăng nhập của họ:

  1. Vô ích. Liên quan đến việc sử dụng thông tin đăng nhập, IP của bạn sẽ được xác thực.
  2. Không hợp lệ. Liên quan đến việc bạn phải được xác thực thông qua cặp khóa công khai/riêng tư.
  3. Kỹ thuật leo thang đặc quyền sẽ yêu cầu anh ta khai thác máy chủ thực tế để được tin cậy.
  4. Khai thác máy chủ thực tế đòi hỏi các kỹ thuật được chế tạo sẽ làm chậm động lực của kẻ tấn công.
  5. Không có cuộc tấn công thành công mà động lực đã kết thúc.

Obfuscation là tốt và làm chậm một cuộc tấn công nhưng nó là hình thức bảo mật ít nhất. Bạn nên dựa vào tiền điện tử tốt hơn sử dụng các khóa.

Hãy nhớ rằng, không có giải pháp bảo mật tuyệt đối ngoài nỗ lực liên tục của bạn để chống gian lận từ góc độ bảo mật kỹ thuật và vận hành.

1
John Santos