안전한 iPhone 앱 ↔ 서버 통신


14

iOS 앱과 서버 구성 요소간에 개인 통신을 수행하는 가장 좋은 방법은 무엇입니까? 하나의 변경되지 않는 "비밀 키"가 앱 소스에 충분히 구워 졌습니까? 아니면 어떻게 든 이러한 "핸드 셰이크"키 세대를 동적으로 설정해야합니까?

서버 자체는 민감한 데이터에 액세스 할 수 없으므로 사용자가 일부 개인 엔드 포인트를 치더라도 아무 데나 가지 못하지만 공개적으로 숨기고 싶습니다. 기본적으로 iOS 앱에서 오지 않는 한 특정 경로에 도달하는 모든 요청을 무시하고 싶습니다.

중요한 경우 서버 구성 요소가 RoR에서 실행됩니다.

답변:


8

모든 고객에게 개별적으로 취소 할 수있는 개인 키를 제공하지 않으면 연결을 효과적으로 거부 할 수 없습니다. 그러나 이것은 아마도 과잉 일 것입니다. 대부분의 사람들이 총알을 발사하지 않아도 방탄 솔루션이 필요하지 않습니다.

보안 질문이므로 위협 모델 및 완화 전략을 설명하겠습니다.

눈에 띄는 비용이 발생할 수있는 URL (예 : 처리 비용)이 있고 간단한 DoS 공격과 copycat 앱 모두에서 URL을 보호한다고 가정합니다.

SSL을 사용하여 연결이 쉽게 분석되지 않도록 숨 깁니다. 비 구속 포트 번호, 경로 재 지정 시퀀스, 쿠키 교환을 사용하여 비용이 많이 드는 요청을하기 전에 연결을 약간 복잡하게하십시오. 앱에 구운 일부 비밀 코드를 사용하여 서버가 연결을 수락해야 함을 알립니다.

이제 누군가 패킷 스니퍼를 실행하거나 코드에서 URL과 유사한 문자열을 확인하여 값 비싼 URL을 배울 수 없습니다. 잠재적 인 공격자는 앱을 디 컴파일해야합니다.

코드가 디 컴파일되거나 디버거에서 실행되는 것을 실제로 보호 할 수는 없습니다. 공격자는 결국 비밀 키와 연결 순서를 알게됩니다.

비용이 많이 드는 URL에서 공격의 형태로, 또는 실행하기 위해 서비스에 액세스해야하는 copycat 앱의 형태로 또는 악용 코드가 공개적으로 게시 된 루즈 요청을 받기 시작했습니다. 하지만 합법적 인 요청에서 불량 요청을 말할 수는 없습니다.

다른 비밀 키를 사용하여 앱을 무료로 업데이트하십시오. 손상된 고가의 URL과 동일한 데이터를 제공하는 다른 고가의 URL을 공격해야합니다. 얼마 동안 두 URL에 모두 액세스 할 수있게하십시오.

사용자 기반이 업데이트 된 버전으로 전환되는 것을보십시오. 손상된 비용이 많이 드는 URL을 조절하고 결국 404로 만듭니다. 너무 많이 잃지 않고 보안 위반을 완화했습니다. 원점으로 돌아가다.

면책 조항 : 저는 보안 전문가가 아닙니다.


사용자가 앱을 가지고 있다면 SSL을 통해 (클라이언트가 인증서 등을 완전히 제어하는 ​​경우에도) 비용이 많이 드는 URL을 발견 할 수 있습니다. 이것은 논쟁의 나머지 부분이 모호함을 통한 보안에 대한 고전적인 예라는 것은 말할 것도 없습니다.
aleemb

@aleemb : 확실히, 당신은 값 비싼 URL을 완전히 비밀로 유지할 수 없습니다. 결정된 공격자가이를 발견 할 것입니다. 요점은이 발견을 비용이 많이 들게하여 "스크립트 아동"이 시간을 들여 파헤쳐 서 활용하고 완화 할 수있는 인센티브를 줄 이도록하는 것입니다. 완화 비용이 합리적으로 낮고 공격자가 발견 한 비용이 공격자가 고가의 URL을 사용하여 추출 할 수있는 것보다 높은 경우 공격은 무의미 해집니다. 이것은 다시 엄격한 보안 이 아닙니다 .
9000

5

당신은 가지고있어 고전적인 문제를 정말 해결 될 수 없습니다.

간단한 프라이버시 를 보장하기 위해 (즉, 데이터가 스누핑되거나 전송 중에 변경되지 않도록하기 위해 ) SSL을 통해 모든 작업을 수행하고 iPhone이 인식하는 CA에 의해 서버에 올바르게 발급 된 인증서를 제공 할 수 있습니다.

그러나 승인을 위해 앱 이외의 다른 사람이 API에 액세스 할 수 없음을 100 % 보장하는 좋은 솔루션은 없습니다. 제안 된 솔루션 다음을 제외하고 작동합니다.

  • 앱을 다운로드 한 사람은 반드시 개인 키를 소유하고 있어야합니다
  • 그들이 어떻게 든 앱의 패키지를 풀고 디 컴파일하면 일반 키로 개인 키를 갖게됩니다
  • 개인 키가 일반 텍스트로 된 후에는이를 사용하여 자신의 악의적 인 요청에 서명 할 수 있습니다.

이 문제를 해결할 방법이 없습니다. 그것은 당신이 그 접근법을 채택 할 수 없다고 말하는 것이 아니라, 그 방법이 완벽하지 않다는 것을 이해합니다. DRM을 완전히 비효율적으로 만드는 것은 바로이 문제입니다 .


0

이것이 TLS와 SSL 의 목적입니다. 고정 비밀 키가 없어도 보안 연결을 만들 수 있습니다. 링크 된 페이지의 설명 섹션을 읽고 어떻게하는지 알아보십시오.

많은 작업을 수행하지 않고도 TLS / SSL의 이점을 얻는 효과적인 방법은 서버가 클라이언트가 HTTPS 프로토콜을 사용하여 액세스하는 웹 서비스를 구현하도록하는 것입니다. HTTPS는 보안 연결을 통한 HTTP 일 뿐이며 iOS의 URL로드 시스템이이를 구현합니다.


HTTPS는 도청에서 통신을 숨기는 반면 서버에서 클라이언트 인증서가 필요하지 않은 한 임의의 클라이언트가 엔드 포인트에 연결하는 것을 막지 않습니다. 이것은 앱에 '구워 질'수 있으며 추출하는 데 약간의 지식이 필요합니다.
9000
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.