Ich hatte grade Probleme beim Umstellen auf HTTPS, kam nicht mehr ins Backend.

Lösung: in der config.php ergänzen:

$config['root_url'] = 'https://www.domain.de';
$config['ssl_url'] = 'https://www.domain.de';

Servus,
Alex

http://leafletjs.com/examples/quick-start/

MfG
Jan

https://www.cmsmadesimple.de/forum/view … 489#p40489

Dass dieser Topic nach wie vor ein topaktuelles Thema ist, zeigt eine aktueller Bericht von Menlo Security, wonach rein statistisch gesehen jede zweite Webseite ein Sicherheitsrisiko darstellt

Dies bestätigt auch ein aktueller Post im Google Webmaster Central Blog - demnach hat sich die Anzahl der gehackten Webseiten 2016 im Vergleich zu 2015 um 32% erhöht

https://webmasters.googleblog.com/2017/ … eview.html

So hab ich mir überlegt, was man da für CMS/ms tun könnte. Und mir ist da etwas kleines, aber effizientes eingefallen, was ich schon immer in CMS/ms umgesetzt haben wollte.

Ihr kennt doch alle unseren Security-Thread

https://www.cmsmadesimple.de/forum/viewtopic.php?id=18

Dort habe ich mir den Punkt 1.1 heraus gegriffen, also die Länge und die Qualität der Passwörter beim Erstellen und Bearbeiten von Nutzern. Da steht

Und haargenau dies hab ich über HTML5 Pattern umgesetzt - kleiner Aufwand, große Wirkung. Bei jeder Eingabe und Bearbeitung eines Nutzers muss jetzt das Passwort eingegeben werden, was diesen Qualitätsanforderungen genügen muss.

Bei der Gelegenheit hab ich die E-Mail-Adresse zum Pflichtfeld gemacht. Ansonsten läuft ja die gesamte Passwortwiederherstellung ins Leere.

Hier nun mein Patch

https://dl.orangedox.com/qalE06rfc1bqXd10FC?dl=1

Einfach in euer CMSMS-1 Installationsarchiv rein oder in eine bestehende Installation drüberkopieren - FERTIG! Natürlich wie bei jeder Aktualisierung ein Backup nicht vergessen .

Dies wäre Stop-Forum-Spam

Dies wäre DNSBL (Domain Name System Blacklists)

Eine weitere Alternative wäre Akismet, als Ersatz für die Captcha-Lösung

Gibt's auch als Modul für CMSMS

http://dev.cmsmadesimple.org/projects/akismet

Ist allerdings schon etwas älter und müsste angepasst werden.

Wie ihr unschwer erkennen könnt, wird da eine Verbindung via http-Protokoll (und nicht dem sicheren https) aufgebaut. Ergo erfolgt sämtliche Kommunikation mit dem Repository unverschlüsselt, weshalb das für Drupal geschilderte Problem für CMSMS genau so relevant ist.

Die Tatsache, dass es bei CMSMS "nur" die Aktualisierung von Modulen betrifft (und nicht die System-Aktualisierung wie bei Drupal), glättet (bei mir) die Sorgenfalten keineswegs. Ob nun das System 'ne Backdoor hat oder nur ein Modul, ist praktisch ohne Bedeutung - Backdoor ist Backdoor.

Fast 1 Jahr hat man benötigt, um diese (eigentlich simple) Sicherheitslücke zu schließen     

Könnte aber auch für CMSMS-Anwender relevant werden, sobald auf der Webseite Besuchereingaben möglich sind, wie zum Beispiel die FE-Aktion beim News-Modul, beim CGFeedback-Modul und beim GBook-Modul (Gästebuch)

Falls gewünscht und erforderlich, kann dies automatisiert über den Smarty-Tag replace ersetzt werden

{$entry->userinput|replace:'target="_blank"':'target="_blank" rel="noopener noreferrer"'}

wobei $entry->userinput die jeweilige Variable ist, die die Eingaben des Benutzers enthält.

http://www.smarty.net/docs/en/language. … eplace.tpl

Jetzt wollte ich mal sehen, wie das mit CMSMS klappt.

Wenn ich folgende Kode in der htaccess eingebe, erwarte ich, dass die Seite immer https ausgibt

[== html ==]
<ifmodule mod_rewrite.c="">
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</ifmodule>

Das funktioniert bei einer einfachen HTML/PHP-Seite, aber nicht mit CMSMS. Da lande ich immer wieder bei http.
Es ist der selbe Server, die selbe PHP-Version und die selben PHP-Einstellungen.
Seiten im admin als HTTPS markieren funktioniert, aber nicht, wenn man die Seite neu aufruft.
Wo soll ich suchen? Offensichtlich übersehe ich etwas.

DNS, mein Himmel wie kann man so auf den Schlauch stehen!!!
Das dauert eine Weile.

MfG
Jan

Musst unbedingt PHP 5.6 Laufen darunter tut sich nix.

Wusste ich bislang auch noch nicht - danke für die Info. Früher hat CG das mal publiziert...

Und in CMSMS gibt's bislang keine Option a la PhpMinVersion und PhpMaxVersion .

sorry, muß ein Anzeigefehler gewesen sein. Wurde mir sehr grau angezeigt.

Uff! Dann bin ich ja sehr erleichtert ;-)

Warten wir einfach ab bis @Dancer uns ein erhellendes Feedback geben kann.
Bis dahin kreuzen wir einfach die Finger

Nun, ich habe mal stichprobenartig (und wahllos) diverse meiner Seiten geöffnet und auf den oben beschriebenen Sachverhalt hin geprüft. Auf keiner dieser Seiten konnte ich den Code feststellen, so dass ich mich der Meinung von faglork anschließen muss

Da ich in der Zwischenzeit ein Update für Firefox installiert habe und ein (für mich unbekanntes) Plugin von Yahoo-Search entfernt habe,

ist die Ursache für den Code damit hoffentlich gefunden und beseitigt worden.

Ich danke allen Beteiligten, die sich der Sache angenommen und mir geholfen haben, noch einmal ausdrücklich und bitte um Entschuldigung, falls meine Ausführungen mißverstanden wurden oder ich nicht sofort die Vorschläge umsetzen konnte.
Ich werde mich in Zukunft bemühen, mich noch aktiver an der Problemlösung anderer zu beteiligen.
@NaN: ich hoffe, das Du Deine Finger wieder entspannen kannst 

Dabei ist mir aufgefallen, dass der Installationsassistent mit Rot anmeckert, wenn das Verzeichnis /modules keine vollen Rechte (=777) hat (nicht nur ein Hinweis).

Die Thematik hatten wir hier schon des öfteren, aber hier noch einmal - für diesen Ordner wird allenfalls nur dann eine Schreibberechtigung benötigt, wenn der ModulManager für die Installation neuer Module verwendet wird.

Der Einsatz des ModulManagers kann jedoch NICHT empfohlen werden!

Wird der ModulManager zur Installation und Aktualisierung von Modulen verwendet, erfolgt das durch einen Server-eigenen Prozess. Und derjenige, der die Installation/Aktualisierung durchführt, wird Eigentümer der neuen Dateien. Sprich, der Server ist dann der Eigentümer.

Im schlimmsten Fall kann (nicht wird) es dazu kommen, dass ihr aufgrund dieses Umstandes via FTP diese Dateien weder bearbeiten noch löschen könnt. Ist von den konkreten Server-Einstellungen abhängig. Manche Hoster haben in deren Backend eine Möglichkeit integriert, den Eigentümer ändern zu können.

Aber es bedeutet für euch auf jeden Fall eines - Mehrarbeit. Und wer will das schon ?

Von daher solltet ihr sowohl zum einen bei der Installation von Modulen auf den Einsatz des ModulManagers verzichten als auch nach der Installation die Berechtigung dieses Verzeichnisses auf einen sicheren Wert setzen.

Sagt nicht, euch hätte niemand gewarnt ...