2017-12-10 3 views
1

안녕하세요, 안녕안드로이드 앱 난독 화 (웹 서버 - 핑핑 | 데이터 가져 오기 (MySQL))

나는 내 안드로이드 애플 리케이션과 관련하여 질문이 있습니다. 내 데이터베이스에 플레이어의 통계를 추가하고 싶습니다. 문제는 소스 코드에 암호를 입력해야하는데 문제가 있다는 것입니다. 사람들은 내 앱을 디 컴파일 할 수 있으며 데이터베이스에 연결하여 사물을 변경할 수 있습니다.

내 플러그인을 난처하게하고 싶습니다. 그래서 저는 ProGuards를 사용하기로 결정했습니다. 이제 두 번째 문제가 있습니다 : Proguard가 Strings를 난독 화하지 않습니다. 또한, 내가 Stringer/ZKM을 사면. 이것을 deobfuscate하는 많은 deobfuscator가 있습니다. 앱 보안 방법을 모르겠습니다.

나 자신을 암호화 할 수 있지만 한 번만 암호를 해독하고 아무것도 안전하지 않습니다.

또한 PHP 게시물도 안전하지 않습니다. 사람들은 여전히 ​​그것을 조작 할 수 있습니다.

문제를 해결하려면 어떻게해야합니까?

감사합니다.

감사

+0

수 없습니다. 귀하의 MySQL pasword는 항상 얻을 수 있습니다. 앱과 데이터베이스 사이에 레이어를 만듭니다. 일부 유형의 휴식 서비스가 통계 json을 반환합니다. 또는 읽기 전용으로'stats' 테이블 만 부여한 데이터베이스 사용자를 생성하고 app에서이 사용자를 사용하십시오. – Bedla

+0

@Bedla 다른 개발자들이 어떻게 그 일을하고 있습니까? 읽기 전용으로 만 수행하는 경우 통계를 서버에 추가 할 수 없습니다. 원한다면 다른 개발자가 레이어를 조작 할 수 있다고 생각합니다. – ExampleGuy12

+1

일반적인 접근 방식은 서버에 서비스를 추가하는 것입니다. 사용자 등록시 인증 토큰을 생성하고 구체적인 사용자와 연결하여 반환하고 앱 저장소 및 데이터베이스에 저장합니다. 유지 및 통계를 얻는 동안 모든 요청에 ​​따라이 인증 토큰을 보내고 서버 측은 현재인가 토큰 (사용자)과 연관된 자원에만 액세스를 허용합니다. – Bedla

답변

1

가정 앱 사용자는 (? 아마 이메일과 비밀번호) ID의 몇 가지 종류가 해당 사용자에 대해 토큰 (일반적으로 GUID)를 사용자를 식별하고 가져 오기 위해 응용 프로그램에서 것을 사용 . 토큰과 유효 상태를 DB에 기록하여 사용자가 통계를 게시하거나 가져 오려고 할 때 확인할 수 있습니다. 토큰이 만료 된 후에 사용자가 암호를 다시 제공해야하므로 특정 시간 동안 만 토큰이 유효하도록 지정할 수 있습니다. 더 나은 보안을 위해 각각의 특정 요청에 대해 새 토큰을 요구할 수 있습니다 (관련된 공격이 발생하면 재전송 공격으로부터 보호해야합니다)

이제 토큰을 앱에 보관하고 게시 할 수 있습니다 사용자가 DB와 통신하기를 원할 때마다 통계와 함께 표시됩니다. 예를 들어 POST를 통해이 작업을 수행 할 수 있습니다. PHP 페이지 (또는 GET URL을 통해 데이터 가져 오기). 이렇게하면 요청이 올바르게 식별 된 사용자 (HTTPS를 사용하고 있다면 어쨌든 수행해야하는 경우)에서 오는 것이 확실 할 수 있으며 앱이 DB와 ​​직접 통신하지 못하도록 할 수 있습니다. 이렇게하기위한 서비스는 분명히 특정 (그리고 식별 된!) 사용자에 대한 통계를 저장하고 가져 오는 데 필요한 최소한의 논리 만 제공해야합니다.

"또한 PHP를 올리기도 안전하지 않습니다. 사람들은 아직도 조작 할 수 있습니다.는"

난 당신이 여기에 원하는 가정, 가짜를 게시에서 사용자를 중지하는 것입니다 앱 외부의 통계

간단히 말하자면 사용자가 API에 액세스하는 방법은 사용자가 요청하는 것이므로 동시에 API에 대한 액세스를 거부하는 것이므로 명확하게 수행 할 방법이 없습니다. 모순. 이 혼전의 너무 많은 대부분의 사람들이 그렇게 귀찮게하는 것을 회피하기 위해 보안 관련 논리를 모호 :

다음은 할 수있는 일입니다.

앱에 키 - 값을 포함 시키면됩니다 (다시 말해 GUID는 트릭을해야 함).이 키의 해시 + 사용자의 토큰이 각 요청과 함께 전달되어야합니다.당신은이 작업을 수행 할 수

  • 하드 코딩 별도의 요청에 키를 가져 오기 키
  • 에 액세스하려면 응용 프로그램을 컴파일하기 위해 사용자가 필요로 귀하의 응용 프로그램에 키를, 그리고 지금 모든를 업데이트하고 그때. 이는 사용자가 코드를 디 컴파일하여 찾지 못했음을 의미 할뿐만 아니라 앱이하는 것처럼 코드를 가져 오기 위해 요청을 재생함으로써 사용자를 찾지 못했음을 의미합니다.
  • 위의 두 가지 조합.

추가 할 수있는 또 다른 걸림돌은 요청을 보내는 사용자 에이전트에 대한 확인을 포함하는 것입니다. 사용자 에이전트가 앱의 요청과 일치 할 경우에만 요청이 허용되는지 확인하면 브라우저 및 기타 애플리케이션의 요청을 필터링해야합니다. 또한 자신의 헤더를 추가하여이를 제한 할 가능성을 조사 할 수도 있습니다.

이 모든 것들은 가짜 요청을 작성하여 데이터베이스에 도달하기 위해 사용자가 뛰어 넘어야하는 "후프"를 만드는 것입니다. 당신이 그들을 위해 만드는 더 번거 로울수록 덜 귀찮을 것입니다. 불행히도, 이것은 또한 앱을 만들 때 (그리고 유지할 때) 개발자로서 당신을 위해 번거 로움을 의미하며, 동기를 가진 공격자는 어쨌든 들어올 수 있습니다.

이러한 동작이 발생하고 리소스가있는 경우 사용자를 더 명확하게 식별하는 더 좋은 방법을 찾을 수 있습니다 (익명을 유지할 수없는 경우 사람들이 잘못 행동하는 가능성이 적음). 또한 비정상에 대한 요청 및 통계를 검사합니다. 완전히 비현실적인 통계가 게시되면 게시 사용자를 차단할 수 있습니다.

결국 이것은 잠재적 인 공격자를 위해 만들어야하는 문제의 양과 그렇게하기 위해 기꺼이 감당할 수있는 작업량 및 리소스의 양 사이의 균형을 깨닫게합니다.