앱 백엔드 통신 보안 방법

하나의 iOS 앱과 apns (Apple Push Notifications)를 관리하기 위해 지금까지 사용하고있는 작은 백엔드가 있습니다. 등록 프로세스는 백엔드에 대한 매개 변수가 포함 된 GET 호출 일 뿐이며 '인증'또는 다른 종류의 제어가 없기 때문에 누구나 허위 장치를 등록하여 백엔드에 과부하가 걸릴 수 있습니다.앱 백엔드 통신 보안 방법

따라서 중요한 질문은 인증이 없을 때 어떻게 이런 종류의 앱 전송 정보 - 백엔드 전송을 안전하게 할 수 있습니까?

장치를 등록 할 때 응용 프로그램이 제공해야하는 토큰을 사용 HASH의 어떤 종류를 생성하는 내 마음에 오는 하나 개의 간단한 아이디어 ...

출처

2014-02-17 apascual

이 문제를 완전히 해결할 방법이 없습니다. 연결중인 앱인지는 알 수 없습니다. 당신이 할 수있는 일은 약간의 난독 화를 추가하는 것입니다.

가장 좋은 첫 번째 단계는 SSL with a pinned certificate을 사용하여 Man-in-the-Middle 공격을보다 세게 수행하는 것입니다. 클라이언트 측 인증서는 도움이 될 수 있지만 설치하는 데 약간의 어려움이 있으며 다른 솔루션보다 훨씬 많은 것을 사지 않을 것입니다.

고정 된 인증서와 SSL이있는 경우 GET과 함께 공유 암호를 보내는 것만으로도 충분할 것입니다. 비밀을 오래된 것에서부터 다른 것으로 바꿀 수 있도록 변경하십시오. 누군가가 고정 된 인증서를 이길 정도로 앱을 리버스 엔지니어링 한 경우 (또는 공유 된 비밀을 직접 읽는 경우), 나머지 모든 접근 방식도 중단됩니다.

는 그럼에도 불구하고, 여기에 약간의 여분의 층을 추가하는 것이 좀 더있다 :

Bidirectional shared-secret verification with AES 좋은 간단한 방법입니다,하지만 (단일 GET와 함께 할 수없는 즉,) 악수를 필요로한다. 물론 단방향으로 구현할 수는 있지만 (서버가 클라이언트가 아닌 키를 확인하기 때문에) 핸드 셰이크가 필요합니다.

인증 토큰을 단일 GET으로 유지하려는 경우 SSL 인증서를 고정 할 수 없으며 GET을 멱등환으로 만들 수 있습니다 (올바른 REST 호출이 있어야 함). 이는 간단한 구현입니다.

하는 구조의 GET 요청
계산 HMAC (SHA-256, 공유 비밀 얻을 요청, 16 바이트)
는 GET 요청

iOS에서 함께 HMAC 보내기,이 보일 것이다 그래서 같은 메시 링 :

NSData *key = ...random 32 bytes shared with server...; 
NSURLRequest *request = ...; 

// Allocate some memory for the HMAC 
NSMutableData *hmac = [NSMutableData dataWithCapacity:CC_SHA256_DIGEST_LENGTH]; 

// Convert your URL into data. This assumes that this is a GET request, so the URL 
// has everything. This also assumes that the GET is idempotent, so if someone 
// replays this GET request, you don't care. 
NSData *requestData = [[[request URL] absoluteString] dataUsingEncoding:NSUTF8StringEncoding]; 

// Compute the HMAC 
CCHmac(kCCHmacAlgSHA256, 
     [key bytes], 
     [key length], 
     [requestData bytes], 
     [requestData length], 
     [hmac mutableBytes]); 

// Truncate the HMAC (this is common practice. It's slightly better, and at least no 
// worse, to send half the HMAC rather than the whole HMAC). 
NSData *token = [hmac subdataWithRange:NSMakeRange(0, [hmac length]/2)]; 

NSURLRequest *finalRequest = ... add the token to your request ...

물론 서버 측에서 같은 것을 계산할 것입니다. 이것을 "GET 서명"이라고 생각할 수 있습니다. 귀하의 요청이 멱등수가 아니라면, 어쨌든 그것을 고치기 위해 정말로 노력해야합니다. 문제를 해결할 수 없으면 타임 스탬프를 해시에 통합하고 너무 오래되었거나 이전에 본 요청을 버릴 수 있습니다. (이렇게하면 GET 멱등수를 만들었습니다 ....)

앱을 업그레이드하면 공유 비밀을 변경해야합니다. 그렇게하면 결국 발견 된 오래된 공유 비밀을 노화시킬 수 있습니다.

예, 모두 리버스 엔지니어링 할 수 있습니다. (사용자가 아닌) 앱을 인증하려고 시도하는 모든 내용을 리버스 엔지니어링 할 수 있습니다. 그러므로 단순하게 유지하고 일어난다면 어떻게 회복 할 것인가에 더 집중하십시오.

가능한 경우 사용자 인증을 추가하십시오. 그것은 훨씬 더 강력합니다.

출처

2014-02-17 16:20:36

감사합니다.이 답변이 더 완전합니다! 정답으로 표시 ... – apascual

이 해시 아이디어 (일 사소한 참고해야 SHA-256 같으면 MD5는 더 이상 안전하지 않다.)하지만 트레이드 오프 (trade-off)에 달려있다. 서비스가 정말로 중요한 것을 포함한다면 클라이언트 측 SSL 인증서가 가장 좋은 방법이다.

출처

2014-02-17 15:23:29 theMarceloR

감사합니다. 클라이언트 측 인증에 대한 두려움은 결국 앱이 디 컴파일 될 수 있고 인증서가 더 이상 신뢰할 수 없다는 것입니다. 맞습니까? – apascual

iOS 장치에서 들어오지 않는 HTTP GET 요청을 삭제할 수 있습니다 (서버 측 처리를 생성하는 요청 수를 줄여야 함). 백엔드 앱에서 http 헤더를 캡처하기 만하면됩니다. – theMarceloR

하지만 누군가가 요청에서 사용자 에이전트를 위조 할 수 있으므로 실제 iOS 장치가 있는지 여부를 알 수 없습니다. – apascual

장치에있는 모든 것은 정해진 공격자가 사용할 수 있습니다.

APN 토큰을 등록 할 때 문제의 토큰에서 장치에 대한 해시를 생성하고 백엔드로 보냅니다. HTTPS를 사용하십시오.

가짜 등록으로 백엔드에 과부하를 걸려면 해시가 생성 된 방법을보기 위해 앱을 디 컴파일해야합니다.

서버가 장치 등록시 토큰에 대한 해시를 확인하도록하십시오.

등록 할 때 장치 IP 번호와 타임 스탬프를 저장하십시오. 동일한 IP 번호에서 합당하지 않은 금액의 등록이있는 경우 등록을 보류하고 사람이 상황을 검토하게하십시오. 모든 것이 OK라면 등록을 해제하십시오.

출처

2014-02-17 16:21:51

답변과 훌륭한 아이디어에 감사드립니다! – apascual

앱 백엔드 통신 보안 방법

답변

관련 문제