7
Binary mit Serververbindung absichern
Hallo zusammen,
ich hätte mal eine Frage, da ich mir absolut nicht sicher bin. Bei Webseiten mit Userlogin usw. kommt das nicht zum tragen deswegen musste ich mich damit bisher nicht beschäftigen.
Also: Ich hab ein selbstgeschriebenes Programm (Client sowie Server). Der Client ist (wenns fertig ist) frei verfügar und verbindet sich dann für die Funktion mit meinem Server.
Wie sorge ich nun effektiv dafür das nur mein Client vom Server bedient wird und nicht jemand die API reverse-engeneered und die Anfragen an den Server auf anderem, mir nicht genehmen, Weg an meinen Server sendet.
Passwort im Quelltext oder Hash kann ja prinzipiell auch mit entsprechenden Tools ausgelesen werden ebenso wie
ein Zertifikat was dem Client beiliegen müsste ... stehe gerade voll auf dem Schlauch.
Ich bitte Antworten zu unterlassen die mir bei Unkenntnis von sowas abraten wollen. Ich hab durchaus Erfahrung aber sowas eben noch nicht gemacht und Google erschlägt mich zu dem Thema eher mit Enduser zeugs zu 2FA-Auth.
Danke
ich hätte mal eine Frage, da ich mir absolut nicht sicher bin. Bei Webseiten mit Userlogin usw. kommt das nicht zum tragen deswegen musste ich mich damit bisher nicht beschäftigen.
Also: Ich hab ein selbstgeschriebenes Programm (Client sowie Server). Der Client ist (wenns fertig ist) frei verfügar und verbindet sich dann für die Funktion mit meinem Server.
Wie sorge ich nun effektiv dafür das nur mein Client vom Server bedient wird und nicht jemand die API reverse-engeneered und die Anfragen an den Server auf anderem, mir nicht genehmen, Weg an meinen Server sendet.
Passwort im Quelltext oder Hash kann ja prinzipiell auch mit entsprechenden Tools ausgelesen werden ebenso wie
ein Zertifikat was dem Client beiliegen müsste ... stehe gerade voll auf dem Schlauch.
Ich bitte Antworten zu unterlassen die mir bei Unkenntnis von sowas abraten wollen. Ich hab durchaus Erfahrung aber sowas eben noch nicht gemacht und Google erschlägt mich zu dem Thema eher mit Enduser zeugs zu 2FA-Auth.
Danke
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672243
Url: https://administrator.de/forum/binary-mit-serververbindung-absichern-672243.html
Ausgedruckt am: 01.04.2025 um 15:04 Uhr
7 Kommentare
Neuester Kommentar
Ganz einfach: Du kannst es nicht verhindern.
Wenn jemand weiß, wie die Kommunikation zwischen API und Client läuft, kann er auch so tun als sei er ein "erlaubter" Client.
Die Frage klingt aber ein wenig nach X/Y-Problem. Was möchtest du denn erreichen?
Grundsätzlich musst du immer davon ausgehen, dass alle Anfragen an deine API potentiell boshaft und nicht vertrauenswürdig sind. Alle Berechtigungs-Prüfungen, Filterungen, Authentizitätsprüfungen u.s.w. müssen in der API geschehen, es darf niemals angenommen werden, dass der Client sich so verhält wie du es erwartest.
Wenn du das berücksichtigst, ist es eigentlich egal, ob jemand die API reverse-engineered.
Wenn es dir um die Verhinderung automatisierter Anfragen geht, hilft dagegen nur serverseitiges Rate-Limiting oder ein Quota für Anfragen pro Tag und Benutzerkonto.
Wenn jemand weiß, wie die Kommunikation zwischen API und Client läuft, kann er auch so tun als sei er ein "erlaubter" Client.
Die Frage klingt aber ein wenig nach X/Y-Problem. Was möchtest du denn erreichen?
Grundsätzlich musst du immer davon ausgehen, dass alle Anfragen an deine API potentiell boshaft und nicht vertrauenswürdig sind. Alle Berechtigungs-Prüfungen, Filterungen, Authentizitätsprüfungen u.s.w. müssen in der API geschehen, es darf niemals angenommen werden, dass der Client sich so verhält wie du es erwartest.
Wenn du das berücksichtigst, ist es eigentlich egal, ob jemand die API reverse-engineered.
Wenn es dir um die Verhinderung automatisierter Anfragen geht, hilft dagegen nur serverseitiges Rate-Limiting oder ein Quota für Anfragen pro Tag und Benutzerkonto.
1
ganz verhindern kannst du es nicht - aber natürlich schon erschweren. Du kannst dir ja zB. bei nem API zugriff übers Web nen Token hinten anhängen der zur Laufzeit generiert wird oder zB. mittels Verschlüsselung schon die Parameter deiner Abfrage verändern so das eben die nur verschlüsselt an den Server gehen.
Wenn man natürlich genug Energie aufwendet wird man das auch "knacken" können - keine Frage. Da kannst du dann eben nur noch irgendwann mit Lizenzcodes, Dongles usw. losgehen. Aber zumindest kann man auch damit schon einiges erschweren - und grad nen "Auth-Token" sorgt ja schon dafür das eben ne einfache Anfrage nicht beantwortet wird. Wenn du dann noch als "Parameter" zur Token-Generieung z.B. ne Versionsnummer mit ranziehst würde ein evtl. Angreifer ja jedes Mal wieder die Daten suchen müssen - ob sich das lohnt is dann die Frage...
Wenn man natürlich genug Energie aufwendet wird man das auch "knacken" können - keine Frage. Da kannst du dann eben nur noch irgendwann mit Lizenzcodes, Dongles usw. losgehen. Aber zumindest kann man auch damit schon einiges erschweren - und grad nen "Auth-Token" sorgt ja schon dafür das eben ne einfache Anfrage nicht beantwortet wird. Wenn du dann noch als "Parameter" zur Token-Generieung z.B. ne Versionsnummer mit ranziehst würde ein evtl. Angreifer ja jedes Mal wieder die Daten suchen müssen - ob sich das lohnt is dann die Frage...
Moin,
Du kannst es erschweren, indem Du Hase und Igel spielst. Dein offizieller Client authentifiziert sich - neben allem anderen - z.B. mit einem bestimmten Secret. Der Client hat einen automatischen Updatemechanismus. Das Secret tauschst Du dann mit dem Client immer wieder aus, so dass auch ein Nachbau nur dann funktioniert, wenn die neue Version wieder auseinandergenommen wurde und wenn der Nachbau ein Update erhält. Nicht unmöglich, eben nur erschwert.
Gruß
DivideByZero
Du kannst es erschweren, indem Du Hase und Igel spielst. Dein offizieller Client authentifiziert sich - neben allem anderen - z.B. mit einem bestimmten Secret. Der Client hat einen automatischen Updatemechanismus. Das Secret tauschst Du dann mit dem Client immer wieder aus, so dass auch ein Nachbau nur dann funktioniert, wenn die neue Version wieder auseinandergenommen wurde und wenn der Nachbau ein Update erhält. Nicht unmöglich, eben nur erschwert.
Gruß
DivideByZero
Proxy davor. Watchguard oder ähnliches. Im Idealfall sollte dann Botnet detection u.ä. greifen.
Country block wäre denkbar, wenn man es auf D oder Europa beschränken will.
Wenn man selber nicht mit fail2ban arbeiten kann, so kann man zumindest auf globale Listen zürück greifen.
Proxy und content expection können ggf. auch was abfangen.
Bei ftp kennen wir ja Anti hammering. Also mehrfach hintereinander gesendete abfragen führen zu Temp. Ban.
Fraglich, in wie weit sich das bei dir integrieren lässt.
Gutes gateway / firewall bietet aber ein paar Optionen, die man ggf sinnvoll kombinieren kann.
Fallen dir im backend komische Dinge automatisch auf, so kann man mit ein paar Zeilen via ssh Firewall mit Temp IP Ban versehen.
Das alles kann z.b. Warchguard oder auch andere Lösungen in der Klasse.
Die Welt zu blocken macht ja keinen Sinn. Du hast nur so Regeln und logs vorgelagert,die man teils manuell triggern kann.
Erschwert zusätzlich und kann ggf akt versuch killen und über Stunden oder Tage die Endstelle lahm legen.
Hardware oder Software Firewall im RZ bieten eine gewisse Vorfilterung und Sicherheit ohne das du an der API drehen musst. Natürlich aber nur in gewissen Rahmen.
Country block wäre denkbar, wenn man es auf D oder Europa beschränken will.
Wenn man selber nicht mit fail2ban arbeiten kann, so kann man zumindest auf globale Listen zürück greifen.
Proxy und content expection können ggf. auch was abfangen.
Bei ftp kennen wir ja Anti hammering. Also mehrfach hintereinander gesendete abfragen führen zu Temp. Ban.
Fraglich, in wie weit sich das bei dir integrieren lässt.
Gutes gateway / firewall bietet aber ein paar Optionen, die man ggf sinnvoll kombinieren kann.
Fallen dir im backend komische Dinge automatisch auf, so kann man mit ein paar Zeilen via ssh Firewall mit Temp IP Ban versehen.
Das alles kann z.b. Warchguard oder auch andere Lösungen in der Klasse.
Die Welt zu blocken macht ja keinen Sinn. Du hast nur so Regeln und logs vorgelagert,die man teils manuell triggern kann.
Erschwert zusätzlich und kann ggf akt versuch killen und über Stunden oder Tage die Endstelle lahm legen.
Hardware oder Software Firewall im RZ bieten eine gewisse Vorfilterung und Sicherheit ohne das du an der API drehen musst. Natürlich aber nur in gewissen Rahmen.
Moin,
danke euch, dann stand ich ja doch nicht so wirklich aufm schlauch denn zu diesen Ergebnissen bin ich auch gekommen.
Grüße
bloody
danke euch, dann stand ich ja doch nicht so wirklich aufm schlauch denn zu diesen Ergebnissen bin ich auch gekommen.
Grüße
bloody
Hallo,
das Meiste wurde ja schon gesagt.
Es muss etwas sein, was man nicht extrahieren kann wenn dies vollständig blockieren möchte.
Dies könnte ein USB-Dongle sein. Auch ein Fido. Etwas externes was mit PKI ein Token generiert. Theoretisch auch TOTP oder HOTP mit einem Dongle. Oder eine USB-SIM-Karte.
Oder etwas was nicht im Program enthalten ist.
Das können Zugangsdaten sein, ein API-Schlüssel oder ein Zertifikat was man seperat verschickt.
Stefan
das Meiste wurde ja schon gesagt.
Es muss etwas sein, was man nicht extrahieren kann wenn dies vollständig blockieren möchte.
Dies könnte ein USB-Dongle sein. Auch ein Fido. Etwas externes was mit PKI ein Token generiert. Theoretisch auch TOTP oder HOTP mit einem Dongle. Oder eine USB-SIM-Karte.
Oder etwas was nicht im Program enthalten ist.
Das können Zugangsdaten sein, ein API-Schlüssel oder ein Zertifikat was man seperat verschickt.
Stefan
Eine Hürde könnten auch HSTS und/oder Client-Zertifikate darstellen.
