Nach In-App-Kauf sende Daten sicher zu Webserver

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Nach In-App-Kauf sende Daten sicher zu Webserver

    Moin zusammen,

    ich bastel gerade an einer ersten App mit In-App-Käufen. Der In-App-Kauf-Prozess war überraschend einfach implementiert, aber ich jetzt
    bin ich an einem Punkt wo ich nicht weiter komme und hoffe, dass ihr einen Tip habt.

    Es geht darum, dass wenn ein User einen In-App-Kauf tätigt, soll die App nach erfolgreicher Bezahlung Daten per PHP in eine MySQL Datenbank schreiben.

    Die Verbindung zur Datenbank ist bereits fertig, aber ich mache mir Sorgen über die Sicherheit dieser Verbindung, denn aktuell ist es so,
    dass wenn der In-App-Kauf abgeschlossen ist, wird einfach nur eine Domain per POST aufgerufen, zwei Variablen (Name und Telefonnummer) übermittelt,
    dass ganze in die Datenbank eingetragen und die App zeigt dann wiederum diese Daten an allen anderen Usern an.

    Leider reicht meine Kenntnis nicht aus, um sagen zu können, ob der Aufruf zur Datenbank (per POST) mitgeschnitten werden könnte
    und so z.B. per PC über Postman oder ein anderes Tool gefaket werden könnte.

    Daher frage ich mich ob ihr eine Idee habt, wie ich entweder dafür sorgen kann das der Webserver prüft, dass die Verbindung zu 100% von
    der App stammt oder aber wie ich serverseitig (per PHP) prüfen kann, ob der Kauf bei Apple tatsächlich stattgefunden hat?

    Vielen lieben Dank für eure Hilfe!

    Viele Grüße
    David
  • gritsch schrieb:

    https verwenden und das zertifikat in der app überprüfen (erfordert natürlich auch dass du weist welchen zertifikatherausgeber du in den nächsten jahren verwenden wirst).
    Hey gritsch,

    vielen Dank für den Tip! Also Https benutze ich bereits. All-Inkl (Hoster) bietet die Möglichkeit LetsEncrypt einzubinden oder zu verwenden.

    Aber wie meinst du das "in der app überprüfen"?

    Würde ich dann nicht nur prüfen, ob die Verbindung von der App zum richtigen Server stattfindet?

    Viele Grüße
    David
  • gritsch schrieb:

    Du musst dann einfach sicherstellen dass das cert gütlig und von LE ist.
    Ansonsten kann jemand sein eigenes selfsigned cert verwenden um die verbindung mitzulesen.
    Ah ok verstehe, dass sollte dann von All-Inkl wohl gültig sein. Ich kenne mich mit den Zertifikaten leider so gar nicht aus,
    aber so wie ich dich verstehe heißt das, wenn das Zertifikat gültig ist, ist es unmöglich ausgehende Verbindungen aus der App zum Server mitlesen?

    Sprich es ist unmöglich rauszufinden, welche URL angesprochen und welche POST Variablen übergeben werden?

    Viele Grüße
    David
  • du musst prüfen dass es gültig ist und dass es von LetsEncrypt ist (AllInkl ist keine CA).
    Unmöglich ist es damit nicht (jailbreak...) aber macht es schon mal viel schwerer als einfach nur seinen proxy dazwischen zu hängen.

    Edit: du kannst natürlich noch zusätzlich deine daten mit einem hardgecodeten wert salzen und hashen. Der Server verarbeitet die Daten dann nur wenn die hashes korrekt sind.
    Mit einem gejailbreakten gerät findet man aber natürlich auch den hardcodierten wert raus und den hash-algo.
    Oder du verschlüsselt die daten mit dem hardcodierten key und entschlüsselst es am server wieder.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von gritsch ()

  • gritsch schrieb:

    du musst prüfen dass es gültig ist und dass es von LetsEncrypt ist (AllInkl ist keine CA).
    Unmöglich ist es damit nicht (jailbreak...) aber macht es schon mal viel schwerer als einfach nur seinen proxy dazwischen zu hängen.

    Ok das werde ich dann noch einmal bei All-Inkl prüfen danke für die Erklärung!


    gritsch schrieb:


    Edit: du kannst natürlich noch zusätzlich deine daten mit einem hardgecodeten wert salzen und hashen. Der Server verarbeitet die Daten dann nur wenn die hashes korrekt sind.
    Mit einem gejailbreakten gerät findet man aber natürlich auch den hardcodierten wert raus und den hash-algo.
    Oder du verschlüsselt die daten mit dem hardcodierten key und entschlüsselst es am server wieder.

    Ja du sagst es genau daran tüftele ich gerade. Egal wie man es dreht, am Ende kommt man doch irgendwie an die Verbindung / URL / POST-Daten.

    Das muss doch eine Möglichkeit geben, die Verbindung serverseitig zu prüfen?

    Das Problem ist der Ablauf innerhalb der App:

    Eine Art Community.

    1. Man sieht Daten
    2. Man möchte Daten anbieten und macht In-App-Kauf
    3. Bei erfolgreichem In-App-Kauf mache Eintrag in die Datenbank mit den Daten

    So der Ablauf und das Problem ist der Eintrag in die Datenbank. Denn findet jemand die URL die aufgerufen wird und die POST Variablen raus,
    kann man leider sehr leicht diesen Aufruf an den Server faken, was wiederum bedeutet, dass die Daten kostenfrei hinzugefügt werden können.

    Ich hatte die Idee mit dem salzen und hashen bereits probiert. Selbst mit verschiedenen Frameworks für Verschlüsselung und sichere Verbindungen
    krieg ich das nicht gelöst, da am Ende immer der Aufruf des Servers stattfindet.

    Vielleicht fällt dir eine Möglichkeit ein oder jemand anderes schaltet sich noch mit dazu. Danke dir für deine Zeit!
  • Wenn deine Software auf fremder Hardware läuft, wirst du das nie vollständig verhindern können außer Apple gibt dir für die In-App-Käufe daten welche du dann bei Apple überprüfen kannst (also ob der kauf stattgefunden hat und für deine App und diese funktion ist). von AIP hab ich aber absolut keine Ahnung.
  • gritsch schrieb:

    Wenn deine Software auf fremder Hardware läuft, wirst du das nie vollständig verhindern können außer Apple gibt dir für die In-App-Käufe daten welche du dann bei Apple überprüfen kannst (also ob der kauf stattgefunden hat und für deine App und diese funktion ist). von AIP hab ich aber absolut keine Ahnung.
    Stimmt ja, anscheint gibt es die Möglichkeit per PHP einen In-App-Kauf zu verifizieren. Wie das genau funktioniert habe ich noch nicht ganz verstanden, aber ich glaube das ist der richtige Weg. Sollte ich dazu etwas rausbekommen, schreibe ich hier noch eine Info für diejenigen, die eventuell das gleiche Problem haben.

    Ich danke dir aber erst einmal für deine Unterstützung!
  • NSObject schrieb:

    Eine URL ist öffentlich und Datenverkehr kann man mitschneiden, verändern und wieder einspielen. Sieh Dir mal mitmproxy, Charles, wireshark, bettercap an.
    Moin NSObject,

    danke für deine Unterstützung! Die Programme kannte ich noch gar nicht, aber erschreckend wie einfach es ist den Verkehr mitzuschneiden.

    Hat irgendjemand vielleicht eine Idee, wie ich den Kaufprozess anders aufbauen könnte, um dem Problem mit dem Mitlesen der Daten aus dem Weg gehen zu können?

    Es wäre mir eigentlich völlig egal,s das jemand die Verbindung mitliest, wenn nicht der Sinn der App dadurch komplett zerstört werden würde. Daher hoffe ich auf eure Unterstützung! Vielen Dank!
  • DKCode schrieb:

    Es wäre mir eigentlich völlig egal,s das jemand die Verbindung mitliest, wenn nicht der Sinn der App dadurch komplett zerstört werden würde. Daher hoffe ich auf eure Unterstützung! Vielen Dank!
    Das Mitlesen kann dir ja egal sein, du musst nur dafür sorgen dass niemand solch gültige events senden kann. Dazu schickst du die IAP-receipts beim request mit und validierst den dann am server. Wenn er valide ist fügst du die daten ein, andernfalls gibst du einfach ein "WTF" aus ;)
  • gritsch schrieb:

    DKCode schrieb:

    Es wäre mir eigentlich völlig egal,s das jemand die Verbindung mitliest, wenn nicht der Sinn der App dadurch komplett zerstört werden würde. Daher hoffe ich auf eure Unterstützung! Vielen Dank!
    Das Mitlesen kann dir ja egal sein, du musst nur dafür sorgen dass niemand solch gültige events senden kann. Dazu schickst du die IAP-receipts beim request mit und validierst den dann am server. Wenn er valide ist fügst du die daten ein, andernfalls gibst du einfach ein "WTF" aus ;)

    Du sagst es! So ist zumindest der Plan und ich hoffe, dass das Validieren per PHP irgendwann bei mir funktioniert.

    Mein von dir zitierter Text war für den Fall, falls hier ein Profi im Bereich In-App-Kauf zufällig mitliest und aufschreit "Der Weg ist total falsch es geht ganz einfach anders" ^^
  • DKCode schrieb:

    Moin NSObject,
    danke für deine Unterstützung! Die Programme kannte ich noch gar nicht, aber erschreckend wie einfach es ist den Verkehr mitzuschneiden.
    Basiswerkzeuge. Sollte man kennen.

    DKCode schrieb:

    Hat irgendjemand vielleicht eine Idee, wie ich den Kaufprozess anders aufbauen könnte, um dem Problem mit dem Mitlesen der Daten aus dem Weg gehen zu können?
    Wie sieht denn dein bisheriger Prozess aus?

    DKCode schrieb:

    Es wäre mir eigentlich völlig egal,s das jemand die Verbindung mitliest, wenn nicht der Sinn der App dadurch komplett zerstört werden würde. Daher hoffe ich auf eure Unterstützung! Vielen Dank!
    Das sollte Dir im Interesse deiner User und der Rechtslage nicht egal sein.
    * Kann Spuren von Erdnüssen enthalten.
  • NSObject schrieb:

    DKCode schrieb:

    Moin NSObject,
    danke für deine Unterstützung! Die Programme kannte ich noch gar nicht, aber erschreckend wie einfach es ist den Verkehr mitzuschneiden.
    Basiswerkzeuge. Sollte man kennen.

    DKCode schrieb:

    Hat irgendjemand vielleicht eine Idee, wie ich den Kaufprozess anders aufbauen könnte, um dem Problem mit dem Mitlesen der Daten aus dem Weg gehen zu können?
    Wie sieht denn dein bisheriger Prozess aus?

    DKCode schrieb:

    Es wäre mir eigentlich völlig egal,s das jemand die Verbindung mitliest, wenn nicht der Sinn der App dadurch komplett zerstört werden würde. Daher hoffe ich auf eure Unterstützung! Vielen Dank!
    Das sollte Dir im Interesse deiner User und der Rechtslage nicht egal sein.
    Ach komm, ich kann bei so vielen Popel Nachrichten Apps mitlesen ;)
  • NSObject schrieb:

    DKCode schrieb:

    Moin NSObject,
    danke für deine Unterstützung! Die Programme kannte ich noch gar nicht, aber erschreckend wie einfach es ist den Verkehr mitzuschneiden.
    Basiswerkzeuge. Sollte man kennen.

    Ja man lernt ja nie aus


    NSObject schrieb:



    DKCode schrieb:

    Hat irgendjemand vielleicht eine Idee, wie ich den Kaufprozess anders aufbauen könnte, um dem Problem mit dem Mitlesen der Daten aus dem Weg gehen zu können?
    Wie sieht denn dein bisheriger Prozess aus?

    1. Klick auf Kaufbutton
    2. Kaufprozess von Apple
    3. Wenn Kauf durch Apple bestätigt ist:
    > Aufruf einer PHP bzw. REST-API (POST-Call) durch Alamofire mit der Übermittlung von 5 POST-Variablen
    > API validiert die POST-Variablen
    > API schreibt die Daten in die Datenbank

    Wenn nicht Abbruch
    4. App aktualisiert sich, lädt die Daten aus der Datenbank und zeigt sie an


    Hast du eine Idee? Danke dir!


    NSObject schrieb:



    DKCode schrieb:

    Es wäre mir eigentlich völlig egal,s das jemand die Verbindung mitliest, wenn nicht der Sinn der App dadurch komplett zerstört werden würde. Daher hoffe ich auf eure Unterstützung! Vielen Dank!
    Das sollte Dir im Interesse deiner User und der Rechtslage nicht egal sein.

    Das wäre mir nicht egal, wenn es bei dem Problem um sensible Userdaten ginge, oder wenn es z.B. um z.B. "1000 Coins" ginge. Sollte in
    diesem Fall jemand die API-Adresse und die Parameter rausfinden dann kann er sich eben 1000 Coins holen ohne dafür zu bezahlen zu müssen.

    Aber in meinem Fall baut der gesamte Sinn der App auf einem In-App-Kauf auf heißt kann man diesen Umgehen hat jeder andere Nutzer einen riesigen Nachteil.

    Daher muss ich irgendwie den Aufruf des Servers also die URL, oder aber die Parameter schützen, oder irgendwie anders eine Verbindung herstellen, oder einen gesonderten Parameter übertragen... bin da schlichtweg ratlos.
  • matz schrieb:

    NSObject schrieb:

    DKCode schrieb:

    Moin NSObject,
    danke für deine Unterstützung! Die Programme kannte ich noch gar nicht, aber erschreckend wie einfach es ist den Verkehr mitzuschneiden.
    Basiswerkzeuge. Sollte man kennen.

    DKCode schrieb:

    Hat irgendjemand vielleicht eine Idee, wie ich den Kaufprozess anders aufbauen könnte, um dem Problem mit dem Mitlesen der Daten aus dem Weg gehen zu können?
    Wie sieht denn dein bisheriger Prozess aus?

    DKCode schrieb:

    Es wäre mir eigentlich völlig egal,s das jemand die Verbindung mitliest, wenn nicht der Sinn der App dadurch komplett zerstört werden würde. Daher hoffe ich auf eure Unterstützung! Vielen Dank!
    Das sollte Dir im Interesse deiner User und der Rechtslage nicht egal sein.
    Ach komm, ich kann bei so vielen Popel Nachrichten Apps mitlesen ;)
    Ohne mich jemals wirklich mit dem Thema auseinandergesetzt zu haben würde ich das auch vermuten :D
  • Was meint ihr denn zu dieser Idee:

    1. User klickt Button
    2 Call zur API mit der Anfrage nach Token - GeräteID für Push wird übertragen
    3. App zeigt ein Eingabefeld für Token
    4. User erhält Token per Push und gibt diesen ein
    5. Token und die Userdaten (POST-Variablen) werden an die API gesendet und
    wenn der Token stimmt, wird der Datenbankeintrag ausgeführt

    Mich stört, dass der User diesen Zwischenschritt machen muss, aber so wäre es dann auf jeden Fall abgesichert, oder nicht?