C# Windows Forms Anwendung mit MySQL Daten

[Larnox0]

Moin zusammen,
ich dachte ich hole mir mal fachliche Meinung zu einem meiner Projekte ein.

Im Moment habe ich eine C# Windows Forms Anwendung, in der ich Daten einer MySQL Datenbank verarbeiten möchte.
( Upload & Download )

Im Netz bin ich jetzt jedoch mehrfach darauf aufmerksam geworden, dass eine direkte Verbindung zu einem MySQL Server nicht wirklich sicher ist und wohl auch nicht der gängige Weg für ein derartiges Vorhaben sein soll.

Deswegen hatte ich jetzt schon den Gedanken eine PHP Schnittstelle einzubauen, ist das schon eher der Way to go?
Was meint Ihr?
Oder doch eine MySQL Anbindung über SSH?

 

[X__]

Ist der Server denn öffentlich erreichbar ?
Ich weiß nicht genau, was daran unsicher sein soll, wenn man für die Verbindungen SSL-Verschlüsselung erzwingt (Konfigurationssache) - wo steht denn das, dass das unsicher sein soll ?
Aus meiner Sicht spricht da eigentlich nichts grundsätzliches gegen - ich glaube, ab 8.x kann MYSQL auch MFA. Python macht an der Stelle eigentlich nichts anderes als C#.

Noch ein bisschen Lektüre dazu

 

[Larnox0]

Guter Punkt den ich sicherlich erwähnen hätte müssen.
Ich habe bereits Webspace mit SQL Datenbank, die nur von internen Servern erreichbar ist.

Als ich versuchte herauszufinden, wieso ich keine Verbindung herstellen kann, bin ich auf besagte Aussagen getroffen, dass SQL von extern vermieden werden sollte.

Mich hindert nichts daran mir einen separaten Hoster für die Datenbank zu suchen, dachte nur es wäre besser grade in diesem Punkt informierter zu sein.

 

[Yuuri]

Ich weiß nicht genau, was daran unsicher sein sol

https://www.computerbase.de/2023-08...-das-melden-einer-sicherheitsluecke-verklagt/

Deswegen hatte ich jetzt schon den Gedanken eine PHP Schnittstelle einzubauen, ist das schon eher der Way to go?

Ja, du klemmst dort ne API vor.

 

[pseudopseudonym]

Denk dran, dich vor SQL-Injektions zu schützen, wenn du deine PHP-API schreibst.

 

[Larnox0]

https://www.computerbase.de/2023-08...-das-melden-einer-sicherheitsluecke-verklagt/

Interessanter Artikel, macht dann auch Sinn

Ja, du klemmst dort ne API vor.

Wird wohl darauf hinauslaufen👍

Denk dran, dich vor SQL-Injektions zu schützen, wenn du deine PHP-API schreibst.

Danke! Grad schon mehrere Seiten dazu offen, werd mich gründlich einlesen!

Schonmal vielen Dank euch!

 

[dms]

Ob ne eigen Wrapper/Proxy-Api (REST?) besser ist als eine native, verschlüsselte Verbindung?

https://dev.mysql.com/doc/refman/8.0/en/encrypted-connections.html

 

[Yuuri]

als eine native, verschlüsselte Verbindung?

Was ist eine "nativ verschlüsselte Verbindung"? Die Welt spricht heute TLS. Das ist im MySQL Fall so, das ist im HTTPs Fall so. Nichts daran ist "nativ" (HTTP und MySQL "sprechen kein verschlüsselt") und wenn ist das "genauso nativ" wie HTTPs. Und selbst wenn MySQL irgendwas "nativ" könnte, ist das prinzipiell egal, denn TLS ist seit Jahrzehnten erprobt und battle-tested, ergo kann ich mit ner "nativen" Verschlüsselung mir auch viel mehr Probleme einhandeln, als wenn ich was nutze, was seit Jahrzehnten jeder produktiv auf der Welt nutzt. Da lässt man sich nicht auf solche Sperenzien ein.

Aber darum gehts überhaupt nicht. Wenn du die Credentials deiner DB offen legst, hast du Freiräume ohne Ende und quasi keine Permissions, die dich aufhalten, bspw. fremde Kundendaten einzusehen, zu manipulieren, zu löschen, Sachen hinzuzudichten usw. Allein der Permissions wegen schaltet man ne API davor, die sich um die Zugangskontrolle kümmert und absichert, dass User A nicht auf Daten von User B zugreifen kann.

Siehe die von mir verlinkte News, wo exakt dieses Szenario produktiv bei einer Firma eingetroffen ist (DB Credentials im Client mitgeliefert). Sahnehäubchen: es war noch nicht mal verschlüsselt. Aber das ist eher ein sekundäres Problem, denn selbst mit Verschlüsselung wurden die Credentials plain in der Anwendung ausgeliefert, womit die Verschlüsselung sowieso obsolet ist, wenn die Tür sperrangelweit offen steht.

 

[X__]

... Wenn du die Credentials deiner DB offen legst ..

Vielleicht schlaf ich ja noch, aber wo genau stand das, dass Larnox0 das vor hatte ?

 

[Yuuri]

Wie stellst du eine Verbindung ohne Credentials her?

 

[X__]

In dem ich beim Verbindungsaufbau die Credentials in eine Eingabemaske eintrage ?

Wie stellst du eine Verbindung ohne Credentials her?

Also gar nicht - aber ich lege sie nicht offen.

 

[Yuuri]

In dem ich beim Verbindungsaufbau die Credentials in eine Eingabemaske eintrage ?

Damit verteilst du deinen Vollzugriff offen in die Welt.

Also gar nicht - aber ich lege sie nicht offen.

Damit sind sie offen gelegt. Es ist schließlich nicht "deine" Datenbank, sondern die vom Service.

Die Credentials sollen nur dir gehören, nur du sollst Zugriff auf deine Daten haben und nur du sollst diese manipulieren können, aber auch nicht unter jedweden Constraints. Sowas kannst du auf DB-Ebene nicht regeln, dazu ist Business Logic im API-Layer nötig.

Meier soll bspw. keine Einsicht in die Daten von Schulze haben. Und Meier soll auch nicht Schulzes Daten manipulieren oder löschen können.

Wenn ich einen User in der DB lösche, dann ist der User weg während der Use Case bspw. noch ne zusätzliche Abfrage vorschreibt oder ne eMail schicken soll oder oder oder. Das ist mit ner kompletten Öffnung der DB nicht möglich und maximal fehleranfällig, da du die Daten direkt manipulieren und somit auch State hervorrufen kannst, der ggf. nicht mittels API Layer passieren kann. Du überlässt die Konsistenz deiner/aller Daten also externen, nicht vorhersehbaren Ereignissen.

Bspw. könnte man damit wunderbar Bestellungen löschen. Problem ist, dass hierbei sowas für Abrechnungszwecke einige Jahre vorgehalten werden muss. Klappt halt nicht, wenn jeder Vollzugriff auf deine DB hat. Glück, wenn du abgeleitete Daten noch als Mail vorliegen hast oder ausdruckst und abheftest. Pech, wenn du deine DB als Single Source of Truth siehst (was eigentlich getan wird) und diese "eine Quelle" nun keine Daten mehr führt. Die Möglichkeit Umsatzstatistiken über Zeitraum x zu fahren, sind damit unmöglich, weil ja jeder Bestellungen löschen kann. Deine Daten sind potentiell inkonsistent und wenn welche vorhanden sind, kannst du diesen prinzipiell nicht trauen, da sie manipuliert sein können. Wenn jemandem grad danach ist, kann man mir nichts dir nichts mal fix alle Foreign Key Constraints entfernen. Super, deine Daten sind so schon nicht nur inkonsistent, sondern auch deine Datensätze selbst sind es nun.

Du gibst deine Datenbank nie frei. Nie und nimmer.

Kennst du einen Fall, in dem ein Ladenbesitzer den Schlüssel seines Ladens seinen Kunden übergibt? Nein? Warum wohl? Warum gibst du also deine Zugangsdaten weiter?

 

[X__]

Damit sind sie offen gelegt.

Nö ?

Abgesehen davon:
Das löst du alles über individuelle Accounts, Privileges, Stored Functions und Views.
Der jeweilige zugreifende Account, legitimiert über die Constraints hat nur den Zugriff, der notwendig ist.
Da wird dann nichts mehr manipuliert, gelöscht oder eingesehen, wenn es mit deinem Zugriff nicht möglich sein soll.

Auf Basis der von Larnox0 geflossenen Information sehe ich da kein grundsätzliches Problem.
Aber sei's drum - ich klink mich hier mal aus.

 

[Ranayna]

Die Sache ist halt, das du in dem Moment wo du deinen SQL Server - wie auch immer du es machst - oeffentlich verfuegbar stellst, du dessen Angriffsflaeche massiv erhoehst.
Damit hast du einen weiteren Service neben deinem Webserver den du abhaerten musst.

Dass die Verbindung verschluesselt ist spielt bei dieser Betrachtung keine Rolle. Das schuetzt vorm Abhorchen der Verbindung, macht aber deinen Service nicht sicherer.