Ich habe eine mobile App (derzeit IOS und bald Android), die mit einem Webdienst kommuniziert. Es gibt kein Login und die Daten sind nicht privat. Grundsätzlich POSTET die App einen Marker (lon, lat) und GETET die nächsten 25 Marker, die auf einer Karte angezeigt werden sollen.

Es ist eine sehr triviale App und ich kann mir nicht vorstellen, dass jemand große Anstrengungen unternimmt, um den Webdienst zu missbrauchen. Ich kann jedoch sehen, dass es für jemanden Spaß macht, viele Marker zu posten. Was mich am meisten beschäftigt, ist, dass jemand ein Skript ausführt, das viele Anfragen pusht (teure Bandbreite verbraucht und meine App-Daten unsinnig macht).

Ich komme langsam zu dem Schluss, dass dies nicht sicher sein kann. Die beste Antwort ist "Mach das nicht". Bieten Sie keinen Webdienst ohne Authentifizierung an. Nicht viele Dienste sind so offen. Die You Tube-API von Google ist geöffnet, die meisten jedoch nicht. Leider habe ich keine andere Wahl. Nach Tagen des Schauens hier ist mein Denken. Seien Sie sich bewusst, dass ich sehr weit von einem Sicherheitsexperten entfernt bin und ich bin zuversichtlich, dass mein Ansatz verbessert werden könnte. Aber es könnte Sie in die richtige Richtung weisen. Hoffentlich kann jemand, der mehr Erfahrung hat, dies korrigieren / verbessern. ich fandDieser Beitrag und Kommentare besonders hilfreich.

Sicherheit auf Nachrichtenebene

Ich werde die Nachrichten mit einer Hash-Verschlüsselung sichern. Die Clients und der Webdienst behalten alle eine Kopie eines gemeinsamen Geheimnisses, das als Salt verwendet wird, um einen Hash aus der URL und allen POST-Argumenten zu erstellen. Der Hash wird als zusätzliches Argument übergeben und der Hash wird neu erstellt und am anderen Ende verglichen (unter Verwendung des gemeinsam genutzten Schlüssels als Salt). Dies ist ziemlich gut, bis Sie verstehen, dass jeder mobile Client-Code innerhalb von Minuten rückentwickelt werden kann. An diesem Punkt ist diese Verteidigungslinie völlig unbrauchbar.

Client-Maßnahmen

Der Client enthält eine Ratenbeschränkung für Nachrichten, um die Anzahl der von ehrlichen Benutzern gesendeten Nachrichten zu begrenzen. Dies ist wiederum gegen einen Angreifer nutzlos, der das mobile Gerät in den Jailbreak steckt.

Serverseitige Sicherheit

Die Serverseite muss daher über so viele zusätzliche Sicherheitsmaßnahmen wie möglich verfügen, um allein davon ausgehen zu können, dass Ihr Client (und das gemeinsam genutzte Geheimnis) kompromittiert sind. Folgendes habe ich:

Ein msg arg ist eine UTC-Zeit, die verwendet wird, um Wiederholungsangriffe zu begrenzen. Dies sollte verhindern, dass ein Angreifer wiederholt dieselbe Nachricht auf dem Server abfeuert.

Der Server führt eine Ratenbegrenzung durch IP durch. Ja, IPs lassen sich leicht fälschen und der Proxy-Wechsel ist kinderleicht, aber alles hilft, wenn Sie so wenig haben.

Natürlich überprüft der Server alle Argumente streng, verwendet parametrisierte Abfragen und gibt keine Ausnahmen zurück.

Sicherheit auf Transportebene

Leider bin ich ziemlich zuversichtlich, dass die Ausstellung von SSL-Zertifikaten für einzelne Kunden ohne einen Registrierungsprozess nicht möglich ist. Und da ich den msg-Hash-Check verwende (und meine Daten nicht privat sind), bin ich mir nicht ganz sicher, was SSL in die Tabelle bringt. Ich werde jedoch wahrscheinlich SSL (mit einem app-weiten Zertifikat) verwenden, da es eine weitere Sicherheitsstufe hinzufügt, die einfach und kostengünstig bereitgestellt werden kann (allerdings zu einem Preis von zusätzlicher Verbindungszeit für jede Nachricht).

Das klaffende große große Loch in meinem Ansatz

Ich wurde gewarnt, dass, sollte die App populär werden, jemand das gemeinsame Geheimnis auf dem Client gefährden wird. Nur weil sie es können und sie es wahrscheinlich im Internet veröffentlichen werden. Es kommt also wirklich alles auf die Serverseite an. Unglücklicherweise,Ich habe keine Möglichkeit, einen Angreifer zu identifizieren und zu blockieren. Das würde ich sehr lieben.

Ein letzter Klagegrund

Nach Tagen der Forschung ist das alles, was ich habe. Aber ich will mehr. Ich würde mich besonders über Ideen freuen, um die Serverseite aufzuwerten. Also habe ich alle meine SO-Punkte als Kopfgeld ausgegeben. Ja Sir, alle 97 Punkte!