소프트웨어의 프라이빗 API를 리버스 엔지니어링하기 위한 자습서: 소파 해킹

여행은 제 열정이며 카우치서핑의 열렬한 팬입니다. 카우치서핑(Couchsurfing)은 여행자들의 글로벌 커뮤니티로, 머물 곳을 찾거나 다른 여행자들과 자신의 집을 공유할 수 있습니다. 또한 Couchsurfing은 현지인과 교류하면서 진정한 여행 경험을 즐길 수 있도록 도와줍니다. 저는 3년 넘게 카우치서핑 커뮤니티에 참여해 왔습니다. 처음에는 모임에 참석했고, 마침내 사람들을 접대할 수 있게 되었습니다. 얼마나 놀라운 여행이었는지! 저는 전 세계에서 온 놀라운 사람들을 많이 만났고 많은 친구를 사귀었습니다. 이 모든 경험이 제 인생을 진정으로 바꿔 놓았습니다.

나는 실제로 아직 서핑을 한 것보다 훨씬 더 많은 여행자를 나 자신에게 접대했습니다. 프렌치 리비에라의 주요 관광지 중 한 곳에서 생활하면서 엄청난 양의 소파 요청을 받았습니다(성수기에는 하루에 최대 10개). 프리랜스 백엔드 개발자로서 나는 couchsurfing.com 웹사이트의 문제가 그러한 "고부하" 사례를 제대로 처리하지 못한다는 점을 즉시 알아차렸습니다. 소파 이용 가능 여부에 대한 정보가 없습니다. 새로운 소파 요청을 받았을 때 이미 누군가를 호스팅하고 있는지 확신할 수 없습니다. 승인된 요청과 보류 중인 요청을 시각적으로 표시해야 더 잘 관리할 수 있습니다. 또한 소파 이용 가능 여부를 공개할 수 있다면 불필요한 소파 요청을 피할 수 있습니다. 내가 생각하고 있는 것을 더 잘 이해하려면 에어비앤비 캘린더를 살펴보세요.

많은 회사가 사용자의 말을 듣지 않는 것으로 유명합니다. 카우치서핑의 역사를 알기에 나는 그들이 이 기능을 곧 구현하리라고 믿을 수 없었습니다. 웹 사이트가 영리 회사가 된 이후로 커뮤니티는 악화되었습니다. 내가 말하는 것을 더 잘 이해하려면 다음 두 기사를 읽는 것이 좋습니다.

• http://www.nithincoca.com/2013/03/27/the-rise-and-fall-of-couchsurfing/
• http://mechanicalbrain.wordpress.com/2013/03/04/couchsurfing-a-sad-end-to-a-great-idea/

나는 많은 커뮤니티 회원들이 이 기능을 가지고 기뻐할 것이라는 것을 알고 있었습니다. 그래서 이 문제를 해결할 수 있는 앱을 만들기로 했습니다. 사용 가능한 공개 Couchsurfing API가 없는 것으로 나타났습니다. 다음은 지원팀에서 받은 답변입니다.

"불행히도 우리 API는 실제로 공개되지 않았으며 현재 공개할 계획이 없음을 알려야 합니다."

내 소파에 침입

내가 좋아하는 소프트웨어 리버스 엔지니어링 기술을 사용하여 Couchsurfing.com에 침입할 때였습니다. 나는 그들의 모바일 앱이 백엔드를 쿼리하기 위해 일종의 API를 사용해야 한다고 가정했습니다. 그래서 모바일 앱에서 백엔드로 오는 HTTP 요청을 가로채야 했습니다. 이를 위해 로컬 네트워크에 프록시를 설정하고 HTTP 요청을 가로채기 위해 여기에 iPhone을 연결했습니다. 이런 식으로 프라이빗 API의 액세스 포인트를 찾고 JSON 페이로드 형식을 파악할 수 있었습니다.

마지막으로 나는 사람들이 소파 요청을 관리하고 서퍼들에게 소파 가용성 달력을 보여주기 위한 목적으로 웹사이트를 만들었습니다. 커뮤니티 포럼에 링크를 게시했습니다(내 의견으로는 상당히 세분화되어 있으며 정보를 찾기가 어렵습니다). 일부 사람들은 웹사이트에 couchsurfing.com 자격 증명이 필요하다는 생각이 마음에 들지 않았지만 이는 대부분 긍정적인 반응이었습니다. 이는 정말 신뢰의 문제였습니다.

웹사이트는 다음과 같이 작동했습니다. 귀하는 couchsurfing.com 자격 증명을 사용하여 웹사이트에 로그인하고 몇 번의 클릭 후에는 couchsurfing.com 프로필에 포함할 수 있는 html 코드를 얻을 수 있습니다. 짜잔 - 자동으로 업데이트된 캘린더가 있습니다. 당신의 프로필. 아래는 달력의 스크린샷이며 여기에 내가 만든 방법에 대한 기사가 있습니다.

• https://github.com/nderkach/couchsurfing-python

나는 Couchsurfing을 위한 훌륭한 기능을 만들었으며 자연스럽게 그들이 내 작업을 감사하게 여길 것이라고 생각했습니다. 나는 웹사이트, 내 이력서 및 참조에 대한 링크가 포함된 이메일을 jobs(at)couchsurfing.com 으로 보냈습니다. 내 카우치서핑 손님 중 한 명이 남긴 감사 편지:

며칠 후 그들은 나의 리버스 엔지니어링 노력에 대한 후속 조치를 취했습니다. 답장에서 그들이 염려하는 것은 보안뿐이라는 것이 분명했기 때문에 API와 웹사이트에 대해 작성한 블로그 게시물을 삭제해달라고 요청했습니다. 내 의도는 사용 약관을 위반하고 사용자 자격 증명을 찾는 것이 아니라 카우치서핑 커뮤니티를 돕는 것이었기 때문에 즉시 게시물을 삭제했습니다. 나는 내가 범죄자 취급을 받고 있다는 인상을 받았고 회사는 내 웹 사이트가 사용자 자격 증명을 요구한다는 사실에만 집중했습니다.

나는 그들에게 내 앱을 무료로 제공할 것을 제안했습니다. 환경에서 호스팅하고 Facebook 인증을 통해 연결할 수 있습니다. 결국 이것은 훌륭한 기능이며 커뮤니티에서 필요했습니다. 내가 받은 최종 해결책은 다음과 같습니다.

“우리는 휴가가 끝난 후 여기에서 상황의 스윙으로 돌아가고 있으며 후속 조치를 원했습니다.

Couchsurfing 사용자가 제3자 사이트에 자격 증명을 입력할 때 사용자 데이터의 개인 정보 보호 및 보안을 잠재적으로 손상시키지 않으면서 귀하의 응용 프로그램과 그것이 보여주는 창의성과 이니셔티브를 존중할 수 있는 방법에 대해 내부 토론을 했습니다.

달력은 현재 작업 중인 더 큰 프로젝트의 일부인 기능인 사이트의 기능 구멍을 명확하게 채웁니다.

그러나 사용자 이름과 비밀번호를 수집하는 문제는 여전히 남아 있습니다. 귀하가 해당 데이터에 액세스하거나 귀하의 사이트를 당사의 작업 제품으로 간주하지 않고 당사 측에서 호스팅하거나 지원할 수 있도록 쉽게 설정할 수 있는 방법을 찾지 못했습니다.

현재 사용 가능한 API는 곧 액세스하는 애플리케이션의 인증/승인이 필요한 버전으로 대체될 예정입니다.”

오늘 내가 이 리버스 엔지니어링 소프트웨어 튜토리얼을 작성하는 동안(이벤트 후 1년), 캘린더 기능은 여전히 ​​카우치서핑에서 구현되지 않습니다.

순수로 돌아가기 - 내 소파 해킹, 다시

몇 주 전에 저는 비공개 API를 리버스 엔지니어링하는 기술에 대한 기사를 작성하라는 영감을 받았습니다. 당연히 나는 이 주제에 대해 작성한 이전 기사를 요약하고 몇 가지 세부 사항을 더 추가하기로 결정했습니다. 새 기사를 작성하기 시작하면서 최신 API로 리버스 엔지니어링 프로세스를 보여주고 API 해킹에 대한 또 다른 스텁을 가져오고 싶었습니다. 내 이전 경험과 Couchsurfing이 최근 완전히 새로운 웹사이트 및 모바일 앱 http://blog.couchsurfing.com/the-future-of-couchsurfing-is-on-the-way/를 발표했다는 사실을 바탕으로, 저는 API를 다시 해킹하기로 결정했습니다.

이 리버스 엔지니어링 프로세스를 수행하는 이유는 무엇입니까? 음, 우선 일반적으로 소프트웨어를 리버스 엔지니어링하는 것은 매우 재미있습니다. 제가 특히 좋아하는 점은 기술뿐만 아니라 직관력도 포함된다는 것입니다. 때때로 상황을 파악하는 가장 좋은 방법은 근거 있는 추측을 하는 것입니다. 이는 무차별 대입에 비해 많은 시간을 절약할 수 있습니다. 최근에 저는 독점 API와 문서가 거의 또는 전혀 없이 작업해야 하는 회사의 이야기를 들었습니다. 그들은 며칠 동안 알 수 없는 형식의 API 응답 페이로드를 해독하는 데 어려움을 겪었고 누군가가 URL 끝에 ?decode=true 를 시도하기로 결정했고 적절한 JSON을 가지고 있었습니다. 때로는 운이 좋다면 JSON 응답을 멋지게 꾸미기만 하면 됩니다.

내가 이 튜토리얼을 하는 또 다른 이유는 일부 회사가 사용자가 요청한 특정 기능을 채택하는 데 오랜 시간이 걸리기 때문입니다. 구현되기를 기다리지 않고 프라이빗 API의 기능을 활용하여 직접 구축할 수 있습니다.

그래서 새로운 couchsurfing.com API를 사용하여 비슷한 접근 방식으로 시작하여 최신 iOS 앱을 설치했습니다.

먼저 MITM(man-in-the-middle attack)을 수행하여 앱에서 API로 오는 HTTP 요청을 위조하려면 LAN에 프록시를 설정해야 합니다.

암호화되지 않은 연결의 경우 공격은 매우 간단합니다. 클라이언트가 프록시에 연결하고 들어오는 요청을 대상 서버에 앞뒤로 중계합니다. 필요한 경우 페이로드를 수정할 수 있습니다. 공용 WLAN에서는 WiFi 라우터를 가장하여 위장한 상태에서 이 작업을 수행하는 것이 상당히 쉽습니다.

암호화된 연결의 경우 약간의 차이가 있습니다. 모든 요청이 종단 간 암호화됩니다. 공격자가 어떻게든 개인 키에 액세스하지 않는 한 메시지를 해독하는 것은 불가능합니다(물론 이러한 상호 작용 중에는 전송되지 않음). API 통신 채널이 안전하더라도 엔드포인트, 특히 클라이언트는 그렇게 안전하지 않습니다.

SSL이 제대로 작동하려면 다음 조건이 충족되어야 합니다.

• 서버의 인증서는 신뢰할 수 있는 인증 기관(CA)으로 서명해야 합니다.
• 인증서에 있는 서버의 일반 이름은 서버의 도메인 이름과 일치해야 합니다.

MITM 공격의 암호화를 극복하기 위해 프록시는 CA(인증 기관) 역할을 하고 즉석에서 인증서를 생성해야 합니다. 예를 들어 클라이언트가 www.google.com에 연결을 시도하는 경우 프록시는 www.google.com에 대한 인증서를 동적으로 생성하고 서명합니다. 이제 클라이언트는 프록시가 실제로 www.google.com이라고 생각합니다.

프라이빗 API를 리버스 엔지니어링하는 데 사용되는 스니핑 프록시를 구현하기 위해 mitmproxy라는 도구를 사용하겠습니다. 다른 투명한 HTTPS 프록시를 사용할 수 있습니다. Charles는 멋진 GUI를 가진 또 다른 예입니다. 이 작업을 수행하려면 다음을 설정해야 합니다.

전화기의 WiFi 연결 기본 게이트웨이를 프록시로 구성합니다(프록시가 중간에 있고 모든 패킷이 통과하도록) 전화기에 프록시 인증서 설치(클라이언트가 신뢰 저장소에 프록시의 공개 키를 갖도록)

인증서 설치에 대한 프록시 설명서를 확인하십시오. 다음은 mitmproxy에 대한 지침입니다. 그리고 여기 iOS용 인증서 PEM 파일이 있습니다.

가로채는 HTTP 요청을 모니터링하려면 mitmproxy를 시작하고 휴대폰에서 연결하기만 하면 됩니다(기본 포트는 8080).

모바일 브라우저에서 웹사이트를 엽니다. 이 시점에서 mitmproxy에서 트래픽을 볼 수 있어야 합니다.

모든 것이 계획대로 작동하는지 확인한 후에는 원하는 프라이빗 API 탐색을 시작할 때입니다. 기본적으로 이 시점에서 앱을 열고 가지고 놀고 API 엔드포인트 및 요청 구조에 대한 아이디어를 얻을 수 있습니다.

소프트웨어 API를 리버스 엔지니어링하는 방법에 대한 엄격한 알고리즘은 없습니다. 대부분의 경우 직관에 의존하고 가정합니다.

내 접근 방식은 API 호출을 복제하고 다양한 옵션을 사용하는 것입니다. 좋은 시작은 mitmproxy에서 포착한 요청을 재생하고 작동하는지 확인하는 것입니다(요청을 재생하려면 'r'을 누르십시오). 첫 번째 단계는 필수 헤더를 파악하는 것입니다. mitmproxy를 사용하여 헤더를 사용하는 것은 매우 편리합니다. 편집 모드로 들어가려면 'h'를 누르고 헤더를 수정하려면 'h'를 누르십시오. 그들이 사용하는 바로 가기를 사용하면 vim 중독자가 집처럼 편안하게 느낄 것입니다. Postman과 같은 브라우저 확장을 사용하여 API를 테스트할 수도 있지만 불필요한 헤더를 추가하는 경향이 있으므로 mitmproxy 또는 curl을 고수하는 것이 좋습니다.

mitmproxy 덤프 파일을 읽고 컬 문자열을 생성하는 스크립트를 만들었습니다 - https://gist.github.com/nderkach/bdb31b04fb1e69fa5346

로그인할 때 보낸 요청부터 시작하겠습니다.

 POST https://hapi.couchsurfing.com/api/v2/sessions ← 200 application/json 

내가 알아차린 첫 번째 사실은 모든 요청에 ​​매번 다른 필수 헤더 X-CS-Url-Signature 가 포함되어 있다는 것입니다. 또한 서버에 타임스탬프 확인이 있는지 확인하기 위해 잠시 후 요청을 다시 재생해 보았는데 아무 것도 없습니다. 다음으로 할 일은 이 서명이 어떻게 계산되는지 알아내는 것입니다.

이 시점에서 저는 바이너리를 리버스 엔지니어링하고 알고리즘을 파악하기로 결정했습니다. 당연히 iPhone용으로 개발한 경험이 있고 iPhone을 마음대로 사용할 수 있으므로 iPhone ipa(iPhone 앱 제공)로 시작하기로 결정했습니다. 암호를 해독하려면 탈옥 전화기가 필요합니다. 중지! 해머 타임.

그런 다음 Android 앱도 있다는 것을 기억했습니다. 나는 Android나 Java에 대해 아무것도 모르기 때문에 이 접근 방식을 시도하는 것을 약간 주저했습니다. 그러다가 새로운 것을 배울 수 있는 좋은 기회가 될 거라 생각했습니다. 고도로 최적화된 아이폰 기계어 코드보다 자바 바이트코드를 디컴파일하여 사람이 읽을 수 있는 유사 소스 코드를 얻는 것이 더 쉬운 것으로 판명되었습니다.

Apk(Android 앱 제공)는 기본적으로 zip 파일입니다. 모든 zip 추출기를 사용하여 내용물의 압축을 풀 수 있습니다. Dalvik 바이트코드인 classes.dex라는 파일을 찾을 수 있습니다. Dalvik은 Android에서 번역된 Java 바이트 코드를 실행하는 데 사용되는 가상 머신입니다.

.dex 파일을 .java 소스 코드로 디컴파일하기 위해 dex2jar이라는 도구를 사용했습니다. 이 도구의 출력은 다양한 도구로 디컴파일할 수 있는 jar 파일입니다. Eclipse 또는 IntelliJ IDEA에서 jar를 열 수도 있으며 모든 작업을 수행합니다. 이러한 도구의 대부분은 유사한 결과를 생성합니다. 우리는 그것을 실행하기 위해 다시 컴파일할 수 있는지 정말로 신경 쓰지 않습니다. 우리는 단지 소스 코드를 분석하기 위해 그것을 사용하고 있습니다.

내가 시도한 도구 목록은 다음과 같습니다.

• FernFlower(현재 IntelliJ IDEA의 일부)
• CFR
• JD-GUI
• 크라카타우
• 프로키온

CFR과 FernFlower가 저에게 가장 잘 맞았습니다. JD-GUI는 코드의 일부 중요한 부분을 디컴파일할 수 없었고 쓸모가 없었지만 나머지는 품질이 거의 같았습니다. 운 좋게도 Java 코드 코드가 난독화되지 않은 것 같지만 코드 난독화에 도움이 되는 ProGuard http://developer.android.com/tools/help/proguard.html과 같은 도구가 있습니다.

Java 디컴파일은 실제로 이 리버스 엔지니어링 튜토리얼의 범위가 아닙니다. 이 주제에 대해 많이 작성되었으므로 Java 코드를 성공적으로 디컴파일 및 해독했다고 가정해 보겠습니다.

다음 요지에서 X-CS-Url-Signature를 계산하는 데 사용되는 모든 관련 코드를 결합했습니다. https://gist.github.com/nderkach/d11540e9af322f1c1c74

먼저 RetrofitHttpClient 에서 찾은 X-CS-Url-Signature 에 대한 언급을 검색했습니다. EncUtils 모듈에 대한 특정 호출이 흥미로워 보였습니다. 파헤쳐보니 그들이 HMAC SHA1을 사용하고 있다는 것을 깨달았습니다. HMAC는 암호화 기능(이 경우 SHA1)을 사용하여 메시지의 해시를 계산하는 메시지 인증 코드입니다. 무결성(즉, 중간에 있는 사람이 요청을 수정하지 못하도록 방지) 및 인증을 보장하는 데 사용됩니다.

X-CS-Url-Signature 를 계산하려면 개인 키와 인코딩된 메시지(아마도 HTTP 요청 페이로드 및 URL의 일부 변형)가 필요합니다.

 final String a2 = EncUtils.a(EncUtils.a(a, s)); final ArrayList<Header> list = new ArrayList<Header>(request.getHeaders()); list.add(new Header("X-CS-Url-Signature", a2));

코드 a 는 메시지이고 s 는 헤더 a2 를 계산하는 데 사용되는 키입니다( EncUtils 에 대한 이중 호출은 HMAC SHA1 16진 다이제스트만 계산함).

키를 찾는 것은 문제가 되지 않았습니다. ApiModule 에 일반 텍스트로 저장되었으며 RetrofitHttpClient의 두 번째 매개변수를 초기화하는 데 사용되었습니다.

 RetrofitHttpClient a(OkHttpClient okHttpClient) { return new RetrofitHttpClient(okHttpClient, "v3#!R3v44y3ZsJykkb$E@CG#XreXeGCh"); }

EncUtils 에 대한 호출을 보면 this.b 가 정의된 경우를 제외하고 위의 문자열 리터럴이 HMAC를 계산하는 키로 그대로 사용되었음을 알 수 있습니다. 후자의 경우 this.b 에 점이 추가됩니다.

 String s; if (this.b == null) { s = this.a; } else { s = this.a + "." + this.b; }

이제 코드를 보면 this.b 가 어디서 어떻게 초기화되는지 명확하지 않았습니다(내가 발견할 수 있었던 유일한 것은 this.a(String b) 서명이 있는 메서드에서 호출된다는 것입니다 그러나 코드 어디에서나 호출을 찾을 수 없습니다).

 public void a(final String b) { this.b = b; }

나는 당신이 그것을 디컴파일하고 스스로를 찾을 것을 권장합니다 :)

메시지를 파악하는 것은 매우 간단합니다. 코드에서 이것이 URL 경로, 즉 /api/v2/sessions 와 JSON 페이로드(있는 경우)가 있는 문자열의 연결임을 알 수 있습니다.

 final byte[] b = this.b(request.getUrl()); byte[] a; if (request.getBody() != null && request.getBody() instanceof JsonTypedOutput) { System.out.println("body"); // this.a(x, y) concatenates byte arrays a = this.a(b, ((JsonTypedOutput)request.getBody()).a); } else { a = b; }

코드만 보면 HMAC 계산을 위한 정확한 알고리즘을 파악하기 어려웠다. 그래서 앱이 어떻게 작동하는지 정확히 파악하기 위해 디버깅 기호로 앱을 다시 빌드하기로 결정했습니다. apktool https://code.google.com/p/android-apktool/이라는 도구를 사용하여 smali https://code.google.com/p/smali/를 사용하여 Dalvik 바이트코드를 분해했습니다. https://code.google.com/p/android-apktool/wiki/SmaliDebugging의 가이드를 따랐습니다.

APK를 빌드한 후에는 서명하고 장치에 설치해야 합니다. 저는 Android 기기가 없었기 때문에 Android SDK와 함께 제공되는 에뮬레이터를 사용했습니다. 약간의 숟가락으로 먹이는 방법은 다음과 같습니다.

 jarsigner -verbose -keystore ~/.android/debug.keystore -storepass android -keypass android <path_to_your_built_apk> androiddebugkey jarsigner -verify -verbose -certs <path_to_your_built_apk> zipalign -v 4 <path_to_your_built_apk> <path_to_your_output_signed_apk>

SDK와 함께 제공되는 내장 Android 에뮬레이터와 HAXM이 활성화된 Atom x86 가상 이미지를 사용하여 원활하게 실행되도록 했습니다.

 tools/emulator -avd mydroid -no-boot-anim -cpu-delay 0

다음은 가상 이미지를 설정하는 방법에 대한 좋은 가이드입니다. http://jolicode.com/blog/speed-up-your-android-emulator

HAX가 작동 중이고 에뮬레이터 시작 시 에뮬레이터가 고속 가상 모드에서 실행되어 HAXM이 활성화되어 있는지 확인하십시오.

그런 다음 에뮬레이터에 APK를 설치하고 앱을 실행했습니다. apktool 가이드에 따라 IntelliJ IDEA 원격 디버거를 활용하여 에뮬레이터에 연결하고 일부 줄 중단점을 설정했습니다.

잠시 앱을 가지고 놀다가 RetrofitHttpClient 를 초기화하는 데 사용된 개인 키가 로그인 요청 서명의 HMAC를 계산하는 데 사용된다는 것을 알 수 있었습니다. 로그인 POST에 대한 응답에서 사용자 ID와 accessToken( X-Access-Token )을 받습니다. 액세스 토큰은 다음 모든 요청을 승인하는 데 사용됩니다. 모든 사후 로그인 요청에 대한 HMAC는 원래 개인 키에 .<user_id> 를 추가하여 키가 구성된다는 점을 제외하고 로그인 요청과 동일한 방식으로 구성됩니다.

권한이 부여되면 앱에서 다음 요청을 보냅니다.

 POST https://hapi.couchsurfing.com/api/v2/users/1003669205/registerDevice ← 200 application/json

경험적으로 공제할 수 있었기 때문에 이 요청은 인증을 위해 선택 사항입니다. 용도를 알면 보너스 포인트!

인증되면 다음과 같이 귀하(또는 다른 사람의 사용자 프로필)를 가져오도록 요청을 보낼 수 있습니다.

 GET https://hapi.couchsurfing.com/api/v2/users/1003669205 ← 200 application/json 

자세한 내용은 다루지 않았지만 프로필이 PUT 요청으로 업데이트되는 것을 확인했습니다. 재미삼아 같은 요청으로 다른 프로필을 업데이트하려고 했습니다. 권한이 없었기 때문에 보안 기본 사항이 구현된 것 같습니다.

나는 귀하의 couchsurfing.com 자격 증명을 사용하여 로그인하고 사용자 프로필을 가져오는 간단한 Python 스크립트를 작성했습니다: https://gist.github.com/nderkach/899281d7e6dd0d497533. API용 Python 래퍼는 다음과 같습니다. https://github.com/nderkach/couchsurfing-python pypi 저장소(pip install couchsurfing)에서 사용할 수 있는 패키지가 있습니다.

다음 단계

이번에는 API로 정확히 무엇을 할 것인지 잘 모르겠습니다. 사용자 프로필의 HTML 코드는 더 이상 허용되지 않으므로 이전 문제에 대해 다른 접근 방식을 찾아야 합니다. 나는 파이썬 API 래퍼에 대한 수요가 있다면 계속해서 개발하고 향상시킬 것이며, couchsurfing.com이 너무 많은 문제를 일으키지 않을 것이라고 가정합니다. API를 너무 많이 탐색하지 않고 몇 가지 기본적인 취약점에 대해 테스트했습니다. 충분히 안전해 보이지만 웹사이트를 통해 사용할 수 없는 데이터에 액세스할 수 있는지 알아내는 것도 흥미로울 것입니다. 어느 쪽이든, 이제 내 역 소프트웨어 엔지니어링을 사용하여 Windows Phone, Pebble 또는 스마트 소파용 대체 클라이언트를 구축할 수 있습니다.

질문으로 마무리

공개하고 싶은 토론이 있습니다. API를 공개하고 공개하지 않으시겠습니까? API를 해킹하지 못하더라도 웹사이트를 긁는 것은 가능합니다. 더 느리고 유지 관리가 더 어려울 수 있지만 확실히 소비자가 웹 스크레이퍼보다 API를 사용하는 것을 선호할 것입니다. API의 가용성은 제3자 개발자가 회사의 제품을 개선하고 이를 중심으로 부가 가치 서비스를 구축할 수 있도록 합니다. 비공개 API보다 공개 API를 유지 관리하는 것이 더 비용이 많이 든다는 주장을 할 수 있습니다. 그러나 다시 말하지만, 제품 위에 커뮤니티 구축 서비스의 이점이 API 유지 관리 비용보다 더 큽니다.

타사 클라이언트의 비공개 API 사용을 완전히 방지할 수 있습니까? 나는 그렇게 생각하지 않는다. SSL 고정을 사용하면 앞에서 설명한 간단한 투명 프록시 기술을 사용하여 API 요청을 스니핑하는 것을 방지할 수 있습니다. 결국 바이너리를 난독화하더라도 약간의 리소스와 시간을 가진 동기 부여된 해커는 항상 앱 바이너리를 리버스 엔지니어링하고 개인 키/인증서를 얻을 수 있습니다. 클라이언트 엔드포인트가 안전하다는 가정은 본질적으로 잘못된 것이라고 생각합니다. API 클라이언트는 약점입니다.

API를 비공개로 유지함으로써 회사는 기본적으로 사용자에게 불신의 메시지를 전달합니다. 물론 프라이빗 API를 더욱 보호할 수 있습니다. 그러나 악의적인 사용을 방지하기 위해 API에 대한 기본 보안을 구현하지 않겠습니까? 대신 더 나은 사용자 경험을 제공하기 위해 소프트웨어를 개선하는 데 리소스를 집중하시겠습니까?

카우치서핑, 설탕을 위에 올려놓고 API를 여세요.