VN Upload Block

[Tommy Herrmann]

Volker,

sorry - wenn die Server-Daten vom SMTP in der Projektdatei lesbar sind, müssen die dort wieder raus. Da reicht ein Sicherheitshinweis nicht - das wäre unverantwortlich

[Volker]

ich überlege mir eine verschlüsselung

[Volker]

OK Tommy Du hast mich überzeugt

(XOR + Base64 wird da jetzt eingebaut. Das ist auch nicht 100% sicher, weil wenn ein Programmierer an die app.js kommt könnte er (mit Aufwand) den schlüssel zurück codieren. Aber jetzt mal ehrlich Tommy WER ?? DU ? Nö ..sonst wer hier ? Nö

Es gibt auch leider im Web keinen 100%igen Schutz. Aber wenn ich das jetzt da rein baue kann niemand etwas in der project.mobirise lesen. Somit ein sehr guter Kompormiss wie ich finde.

Ist heute Abend oder Nachmittag in allen Anwendungen drin


Was jetzt gilt:

In project.mobirise steht nicht mehr das Klartext-Passwort, sondern nur noch sowas wie ENC1:kX9mP2vL8q... (verschlüsselter Kauderwelsch)
Jemand, der einfach nur die Datei öffnet sieht nur den Kauderwelsch, kann das Passwort nicht direkt ablesen.

die letzten 10% Tommy: Wenn ein böser Bube nun auch diese Erweiertung runter läd, die app.js raus holt und genau untersucht, könnte er - wenn er Ahnung hat- den Schlüssen rauslesen - JA ist so und muss ich erwähnen.

Aber wenn Du die Erweiterung auf Deiner Webseite hast, kann da keiner irgend was lesen . Der Angreifer braucht also den Schlüssel udn Deine project.mobirise um Dann dein Passwort zu sehen. Nicht ausgeschlossen- von daher die 10%

[Tommy Herrmann]

Ja - das fände ich auch sicher genug - allerdings musst Du dann zwingend auf das Risiko hinweisen, sodass es jedem, der das einbaut eben auch klar ist.

Ich frage mich nur, ob diese Möglichkeit das nun unbedingt in den Site-Einstellungen von Mobirise eintragbar zu machen, diesen Aufwand wert ist Ich würde es ganz raus schmeißen, dann ist es wirklich sicher.

[Volker]

Ne Tommy das soll so bleiben weil eben einfacher und schneller.
Mit der Sicherung kann keiner mehr an Deine Passwörter. Es sein denn er hat die app.js und Deine project.mobirise

Aber die schützt du ja wie du sagtest

[Volker]

Tommy,

wenn morgen dein PHP auf dem Server mal abkackt, lese ich dir die ganze config.php aus ohne
irgend etwas zu hacken Zum Beispiel. Es gibt kein 100% sicheres Internet !!

KI gibt mir Recht

Kurz gesagt: Der Schlüssel allein ist wertlos ohne Tommys spezifische Datei. Und seine Datei zu bekommen erfordert schon einen viel direkteren Zugriff auf sein System – da wäre dann sowieso deutlich mehr im Argen als nur ein SMTP-Passwort (z. B. hätte ein Angreifer mit Zugriff auf seinen PC ohnehin schon viele andere Wege, an sensible Daten zu kommen).

Fazit: Für den ursprünglichen Sorge-Fall ("Datei liegt irgendwo offen rum, jemand stolpert einfach drüber") ist das jetzt solide abgesichert. Gegen einen gezielten Angriff auf Tommys Rechner selbst hilft keine Verschlüsselung der Welt wirklich zuverlässig – da geht's dann um generelle PC-Sicherheit, nicht mehr um dieses eine Passwort-Feld.

[Volker]

VN Upload ist nun Verschlüsselt. Ich hab es noch nicht getestet, da noch im Bus

[Volker]

Halt Stopp
Ich hab was viel besseres - 100% Schutz

Das Passwort wird nicht in die project.mobirise geschrieben, sondern direkt in die config.php und zwar leider bei jedem publichen. Wird also ein Feld aufehen SMTP Passort eingeben. Aber nun die gute Nachricht: Gilt dann für alle Blöcke die SMTP haben und im Prjekt sind

Das teste ich gerade.... meld mich dann

[Volker]

So, ich lasse es jetzt erstmal so.

Wenn Du uploads einbaust und mobirise beendest sind die SMTP Daten weg.
Wenn Du nach erneuten öffnen von Mobirise einen anderen Block, z.B. fromrender einbaust, musst du dem ebenfalls smtp daten geben einmalig. Nur werden dann auch die SMTP Daten des Uploads damit überschrieben.

Aber das war ja von Anfang an mein Plan. Alle Blöcke nutzen den selben SMTP.
Da man ja in jedem Block eine andere Empfänger E-Mail einsetzen kann macht das für mich am meisten Sinn, anstatt zig verschiedene SMTP Server Konfigurationen da zu haben

Also das DING ist jetzt Sicher !!! Keine Daten in Mobirise - alles in der config.php

[Volker]

Ach ist das herrlich

Man muss nur Ideen haben

Ich habe eine zentrale config.php für alle Blöcke die SMTP nutzen. die wird in den Ordner assets/vn-shared/config.php gelegt.

Egal welcher Block zuerst eingebaut wird, der legt die config.php an, alle anderen Blöcke die danach kommen, egal wann, lesen genau diese config aus

Jetzt sagt bitte keiner - oh das ist aber kacke, ich hab ja 10 verschiedene SMTP Mails NEIN habt ihr nicht (normalerweise)

Ich sagte es ja bereits: Die Empfänger Email ist nicht die Sende Email des SMTP !!! Die wird bei jedem Block eingegeben und somit kann der Upload an volker gehen, der GB Eintrag an die info und der formrender an die mail@niederastroth.de oder auch an info@sound-dj.de oder an welche auch immer ich da eintrage

[Tommy Herrmann]

Ja - wenn die Daten nun nur noch in der config.php sind, finde ich das in Ordnung - bzw. großartig

Was macht denn jetzt so ein Webdesigner, wie unser Frank? Der bearbeitet nehmen wir mal an - 5 verschiedenen Kunden am gleichen Tag. 4 dieser 5 Kunden haben nun zufällig das gleiche Upload-Formular, bzw eine Anwendung die eben genau diese Technik verwendet, in ihren Projekten.

Kann Frank dann die SMTP Daten einfach neu eintragen oder werden dann die von Kunde A auf den Server vom Kunden B kopiert ...

[Volker]

So Dank Tommy habe ich nun meine Erweiterungen sicherer machen können.
Danke nochmal an Tommy der immer kritisch ist - das ist gut so
Ich bin auch manchmal zu schnell, weil ich auch schnell begeistert bin

Aber nun zu den Tatsachen:

Alle Blöcke die Mailversand haben, nutzen ab sofort eine zentrale config.php
Die hat dann die SMTP Daten einmalig gespeichert. Es werden keine Daten im Projekt gespeichert, alles extern in der config.php und somit 100% Sicher - falls nicht euer PHP ausfällt

Den Einwand von Tommy das er zig SMTP Mails hat lasse ich nicht gelten, weil so nicht richtig. Wenn man eine Domain hat bei ionos oder sonst wo, hat man nur einmal SMTP Daten, auch wenn man 5 oder 10 Email Konten hat.

Die sende Email die eigegeben wird also der SMTP Benutzer kann auch mit allen anderen Mailadressen senden !! IMMER

Beispiel: meine SMTP Email ist die smtp@niederastroth.de (weil da kenn ich das PW auswendig )
Trotzdem kann ich als Absender jede beliebige Emailadresse meines Servers angeben - Das geht auch bei Tommy
Welche Emailadresse was empfangen soll legt man ja im Block selber fest. Hatte ich aber jetzt auch mehrfach schon erwähnt

Also ist jetzt im Download und kann gerne getestet werden

[Volker]

Ja - wenn die Daten nun nur noch in der config.php sind, finde ich das in Ordnung - bzw. großartig

Was macht denn jetzt so ein Webdesigner, wie unser Frank? Der bearbeitet nehmen wir mal an - 5 verschiedenen Kunden am gleichen Tag. 4 dieser 5 Kunden haben nun zufällig das gleiche Upload-Formular, bzw eine Anwendung die eben genau diese Technik verwendet, in ihren Projekten.

Kann Frank dann die SMTP Daten einfach neu eintragen oder werden dann die von Kunde A auf den Server vom Kunden B kopiert ...

Das sind ja dann auch verschiedene Server, bzw. wenn Frank das bei sich auf dem Server zuerst testet verschiedene Ordner- kein Problem

[Volker]

Tommy,

wenn du die SMTP Daten leer lässt, kannst du auch gerne die per Hand eingeben -direkt in die config.php auch das geht
Die muss dann aber auch so aussehen:

Code: Alles auswählen

<?php
$smtp_host = "smtp.deinserver.de";
$smtp_port = 587;
$smtp_encryption = "tls";
$smtp_username = "deine@email.de";
$smtp_password = "dein-passwort";
$smtp_from_email = "no-reply@deinedomain.de";
$smtp_from_name = "Deine Website";
// Aliase für Gästebuch (andere Namenskonvention)
$smtpHost = $smtp_host; $smtpPort = $smtp_port; $smtpCrypt = $smtp_encryption; $smtpUser = $smtp_username; $smtpPass = $smtp_password;

[Tommy Herrmann]

Moin,

… nur noch zur Klarstellung - eigentlich meinte ich auch verschiedene SMTP-Server - also von verschiedenen Domains mit verschiedenen E-Mail Adressen - eben dann, wenn man z.B. für verschiedene Kunden Webseiten erstellt. Bei meinem Provider IONOS ist ja der SMTP-Server immer gleich - smtp.ionos.de - egal um welche Domain es sich handelt. Da hattest Du mich falsch verstanden oder ich habe mich blöd ausgedrückt.

Es muss jedenfalls ausgeschlossen sein, dass da versehentlich durch diese Eingabemaske der Mailzugang vom Kunden A beim Kunden B am Server landet.

Aber Du schreibst ja, dass da nix passieren kann.

Offenbar habe ich die Logik dieser Eingabemaske noch nicht vollständig verstanden. Meiner Ansicht nach ergibt sie nur Sinn, wenn man ständig mit derselben Domain arbeitet — bei Mobirise ist das jedoch häufig nicht der Fall.

Dann müsste der Benutzer auch noch mehrfach diesen SMTP-Zugang benötigen, also mehrere Deiner Anwendungen einbauen, nur dann würde es einen gewissen Sinn machen - aber eigentlich auch dann nicht, denn die Eingabe der SMTP Daten ist ja einmalig.

[Volker]

Moin Tommy,

danke für die Klarstellung – jetzt verstehe ich dein Anliegen richtig, und ehrlich gesagt: dein Einwand ist berechtigt.

Kurz zur aktuellen Funktionsweise: Die SMTP-Daten, die du im Sidebar einträgst, landen in einem gemeinsamen Arbeitsspeicher-Objekt, das für die gesamte laufende Mobirise-Sitzung gilt – nicht pro Projekt. Das war ursprünglich so gedacht, damit man SMTP nicht für jeden einzelnen Block auf derselben Website neu eintragen muss.

Das Problem, das du zurecht siehst: Falls Mobirise beim Wechsel zwischen zwei unterschiedlichen Projekten (Kunde A → Kunde B) die App nicht komplett neu lädt, sondern einfach nur das Projekt im Hintergrund wechselt, würden die SMTP-Daten von Kunde A im Speicher hängen bleiben – und beim Publishen von Kunde B's Seite versehentlich mit reinlaufen. Das wäre tatsächlich ein Datenleck zwischen Kunden, genau wie du befürchtest.

Ob das wirklich passieren kann, hängt davon ab, ob Mobirise beim Projektwechsel die komplette Anwendung neu startet (dann ist der Speicher automatisch leer) oder nur das Projekt im Hintergrund tauscht (dann bleibt der Speicher bestehen). Das weiß ich ehrlich gesagt nicht sicher – das muss getestet werden, bevor ich "Entwarnung" geben kann.

Was ich als Nächstes mache: Ich baue das so um, dass die SMTP-Daten projektgebunden sind statt nur sitzungsgebunden – dann kann selbst bei einem Wechsel innerhalb derselben Mobirise-Sitzung nichts zwischen verschiedenen Kundenprojekten überspringen. Bis das eingebaut und getestet ist: sicherheitshalber Mobirise nach jedem Kundenprojekt einmal komplett schließen und neu starten, bevor du am nächsten Kunden weiterarbeitest – dann ist der Speicher garantiert leer.

Danke fürs genaue Hinschauen, das war ein wichtiger Punkt!

[Tommy Herrmann]

Tante KI hat mich verstanden —

Es ist schlichtweg so: Man darf niemals davon ausgehen, dass ein Benutzer etwas richtig macht. Man muss immer damit rechnen, dass er es falsch macht — und trotzdem darf dadurch nichts passieren.

[Volker]

Ja die kanns halt besser erklären wie ich

Also wird auch gefixt

[Tommy Herrmann]

Eigentlich könnte man doch auch einen Block erstellen, der dann mit den fertigen SMTP-Daten für einen jeden Kunden als User-Block speicherbar ist. Dann müsste man diesen Block einfach auf jeder Seite aufziehen um irgendeiner Anwendung die SMTP-Daten mitzugeben. Wenn keine SMTP-Daten benötigt werden, dann gibt es eben auch keinen Block.

… nur falls Du nichts mehr zu tun haben solltest

[Volker]

So Tommy,

jetzt Idioten Sicher
KI Antwort für Tommy:

ist erledigt – hab's heute noch gefixt, nicht nur versprochen.

Was sich geändert hat: Jedes Mobirise-Projekt bekommt jetzt automatisch einen eigenen, zufälligen "Fingerabdruck", der ganz normal im Projekt gespeichert wird. Bei jedem Öffnen der Projekteinstellungen wird geprüft: "Ist das noch dasselbe Projekt wie beim letzten Mal?" Falls nicht (anderes Kundenprojekt, oder komplett neues Projekt) – wird der SMTP-Speicher automatisch geleert, bevor überhaupt was schiefgehen könnte.

Für dich heißt das konkret: Wechselst du von Kunde A zu Kunde B (egal ob mit oder ohne kompletten Mobirise-Neustart dazwischen), springen die SMTP-Daten von A nicht mehr automatisch zu B rüber. Bei B siehst du dann einfach leere SMTP-Felder und trägst seine eigenen Zugangsdaten neu ein – so wie du's ja sowieso erwartet hast.

Du musst also nichts mehr manuell absichern oder dran denken – läuft jetzt automatisch richtig.