Ứng dụng iPhone an toàn communication liên lạc với máy chủ


14

Điều gì sẽ là cách tiếp cận tốt nhất để đạt được giao tiếp riêng giữa ứng dụng iOS của tôi và thành phần máy chủ của nó? Là có một khóa bí mật không thay đổi được, đã được đưa vào nguồn ứng dụng, hay tôi cần phải thiết lập các thế hệ của các khóa bắt tay như vậy bằng cách nào đó?

Bản thân máy chủ không có quyền truy cập vào bất kỳ dữ liệu nhạy cảm nào, vì vậy ngay cả khi người dùng truy cập vào một số điểm cuối riêng tư, nó sẽ không nhận được chúng ở bất cứ đâu, nhưng tôi chỉ muốn chúng bị ẩn khỏi công chúng. Về cơ bản, tôi muốn bỏ qua tất cả các yêu cầu đạt các tuyến cụ thể, trừ khi chúng đến từ ứng dụng iOS của tôi.

Thành phần máy chủ chạy trên RoR, nếu điều đó quan trọng.

Câu trả lời:


8

Bạn không thể từ chối các kết nối một cách hiệu quả trừ khi bạn cung cấp cho mọi khách hàng một khóa riêng mà bạn có thể thu hồi riêng lẻ. Nhưng điều này có lẽ là quá mức cần thiết. Bạn không cần một giải pháp chống đạn nếu hầu hết mọi người sẽ không muốn bắn một viên đạn.

Đó là một câu hỏi bảo mật, vì vậy hãy mô tả một mô hình mối đe dọa và các chiến lược giảm thiểu.

Giả sử bạn có một lần truy cập URL có thể gây ra chi phí đáng chú ý cho bạn (ví dụ: chi phí xử lý) và bạn muốn bảo vệ nó khỏi cả một cuộc tấn công DoS đơn giản và từ các ứng dụng copycat.

Sử dụng SSL để ẩn kết nối khỏi bị phân tích dễ dàng. Sử dụng số cổng không obviuos, trình tự chuyển hướng, trao đổi cookie để làm phức tạp kết nối một chút trước khi bạn thực hiện phần tốn kém của yêu cầu. Sử dụng một số mã bí mật được đưa vào ứng dụng của bạn để cho máy chủ biết rằng nó phải chấp nhận kết nối.

Bây giờ ai đó không thể tìm hiểu URL đắt tiền để truy cập chỉ bằng cách chạy gói sniffer hoặc bằng cách xem các chuỗi giống như URL trong mã của bạn. Kẻ tấn công tiềm năng phải dịch ngược ứng dụng của bạn.

Bạn không thể thực sự bảo vệ mã của mình khỏi bị dịch ngược và / hoặc chạy theo trình gỡ lỗi. Kẻ tấn công cuối cùng cũng học được khóa bí mật và trình tự kết nối.

Bạn nhận thấy rằng bạn bắt đầu nhận được các yêu cầu chia sẻ tại URL tốn kém của mình: dưới hình thức tấn công hoặc dưới dạng một ứng dụng copycat phải truy cập dịch vụ của bạn để chạy hoặc có thể mã khai thác được đăng công khai. Bạn không thể nói một yêu cầu giả mạo từ một yêu cầu hợp pháp, mặc dù.

Tạo một bản cập nhật nhỏ miễn phí cho ứng dụng của bạn, với một khóa bí mật khác. Nó sẽ đạt một URL tốn kém khác phục vụ cùng một dữ liệu như URL tốn kém bị xâm phạm. Trong một thời gian, làm cho cả hai URL có thể truy cập.

Xem chuyển đổi cơ sở người dùng của bạn để phiên bản cập nhật. Điều chỉnh URL tốn kém bị xâm phạm và cuối cùng là 404. Bạn vừa giảm nhẹ vi phạm an ninh, hy vọng không mất quá nhiều. Làm lại từ đầu.

Tuyên bố miễn trừ trách nhiệm: Tôi không phải là chuyên gia bảo mật.


Nếu người dùng có ứng dụng, họ có thể khám phá URL tốn kém ngay cả khi qua SSL (khách hàng có toàn quyền kiểm soát certs, v.v.). Điều này làm cho phần còn lại của cuộc tranh luận không đề cập đến đây là ví dụ kinh điển chống lại bảo mật thông qua che khuất.
aleemb

@aleemb: Chắc chắn, bạn không thể giữ bí mật URL tốn kém. Một kẻ tấn công quyết tâm sẽ khám phá ra nó. Vấn đề là làm cho phát hiện này cũng tốn kém, do đó một "kiddie kịch bản" sẽ có thời gian (er) khó khăn và do đó ít khuyến khích để khai thác và khai thác, và làm cho việc giảm thiểu có thể. Nếu chi phí giảm thiểu của bạn thấp một cách hợp lý và chi phí phát hiện ra kẻ tấn công là cao so với bất kỳ lợi ích nào mà kẻ tấn công có thể trích xuất từ ​​việc sử dụng URL tốn kém, thì cuộc tấn công trở nên vô nghĩa. Điều này, một lần nữa, không phải là bảo mật nghiêm ngặt .
9000

5

Bạn đã có một vấn đề kinh điển mà thực sự không thể giải quyết được.

Để đảm bảo quyền riêng tư đơn giản (nghĩa là đảm bảo dữ liệu của bạn không bị rình mò hoặc thay đổi trong quá trình vận chuyển), bạn có thể thực hiện mọi thứ qua SSL và cung cấp cho máy chủ của bạn một chứng chỉ được cấp bởi CA mà iPhone nhận ra.

Tuy nhiên, đối với ủy quyền, không có giải pháp tốt nào đảm bảo 100% rằng không ai khác ngoài ứng dụng của bạn có thể truy cập API. Giải pháp đề xuất của bạn sẽ hoạt động, ngoại trừ:

  • bất cứ ai đã tải xuống ứng dụng của bạn nhất thiết phải sở hữu khóa riêng
  • nếu họ bằng cách nào đó quản lý để đóng gói ứng dụng của bạn và biên dịch lại nó, họ sẽ có khóa riêng ở dạng văn bản đơn giản
  • một khi họ có khóa riêng ở dạng văn bản đơn giản, họ có thể sử dụng nó để ký các yêu cầu độc hại của riêng họ.

Không có cách nào xung quanh điều này. Không phải nói rằng bạn không thể áp dụng cách tiếp cận đó, nhưng hãy hiểu rằng nó không phải là hoàn hảo. Chính vấn đề này khiến DRM hoàn toàn không hiệu quả .


0

Đây là những gì TLS và SSL dành cho. Một trong hai người có thể tạo kết nối an toàn mà không cần khóa bí mật cố định. Đọc phần Mô tả trên trang được liên kết để tìm hiểu cách họ thực hiện việc này.

Một cách hiệu quả để có được lợi ích của TLS / SSL mà không phải thực hiện nhiều (bất kỳ) công việc nào là để máy chủ của bạn triển khai dịch vụ web mà khách hàng truy cập bằng giao thức HTTPS. HTTPS chỉ là HTTP qua kết nối an toàn và hệ thống tải URL trong iOS triển khai nó cho bạn.


Mặc dù HTTPS không che giấu liên lạc khỏi việc nghe lén, nhưng nó không ngăn các máy khách ngẫu nhiên kết nối với điểm cuối, trừ khi máy chủ yêu cầu chứng chỉ máy khách. Điều này có thể được 'nướng vào' ứng dụng và yêu cầu một số kiến ​​thức để trích xuất.
9000
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.