Beiträge von Melewo

    Kann mich daran erinnern, als meine Seite damals gehackt wurde, dass da gerade die Kurden statt einfache HTML-Seiten Images mit einem Logo von der PKK oder so etwas in der Richtung im Internet verteilt haben sollen. Ist lange her, doch wenn ich jetzt danach suche, so finde ich kaum noch etwas davon.

    Bei mir auf der Seite war auch nur ein kurzer Spruch und irgendwie hing das wohl mit einem Wettbewerb zusammen, wer in einer vorgegebenen Zeit wie viel Seiten hackt oder so. Also ohne böse Hintergedanken oder Verbreitung von Malware, einfach nur ein Wettbewerb, ohne die Seiten wirklich zu schädigen.

    Und einige Hacker fingen ja mal anders an, wie zum Beispiel:

    Zitat

    Auf dem regelmäßig am Dienstagabend stattfindenden Hacker-Treff in den hannoverschen Restaurants Spektakel und Sesam...


    http://de.wikipedia.org/wiki/KGB-Hack

    Und bei solchen Treffen möchte man ja auch etwas zu berichten haben, oder?

    Man kann ein Inline-Image auch in der CSS-Datei verwenden und darüber dann die Sprites definieren.


    Das hört sich zumindest erst einmal interessant an und ist somit doch einer Überlegung wert.

    Wegen der anderen Geschichte, habe noch einmal geschaut, für FF gibt es dieses Add-on ebenfalls. Im Chrome hängt es bei mir bisher unbenutzt im Browser als Button herum, weil mich dieser Satz abschreckte:

    Zitat

    Sign up for a 30-minute unrestricted, free trial BrowserStack account or sign in using an existing account to test websites.

    https://addons.mozilla.org/en-US/firefox/addon/test-ie/

    Warum soll ich mir für läppische 30 Minuten irgendwo registrieren?
    @ Blau - Womit hast Du nun den IE 7 simuliert?

    Mir ging es nicht so sehr wegen dem Design, sondern mehr darum JavaScript abwärtskompatibel zu halten, als ich mir mal dieses Add-on installierte und dann erst einmal wieder Abstand davon nahm, mich für 30 Minuten irgendwo zu registrieren, was ja lächerlich wenig Zeit zum Testen wäre.

    Alle reservierten Zeichen sind in einer URL erlaubt, keine Frage, sonst brauchten die ja nicht reserviert zu sein. Nur wie sehen die WP-Rerwites dafür aus? Ich meine, die habe ich mir mal angesehen und nur angesehen, aber nicht im Kopf. Wenn WP dafür bei den Regulären Ausdrücken keinen Ausdruck definiert hat, dann kann auch preg_match nichts finden und es wird lediglich eine Fehlerseite ausgegeben.

    Also solltest Du im ersten Schritt die vorhandenen überprüfen, ob eine Seite mit einem Komma im Dateinamen überhaupt von WP geladen werden kann und gegebenenfalls eine entsprechende Regel hinzufügen.

    http://codex.wordpress.org/Class_Reference/WP_Rewrite

    Erst danach kannst Du Dir dann die Frage stellen, wie alles weitere zu verändern ist, damit ein Komma im Dateinamen enthalten bleibt. Ob es damit dann aber bereits getan ist, daran habe ich auch noch einige Zweifel. Denn die Slugs müssen ja auch von WP verwaltet werden.

    Weiterhin steht die Frage, warum wirft die WP heraus?
    Gab es diesbezügliche Sicherheitslücken und Angriffe?
    Auch diese Fragen sind zu klären.

    Habe eben IE7 simuliert.


    Womit, wenn ich ernsthaft fragen darf?

    Der vom IE 11 funktioniert nicht mehr richtig, der vom Expression Web 4 hat mich auch im Stich gelassen, von MS wurde nur auf ein Tool für den Chrome von browserstack.com verwiesen, da werden zwar nun von IE 6 bis IE 11 alle Versionen angezeigt, doch wenn ich eine Seite testen möchte, so sollte ich mich da irgendwie mit einer Mail-Adresse registrieren, was mich bisher zurückhielt.

    Zitat

    Weitere Zeichen haben spezifische Bedeutungen im Dokumentenpfad. Insgesamt gelten folgende Zeichen als reserviert:

    Code
    ! # $ % & ' ( ) * + , / : ; = ? @ [ ]


    http://de.wikipedia.org/wiki/URL-Encoding

    Der Name einer Datei, der als Slug in einer URL verwendet wird, sollte somit nur aus Buchstaben, Ziffern, Unterstrich und Bindestrich bestehen. Unter Umständen noch aus einem Punkt und einer Tilde, wobei sich daraus aber schon ein Streitthema ergab (finde ich gerade nicht wieder). Weitere Zeichen, Sonderlaute usw. können gegebenenfalls, falls unbedingt erforderlich, url-kodiert übergeben werden.

    Wenn Du WordPress nicht zum Absturz bringen möchtest, würde ich bis zu dem Zeitpunkt, an dem Du ahnst was Du machst (bisher ahnst Du scheinbar noch nichts davon und von wissen, was Du machst, kann keine Rede sein), auf weitere Manipulationen verzichten.

    Gesucht und noch gefunden:

    http://forum.wpde.org/allgemeines/12…ht-nicht-2.html

    So, eigentlich sind nur diese Zeichen in Dateinamen nicht erlaubt,

    Code
    < > ? " : | \ / *

    doch diese haben eine gewisse Bedeutung:

    Code
    ! # $ % & ' ( ) * + , / : ; = ? @ [ ]

    Als Nachteil habe ich bisher noch gefunden, dass IE 7 noch keine Inline-Images unterstützen soll, erst ab IE 8. Bei kleinen Grafiken, wie für Buttons und so ein Zeug, die nur viele Requests erzeugen, fand ich eine Diskussion, ob Inline-Images als Alternative für CSS-Sprites in Frage kommen.

    Ich halte das alles für unsicher, wenn Du vom Hoster kein Backup einspielen kannst, welches noch sauber war. So weißt Du nicht, ob irgendwo noch Schadcode versteckt ist, den Du nur noch nicht gefunden hast. Somit müsstest Du vor einem Update alle Dateien löschen und in einem leeren Webspace beginnen.

    Was auch nur dann Erfolg hätte, wenn die Datenbank nicht kompromittiert ist.

    Könnte sein, möchte mich da nicht festlegen. Doch wenn über FTP, dann hast Du vermutlich Malware auf Deinem Rechner, die jedes neue Passwort gleich wieder ausliest, wenn es unverschlüsselt ist.

    Hatte vor vielen Jahren mal etwas ähnliches mit einer index.html, war ein Forum, nicht WP, aber egal, die Schwachstelle war ein Formular.

    [COLOR=#000000]Leider hatte ich bis heute noch nicht auf [/COLOR][COLOR=#000000]WordPress 3.8.1[/COLOR]


    Und mit der Aktualisierung von Plugins hinkst Du auch hinterher?

    Dann haben Hacker es zumindest leichter bereits bekannte Sicherheitslücken zu nutzen.
    Wenn Du Glück hast, handelt es sich nur um einen sportlich fairen Wettkampf, bei dem es nur darum geht innerhalb einer bestimmten Zeit möglichst viele Websites zu hacken und einfach nur zusätzlich eine index.html im Hauptverzeichnis abgelegt wird.

    Informiere den Hoster, spiele ein Backup ein, suche die Sicherheitslücke und schließe diese, bereinige den Rechner von Malware und irgendwo gab es noch eine richtige Anleitung für derartige Fälle mit weiteren Punkten.

    Wenn Du die Sicherheitslücke nicht allein finden solltest, bleibt Dir ohnehin nichts weiter übrig, als die Jobbörse zu nutzen, da es sonst täglich wieder passieren könnte.

    Bis jetzt sind alle Sachen noch da, vielleicht sollte ich das Sichern, und danach auf die Suche gehen ?


    Nein, damit würdest Du vorhandenen Schadcode mitsichern. Nur eine noch saubere Sicherung verwenden.

    Dann hatte ich mich auf die Suche begeben den englischen Content auf einen deutschen String im Form Value zu ändern,


    Wie geschätzte 98 Prozent aller Einsteiger, weil es irgendwie nicht einleuchtend ist, zuerst in den *.po / *.mo Sprachdateien vom Plugin oder vom Theme zu suchen. Und da beide Dateien geändert werden müssen, geht es nur mit einem Editor, wie dem Poedit oder einem Plugin.

    Ich kann aber kein .php im Theme finden, in welchem das Form generiert wird.

    Dann existiert dafür eine Rewrite-Regel oder etwas in der Art.

    Wenn Du nach einem typischen Text in der *.po suchst, sollte eigentlich die Datei und Zeile dabei stehen, wo der Text benötigt wird und so lässt sich eventuell der Weg verfolgen.

    dachte nur das Child-Theme sei so wichtig, weil auf so vielen Seiten dazu geraten wird


    Ein Child-Theme ist ja auch wichtig, wenn Du nur einige Veränderungen vornehmen möchtest, ohne gleich eine Entwicklungsumgebung einzurichten. Auch für Theme-Entwickler könnte ich mir Vorteile vorstellen, wenn die von einer Version weitere Versionen ableiten möchten, um nicht bei jedem Entwurf von vorn zu beginnen. Und nicht zuletzt auch halt bei Updates, da die Child-Themes wohl nicht mit überschrieben werden. Die Zusammenfassung ist denke ich ganz gut:

    http://bueltge.de/wordpress-child-themes-verstehen/1192/

    Habe noch kein Child-Theme gehabt. Irgendwann wollte ich es zwar auch mal probieren, bisher sah ich aber noch keine Notwendigkeit. Teste alles unter Localhost im Xampp und lade dann erst die fertigen Dateien hoch, wenn alles fehlerfrei läuft.

    Was weg ist, das ist weg und kann ärgerlich sein. Hatte mal ein Plugin mit einem Namen angelegt, den es bei WordPress bereits gab. Da wollte WP aktualisieren und ich bestätigte, anschließend waren meine eigenen Dateien komplett gelöscht und ein fremdes Plugin lag in dem Verzeichnis. Hätte ich nicht den größten Teil bereits auf einer externen Festplatte gespeichert, dann hätte ich mich grün und blau geärgert, so waren nur die letzten Bearbeitungsschritte verloren. Seither wird nur noch das aktualisiert, was ich selbst aktualisiere.

    Also neue Version herunterladen und per FTP nur die Core-Dateien und Verzeichnisse überschreiben bei einem Update, nicht aber das Theme-Verzeichnis. Plugins sicherlich auch regelmäßig updaten, ist wichtig. Fällt bei mir nur flach, weil ich nur eigene benutze.

    Du brauchst doch bei einem Update der WP-Version nicht Dein Theme überschreiben. Wichtig ist, dass Du mit den WP-Versionen auf dem Laufenden bleibst, mit den verwendeten Themes sicherlich auch, doch die sind eigentlich unabhängig davon. Bei den Standard-Themes und automatischen Updates ist das wohl so eine Sache, deshalb mache ich nur manuelle und sichere alles in Abständen.

    Wenn Du ein eigenes Theme entwickeln würdest, könnte WP das ja auch nicht einfach bei einem Update überschreiben. Bei meinen Plugins steht auch immer da, dass alle aktuell wären, weil die WP nicht kennt, nehme ich mal an. Und mein Standard-Theme hat sich mit der Zeit so verändert, das da einige Dateien weit vom Original entfernt sind. Wichtig ist nur keine veralteten Funktionen zu benutzen und sich insoweit mit PHP und JS auszukennen, dass man keine Sicherheitslücken einbaut.

    Und nach allem was ich hier so sehe, wissen viele gar nicht, was sie eigentlich tun, wenn sie irgendeinen Codeschnipsel finden, worin dann wirklich eine Gefahr besteht.