Sind mit Delphi erstellte Programm sicherer?

[dummzeuch]

Zitat:

Zitat von Sherlock (Beitrag 1527792)

Ich würde in der Tat erst dann einen Browser in meine Anwendung integrieren, wenn sonst absolut nichts geht - und damit meine ich auch selbst schreiben mit ca. einem Mannjahr Aufwand. Denn Browser öffnen dem entsprechend geneigten Menschen Tür und Tor.

1 Mannjahr? Und Deine Kunden bzw. dein Arbeitgeber bezahlt das dann?
Bei meinem müsste ich dafür schon ziemlich gute Argumente bringen.

[himitsu]

Grund: Sicherheit :stupid:

[jaenicke]

Bei manchen Aufgabenstellungen wie z.B. einer XSL Transformation gibt es leider oft gar keine andere Wahl. Wenn da eine Chromium-basierte Bibliothek die einzige ist, die diese Transformation korrekt ausführt...
(Selbst große und teure Bibliotheken waren daran gescheitert.)

Wenn es aber nicht wirklich nötig ist, würde ich auch von einer solchen Integration absehen. Gibt es keine Alternative, sollte ein Plan vorliegen, wie man die Bibliotheken aktuell hält, um Sicherheitslücken zu stopfen.

[gubbe]

Zitat:

Zitat von BlueStarHH (Beitrag 1527769)

Der Kunde hat Angst, dass wenn dort eine Sicherheitslücke auftreten sollte (was soll das hier sein) der Angreifer Schaden auf seinen System anrichtgen könnte oder sogar Vollzugriff auf alles bekommt.

Wo stellt sich denn der Kunden einen potentiellen Angreifer vor? Aus dem Internet? Das fällt ja hier aus, wenn Dein Programm keinen Internet-Zugriff braucht. Wenn ich es richtig verstehe, verarbeitet es auch keine fremden Dateien. Dann bliebe ja nur ein lokaler Angreifer, der sowieso schon Zugriff auf den Rechner hat. Dann braucht er auch keine Lücke in Deinem Programm mehr zu nutzen, sondern könnte sowieso alles mit den Rechten des lokalen Nutzers machen. Solange Dein Programm nicht mit höheren Rechten läuft, ist es für Angreifer auch nicht interessant.

Ob das Programm jetzt in Delphi, C oder einer anderen Sprache geschrieben ist, spielt hier doch gar keine Rolle. Einziger Knackpunkt ist vielleicht die Einbettung eines Browsers. Wie liest der Browser denn die mitgelieferten HTML-Dateien und SVG-Animationen? Einfach lokal mit dem File-Protokoll oder von einem (lokalen) Webserver? Wenn der Browser mitgeliefert wird, sollte er natürlich keinesfalls dafür benutzt werden können, irgendwelche externen Internet-Seiten anzuzeigen, da er vermutlich nicht regelmässig aktualisiert wird und für diesen Zweck als unsicher gelten muss. Ist ausgeschlossen, dass die Benutzer ihn trotzdem dafür verwenden können?

Ohne jetzt das Konzept in Frage stellen zu wollen, aber warum muss überhaupt ein Browser in Delphi eingebettet werden? Die Seiten mit einem normalen Browser anzuschauen ist nicht möglich?

[himitsu]

Zitat:

Zitat von gubbe (Beitrag 1527801)

Ob das Programm jetzt in Delphi, C oder einer anderen Sprache geschrieben ist, spielt hier doch gar keine Rolle. Einziger Knackpunkt ist vielleicht die Einbettung eines Browsers.

oder andere Fremdkomponenten (extern oder intern)

oder selbsteingebaute Lücken (SQL-Injektion uvm.)

oder Lücken in den Funktionen der verwendeten Basis-Libraries. (.NET-Runtime, C++Runtime, RTL, VCL, FMX, .......)

oder

oder

[gubbe]

Zitat:

Zitat von himitsu (Beitrag 1527802)

oder andere Fremdkomponenten (extern oder intern)

oder selbsteingebaute Lücken (SQL-Injektion uvm.)

oder Lücken in den Funktionen der verwendeten Basis-Libraries. (.NET-Runtime, C++Runtime, RTL, VCL, FMX, .......)

oder

oder

Ja, aber jegliche Lücken lassen sich doch nur ausnutzen, wenn fremde Benutzereingaben oder Dateien verarbeitet werden. Angenommen, die verwendete JPG-Bibliothek wäre verwundbar, spielt das in diesem Fall gar keine Rolle, solange das Programm keine fremden JPGs lädt.

[Sherlock]

Zitat:

Zitat von dummzeuch (Beitrag 1527797)

1 Mannjahr? Und Deine Kunden bzw. dein Arbeitgeber bezahlt das dann?
Bei meinem müsste ich dafür schon ziemlich gute Argumente bringen.

Das dient rein der Abschreckung. Browserbasiertes Zeug darf jeder gerne im Browser nutzen. Aber ich bring mich doch nicht in Richtung Haftbarkeit, nur um einen schicken Rahmen drumherum zu bauen. Davon abgesehen, bin ich in der glücklichen Situation nicht selbständig zu sein und keine browserbasierten Applikationen herstellen zu müssen. Meine Applikation muss gemäß MPDG und einem Stapel Normen entwickelt sein, da fallen Spirenzchen wie Browser schon fast automatisch raus. Es reicht da auch nicht, nur zu schreiben die Software sei sicher, das muß entsprechend unabhängig belegt werden.

Sherlock

[QuickAndDirty]

"Das Programm braucht keinen privilegierten Zugriff, ist also sicher!"

[Gausi]

Zitat:

Zitat von QuickAndDirty (Beitrag 1527874)

"Das Programm braucht keinen privilegierten Zugriff, ist also sicher!"

Ich glaube kaum, dass man mit diesem Argument einen auf Sicherheit fixierten IT-Admin überzeugen kann. :lol:

"Zum Starten des Autos braucht man keinen Führerschein. Also ist es sicher." (Ich liebe hinkende Auto-Vergleiche.)

[masc-online]

Zitat:

Zitat von Gausi (Beitrag 1527882)

Zitat:

Zitat von QuickAndDirty (Beitrag 1527874)

"Das Programm braucht keinen privilegierten Zugriff, ist also sicher!"

Ich glaube kaum, dass man mit diesem Argument einen auf Sicherheit fixierten IT-Admin überzeugen kann. :lol:

"Zum Starten des Autos braucht man keinen Führerschein. Also ist es sicher." (Ich liebe hinkende Auto-Vergleiche.)

Beim ursprünglichen Zitat fehlt hoffentlich nur das Zwinker-Smiley. Ansonsten dürfte die Aussage gar keinen IT-Admin überzeugen. Auch ohne Admin-Rechte kann man genügend Schindluder treiben (Stichwort Ransomware).

Bei solchen Fragen geht es in der Regel weniger darum darzulegen, dass eine Software, die mit Programmiersprache A programmiert wurde, mehr oder weniger fehleranfällig ist, als eine Anwendung, die mit Programmiersprache B entwickelt wurde. Man soll nur darlegen, dass man weiß

• Was die Anwendung macht
• Was drin steckt
• Es eine verantwortliche Person oder Firma gibt, die sich um den Lifecycle der Anwendung kümmert

Es hilft / ist in der Regel ausreichend, wenn man den entsprechend interessierten Personen darlegen kann:

• In welcher Frequenz neue Versionen veröffentlich werden (gerne inkl. Changelogs)
• Ein Fehlertracking / Support Tool im Einsatz zu haben
• Eine Erreichbarkeit im Problemfall sicherzustellen
• Welche Bibliotheken verwendet werden
  • Klingt erstmal lästig, aber eigentlich sollte man 3rd-Party-Komponenten schon aus Eigeninteresse inkl. Quelle dokumentieren
  • Wenn man nicht jeden Kleinkram angeben will (und auch aus bspw. Lizenzgründen nicht muss), sollten in der Liste zumindest die größeren Kandidaten auftauchen (bspw. Synopse mORMot, JEDIs, TMS VCL UI Pack, etc.)
  • Insbesondere eingebettete Browser sind inkl. Version anzugeben
  • Programme Dritter, die man mit ausliefert, inkl. Version und Lizenz angeben
  • Wenn man schon nicht selbst jeder Release-Note der entsprechenden Pakete hinterherlaufen will, kann die anfragende Person aufgrund der Infos auf Wunsch selbst ein CVE-Tracking der genutzten Pakete durchführen und dem Anwendungsentwickler bei Bedarf auf die Füße treten und anfordern, dass die Software entsprechend aktualisiert wird

Wenn alles nichts hilft, kann man noch einen Pentest für die Anwendung beauftragen, was aber dann auch kostet. Aber dann hätte man (wenn's gut läuft) im Anschluss in der Regel ein Schriftstück, in dem vermerkt ist, dass keine Probleme wie SQL-Injektions, unverschlüsselte Passwörter, Memory Leaks, etc. gefunden wurden. Oder man hat eine Liste mit offenen Punkten und weiß, was man noch zu verbessern hat. ;-)