Hilfe, mein WYSIWYG-Editor ist plötzlich weg!!!

  • Ich hoffe sehr, dass mir jemand einen Ratschlag geben kann, denn ich kann keine Artikel mehr bei mir einpflegen, denn ohne Editor kann ich einpacken!!
    Der WYSIWYG-Editor steht auf true und ich habe dort auch keine Einstellungen verändert. Gestern war ich "nur" bei anderen Einstellungen zugange, denn ich habe die Spider-Sessions vermeiden Option auf true gestellt. Sonst habe ich nichts verändert und seit heute ist halt mein Editor weg!!!!
    Wie bekomme ich ihn wieder????
    Bitte helft mir!!! Leider sind hier die Antworten immer sehr spärlich bis gar keine und ich hoffe, dass hier irgendjemand meine Anfrage liest, denn ich komme sonst mit meinem Shop nicht weiter.

  • Nun kommt noch hinzu, dass sich der Admin-Bereich verändert hat! Plötzlich ist das Layout der Kategorieübersicht verändert und auch die Startseite des Adminbereichs! Ist evtl. zufällig ein automatisches Update vorgenommen worden???
    Ich bin am verzweifeln!

  • Sehr seltsam, ich nehme an du hast schon versucht die Option wieder auf false zu stellen?

    MfG

  • Habe ich gemacht und wieder neu. Jetzt meldet auch noch mein Virenprogramm irgendetwas und verweigert die Zugriffe! Kann ich ein Virus auf meiner Seite haben????????

  • Die Statistik ist jetzt auch weg!! Fehler: Parse error: syntax error, unexpected '<' in /home/www/web172/html/casally/admin/includes/slimstat/index.php on line 219

    Einmal editiert, zuletzt von similar (18. Oktober 2010 um 01:44)

  • Das tritt alles ohne Änderungen deinerseits auf? Schau dir mal den Code der Datei dort an. Dort ist entweder ein "<" zuviel oder nicht richtig ausgeklammert.

    MfG

    Ps.: Antivir und Browser melden keinen Schadcode.

  • Komisch, ich habe jetzt einen anderen Rechner verwendet und da meldet sich auch Antivir, wenn ich meine Seite aufrufe.
    Nein, ich habe nichts aber auch rein gar nichts verändert!! Kann es sein, dass mein Adminbereich gehackt wurde???

  • Kommt darauf an wie sicher dein Passwort ist und wie du damit umgehst. Wenn sich plötzlich Dateien von "selber" ändern ist es allerdings wahrscheinlicher das jemand einen FTP Zugang hat. Ich kenn mich damit auch nicht sonderlich aus. Aber Passwörter ändern schadet bestimmt nicht.

    MfG

    Ps.: Wie sieht denn die Virenmeldung aus?

    Einmal editiert, zuletzt von Praktikant (17. Oktober 2010 um 19:20)

  • Hm, das könnte sein. Habe gestern Einstellungen meines Providers verändert bekommen für andere Seiten. Evtl. liegt es daran? Vielleicht wurden auch für diese Seite irgendwelche Einstellungen verändert.
    Bezüglich der Meldung muss ich mal eben gucken, da sie ja gleich geblockt wurde.

  • Kann dieses Problem evtl. auch an der GZIP-Kompression liegen? Ich hatte gestern, als der Shop noch lief, die G-Zip Kompression auf true geschaltet. Vorhin wollte ich diese Einstellung auf false setzen, um auszuprobieren, ob mein Admin-Bereich dann wieder funktioniert...
    Danach hat sich der Admin-Bereich nicht mehr geladen und es wurde eine weiße Seite angezeigt... Kam also nicht mehr in den Shop rein. Die Datei: login.php?action=process lädt sich dann, aber nicht start.php.
    Das ist doch alles nicht mehr normal, oder ???

    Ich glaube, das ist die Lösung! Wenn also die Seiten gezippt werden, dann auch der Admin-Bereich und dadurch kommt dieser dann durcheinander.
    Leider kann ich das Gezippe nicht wieder abstellen, weil ich dann nicht mehr in den Admin-Bereich komme.
    Hat jemand eine Idee???

    2 Mal editiert, zuletzt von similar (18. Oktober 2010 um 03:16)

  • ich, an deiner stelle, würde wie folgt vorgehen:

    server abschalten.
    backup ziehen.
    jemanden hinzuziehen, der sich mit serversicherheit auskennt.


    jeden tag werden mehr server gehackt, als man sich vorstellen kann.

    php ist sehr sicherheitskritisch - ergo ist mindestens eine sehr restriktive php-konfig unabdingbar, da mit sicherheit in jedem php-script sicherheitsrelevante fehler enthalten sind. die frage ist nur, WANN diese ausgenutzt werden.

    darüber hinaus sind folgende anwendungen/szenarieren im prinzip auch nicht mehr tragbar - gleich gar nicht, wenn man mit kundendaten hantiert:
    - fehlender apache-ssl
    - ftp
    - schwache passwörter

  • Und was hast du noch alles geändert? Spider-Session und GZIP Komprimmierung hab ich ausprobiert, funktioniert bei mir alles ohne Probleme.

    MfG

  • Hm, backup ziehen? Dann habe ich ja die fehlerhaften Dateien gespeichert. Habe noch ein Backup, was aber bereits 2 Wochen alt ist :) Hm, paulchen, Du machst mir keine grosse Hoffnung.
    @Praktikant: Mehr habe ich wirklich nicht verändert gehabt. Lediglich war mein Provider bei mir zugange, aber an anderen Domains. Habe ihn aber noch nicht erreichen können. Der ist meine letzte Hoffnung.

  • OMG - paulchens Bullsh.. kommentiere ich gleich noch *kopfschüttel*

    Mal zum Prob, also erstens ist das überhaupt ein richtiger Server (DE-Server, V-Server, ROOT-Server o.ä.) und bei welchem Provider steht dieser denn?
    Wenn es also ein "richtiger" Server (meine keinen Webspace oder so nen Quark) ist und du schon ein Backup hast (ein Backup zum jetzigen Zeitpunkt wäre schlichtweg nutzlos), dann gehe doch einfach ins Provider-Backend, mache entweder ein Restore von einem Zeitpunkt davor oder schieb einfach nen Neu-Install drüber, fertig.
    Entscheide einfach selber, was für dich schneller geht, weiter Fehlersuchen oder Server-neu aufsetzten!

    Einmal editiert, zuletzt von exception (18. Oktober 2010 um 19:35)

  • In Foren sind nun mal oft Laien unterwegs auf der Suche nach Hilfe und bekommen dann solchen bullsh... präsentiert und nehmen es wahrscheinlich noch für "bare Münze". Dabei gilt, wenn man keine Ahnung hat...

    ich, an deiner stelle, würde wie folgt vorgehen:

    server abschalten.
    backup ziehen.

    Du würdest so vorgehen? Wie lange möchtest du denn auf ein Backup warten, wenn der Server down is?


    php ist sehr sicherheitskritisch - ergo ist mindestens eine sehr restriktive php-konfig unabdingbar, da mit sicherheit in jedem php-script sicherheitsrelevante fehler enthalten sind. die frage ist nur, WANN diese ausgenutzt werden.

    Der "Größte" Mythos den es gibt. PHP ist NICHT sicherheitskritischer als andere Programmiersprachen (JAVA, Perl, C etc.)! Die Progger bzw. User sind das Risiko :)
    Was soll denn eine "sehr restriktive php-config" sein? Weißt du überhaupt, wovon du sprichst? Von solch unqualifizierten Aussagen...ach nee, no comment!

    "in jedem php-script sicherheitsrelevante fehler"
    Ein Beispiel:

    <?php echo 'Hello world!';?> //da ist kein Fehler drin und wird auch NIE einer sein! loool


    darüber hinaus sind folgende anwendungen/szenarieren im prinzip auch nicht mehr tragbar - gleich gar nicht, wenn man mit kundendaten hantiert:
    - fehlender apache-ssl
    - ftp
    - schwache passwörter

    1. SSL hat grundsätzlich nix mit Apache zu tun. SSL (Secure Sockets Layer) ist ein Verschlüsselungsprotokoll und die Module gibt es für viele Server, egal ob Apache, Tomcat, IIS, nginx usw.
    2. Gibt's die Apache (standard) install überhaupt noch ohne mod_ssl? Schon vor 6 Jahren war diese standardmäßig dabei.
    3. Was bitte hat FTP damit zu tun? Wie überträgst du denn Files zum Server? --per $_POST...haha - insider
    4. schwache Passwörter - da stimme ich dir zu!


    So nun hat der exception-handler wieder zugeschlagen :D

  • exception:

    zuallererst würde ich um einen gepflegten umgangston bitten ;)

    mit "server" meinte ich seinen http-server, welcher auch immer da läuft, vermutlich der apache.
    noch besser wäre in der tat ein server-halt und dann per remote-konsole, falls vorhanden, auf den rechner zugreifen. es könnte durchaus sein, dass der server komplett kompromittiert wurde. dann ist recherche am laufenden system fix für die katz.

    das backup zieht man aus forensischen gründen (fehleranalyse offline). ansonsten läuft man gefahr, dass das gleiche wieder passiert.


    es ist in dem fall irrelevant, ob php genau so kritisch ist wie andere sprachen, da auf seinem server definitiv php läuft.


    mit restriktive php-config meine ich wenigstens ein eingehendes befassen mit der php.ini
    stichworte wären hier z.b. allow_url_fopen, allow_url_include, disable_functions, open_basedir, register_globals, safe_mode etc.

    ob programmierer, anwender oder sonstwer der grund für dieses risiko sind, interessiert den threadstarter in diesem moment vielleicht eher weniger.


    ssl THEMENBEZOGEN, was sonst? d.h. aktiviertes apache-ssl-modul. in diesem fall hat der apache sehr wohl etwas mit ssl zu tun. ebenso muss bei der shopeinrichtigung ssl berücksichtigt werden. wenn nicht, loggt sich auch der admin unverschlüsselt ein.


    ftp ist ein unsicheres und unverschlüsseltes protokoll, d.h. zugriffskennungen werden unverschlüsselt übertragen. die momentan beste "alternative" wäre ssh bzw. sftp (am besten noch mit auth-key).

    ja. ich ging davon aus, dass er einen root-server unterhält.


    nach deiner methode (wiederherstellen eines backups), würdest du genau den fehlerhaften zustand wie VOR dem hack herstellen, welcher zu den entsprechenden ereignissen führte - ohne zu wissen WO der betreffende fehler liegt.

    aus diesem grund halte ich deine tipps für streng fahrlässig.


    ich möchte mich hier nicht profilieren, sondern einzig dem threadstarter helfen.


    ist (hoffentlich) kein root-server vorhanden, gilt oben geschriebenes natürlich nicht. dann bleibt nur backup und neuaufsetzen des shops mit neuen zugangsdaten.