@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.

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.: Zu scharf eingestellt.

@Thomas: Du musst die Kommentare in deinem Blog schon durchlassen – sonst wird das nix mit dem Dialog. :-)

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…

Manueller trackback: http://ananasblau.com/2008/4/8.....eiterungen

@9/Thomas: Wie soll die Verwendung einer DSL ein Sicherheitsproblem lösen bzw. entschärfen?

sechs plus sieben, sechs plus sieben, ….

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.

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.

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…

@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.

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?

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 ….

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.