Achtung: Dieses Blog ist umgezogen auf die Adresse blog.xwolf.de
Bitte ändern Sie Ihre Bookmarks entsprechend.

Samstag, 9. Juli 2005
phpBB nervt Provider
Webworking
Laut einem Bericht von Netcraft gehen viele Provider dazu über, phpBB von Ihren Domains zu verbannen, bzw. dessen Nutzung zu verhindern.

Vgl:
Hosts Ban phpBB As Security Issues Persist

(Über sunflyer)

Hintergrund sind die häufigen Sicherheitsprobleme und das offenbar mangelnde Sicherheitsbewsstsein der Entwickler.

Seit Januar gab es bereits 5 kritische Vorfälle, die jedesmal zu Zwangsupdates führten, aber auch jedesmal nur die spezifische Sicherheitslüche behoben, nicht aber auf gleichartige Lücken an anderen Programmteilen eingingen.

Würde ich die phpBB-Software selbst einsetzen und pflegen müssen, wäre ich auch schon recht gereizt
und hätte sie längst über den Jordan geworfen.
Schließlich gibt es wirklich bessere Boardsystem, die dann sogar ein Forumssichtweise haben.
Beispielsweise cForum.

Aber auf der anderen Seite wundert es mich schon etwas, daß die Provider sich darüber aufregen und es bannen wollen, wenn ihre Kunden phpBB einsetzen.
Denn das bedeutet doch nur, daß die Sicherheitslöcher von phpBB auf andere Kundeninstallationen Einfluß nehmen können.
Und dies wiederum verweist auf ein mangelhaftes Sicherheitskonzept seitens der Provider.

Eine geeignete Umgebung für eine Kundendomain bei einem Provider muss so aussehen, daß alle Skripten und Tools, die von der Kundendomain ausgeführt wreden auch nur unter dessen Account laufen. Aber auf keinen Fall zum Beispiel unter der Kennung des Webservers.

Das dies wiederum bedeutet, daß PHP-Skripten nun nicht als Apache-Modul, sondern als CGI ausgeführt werden müssen, ist eigentlich naheliegend.

Aber das wird wohl dann auf das Kernproblem zurückführen: PHP als CGI ausgeführt macht -genügend schlechte Programmierstile vorausgesetzt- die Skripten langsam.
Der unbedarfte Kunde (und natürlich der PHP-Programmierer, der ja meist nur zu Hause auf seiner eigenen Kiste arbeitet) sieht die Ursache der Langsamkeit dann beim Provider, aber nicht am Skript.
Er würde also möglicherweise einen anderen Provider wählen.

Kurz gesagt: Höhere Sicherheit beim Provider bedeutet weniger Kunden und Mehraufwand (in Support).


Was wird also die Folge sein?
Ich vermute, ähnlich wie beim FormMail.cgi wird bei vielen Provider schlichtweg ein Eintrag wie folgender sein:
   <Location /cgi-bin/FormMail*>
      Deny from all
   </Location>
   <Location view(.*).php>
      Deny from all
   </Location>
   <Location posting.php>
      Deny from all
   </Location>
Das dies eine naive, nur scheinbare Lösung ist, solltem jedem klar sein.
Aber es ist ein Dummy-Schranke, mit der ein Provider sicher 90% aller Kunden daran hindert, phpBB zu nutzen :)
Und die 10% oder weniger, die etwas mehr Ahnung haben, kennen auch die Sicherheitsprobleme - die werden bei so einem Provider eh nicht sein...(?)


Aber das Problem wird nicht wirklich gelöst, so lange die Provider nicht durchgängig das Hosting so bauen, das Skripten nur vor der Benutzerkennung ausgeführt werden. Egal ob dies Performanceeinbußen bedeutet oder nicht.


To prevent spam abuse referrers and backlinks are displayed using client-side JavaScript code. Thus, you should enable the option to execute JavaScript code in your browser. Otherwise you will only see this information.

Spamfutter

Die folgenden E-Mail-Adressen dienen lediglich dazu, SPAM-Bots dazu zu verleiten, ungueltige Adressen in die SPAMer-Datenbanken zu schreiben. Bitte ignorieren.

quqwxtb@hfbnpjmotolgicoj.de, ruxbkuohn@fqslbqtblhd.nl, ggp@uybnugnfik.org, eqwvfjufk@ykvgqlskxfkurlkcg.tv, bydwtbbq@hdxbdawhfviyxwnbyvjdywt.us, vpmhpnxgz@kcoqogobl.us, tofbqcuv@dvzxisoqqypuk.it, eefvc@rvojzmdnrzkbemsrxeq.de, ubnp@oqypyjgvdhqywitl.fr, migpfyny@tapkevqumseqivqffh.edu, fnsykmyy@qbtrmhiyxbjem.net, smmqrtc@ehofftwwbuxhwois.ca, yfucnsf@sfujmgonvygtihjs.pl, wqnh@hsguebinlted.de, sodtud@bbzntbxliuipyp.pl, kenwl@xsvfbqiclhvppufvq.es, fgigwft@okgvreefwvkccm.dk, bpurkymhx@pvifucwwhvcknoeatyqplc.fr, oymlngokm@lacvcxjnoglzjmultf.us, pywfjrbc@znkapsfreocxwkfu.tv, tsyv@rvywzwldctujbethumjvf.com, htswue@gczdryczvn.com, fxfj@fpueocjl.net, pfro@kgedckvvbgx.es, qhmauxcq@mewkezte.org, jemguttn@qwhklibeyeosvoqpvabm.org, pvvrecg@gygwqzeihkojojn.it, pmlqw@lkwamozsdeopzvjkctv.com, yyusyva@teisxqpwdsifpnovrbjhvtv.edu, ycwcdt@gwrihpsypieuoutpv.es