데이터 수신 / 설정을 위해 .Net API에 연결하는 Android 애플리케이션이 있다고 가정 해 보겠습니다. 내가 가진 혼란은 사용자를 처음 등록 / 로그인하고 API에 요청할 때마다 인증하는 방법에 관한 것입니다.
사용할 수있는 다른 패턴과 가장 효율적이고 안전한 패턴은 프로세스 흐름 만 있으면됩니다. 누군가가 Facebook, FourSquare 또는 Twitter와 같은 유명한 Android 애플리케이션이 모바일 애플리케이션에서 서버로 들어오는 모든 요청을 인증하는 데 사용하는 방법을 말해 줄 수 있습니까?
공개 정보가 아닌 경우 미리 죄송합니다.
답변:
나는 그들이 "토큰"기반 보안 시스템을 사용한다고 생각한다. 그래서 암호는 실제로 어디에도 저장되지 않고 단지 처음 인증에 사용된다. 따라서 앱은 처음에 사용자 이름 / 암호 (ssl을 통해)를 게시하고 서버는 앱이 저장하는 토큰을 반환합니다. 후속 동기화 시도의 경우 토큰이 먼저 전송되고 서버는 토큰이 유효한지 확인한 다음 다른 데이터가 게시되도록 허용합니다.
서버가 인증 시도를 다시 요청할 수 있도록 토큰이 만료되어야합니다.
Android 프레임 워크 내에서 동기화 어댑터에 연결하면 내부에서 모두 동기화 및 인증 할 수 있습니다.
http://developer.android.com/training/sync-adapters/creating-sync-adapter.html
기기의 설정에서 계정을 확인하면 무슨 뜻인지 알 수 있습니다.
기본적으로이 유명한 것은 OAuth 프로토콜 (1) / 프레임 워크 (2)를 사용합니다. 표준이어야하지만 각각은이 프로토콜 / 프레임 워크의 다른 구현을 가졌습니다. 따라서 통합에 관해서는 매우 조심해야합니다.
예 : Dropbox는 여전히 OAuth 1을 사용하고 있으며 최근에 OAuth 2 지원을 제안했습니다.
Back to Answer, peterpan이 말했듯이 토큰 기반 인증 방식은 일회성이며 방정식에서 벗어난 것입니다.이 토큰은 만료되거나 경우에 따라 개발자에게 권한이 부여됩니다.
흥미로운 점은 클라이언트 응용 프로그램이 위험한 사용자 이름, 암호를 유지하도록 허용하는 대신 리소스 액세스 범위를 정의 할 수 있다는 것입니다.
이것이 어떻게 작동하는지에 대한 기본적인 그림입니다.
요즘이 분야에서 일하고 있기 때문에 자세한 내용을 얻은 후에 답변을 업데이트 할 것입니다. :)
사용자 이름 / 암호 기반 인증 만 사용하면 충분히 안전하지 않습니까?
아니요, API 서버에 액세스하는 WHO 만 식별하고 액세스하는 WHAT 는 식별 하지 않기 때문입니다.
WHO 와 API 서버에 액세스하는 WHAT 의 차이점을 더 잘 이해하기 위해 다음 그림을 사용하겠습니다.
의도 된 커뮤니케이션 채널은 악의적 인 의도없이 합법적 인 사용자가 예상대로 사용하고있는 모바일 앱을 의미하며, 조작되지 않은 버전의 모바일 앱을 사용하고 중간자 공격을받지 않고 API 서버와 직접 통신합니다.
실제 채널은 모바일 앱의 리 패키지 버전을 사용하는 악의적 인 의도를 가진 합법적 인 사용자, 모바일 앱의 정품 버전을 사용하는 해커, 중간에있는 사람이 어떻게 공격하는지 등 여러 가지 시나리오를 나타낼 수 있습니다. API에 대한 공격을 자동화 할 수 있도록 모바일 앱과 API 서버 간의 통신이 수행되고 있습니다. 다른 많은 시나리오도 가능하지만 여기서 각각을 열거하지는 않겠습니다.
지금 쯤이면 WHO 와 WHAT이 왜 가 동일하지 않은 겠지만, 그렇지 않다면 곧 명확해질 것입니다.
WHO 우리가, 인증 권한을 부여하고 오픈 ID 연결 또는 OAUTH2 흐름을 사용하는 것과 같이 여러 가지 방법으로 식별 할 수있는 모바일 앱의 사용자입니다.
일반적으로 OAuth는 클라이언트에게 리소스 소유자를 대신하여 서버 리소스에 대한 "보안 위임 액세스"를 제공합니다. 리소스 소유자가 자격 증명을 공유하지 않고 서버 리소스에 대한 타사 액세스 권한을 부여하는 프로세스를 지정합니다. HTTP (Hypertext Transfer Protocol)와 함께 작동하도록 특별히 설계된 OAuth는 기본적으로 리소스 소유자의 승인을 받아 권한 부여 서버에서 타사 클라이언트에 액세스 토큰을 발급 할 수 있도록합니다. 그런 다음 타사는 액세스 토큰을 사용하여 리소스 서버에서 호스팅하는 보호 된 리소스에 액세스합니다.
OpenID Connect 1.0은 OAuth 2.0 프로토콜 위에있는 간단한 ID 계층입니다. 이를 통해 클라이언트는 권한 부여 서버에서 수행 한 인증을 기반으로 최종 사용자의 신원을 확인하고 상호 운용 가능하고 REST와 유사한 방식으로 최종 사용자에 대한 기본 프로필 정보를 얻을 수 있습니다.
사용자 인증은 API 서버가 알려 수 있지만 WHO API를 사용하고,이 요청이 유래 한 것을 보장 할 수 없습니다 무엇 당신이, 모바일 앱의 원래 버전을 기대합니다.
이제 우리는 식별 할 수있는 방법이 필요 무엇 API를 서버를 호출하고, 여기 일이 대부분의 개발자가 생각하는 것보다 더 까다하게된다. 무엇 API를 서버에 요청하는 것입니다. 실제로 모바일 앱의 진짜 인스턴스입니까, 아니면 봇, 자동화 된 스크립트 또는 Postman과 같은 도구를 사용하여 API 서버를 수동으로 조작하는 공격자입니까?
놀랍게도 모바일 앱의 리 패키지 버전을 사용하는 합법적 인 사용자 중 하나이거나 애플리케이션에서 제공하는 서비스를 게임 화하고 활용하려는 자동화 된 스크립트 일 수 있다는 사실을 알게 될 수 있습니다.
글쎄, 무엇 을 식별하기 위해 개발자는 일반적으로 모바일 앱의 코드에 하드 코딩하는 API 키에 의존하는 경향이 있습니다. 일부 개발자는 모바일 앱에서 런타임에 추가 작업을 수행하여 키를 계산하므로 정적 비밀이 코드에 포함 된 이전 접근 방식과 달리 런타임 비밀이됩니다.
위의 글은 내가 작성한 기사에서 발췌 한 것입니다. 모바일 앱에 API 키가 필요한 이유는 무엇입니까? 여기 에서 전체를 읽을 수 있습니다 .이 기사는 API 키에 대한 일련의 기사 중 첫 번째 기사입니다.
물론 보안상의 이유로 사용자 이름 / 암호를 장치에 저장할 수 없습니까? 가입 할 때 모든 사용자에 대해 GUID를 발급하고 장치에 저장하고 API 요청 중에 매번 검색해야합니까?
암호화 된 경우라도 장치에 저장하는 모든 것은 Frida 또는 Xposed와 같은 도구를 사용하여 런타임 중에 리버스 엔지니어링 할 수 있습니다.
자신의 스크립트를 블랙 박스 프로세스에 삽입합니다. 모든 기능을 연결하고, 암호화 API를 스파이하거나, 비공개 애플리케이션 코드를 추적하고, 소스 코드가 필요하지 않습니다. 편집하고 저장을 누르면 즉시 결과를 볼 수 있습니다. 컴파일 단계 나 프로그램 재시작없이 모두 가능합니다.
Xposed는 APK를 건드리지 않고 시스템 및 앱의 동작을 변경할 수있는 모듈 용 프레임 워크입니다. 이는 모듈이 변경없이 다른 버전 및 ROM에서도 작동 할 수 있다는 것을 의미하기 때문에 훌륭합니다 (원본 코드가
공격자가 제어하는 장치에서 공격자는 프록시를 사용하여 Man in the Middle 공격을 수행하여 Man in the Attack으로 API 키를 훔치는 기사에서 보여 주듯이 WHAT 또는 WHO 를 식별하는 데 사용할 수있는 비밀을 추출 할 수도 있습니다. :
JNI / NDK와 같은 고급 기술을 사용하여 모바일 앱 코드에서 API 키를 숨길 수는 있지만 API 키를 훔치기 위해 누군가가 MitM 공격을 수행하는 것을 방해하지는 않습니다. 실제로 MitM 공격은 개발자가 아닌 사람도 달성 할 수있을 정도로 쉽습니다.
이제 어떻게 ... API 서버가 남용되지 않도록 보호 할 수 없을 정도의 운명입니까 ??? 조용하지 않기 때문에 ... 희망은 여전히 존재합니다 !!!
누군가가 Facebook, FourSquare 또는 Twitter와 같은 유명한 Android 애플리케이션이 모바일 애플리케이션에서 서버로 들어오는 모든 요청을 인증하는 데 사용하는 방법을 말해 줄 수 있습니까?
죄송합니다.이 앱에 대한 지식이 부족하여 여러분을 설명 할 수는 없지만 다른 접근 방식을 알려 드릴 수 있습니다.
사용할 수있는 다른 패턴과 가장 효율적이고 안전한 패턴은 프로세스 흐름 만 있으면됩니다.
따라서 클라이언트 측에서 실행되고 API에 액세스하기 위해 약간의 비밀이 필요한 모든 것은 다른 방식으로 악용 될 수 있으며 모바일 API 보안 기술에 대한 이 일련 의 기사 에서 자세히 알아볼 수 있습니다 . 이 기사에서는 API 키, 사용자 액세스 토큰, HMAC 및 TLS 고정을 사용하여 API를 보호하는 방법과이를 우회하는 방법을 설명합니다.
모바일 앱에 액세스 하는 WHAT 의 문제를 해결하려면 위에서 언급하고 API 서버에 대한 무단 액세스 만 더 어렵게 만들 수 있다는 것을 받아 들인 모바일 API 보안 기술에 대한 일련의 기사에서 언급 된 하나 또는 모든 솔루션을 사용해야합니다. 우회하지만 불가능하지는 않습니다.
API 서버가 정품 모바일 앱의 요청 만 수신하고 있음을 알 수있는 모바일 앱 증명 솔루션을 사용하면 더 나은 솔루션을 사용할 수 있습니다.
모바일 앱 증명 솔루션을 사용하면 API 서버가 요청을 보내는 것이 무엇 인지 알 수 있으므로 안전하지 않은 소스의 다른 모든 요청은 거부하고 정품 모바일 앱의 요청에만 응답 할 수 있습니다.
모바일 앱 증명 솔루션의 역할은 런타임에 모바일 앱이 변조되지 않았는지, 루팅 된 장치에서 실행되지 않았는지, xPosed 또는 Frida와 같은 프레임 워크에 의해 계측되지 않았으며 MitM 공격을받지 않았 음을 보장하는 것입니다. 백그라운드에서 SDK를 실행하면됩니다. 클라우드에서 실행되는 서비스는 앱에 도전하고 응답을 기반으로 모바일 앱과 실행중인 장치의 무결성을 증명하므로 SDK는 어떠한 결정에도 책임을지지 않습니다.
모바일 앱 무결성을 성공적으로 증명하면 단기 JWT 토큰이 발급되고 클라우드의 API 서버 및 모바일 앱 증명 서비스 만 인식하는 비밀로 서명됩니다. 모바일 앱 증명에 실패한 경우 JWT 토큰은 API 서버가 알지 못하는 비밀로 서명됩니다.
이제 앱은 모든 API 호출과 함께 요청 헤더에서 JWT 토큰을 보내야합니다. 이렇게하면 API 서버가 JWT 토큰에서 서명 및 만료 시간을 확인할 수있을 때만 요청을 처리하고 확인에 실패하면 거부 할 수 있습니다.
모바일 앱 증명 서비스에서 사용하는 비밀이 모바일 앱에 알려지지 않으면 앱이 변조되거나, 루팅 된 장치에서 실행되거나, 연결을 통해 통신하는 경우에도 런타임에이를 리버스 엔지니어링 할 수 없습니다. 중간 공격의 대상입니다.
모바일 앱 증명 서비스는 iOS, Android, React Native 등을 포함한 여러 플랫폼 용 SDK를 제공하는 Approov (저는 여기서 일합니다)의 SAAS 솔루션으로 이미 존재합니다. 또한 통합에는 클라우드 서비스에서 발행 한 JWT 토큰을 확인하기 위해 API 서버 코드에서 작은 확인이 필요합니다. 이 검사는 API 서버가 제공 할 요청과 거부 할 요청을 결정할 수 있도록하는 데 필요합니다.
결국, API 서버를 보호하기 위해 사용할 솔루션은 유럽의 GDPR 규정과 같이 보호하려는 데이터의 가치와 해당 유형의 데이터에 대한 법적 요구 사항에 따라 선택해야합니다.
OWASP 모바일 보안 프로젝트는 개발자와 보안 팀이 안전한 모바일 애플리케이션을 구축하고 유지하는 데 필요한 리소스를 제공하기위한 중앙 집중식 리소스입니다. 이 프로젝트를 통해 우리의 목표는 모바일 보안 위험을 분류하고 개발 제어를 제공하여 악용의 영향이나 가능성을 줄이는 것입니다.
나는 정확히 똑같은 것을 찾고 있었고 peterpan이 말한 것과 같은 Google 방식을 찾았지만 Google API를 통해 찾았습니다. 이 링크를 시도하고 그것을 통해 당신의 방법을 Google, 나도 시작합니다! 나는 그것에있는 동안 새로운 정보를 게시 할 것이다!
사용자 이름과 암호는 SharedPreferences에 배치 할 때 안전 할 수 있습니다 . https를 사용하여 서버에 연결하는 것도 좋습니다.