php startet über exec() EXE und waaaaaaaartet endlos

[alter_Bekannter]

Okay, das musst du mir jetzt erklären wie wird ausgerechnet in diesem Szenario die Angriffsfläche kleiner indem man mehr Code involviert?

Normalerweise funktioniert es exakt umgekehrt. Beispiel aus der jüngeren Vergangenheit: shellshock, die Lücke war nicht in der Anwendung auf die von außen zugegriffen wurde selbst. Mehr Instanzen die zugegriffen werden können erhöhen das Sicherheitsrisiko außerhalb des Wunschdenkens immer. Außer für Dr. Manhatten natürlich. Aber für uns nicht allwissende Existenzen sollten wir Dinge wohl lieber so einfach wie möglich halten.

Es geht ja schließlich nicht nur um den selbst geschrieben Code sondern auch um die im Hintergrund immer größer werdende Liste an Fremdbibliotheken die man durch sowas massiv erweitert.

Dazu kommt:
Nur Whitelists sind Vertrauenswürdig.

 

[sia]

Ob man das Programm mit ner SQLI oder direkt ausführt, ist wurst. Bin da ausnahmsweise vollkommen bei alter_Bekannter.

Filterfunktion schreiben, fertig. Security by obscurity durch ne SQL-Abstraktion geht nur nach hinten los.

 

[drfuture]

das hat nichts mit Security by obsecurity zu tun sondern mit Rechteteilung.

Der Service der nach Außen geht ist der Webserver.
Dieser Empfängt ja die Anfragen und leitet sie in diesem Falle an ein .php-Script weiter. Somit ist die Betriebsumgebung die Abgesichert werden muss (unabhänging von anderen Diensten am System) die PHP-Umgebung.
Mit Systemnahen Befehlen kann sehr viel Schaden angerichtet werden - je nach php-konfiguration können beliebige Befehle am System ausgeführt werden oder zumindest die im Webroot - wenn nun ganze Serverdienste im Webroot liegen ist das schon schlimm genug.
Da bringt die Whiteliste im Script nicht viel... Wenn der Angreifer es schafft über eine Schwachstelle im php-script eine Datei auf den Server hochzuladen mit eigenem Programmcode.
Daher alle php-funktionen die Systembefehle Ausführen können Global sperren.

Das Modell über die Datenbank - von mir aus könnt ihr auch ein Flatfile nehmen - stellt eine Rechte-Trennung + die Restriktion der Rechte auf das Nötigste dar.
Die Anwendung und die gesamte Laufzeitumgebung auf die von extern zugegriffen werden kann - kann "nur" die .php-scripte ausführen und gehört zusätzlich in das eigene webroot eingesperrt.

Nun sollen aber Dienste am System gestartet werden was somit nun nicht mehr möglich ist. Daher eine Daten-Brücke mit allen benötigten und natürlich validierten benötigten Daten um die Dienste am Server passend zu konfigurieren und zu starten. Der Start passiert dann mit einem eigenen Benutzer mit passenden Rechten - der jedoch nicht mit dem Web-Benutzer in Verbindung steht.

Die Infos müssen vermutlich ja eh irgendwo gespeichert werden - da es eben ja auch den Fall gibt das das 1x gestartete sicher auch mal wieder gestartet werden soll / muss und dafür bietet sich wohl eher ein DBMS an als irgend ein Flatfile.
Insofern die Datenfelder dann auch passend bemessen sind und bei der Eingabe wie beschrieben auf gültigkeit validiert sind (portangaben die der User eingibt in ein int mit passender länge, Gameservername [A-Za-z0-9 ]) und die Daten vom Taskplaner ausgelesen und an die passende Stelle gesetzt werden. können auch keine geheimen Steuerbefehle eingeschleust werden.

 

[virtus]

Ich würde sagen, das hängt mit der Anwendungsgröße und dem Umfang zusammen. Geht es wirklich nur darum einen (einzigen) Server zu starten, dann birgt die Datenbank-Lösung sicherlich zusätzliche Gefahren, die nicht durch die gewonnene Sicherheit aufgewogen werden können. Andererseits stimmt es schon, was drfuture sagt: Die Webanwendung sollte keine Möglichkeit haben direkt Systemapplikationen auszuführen. Sollen auf diese Weise zig Server mit unterschiedlichen Konfigurationen gemanaged werden, würde ich ebenfalls zu drfutures Lösung tendieren.

Wenn die Webanwendung Programme ausführen kann, dann birgt das ein potentiell sehr hohes Sicherheitsrisiko. Geschickter ist es, wenn das WebUI nur Anfragen entgegen nimmt und vormerkt. Dabei muss das UI natürlich sicher stellen, dass nur Berechtigte Anfragen stellen können und dass die Anfragen korrekt eingetragen werden. Das heißt ein Nutzermanagement muss her und natürlich muss sich darum gekümmert werden, dass bspw. keine SQL-Injections möglich sind.
Bei einer Sicherheitslücke in dem UI wäre es zwar immer noch möglich, dass diverse manipulierte Anfragen gestellt werden, aber zumindest kann der Angreifer nicht direkt Anwendungen auf dem Server starten.
Ein rein interner Prozess, der sich um die Abarbeitung der Anfragen kümmert, muss sich um den ganzen UI-Quatsch nicht kümmern, sondern nur darum, dass Anwendungen gemanaged werden, so wie es einerseits in den Anfragen gefordert wird, aber andererseits logisch ist. Wenn in den Anfragen steht, es soll ein Webserver auf 80 gestartet werden, dann sollte erkannt werden, dass ein Webserver keine zulässige Anwendung ist und dass Port 80 auch nicht erlaubt ist. Andererseits, wenn in der Datenbank steht, dass 100 Gameserver auf den Ports 23000 - 23099 zu starten sind, dann sollte genau das passieren, soweit Systemressourcen verfügbar sind.

Das Konzept kommt dem MVC Pattern nahe. Das WebUI ist nur ein View und sollte keine Kontrollstruktur für das System realisieren und schon gar nicht sollte sie direkt Änderungen am Model durchführen. Trotzdem muss es natürlich sicherstellen, dass in z.B. ein Zahlenfeld nur Zahlen eingetragen werden können.


Ich weiß nicht, wie es mit Windows-Anwendungen und Docker aussieht, ggf. wäre es ganz interessant den Server als Dockercontainer zu packen und beim Start nur noch die Portbindung umzubiegen.