WBCE CMS – Way Better Content Editing.
You are not logged in.
Hi,
ich habe mein Addon File Editor Modul reaktiviert und eine erste WebsiteBaker CE Version auf GitHub bereit gestellt.
https://github.com/cwsoft/wbce-addon-file-editor
Eine angepasste Postits Version wird die nächsten Tage folgen.
Gruss cwsoft
Last edited by cwsoft (27.07.2015 20:06:37)
Account inactive since 2018/11/17.
Offline
Genial, danke!
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Kleine Anmerkung meinerseits: Der AFE _kann_ zu einem Sicherheitsloch werden, da er den Zugriff auf Dateien ermöglicht, an die man sonst nur per FTP dran käme. Ich weise deshalb darauf hin, weil genau das bei BC vorgekommen ist. Ursache war eine Sicherheitslücke außerhalb des AFE, nichtsdestotrotz sollte man das im Hinterkopf behalten.
Ich handhabe das jetzt so, daß ich den AFE nur installiere, wenn ich ihn brauche, und hinterher wieder entferne.
Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal
Offline
Hi,
denke den optionalen FTP-Layer in AFE verwenden nur ganz wenige, die auf schlecht konfigurieren shared hosting providern unterwegs sind. Dazu müssen die FTP-Zugangsdaten eingetragen werden, welche in der AFE Modul-DB im Klartext (anders gehts nicht) gespeichert werden.
Gruss
Account inactive since 2018/11/17.
Offline
Ich sprach nicht vom FTP-Layer in AFE.
Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal
Offline
@webbird: Habe Deine Antwort gelesen :-) Die BC-Lücke bezog sich auf externen FTP-Zugriff (nicht AFE). Meine Antwort bezog sich auf Dein Statement, dass Du AFE installiert solange es gebraucht wird und danach wieder löscht. Nach meiner Erfahrung verwenden 95% der AFE-Anwender den optionalen FTP-Layer gar nicht.
Sprich nur wer den FTP-Layer in AFE aktiviert (5% der Anwender) setzt sich der Gefahr aus, dass durch auslesen der WB-DB die FTP-Zugangsdaten in die Hände fallen. Würde aber mal sagen wenn man die WB-DB auslesen kann, sollte man a) zu der vertrauenswürdigen Nutzern gehören (z.B. Zugang zu Droplets, Admin-Tools), oder b) man sitzt eh schon tief in der Sch.. :-)
Grüsse
Account inactive since 2018/11/17.
Offline
https://github.com/WBCE/WebsiteBaker_CommunityEdition/issues/19
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
@cwsoft: Das ist korrekt, aber nicht vollständig. Bei BC war es folgendermaßen: Durch eine Lücke konnte man die config.php runterladen, die beinhaltete das DB-Kennwort, der Hacker änderte das Kennwort des Admin Accounts und konnte sich im Backend anmelden. Und dort wiederum konnte er mit dem AFE dann supereasy seine Schadscripten hochladen. Hat mit dem FTP-Kennwort an dieser Stelle nichts zu tun.
Okay, mit dem Admin Zugriff hätte er auch den AFE nachinstallieren können, aber dazu ist noch etwas mehr Kenntnis des CMS notwendig als für das beschriebene Vorgehen.
Es ging mir auch nur drum, ein wenig Sensibilität im Umgang mit Powertools wie dem AFE anzuregen.
Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal
Offline
@Webbird: Die genauen Details des BC-Angriffs kenne ich natürlich nicht.
Nur soviel. Wenn ein Angreifer (oder Benutzer) Zugang zum Backend und den "Admin-Tools" hat, kann dieser eh beliebigen PHP-Code ausführen (Module: Code, Code2, Droplet, Notfalls SQL-Injektion mit Backshell). Da ist es dann auch Wurscht, ob er mit AFE eine Datei über eine "GUI" hochladen kann. Er kann dies ja auch einfach per: echo "Schadcode" > Datei tun und die Datei dann aufrufen ...
Generell gilt: Die WB-Admintools sind sehr mächtig. Wer Zugang zu Code/Code2 und Droplets hat, kann mit minimalem PHP-Anwenderwissen nach belieben schalten und walten wie er will.
Ich habe Deine Anregung aber aufgenommen und den Abschnitt Security in der README hinzugefügt.
Habe mir auch die Freiheit genommen AFE im Github Repo durch die aktualisierte wbce-afe Version auszutauschen (Quasi als Test ob mein Zugang zum Repo geht).
Gruss
P.S.: Ach ja. Sollten wir im Team beschliessen AFE fliegt wegen Sicherheitsbedenken raus, hätte ich kein Problem damit. Ich will/muss keinem was beweisen oder meinen Willen um jeden Preis durchsetzen
Last edited by cwsoft (27.07.2015 23:05:47)
Account inactive since 2018/11/17.
Offline
Da hast Du recht. Wobei es in BC standardmäßig kein Codemodul gibt, aber wir sollten das vielleicht nicht weiter ausführen. Wie gesagt, mir ging es nur darum zu sensibilisieren. Womöglich ist mein Fall der einzige, der über den AFE stattfand. Man weiß es nicht.
Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal
Offline
Hi,
Da hast Du recht. Wobei es in BC standardmäßig kein Codemodul gibt
Nur aus reiner Neugierde. Ist das Droplets Module das im BC-Standardpacket enthalten ist im Vergleich zum WB-Droplet Modul noch in irgendeiner Hinsicht "abgesichert"? Mit Droplets kann ein "bösartiger" Angreifer ja auch nach belieben Schindluder treiben (PHP, MySQL).
Gruss
Account inactive since 2018/11/17.
Offline
Man kann Rechte auf Droplets vergeben, ansonsten ist eine Absicherung kaum möglich. Wenn man es noch weiter treiben will, könnte ein Angreifer auch ein Modul bauen, das Schadcode enthält, und dieses installieren. Ist man erst im Backend, ist so ziemlich alles möglich. Nur die Hürde ist halt etwas höher.
Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal
Offline
Also, wenn jemand BE Zugriff bekommt mit Admin Rechten hat er in Jedem Fall den Jackpott. Das System liegt sozusagen Nackig vor Ihm. Er kann einfach modifizierte Module installieren oder z.B. ein Code Modul, kann Droplets schreiben , was auch immer . Wenn ein Angreifer bis dahin kommt haben Wir verloren , kein Wenn und Aber.
Was können Wir also tun ?
1. Verhindern das Andere als vom Admin festgelegte Nutzer auf solche Tool Zugriff bekommen.
2. Verhindern das irgendjemand von extern auf diese Tools Zugriff bekommt
3. Solche Tools entfernen.
3. Ist nicht akzeptabel da diese Tools gebraucht werden. Man muss Sie nicht alle im Core mitliefern das Vermindert die Anzahl der Schadensfälle wenn mal was Schiefgeht. Nicht jeder Braucht Code, AFE und einige andere. Also einfach nicht Alles im Core mitliefern, sondern ein gutes Modul Repo anbieten.
2. Ist eigentlich Standard , wir wollen ja auch nicht das sich jemand Core Funktionalitäten von Außen kapert. Kann halt Passieren, muss dann gefixt werden.
1. Hier geht ne Menge aber ich bin mir nicht völlig sicher mehr wie das bei WB geht.
a. Dafür Sorgen das diese Module nach der Installation nur für Admins zur Verfügung stehen.
b. für Vorinstallierte gilt das gleiche.
c. Manche Tools einfach für alles außer Gruppe Admin sperren.
d. vielleicht bei der Installation ein Warnhinnweis.
e. Die Tabelle Gruppenrechte von WBCE so ändern das erst einmal beim neu erstellen Alles deselektiert ist oder zumindest diese Module deselektiert sind.
Ich glaube Mehr geht nicht außer auf diese Module zu verzichten.
Offline
Ahhh nochwas... das eval() aus den Modulen entfernen. Das WB Core Team hatte mit haufenweise zusätzlich eingefügten eval() zu kämpfen(Seite war ja gründlich gehackt). Wenn man weiß das im Original keine Evals drin sind, dann weiss man sofort , das gehört da nicht hin. Zumal Eval deutlich langsamer ist.
Man kann dann auch automatisierte Warnmechanismen auf Eval ausweiten. Einmal Am Tag ein kleines Grep, und wenn ein Bas64 oder ein eval() auftauchen .... ALAAAARM. Mach Strato zum Beispiel so mit Base64 decode.
Offline
Frage in die Runde. Nutzt AFE noch jemand regelmässig, oder werden andere Tools wie FTP, Browser, PHP Filemanager verwendet. Was stört an AFE, was wird vermisst.
Prüfe gerade ob sich ein Update noch lohnt. Gibt ja zwischenzeitlich gute Alternativen und wir sind auch nicht in 2008 stehen geblieben - obwohl AFE für 2008 recht gut war
Meinungen?
Gruss cwsoft
Last edited by cwsoft (22.05.2016 23:48:04)
Account inactive since 2018/11/17.
Offline
Also ich verwende den AFE durchaus oft - um mal schnell was nachzuschauen oder zu fixen ohne erst FTP und Notepad++ bemühen zu müssen. Einige Module bringen zudem selbst keine Möglichkeit mit, z.B. Styles zu bearbeiten und verweisen ausdrücklich auf den AFE.
Praktisch finde ich auch die Funktion, sich Vorlagen und Templates als Zip herunterzuladen, das kommt häufiger vor, dass ich Anpassungen vorgenommen habe und diese nun auch auf anderen Websites einsetzen will und so gleich einen Installer dafür habe.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Ich möchte ihn auch nicht missen
WBCE Version: 1.5.4
Tag: 1.5.4
PHP Version: 8.0.22
Offline
Ich benutze ihn auch öfter...
Offline
Anbei eine Bugfix Version 3.0.1 für AFE (WBCE).
Diese Version stellt die Funktion der Downloads von Addons (z.B. für Backup) unter PHP7 wieder her. AFE 3.0.1 läuft aber auch noch ganz normal mit PHP5. Danke an Florian für den Bugreport auf GitHub.
P.S.: Mist, sieht so aus als könnte ich AFE noch nicht in Rente schicken
Account inactive since 2018/11/17.
Offline
Danke. Ich habe den Eintrag im AOR aktualisiert.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Hi,
du nutzt mit toggle() eine veraltete jQuery Funktion:
deprecated: 1.8, removed: 1.9
Quelle: https://api.jquery.com/toggle-event/
Dein pöhser Code:
[== JavaScript ==]
$('#trigger_modules, #trigger_templates, #trigger_languages')
.toggle(
function() {
var id = $(this).attr('id').replace(/trigger_/, '');
document.cookie = 'AFE_' + id + '=1';
setViewMode(id);
},
function() {
var id = $(this).attr('id').replace(/trigger_/, '');
document.cookie = 'AFE_' + id + '=0';
setViewMode(id);
}
);
Ich werde gucken ob ich gleich einen Fix schreiben kann und mach dir dann bei GitHub ein Pull Request. Dann würde wohl dein Modul auch sauber mit Fraggy funzen...
UPDATE: Hab einen Pull Request mit diesem Fix erstellt: https://github.com/cwsoft/wbce-addon-file-editor/pull/4
Hier noch der Code:
[== JavaScript ==]
$('#trigger_modules, #trigger_templates, #trigger_languages').click(function() {
var $this = $(this);
if($this.hasClass('clicked')) {
var id = $this.attr('id').replace(/trigger_/, '');
document.cookie = 'AFE_' + id + '=0';
setViewMode(id);
$this.removeClass('clicked');
} else {
var id = $this.attr('id').replace(/trigger_/, '');
document.cookie = 'AFE_' + id + '=1';
setViewMode(id);
$this.addClass('clicked');
}
});
Last edited by rjgamer (22.06.2016 12:47:18)
Offline
@rjgamer: Danke für das Update. Werde es am WE einpflegen und ne neue Version veröffentlichen.
Gruss cwsoft
Account inactive since 2018/11/17.
Offline
Hi,
kein Ding. Scheint aber weiterhin noch ein Problem zu geben: http://forum.wbce.org/viewtopic.php?pid=5343#p5343
Ich guck es mir morgen an und werde den Pull Request vielleicht nochmals aktualisieren.
Gruss
Offline
@rjgamer: Danke für das Update. Werde es am WE einpflegen und ne neue Version veröffentlichen.
So jetzt habe ich es sogar noch vor dem Wochende geschafft
AFE 3.1.0 steht zum Download bereit. Vielen Dank an rjgamer für den Fix für die veraltete jQuery toggle Funktion.
P.S.: Die Anforderungen an Addons um in AFE gelistet zu werden (Addon in WBCE Datenbank gelistet, Addon hat eine index.php und evtl. info.php im Wurzelverzeichniss des Addons) entsprechen noch immer den alten WB 2.7 Addon-Guidelines. Wenn gewünscht können diese Anforderungen (index.php, info.php Prüfung) in einer zukünftigen Version von AFE auch entfallen.
Account inactive since 2018/11/17.
Offline