Laden...

Zugriff auf einen nicht-IIS Webservice NUR durch Client-Anwendung?

Erstellt von 7.e.Q vor 12 Jahren Letzter Beitrag vor 12 Jahren 1.735 Views
7.e.Q Themenstarter:in
925 Beiträge seit 2004
vor 12 Jahren
Zugriff auf einen nicht-IIS Webservice NUR durch Client-Anwendung?

Hi Leute,

hab mal eine Frage bezüglich Sicherheitssysteme: ich habe eine Anwendung, die auf einen RESTful Webservice zugreifen soll. Dieser Service läuft mit PHP/MySQL auf einem Apache2 Webserver. Nun möchte ich irgendwie bewerkstelligen, dass auf diesen Service wirklich NUR und ausschließlich die Anwendung zugreift.

Sie soll auf dem Wege auch Schreibrechte bekommen, also Datensätze anlegen dürfen. Daher der Sicherheitsgedanke. Es soll nicht möglich sein, mit einem Bot-Programm oder ähnlichem Datensätze anzulegen.

Allerdings wird die Anwendung einer zwar überschaubaren, aber mir dennoch weitgehend unbekannten Nutzerbasis zur Verfügung stehen. Sie ist also öffentlich verfügbar. Ich mache mir daher natürlich Gedanken darüber, dass (nicht nur) unter den Nutzern auch solche sein könnten, die den Server auf dem Wege zu kompromittieren versuchen könnten.

Das suche ich zu verhindern.

Ich danke für jedwede Form der Unterstützung.

Viele Grüße,
Hendrik

C
1.214 Beiträge seit 2006
vor 12 Jahren

Wenn es ein Programm gibt, das etwas darf, und dieses Programm aus der Hand gibst, wirst du keine 100% Sicherheit erreichen können. Du kannst versuchen, es etwas komplizierter zu machen, z.B. durch Handshake Verfahren, wobei der Algorithmus in dem Programm "versteckt" ist, oder durch Client Zertifikate. Aber im Endeffekt machst du es damit dir selber schwerer und erreichst auch damit keine 100% Sicherheit, weil ein Benutzer das Programm eben reverse engineeren könnte.
Ich würde das auf Benutzerbasis machen. Wenn jemand Schreibrechte haben will, muss er sich anmelden. Wenn unter seinem Konto Unfug betrieben wird, muss er sich eben dafür verantworten.

7.e.Q Themenstarter:in
925 Beiträge seit 2004
vor 12 Jahren

Hmm, ja, das klingt plausibel. Leider. Ich dachte schon daran, das über SSL zu realisieren. Aber ich glaub, dafür lohnt der Aufwand nicht. Naja, mach ich das halt über Benutzeraccounts...

Danke dir dennoch!

C
1.214 Beiträge seit 2006
vor 12 Jahren

Ich dachte schon daran, das über SSL zu realisieren.

SSL kannst du natürlich benutzen, zumindest für die Verschlüsselung. Du kannst auch Client Zertifikate einsetzen. Nur hast du halt keine Möglichkeit zu verhindern, dass jemand das Zertifikat ausliest und in einer anderen Anwendung einsetzt.

7.e.Q Themenstarter:in
925 Beiträge seit 2004
vor 12 Jahren

Müsste es nicht theoretisch möglich sein, aus einem Teil des Bytecodes der Binary ein private/public key Paar zu erstellen, mithilfe dessen die gesamte Kommunikation verschlüsselt wird? Das Paar müsste dann für jede neue Version neu erzeugt werden. Eine Bruteforce Attacke übersteht das natürlich auch nicht, wenn jemand weiß, dass ein Teil des Bytecodes als Grundlage für das Keypair steht. Aber das ließe sich zumindest serverseitig mit IP bans erschweren.

Nun ja... wie gesagt, eigentlich ist Aufwand/Nutzen dafür einfach zu groß. Ich denke mal, ein einfaches cookie/session based Benutzersystem langt da völlig aus. Ich muss mich nur noch schlau machen, wie man das mit RESTful Services und WCF realisiert. Dafür mach ich dann aber zu gegebener Zeit einfach noch einen Thread auf. 😃 Es sei denn, es hat jemand auf die Schnelle die zündende Idee.

Info dazu, nochmal kurz: der RESTful Service läuft auf einem LAMP. Clientseitig geht das ganze wunderbarst über DataContracts und WebGet/WebInvoke. Das ist damit so dermaßen einfach, dass es schon weh tut. 😃 Man muss sich um so gut wie nix mehr selbst kümmern. Nur kurz den Endpoint in der config beschreiben, den Client und die DataContracts aufziehen und fertig ist die Laube.

G
538 Beiträge seit 2008
vor 12 Jahren

Dieser Ansatz zur Verschlüsselung von Code etc. pp. bringt dir recht wenig.

Du kannst natürlich (a)synchron verschlüsseln, aber das kann jemand der es unbedingt will auch nachmachen.

Die einzige Möglichkeit deinen Service sinnvoll zu schützen ist es beim Service selbst unerwünschtes verhalten zu blockieren.
Wenn du zum Beispiel willst, dass ein Benutzer nur 1 x pro Minute Daten lesen/schreiben darf, so musst du im Server mitschreiben, wann wer da war.

Wenn du schreibrechte nur für bestimmte Nutzer willst... alle Webserver kennen Basic Authentifizierung - in verbindung mit SSL ist das eine echt gute Variante (im übrigen kannst du so auch Audits machen, wer denn unfug treibt).

Den Client kannst du niemals komplett sicher machen (das ist im übrigen auch etwas, was Spielefirmen jedesmal wieder schmerzlich erfahren, wenn Sie unsummen für nichtsnutze Kopierschutzmechanismen ausgeben - die Schwelle wird immer Höher, aber scheinbar gibt's noch Leute die das dennoch aushebeln - und genau solche Leute können auch bei dir mechanismen aushebeln).

Was auch noch helfen kann (auf Client Seite): Hardware-Keys - aber die sind vergleichsweise teuer - und wer einen hat kann immer noch unfug treiben.

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)