0

Wir entwickeln ein iOS-Spiel, in dem einige Benutzer wahrscheinlich die Antworten ändern werden, die vom Serverless-Backedend zurückkommen, um zu betrügen (über MITM gefälschte Zertifikate). Um dem entgegenzuwirken, hätten wir gerne eine Signatur, die schwer zu verstehen ist. Diese Implementierung ist abgeschlossen (und an Serverless-Offline gearbeitet worden, aber es fällt uns schwer, aufgrund von Einschränkungen in API Gateway unbehandeltes JSON aus Lambda zurückzugeben. Wir müssen in der Lage sein, einen Snapshot unseres JSON zu erstellen, um dies sicherzustellen dass die stringifizierte Version in der gleichen Reihenfolge ist, wenn wir eine Prüfsumme nehmen, andernfalls könnte sie auf der iOS-Seite anders berechnet werden, wo sie bereits eine Zeichenfolge vor dem Aufblasen in ein Objekt ist einen String zurückgeben und API es nicht entkommen Gateway-Wie kann ich eine Antwort von API Gateway und Lambda signieren?

Zum Beispiel:

callback(null, flattened_json_string); 

liefert eine korrekte Antwort auf Serverless-Offline, da Sie eine Zeichenfolge zurückgeben können. Wenn tatsächlich in API-Gateway-hosted, wir bekommen etwas entgangen wie:

"{\"metadata\":{\"cmKey\":\"537d1a54916e56bac1d03478b18575e8c0c74d86\",\"cacheReady\":true,\"serverTime\":1467433541108},\"commands\":[]}" 

ich Möglichkeiten, weiß es in einem Block wie diese passieren, aber ich will es nicht analysiert werden und Re-Zeichenfolge und Risiko die Reihenfolge ändert sich aufgrund der Prüfsumme.

Ich bin mir auch bewusst, dass es gute Javascript-Frameworks für das Erhalten von Hasen von Objekten gibt, aber dies ist offensichtlich nicht Client-Seite auf iOS.

Antwort

0

Nach ein paar Stunden Arbeit war die Lösung eigentlich ziemlich einfach. Ich musste den Antworttyp auf Text/HTML ändern und dann stringifizieren, bevor ich zurückkomme.

Mit serverless, stelle ich die folgenden

"responseTemplates": { 
     "text/plain": "$input.path('$')" 
     } 

In meinem Code dann:

callback(null, JSON.stringify(data)); 
1

Zum Zeitpunkt des Schreibens, der Autor ein beantwortet seine eigene Frage hat, aber es gibt einige Probleme auswirken die Langzeitstabilität der Lösung.

Die richtige Lösung ist das Sortieren der Schlüssel (normalerweise in lexikalischer Reihenfolge) vor dem Kodieren oder nach dem Dekodieren des Objekts, und ein Hash (oder vielleicht besser ein HMAC?) Der kanonischen Daten - sortierte Schlüssel und Werte . Dies macht das Signieren und Verifizieren wirklich deterministisch.

Die Verwendung des falschen Inhaltstyps, um etwas zum Funktionieren zu bringen, erscheint ein wenig skizzenhaft und fragil.

Außerdem sollte es möglich sein, das Problem vollständig zu beseitigen, indem man erwartet, dass bestimmte Zertifikate vom Anwendungsserver präsentiert werden - Zertifikats-Pinning in gewisser Hinsicht. Ein böswilliger Benutzer mit einem MITM-Proxy und einem gefälschten SSL-Zertifikat hätte in diesem Fall eine rechnerisch unpraktische Zeit, in der er sich als Anwendungsserver entpuppt.

JSON Web Tokens auch scheinen vielversprechend, aber vielleicht nicht innerhalb der Grenzen der Frage.

+0

Ist es möglich, bestimmte Zertifikate vom Server zu erwarten?Wenn der Client Datenverkehr abfangen und ändern möchte, ist es in der Regel einfach, einem alternativen Stammzertifikat zu vertrauen, das die geänderten Anforderungen sofort signiert. – David

+0

Wenn es Ihr SSL-Zertifikat ist oder eines, das Sie kontrollieren, dann würden Sie es wissen der [Certificate thumbprint] (http://security.stackexchange.com/a/35694/32112), der für alle praktischen Zwecke immun gegen Manipulationen ist. Wenn Sie einen generischen Endpunkt wie 'https: // example.execute-api.us-east-1.amazonaws.com /' verwenden, sollten die Informationen dennoch einigermaßen konsistent und vorhersehbar sein, sind jedoch außerhalb Ihrer Kontrolle. –