Frage:
Ist es grundsätzlich möglich zu überprüfen, ob eine unveränderte Version Ihres Clients eine Verbindung zu Ihrem Server herstellt?
Uwe Plonus
2014-09-23 23:37:58 UTC
view on stackexchange narkive permalink

Sie können HTTPS zusammen mit der Clientzertifikatauthentifizierung verwenden. Dann können Sie sicherstellen, dass nur Clients mit einem gültigen Zertifikat Ihre Site verwenden können.

Das Client-Zertifikat ersetzt dann das von Ihnen erwähnte Kennwort und der Benutzer bemerkt die Magie im Hintergrund nicht.

Ich glaube nicht, dass unsere Kunden bereit sind, sich mit einem Zertifikat zu beschäftigen. Ich wünschte, sie würden es tun, aber die Leute finden das ein Schmerz.
@DavidThielen Sie können beim ersten Start der Anwendung ein Zertifikat erstellen und dieses verwenden. Dann wissen Ihre Kunden das gar nicht. Die Sicherheit ist dann geschwächt, aber in Ihrem Fall sollte es in Ordnung sein.
Wenn die App auf dem Client-System das Zertifikat bei der ersten Ausführung erstellt, woher wissen wir dann, wenn es verwendet wird, dass es wirklich von ihnen stammt? Vertrauen wir dem ersten Mal und sind wir von da an sicher? Vielen Dank
Ja, Sie vertrauen ihm beim ersten Mal und speichern ihn dann. Bei der zweiten Verbindung ist der Client also bereits bekannt.
Vielen Dank. Wenn ich zwei richtige Antworten auswählen könnte, würde ich dies auch auswählen.
Sechs antworten:
gowenfawr
2014-11-01 00:31:48 UTC
view on stackexchange narkive permalink

Es ist grundsätzlich unmöglich, einen Client auf einem System zu validieren, das Sie nicht kontrollieren.

Das bedeutet nicht, dass dies nicht in ausreichendem Maße möglich ist. Beispielsweise versuchen eBook-Reader im Allgemeinen sicherzustellen, dass der Client authentisch ist. Sie tun dies auf eine Weise, die sicher genug ist, um sich gegen ihre Bedrohung zu verteidigen. Gut genug, um nukleare Geheimnisse zu schützen? Nein. Aber gut genug für die Bedrohungsumgebung.

Finden Sie heraus, wie wichtig diese Kontrolle für Ihre Anwendung ist, und bestimmen Sie die Ausgleichskontrollen, die Sie einrichten, um den Schaden zu begrenzen, wenn jemand die Probleme von Zerreißen und dann Ihre Anwendung nachahmen. Denken Sie nicht in Schwarz / Weiß, möglich / unmöglich; Denken Sie an akzeptable und erreichbare Sicherheit.

Mit anderen Worten, es läuft auf den alten Witz hinaus: Man muss nicht schneller laufen als ein Bär, um ihm zu entkommen; du musst nur schneller laufen als dein Freund. Sie müssen es ärgerlich genug machen, Ihre Anwendung rückzuentwickeln, damit die Leute etwas anderes suchen (z. B. das Herunterladen von Videos mit Bittorrent anstelle Ihres Video-on-Demand-Dienstes).
Ich bin mir nicht sicher, warum das richtig ist. Ein gehackter Client muss einen gültigen Client imitieren. Der gehackte Client kann nicht immer vorkompiliert werden, da hierfür ein Reverse Engineering des ursprünglichen Clients erforderlich wäre, was der Lösung des Stoppproblems entspricht. Daher muss für einen ausreichend komplizierten Client die Nachahmung den Code im laufenden Betrieb interpretieren, anstatt ihn neu zu kompilieren. Dies führt zwangsläufig zu einer zusätzlichen Verzögerung, die vom Server durch Messen der Antwortzeiten erkannt werden kann. Daher sollte es im Prinzip möglich sein, nicht wahr?
@Mehrdad Wenn Sie hypothetisches Denken mögen, sollten Sie auch den [Satz zur Beschleunigung] (http://en.wikipedia.org/wiki/Linear_speedup_theorem) berücksichtigen, der im Grunde besagt: Nein, Sie können den Interpreter so schnell wie nötig laufen lassen , genügend Ressourcen gegeben.
@Mehrdad: Jede VM ist im Wesentlichen ein Interpreter. Natürlich sind die Perf-Kosten hier nicht unbedingt riesig.
@Mehrdad Sie können (oder sollten) sich nicht auf Antwortzeiten in einer Client / Server-Umgebung verlassen, die über das Internet ausgeführt wird, zumindest nicht mit der Genauigkeit, die erforderlich ist, um das zu tun, was Sie vorschlagen. Sie haben keine Ahnung, über welche Art von Konnektivität der Client verfügt, was mit den Routen der einzelnen Pakete geschieht und wie viele Personen unterwegs versuchen, Netflix auf dem Weg zu streamen ...
@Mehrdad, Nichts sagt, dass der gehackte Client dieselbe Codebasis wie der gültige Client ist - er muss nur genügend Eingaben korrekt präsentieren, um Sie davon zu überzeugen, dass es sich um den gültigen Client handelt. Und [Timing kann genau analysiert werden] (http://users.ece.cmu.edu/~dawnsong/papers/ssh-timing.pdf) und bei Bedarf nachgeahmt werden.
Hat jemand dies tatsächlich bewiesen? Ich habe eine vage Idee für einen Beweis: Wenn jemand genügend Zugriff auf Ihren Client hat, um ihn ausführen zu können, muss er über genügend Zugriff auf Ihren Client verfügen, um ihn rückentwickeln zu können. Klingt nach etwas, das Turing oder jemand bereits bewiesen hat.
J.Todd
2014-11-01 00:24:33 UTC
view on stackexchange narkive permalink

Ich poste diese Frage von Programmers.SE, weil ich denke, dass sie hier gleichermaßen thematisch ist und die Frage auch dieser Community stellen möchte.

Dies scheint eine Programmierfrage zu sein, ist aber auch eine grundlegende Sicherheitsfrage.


Ist es grundsätzlich möglich zu überprüfen, ob eine unveränderte Version Ihres Clients eine Verbindung zu Ihrem Server herstellt?

Ich habe gerade über die Idee nachgedacht, dass meine clientseitige App ihren eigenen Quellcode hasht und diesen als Schlüssel an den Server sendet, mit allen Anfragen als Beweis dafür, dass er unverändert ist, aber das ist albern, weil jeder es könnte Lassen Sie den Client einfach einen Hash der unveränderten Version über eine geänderte Version senden.

Ich habe mich gefragt, ob es einen sicheren Weg gibt, dies zu tun, und zwar über einen Beweis dafür, dass der Client unverändert war.

In Bezug auf Ihren "Passwort" -Ansatz funktionieren [API-Schlüssel] (https://en.wikipedia.org/wiki/Application_programming_interface_key) genau so. Dadurch wird der * Benutzer * jedoch nur eindeutig identifiziert. Es wird nicht überprüft, ob der Benutzer Ihre ursprüngliche Software verwendet (und nicht beispielsweise einen von Grund auf neu geschriebenen Klon).
@apsillers Ich denke das wäre ok. Ich mache mir keine Sorgen, dass ein legitimer Benutzer Probleme verursacht. Wenn Sie das als Antwort angeben, wähle ich es gerne aus.
Wenn Sie der Meinung sind, dass die Validierung des Clients die Lösung ist, stellen Sie die falsche Frage.
@Rook kann beispielsweise eine App-Umgebung erstellen, in der die Qualität von Apps überprüft wird, bevor sie in den Store zugelassen werden. Ich möchte überprüfen, ob die Apps ihre Funktionalität nicht dynamisch ändern und so das System betrügen.
Ihre Anwendung ist ein Gast auf dem Computer des Angreifers, und Gäste müssen die Regeln befolgen. Der Angreifer macht alle diese Regeln.
@j0dd Was ist, wenn der Code der Anwendung aus einem Interpreter besteht? Wirst du es verbieten, Dateien zu lesen? Würden Sie die Änderung der Dateien verbieten?
@Doval Ich weiß nicht, dass es nur ein Gedanke war. Scheint aufgrund der Antworten so oder so unmöglich.
Es hat einen Namen. Weiß es. "Fernbescheinigung"
In den schlechten alten Zeiten hat der Server für die Windows-Version von AOL Instant Messenger manchmal eine Herausforderung gesendet. Es war eine Adresse im Codebereich des von AOL bereitgestellten Clients, und der Client antwortete, indem er alle Binärdaten sendete, die sich in dieser Version an dieser Stelle befanden. Eine falsche Antwort führte zu einer vom Server initiierten Trennung.
Dies hat einen Namen ... vertrauenswürdige Plattform. Ja, "Vertrauen" ist eine äußerst schlechte Formulierung für etwas, das nur dazu gedacht ist, Benutzerrechte zu verlieren. Wenn Microsoft und die amerikanische Filmindustrie eines Tages ihren Weg finden, ist dies möglich (solange niemand Ihren Client auf einem alten Computer ausführt, der die TPM-Scheiße nicht erzwingt).
Thomas Pornin
2014-11-01 00:41:27 UTC
view on stackexchange narkive permalink

Es ist grundsätzlich unmöglich zu überprüfen, ob eine unveränderte Version Ihres Clients eine Verbindung zu Ihrem Server herstellt.

... es sei denn, Sie tun, was ist notwendig, um es zu gewährleisten. Dies bedeutet clientseitige manipulationssichere Hardware.

Wenn Ihr Code auf dem Computer des Clients ausgeführt wird, kann der Computerbesitzer einen Debugger ausführen und den Clientcode jederzeit mit beliebigen Werten ändern. Der "Debugger" kann eine vollständige virtuelle Maschine sein. Wenn Sie dies vermeiden möchten, können Sie versuchen, sich auf ein ausgeklügeltes hide&seek-Spiel einzulassen, in dem Sie sich zusätzliche Erkennungssysteme vorstellen, und Angreifer begegnen diesen mit Varianten ihrer eigenen Tools. Dies ist das Problem von Menschen, die versuchen, Anti-Cheat-Softwarelösungen zu entwickeln (z. B. PunkBuster). Dies ist auch das Problem von Personen, die Video-on-Demand-Dienste verkaufen und gleichzeitig verhindern möchten, dass die Kunden die Videos lokal speichern und dann auf verschiedenen Filesharing-Plattformen veröffentlichen.

Zusammenfassend lässt sich sagen, dass diese Schutzmaßnahmen funktioniert nicht gut, selbst wenn die zu schützenden Daten so trivial sind wie zusätzliche Leben in einem Spiel.

Um dies zu vermeiden, müssen Sie Ihren Code auf geschützter Hardware ausführen, die sich gegen Deep verteidigt Inspektion von seinem mutmaßlichen Besitzer. Dies ist das Modell von Spielekonsolen, Zahlungsterminals und Smartcards.

Ein TPM ist ein Versuch eines Kompromisses: ein manipulationssicheres Modul, das auf einem ansonsten normalen PC ausgeführt wird ;; Hierbei wird davon ausgegangen, dass es für einen normalen Benutzer zu schwierig ist, die Hardware so zu ändern, dass beispielsweise der gesamte RAM gelesen und geschrieben wird, ohne die Teile zu durchlaufen, die vom TPM-Modul (z. B. der CPU) überwacht werden.

Ohne solche Hardware auf der Clientseite funktioniert das, was Sie versuchen, nicht. Es sei denn, eine Änderung des Client-Codes wäre so wertlos, als es niemand versucht. Es hängt alles vom Wert dessen ab, was hier auf dem Spiel steht.

Und selbst dann bewegen sich Katz und Maus einfach über Mod-Chips in Hardware. Ich nehme an, das Endspiel sieht aus wie Angreifer, die komplette Chipklone mit modifizierten TPM-Blöcken fälschen.
Der Schritt im Katz- und Mausspiel darüber hinaus ist Hardware, die manipulationssichere Sensoren im Gehäuse hat und sich selbst abwischt, wenn sie ausgehen. Selbst das wird wahrscheinlich gegen einen entschlossenen Angreifer mit tiefen Taschen für alles auf dem Massenmarkt scheitern, da der Angreifer einfach weiter kaufen kann, bis er schließlich das Intrusion Detection-System besiegt.
@DanNeely: Eigentlich glaube ich, wenn Sie den Originalchip behalten, können Sie wahrscheinlich die Authentifizierungsanforderungen hinein- und herausgeben. Möglicherweise können Sie sogar die Netzwerkverschlüsselung durchführen, solange nicht überprüft wird, ob die Verschlüsselungsanforderung von einer authentifizierten Ausführungsseite stammt.
Das Problem "Programm läuft auf einem vom Client gesteuerten Computer" reduziert sich auf das Problem "Wie stelle ich die vollständige Kontrolle über den Client-Computer sicher?".
@Peteris Was zufällig für Malware-Autoren sehr wünschenswert ist.
PyRulez
2014-11-01 06:36:16 UTC
view on stackexchange narkive permalink

Sie können versuchen, kryptografische Verschleierung, wenn sie vorhanden ist.

Kryptografische Verschleierung ist, wenn Sie in gewissem Sinne einen Quellcode eines Programms unlesbar machen. Sie können dann einen kyrptografischen Schlüssel in das Programm fest codieren. Sie möchten auch, dass der Server Ihrem Programm einen zufälligen Startwert bereitstellt, da dem Computer nicht vertraut werden kann. Das einzige Problem bei diesem Ansatz ist, dass die kryptografische Verschleierung noch nicht implementiert wurde und dass nur bestimmte Sinne möglich sind.

Ich habe es durchgelesen; Sehr ordentlich und eine Antwort auf meine Frage insgesamt.
@jt0dd Es ist möglich, die zu akzeptierende Antwort zu ändern, falls Sie sich fragen.
Nun, der Artikel befasst sich eingehend mit dem Thema, aber Ihre Antwort enthält keine wichtigen Teile wie eine klare Antwort auf die Frage (was anscheinend "Nein" ist). Ihre Antwort müsste jedoch den relevanten Inhalt dieses Artikels diskutieren. +1 für den Artikel, sehr interessant
Cameron Does Things
2014-11-01 00:30:51 UTC
view on stackexchange narkive permalink

Auch ich habe mich mit der Firma, für die ich arbeite, einem solchen Problem zugewandt. Nach wochenlangem Ausarbeiten ist die Antwort nicht wirklich möglich.

Und hier ist der Grund:

Grundsätzlich tritt ein Problem mit "Trusted Client" auf. Der Client-Code wird auf dem PC des Benutzers ausgeführt, und der Benutzer hat die volle Kontrolle über den PC, von dem er stammt. Der Benutzer kann die Bytes des Programms auf der Festplatte oder in einigen Fällen sogar im Speicher ändern. Wenn Sie versuchen würden, einen Hash oder eine Prüfsumme für den Code durchzuführen, könnte er einfach den Code ändern, der diese Überprüfung durchgeführt hat, und ihn "unverändert" zurückgeben. Es ist eine Rauch- und Spiegel-Taktik.

Sie könnten versuchen, einem böswilligen Benutzer die Dinge etwas schwerer zu machen, aber es gibt keinen praktischen Weg, um das zu erreichen, was Sie sich erhoffen. Nicht ohne dass es zu großen Kopfschmerzen kommt.

apsillers
2014-09-24 00:13:08 UTC
view on stackexchange narkive permalink

Wenn Sie den Benutzer eindeutig identifizieren möchten, funktionieren API-Schlüssel gut für Sie. Um die API von Facebook oder die API von Stack Exchange (usw. usw.) verwenden zu können, benötigen Sie einen API-Schlüssel, um sich als bestimmter Benutzer von zu identifizieren die API und senden Sie diesen API-Schlüssel bei jeder Anfrage. Somit kann jede Anforderung, die die API trifft, auf einen ursprünglichen Benutzer zurückgeführt werden. Auf diese Weise kann der API-Eigentümer auch steuern, wer auf die API zugreift, indem er einschränkt, wer auf einen API-Schlüssel zugreifen darf.

Dadurch wird jedoch nur der Benutzer eindeutig identifiziert. Es wird nicht überprüft, ob der Benutzer Ihre ursprüngliche Software verwendet (anstatt beispielsweise einen von Grund auf neu geschriebenen Klon). Es ist praktisch unmöglich zu überprüfen, ob der Benutzer Ihre ursprüngliche Software verwendet, da davon ausgegangen wird, dass der Benutzer keine Kontrolle über seinen eigenen Computer hat und das Programm beispielsweise nicht in einem Debugger ausführen und die Softwareanweisungen nach Belieben ändern kann .



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...