die meisten WP-Hacks laufen zZt darauf hinaus, in Artikeln Spamlinks zu hinterlegen. Dazu muss ein bestehender Artikel in der Datenbank aufgerufen, editiert und die Änderungen in den Datensatz zurückgeschrieben werden. Nun mal eine ganz doofe Frage: Gibt es eine Möglichkeit, den Editiervorgang bzw. genauergesagt den Speicherungsvorgang so zu kontrollieren, dass der Admin einen Code („PIN“) eingeben muss, bevor in die DB geschrieben wird? An welcher Stelle der Code-Aufruf zu platzieren wäre? Je nachdem, was sicherer ist: In einem Plugin oder im WP-Core. Ich gehe davon aus, dass der Hacker die Corefiles nicht einfach so umgehen kann. Daher dort.
Ungefähr verstanden? Ist sowas schon mal eine Hürde mehr? (solange der Hacker nicht direkt die DB angreift, wird er die Artikel nicht mehr Spamlinks vollstopfen können).
Der Pin-Code müsste wohl in der Klasse wpdb hinterlegt werden, die für alle Interaktionen mit der Datenbank verantwortlich ist. Davor macht keinen Sinn, da umgehbar, Plugin fällt also flach.
In den Core-Files sollte man aber ehrlich gesagt nicht rumpfuschen. Eine solche Änderung bzw. Erweiterung wäre immens, und man weiss nie, wie sich das auf Plugins etc. auswirkt. Mal davon abgesehen, dass man die nach einem Update von WordPress jedes Mal aufs neue vornehmen müsste.
Besser wäre es wohl, zu schauen, woher die Themes bzw. Plugins mit schadhaftem Code eigentlich kommen und dann davor zu warnen.
Gehen tut wohl alles – nur reicht es nicht schon, dass wir hier die Deppenfragen („was ist 2 plus 7“) beim kommentieren beantworten müssen? Muss ja beim Schreiben eines Kommentars nicht auch noch sein. 😀
@Jeriko:
Das Problem ist doch, dass die Leute sich irgendwann ein Template von irgendwoher gezogen haben.
Dann aber NUR ihre WP updaten – nicht ihr Template.
D.h. werden Änderungen im Standard-Template aus Sicherheitsgründen vorgenommen, ziehen die Blogger nicht mit, weil sie gar nicht wissen, was sie in ihrem Template anpassen müssen.
So kommt es doch zu den Sicherheitslöchern.
Moment, was ist nochmal eins + zwei?
Theoretisch wäre es möglich, da alle WP-Datenbankabfragen über eine Klasse gehen.
Aber:
* Schutz müsste auch beim Schreiben von Dateien eingeschaltet werden, da diese manipulierten Themes die Spamlinks theoretisch auch direkt in das Template schreiben könnten. Die WP aber die nativen PHP Funktionen nutzt, wird das nicht wirklich möglich sein. Und selbst wenn in WP nur mehr eine eigene Funktion genutzt wird
* könnte ein „Virus“ trotzdem die nativen PHP Funktionen nutzen, sowohl beim Schreiben ins Dateisystem als auch beim Schreiben in die Datenbank.
* Die PIN Eingabe müsste bei jedem Schreiben in die Datenbank bzw. das Dateisystem gemacht werden, also auch beim Cachen, Countern, Kommentare, Statistiken, Track- & Pingbacks, etc…
Also praktisch ist ein derartiger Schutz einfach nicht möglich. Es ist so wie bei Viren, Trojanern, etc allgemein. Das Wissen des Benutzers ist der beste Schutz…
Edit: Natürlich könnte entsprechend eingestellt werden das nur Tabellenspalten „überwacht“ werden die HTML-Code enthalten. Allerdings nützt das auch nichts gegen meinen Aber-Punkt-2, ein Plugin oder Theme kann jederzeit auch die nativen PHP Funktionen nutzen um in die Datenbank oder das Dateisystem zu schreiben. Die entsprechenden Zugangsdaten (zur Datenbank) liegen im PHP-Script vor. Selbst wenn man nach dem initialisieren der Datenbankverbindung von wpdb die entsprechenden Variablen (eig. Konstanten) löscht, das Theme oder Plugin kann auch auf die wp-config.php zugreifen um die Daten zu lesen.
Weil Katz- und Mausspiele zwischen Sicherheitsinformatikern und Hackern lustig sind, könnte man dann natürlich die Zugangsdaten verschlüsseln (und die entschlüsselung in der wpdb vornehmen, danach die variablen mit den entschlüsselten werten löschen), wie man dann allerdings den Schlüssel schützt weiß ich nicht genau. ging wahrscheinlich auch irgendwie.
um das manipulieren der templates zu verbieten könnte man die schreibrechte wegnehmen, (dann könnten die templates allerdings auch nicht mehr im wp internen template editor bearbeitet werden).
allerdings könnten dann wiederum hacker zB die cache files direkt editieren (auf die muss schreibzugriff sein).
wahrscheinlich würde mir noch mehr einfallen wenn ich noch weiter darüber nachdenken würde, aber ich glaube es recht.
ich schließe mich Jeriko an und mag erweitern:
updates on the fly… jeder freut sich ..kaum wer kapiert, dass er alles aufmacht , was man vorher als Sicherheitsrisiko zugelassen hat.
phpmyadmin Zugang via Admininterface nutzen auch etliche,
dann noch Plugins, die von der Webseite der Schwester ihrer Cousine dem dessen Freund und dort via was weiß ich zum Download angeboten wurden ..
Passwörter, die das Wort *Passwort* nicht verdienen.
meist auch noch Freehoster, die oftmals Sicherheitsvorkehrungen haben, die ein wenig in die Jahre kamen…
usw.
und Templates – da redet man sich den Mund fuseligst, wenn man warnt.
(dasohneTaschenrechnerisschongemein) meint meinSchalk ….
Ich würde mal tippen, dass bei den meisten Hacks nichts per Hand gemacht, sondern direkt auf die Datenbank zugriffen wird. Geht schneller und hinterlässt weniger Spuren. Warum sollte ich mich durch das Dashboard quälen, wenn ich alles automatisiert über eine manipulierte PHP-Datei machen kann?
@kommandozeilen-junkie: ja, genau das meinte robert. er fragte ob es möglich sei einen entsprechenden schutz direkt in den, ich sag mal, schreibenden funktionen zu implementieren.
Der Schutz müsste schon beim DBMS anfangen. Da gibt MySQL eben nicht viel her. Klar könnte man DB2 oder Oracle verwenden (von den Sicherheitslücken dieser Systeme mal abgesehen).
Doch welcher Provider bietet solche DBMS schon an?
Und wenn ja, dann kostet das was. Die Dinger bekommt man nicht kostenlos.
hm, sechs plus neun…
Nein, selbst wenn man WordPress absichert kann ein Plugin (oder jede beliebige andere Datei die über den Webserver ausführbar ist) immer noch mit den stinknormalen mysql-Funktionen arbeiten. Was hilft ist die Plugins nicht in PHP sondern in einer anderen Sprache (eine domain specific language, sehr lehrreich übrigens) schreiben zu lassen. So wie es facebook hat. Aber Lücken bestehen weiterhin, man hat halt nur ein wenig mehr Sicherheit gewonnen.
schutz auf dbms ebene bzw. eine modifizierte version von php die den „pin-check“ direkt in den mysql_query() aufrufen sind natürlich eine möglichkeit. aber wir wollen hier ja realistisch bleiben. wer solche methoden einsetzt bzw. einsetzen könnte würde kein verseuchtes theme benützen.
@9/Thomas: Wie soll die Verwendung einer DSL ein Sicherheitsproblem lösen bzw. entschärfen?
sechs plus sieben, sechs plus sieben, ….
Manueller trackback: http://ananasblau.com/2008/4/8/enge-grenzen-fuer-erweiterungen
wie wäre es, wenn wordpress einfach mal aufhört features rauszuhauen und an der sicherheit des system arbeitet? wordpress 2.5 ist doch vor allem eyecandy im admin. sorry, brauch ich nicht.
andere projecte wie z.b. drupal haben dedizierte security teams, die sich nur um solche aspekte wie sql injects kümmern.
klar ist wp einfach mal so massiv oft instaliert, dass sich hacker dadran festbeissen, weil ein exploit die tür zu millionen von installs öffnet.
man muss sich halt auch fragen ob es immer wordpress sein muss…
@Thomas: Du musst die Kommentare in deinem Blog schon durchlassen – sonst wird das nix mit dem Dialog. 🙂
@C.J.: Zu scharf eingestellt.
nunja, ist halt wie mit phpbb damals.. millionenfach installiert und wohl zu 50-75% im originalzustand belassen. dabei ist wp ein großer schritt nach vorn mit regelmäßigen und einfach zu installierenden updates, updatebenachrichtung usw. – nur der betreiber (sofern er noch lebt) muss die dinger halt auch mal installieren. von der aktualisierung von templates mal ganz zu schweigen, da warnt niemand und es ist sich kaum jemand bewusst, dass auch das wichtig ist. voilá…
@C.J.: MySQL dürfte eigentlich genug hergeben. Hier kann man bis hinunter auf Spalten-Ebene – oder wie auch immer Du das nenne möchtest – Benutzern entsprechende Rechte zuordnen. Legt man also einen Datenbank-Benutzer an, der die Posts nur lesen kann und einen Datenbank-Benutzer, der die Posts nur schreiben kann, dann kann man das schon einmal sauber trennen.
Wenn man für WordPress jetzt hingeht und alles was mit Posts zu tun hat über den Datenbank-Benutzer mit Schreibrechten laufen lässt, dass Kennwort nirgendswo speichert, sondern dieses bei jeder Änderung mitangegeben werden muss, dann hätte man die PIN, die Robert sucht. Das dürfte selbst bei so einem WordPress-PHP-Murks mit endlichen Aufwand möglich sein. Wobei bei einem kompromitierten Blog es kein Problem sein dürfte, diese PIN abzuhören. Womit man wieder am Anfang wäre. Ist einmal der Wurm drin, hilft halt irgendwie nichts.