WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: Waldschwein on July 27, 2010, 01:04:38 PM
-
...heisst noch ältere WB Versionen (bspl. 2.6.7, 2.7) sind unsicher ??
Ich denke, so genau kann man das alles gar nicht sagen. Die meisten gemeldeten Sicherheitsgeschich ten sind recht speziell, aber viele sind wohl durchaus seit Beginn dabei.
Wenn man weiß, welche Module man hat, den /admin abgesichert hat (oder einfach niemand Backend-Zugang oder sonst irgendwie Zugang gibt) und ein bißchen nachguckt ist es schon halbwegs sicher.
Gut, andere Systeme (die immer im Himmel gelobt werden) sind noch viel unsicherer, aber das macht es auch nicht besser. :wink:
Gruß Michael
-
.... und ein bißchen nachguckt ist es schon halbwegs sicher.
:wink:
Gruß Michael
na ich bin beruhigt - lach
-
na ich bin beruhigt - lach
Sicher ist bloß HTML und CSS, wenn man auf Kontaktformular, FTP-Zugang usw. verzichten kann. Alles andere ist nichtmal mit Aluhut auszuhalten.
Aber es ist ja alles kein Geheimnis:
http://secunia.com/research/
Trotzdem aber OffTopic!
Gruß Michael
-
Sicher ist bloß HTML und CSS
Trotzdem aber OffTopic!
Gruß Michael
<oftopic>
ja dazu gibts auch gute ansätze ... nennt sich erevu und wäre meiner ansicht nach WebsiteBaker Vers. 20.0
bspl sein.de - made in rgbg :-)
</oftopic>
-
<oftopic>
ja dazu gibts auch gute ansätze ... nennt sich erevu und wäre meiner ansicht nach WebsiteBaker Vers. 20.0
bspl sein.de - made in rgbg :-)
</oftopic>
<offtopic>
Na, die Webseite, die das Produkt bewerben soll ist ja fast so fehlerfrei wie die www[pünktle]thepaceredition[pünktle]com :-D Zumindest erfährt man nichts über das Produkt, muss man sich schon keine Gedanken machen, was es alles kann und nicht kann. Und Zend ist erstmal PHP pur, und damit per se nicht sicherer als WB. :wink:
</offtopic>
-
Aber es ist ja alles kein Geheimnis:
http://secunia.com/research/
Na im Juni war wohl hier grade Urlaubszeit?
Ich sehe mir nur mal den erstbesten Fehlerreport dort an:
6) Time Table
07/06/2010 - Vendor notified.
14/06/2010 - Vendor notified (2nd attempt).
22/06/2010 - Vendor notified (3rd attempt).
30/06/2010 - Public disclosure.
Es gibt ja im Forum auch eine Abteilung "Security Announcements" - aber dort stammt der letzte Beitrag vom 2. April - bravo. Man ist also hier nach wie vor nicht gewillt, die User über die offenen Messer zu informieren, die in WB stecken.
-
Zend = "Hersteller" von PHP
Zend Framework = PHP Framework von Zend
http://www.zend.com/de/
Die Nutzung eines vernünftigen Frameworks ist an sich eine sehr gute Idee, da man die Standard-Sachen dem Framework überlassen kann. (Authentifizierung, Sessionmanagement, Sprachunterstützung, Datenbankabstraktio n, ...) Das betrifft selbstverständlich _auch_ die Sicherheit. Und da halte ich jede Wette, daß WB deutlich unsicherer ist, als PHP selbst oder auch das Zend Framework.
Was nicht heißt, daß man nicht basierend auf einem Framework eine unsichere Applikation schreiben kann. :evil:
-
Zu Zend: Ich kann mit einem Auto mit Airbags auch gegen die Wand fahren und das Auto ist incl. mir hin. Zend, MVC usw. bieten viele tolle Möglichkeiten, aber wenn man sie nicht nutzt ist da null nischt mit Sicherheit. Aber man kann ja mal Herrn Esser fragen, was er von der Sicherheit in PHP hält. :-D
Es gibt ja im Forum auch eine Abteilung "Security Announcements" - aber dort stammt der letzte Beitrag vom 2. April - bravo. Man ist also hier nach wie vor nicht gewillt, die User über die offenen Messer zu informieren, die in WB stecken.
Ja und nein. Ich muss hier die beiden Entwickler einmal in Schutz nehmen, ich habe die Informationen ja auch sofort bekommen - nicht dass hier einer meint, die Formulare auf der Webseite wären nur zur Zierde da.
Wenn man sich die Secunia reports (das Datum stimmt mit meinem E-Mail-Postfach überein) im Detail ansieht wird man feststellen, dass es viel schwerer ist, einen "Tipp" zu geben wie man die Fehler vermeidet.
Gerade CSRF vermeidet man nicht mal einfach so mit einer Zeile Code irgendwo, wie es z.B. beim (wesentlich gravierenderen) Backup-Exploit der Fall war - Secunia selbst stuft die Ganzen Exploits eher gering ein.
Daher stellt sich die Frage, was man eigentlich in solch einem Announcement dann außer Verunsicherung erzeugt. "WB ist unsicher, wir haben zwar keine Lösung aber wir wollten's mal gesagt haben" ist ja auch Mist.
Dass die momentane SVN zwar teilweise (oder sogar mittlerweile schon vollständig) alle Exploits mit vielen Kompromissen hinsichtlich alter Module (also wir stellen eine Strickschnur vor das offene Scheunentor und durch die offenen Löcher nageln wir ein paar OSB-Platten, damit es nicht ganz so arg durchpfeift, das Scheunentor aber muss wegen Denkmalschutz erhalten bleiben, weil Scheunentor abreisen und völlig neues, einbruchsicheres aufbauen muss lange überdacht werden) stopft ist klar. Auf der anderen Seite ist die momentane SVN ein bißchen ziemlich wackelig, weil eben einiges Einzug gehalten hat, was erst einmal richtig bewährt sein muss - FTAN, u.v.a.m.
Gruß Michael
-
Zu Zend: Ich kann mit einem Auto mit Airbags auch gegen die Wand fahren und das Auto ist incl. mir hin. Zend, MVC usw. bieten viele tolle Möglichkeiten, aber wenn man sie nicht nutzt ist da null nischt mit Sicherheit.
Du vergleichst da Äpfel mit Birnen. Wenn man die Methoden nutzt, die beispielsweise Zend zur Verfügung stellt, ist das allemal sicherer, als selbst einen Datenbankzugriff zu programmieren. Zumal man dann das Thema Sicherheit Leuten überlassen kann, die auch was davon verstehen. Natürlich _kann_ ich auch bei Nutzung eines Frameworks um dessen API drumrum programmieren, aber dann brauche ich auch kein Framework.
-
Bis auf ein Problem im Backend vom Form-Modul betreffen alle Sicherheitsprobleme das admin-Verzeichnis.
Nun ich vermute daher mal, für die übergroße Mehrheit der Webseiten besteht der optimale Schutz einfach darin, das gesamte admin-Verzeichnis per .htaccess zu schützen. Der Admin, der regulär Zugriff hat, wird sich kaum selbst in den Fuß schießen wollen und hat also kein Bedürfnis, die Lücken gegen sich selbst auszunutzen. Bei Seiten mit vielen Benutzer-Logins wird es dann allerdings etwas komplizierter.
-
Bis auf ein Problem im Backend vom Form-Modul betreffen alle Sicherheitsprobleme das admin-Verzeichnis.
Nicht nur das, für die meisten musst Du sogar angemeldet sein UND Rechte auf dem System haben ...
Gruß
Klaus