Sicherheitsdiskussion SWM/SML
Moderator: mirko
Re: Sicherheitsdiskussion SWM/SML
Naja, die Umlaute kannst ja wirklich im Notfall "händisch" machen. Ich weiß ja nicht wie groß die DB ist, aber im Notfall exportierst über phpmyadmin aber als "UPDATE". Öffnest im Editor und ersetzt alle "hässlichen" Zeichen, danach wieder ein Import bzw. Update der Datei.
Das mit dem neuen Passwort anfordern hat prima funktioniert, siehst ja an mir
Und der neue Look macht einiges mehr her als der Alte
Das mit dem neuen Passwort anfordern hat prima funktioniert, siehst ja an mir
Und der neue Look macht einiges mehr her als der Alte
Re: Sicherheitsdiskussion SWM/SML
naja ein paar Umlaute und EURO-Zeichen sind versaut aber das kann ich nicht ändern, ist ein Konvertierungsfehler von der 2.x auf die 3.x dieses Scripts hier und Passwort muss man sich neu zusenden lassen, das wurde nicht konvertiert.
Re: Sicherheitsdiskussion SWM/SML
Hi Mirko,
coole Sache, ging ja doch recht zügig und vorallem, mit allen Usern und Beiträgen Sehr gut!! Find ich echt gut, dass du so schnell reagiert hast!
Vielen Dank
Gruß
the_scrat
coole Sache, ging ja doch recht zügig und vorallem, mit allen Usern und Beiträgen Sehr gut!! Find ich echt gut, dass du so schnell reagiert hast!
Vielen Dank
Gruß
the_scrat
Die Version 3 gibt es nicht, das ist scheint derzeit nur eine Idee von denen zu sein. Es ist auch nicht gesagt, dass in Version 3 die Probleme gelöst sind, in den angedachten Features steht nichts zum Thema Sicherheitslöcher.
Vielleicht wird es phpbb, mal schauen, wobei dort genauso Lücken enthalten sein können, es machen halt Menschen die Scripte und damit können immer Fehler enthalten sein.
Nachtrag: Oder überhaupt kein Forum mehr, das sind 200-300 Einträge im Monat hier, die meisten beantworte ich sowieso selbst und mindestens die doppelte Menge nochmals per E-Mail.
Vielleicht wird es phpbb, mal schauen, wobei dort genauso Lücken enthalten sein können, es machen halt Menschen die Scripte und damit können immer Fehler enthalten sein.
Nachtrag: Oder überhaupt kein Forum mehr, das sind 200-300 Einträge im Monat hier, die meisten beantworte ich sowieso selbst und mindestens die doppelte Menge nochmals per E-Mail.
Zuletzt geändert von mirko am 24.07.2011, 21:25, insgesamt 1-mal geändert.
Na das ist auch eine Möglichkeit, das Problem aussitzen und hoffen, dass sich irgendwer an eine fast 12 Jahre alte Boardsoftware ranmacht.
Ich war grad mal auf der Seite und sehe, dass es ja bereits APBoard3 gibt. Würde es nicht langen auch mal einfach ein Update zu machen?
Im Notfall mach es doch einfach, wie es viele Boardbetreiber machen, die vor der Aufgabe stehen, dass Sie nicht alle Beiträge übernehmen können.
Such dir eine NEUE und aktuelle Boardsoftware aus. Die alte wird als \"Archiv\" noch behalten. User kannst du ja recht leicht übernehmen, da meistens ja der md5 hash vorliegt. Im alten Board werden alle Passwörter und E-Mailadressen der Benutzer gelöscht.
Dann fängst du zwar in einem neuen Board an, was auch mal Gelegenheit für neue Bereiche gibt oder alte rauszuschmeissen bzw. zu migrieren.
Und schon hast du das Problem sauber gelöst! Und glaub mir, KEINER wird dir böse sein. Im Gegenteil!
Ich war grad mal auf der Seite und sehe, dass es ja bereits APBoard3 gibt. Würde es nicht langen auch mal einfach ein Update zu machen?
Im Notfall mach es doch einfach, wie es viele Boardbetreiber machen, die vor der Aufgabe stehen, dass Sie nicht alle Beiträge übernehmen können.
Such dir eine NEUE und aktuelle Boardsoftware aus. Die alte wird als \"Archiv\" noch behalten. User kannst du ja recht leicht übernehmen, da meistens ja der md5 hash vorliegt. Im alten Board werden alle Passwörter und E-Mailadressen der Benutzer gelöscht.
Dann fängst du zwar in einem neuen Board an, was auch mal Gelegenheit für neue Bereiche gibt oder alte rauszuschmeissen bzw. zu migrieren.
Und schon hast du das Problem sauber gelöst! Und glaub mir, KEINER wird dir böse sein. Im Gegenteil!
Ich weiss, dass hier im Forum Lücken drin sind, einen Teil hatte ich schon angefangen mal zu schließen aber das ist einfach Irre bei den vielen Scripten im Hintergrund. Meine Hoffnung ist noch immer, dass die unter www.php-programs.net mal weitermachen aber zur Zeit geht da wie mal nichts voran.
Hallo MP0-Crew,
danke für den erneuten Hinweis auf die fehlende Sicherheit. Dieses Beispiel zeigt mal wieder, wie durch Nachlässigkeit ein Sicherheitsleck nicht beseitigt wird.
Hier das Zitat nach dem du gesucht hast:
Ich finde es weiterhin wirklich traurig, wie wenig du auf Sicherheit achtest. Sei es in der eigenen Software, noch in der Boardsoftware hier.
Die Ausrede mit der Bequemlichkeit und \"Nutzen\" finde ich doch sehr unzureichend.
Ich gehe jetzt einfach mal soweit, dass ich sage, wenn etwas durch deine Software passiert (da du diese kommerziell vertreibst) und ein Schaden angerichtet wird, kannst du dafür belangt werden. Auch wenn du vielleicht jegliche Gewährleistung oder Haftung ausschließt. Alleine dieser Tread hier, der offenkundig auf massive Sicherheitsmängel hinweist, sollte ausreichen um jeglichen Ausschluss in den AGBs aufzuheben!
Bitte Mirko, kümmere dich darum! Das ist kein Zustand. Jetzt hast du eh schon massives Glück, dass die MP0-Crew dir \"hilft\" und Hinweise liefert!
Kontaktier diese Gruppe doch mal und lass dir zeigen wo es hapert. Oder willst du es wirklich warten, bis sich irgendwelche Script-Kiddies austoben?
gruß
the_scrat
danke für den erneuten Hinweis auf die fehlende Sicherheit. Dieses Beispiel zeigt mal wieder, wie durch Nachlässigkeit ein Sicherheitsleck nicht beseitigt wird.
Hier das Zitat nach dem du gesucht hast:
@Mirko. Bitte tu endlich etwas dagegen. Eine Boardsoftware aus dem Jahre 2000 ist heute einfach nicht mehr Zeitgemäß, vorallem wenn offenkundig Sicherheitslücken bekannt sind und wohl einfachs ausgenutzt werden können.Nee aus dem Jahr 2000 siehe rechts unten auf der Seite das Copyright. Eine andere gibt es aber erstmal nicht, da die Beiträge und Nutzer nicht so einfach übernommen werden können oder willst DU die alle abtippen. :biggrin:PS: Nur diese Forensoftware ist ja grauslig. Stammt die noch irgendwie aus den 60ern?
Ich finde es weiterhin wirklich traurig, wie wenig du auf Sicherheit achtest. Sei es in der eigenen Software, noch in der Boardsoftware hier.
Die Ausrede mit der Bequemlichkeit und \"Nutzen\" finde ich doch sehr unzureichend.
Ich gehe jetzt einfach mal soweit, dass ich sage, wenn etwas durch deine Software passiert (da du diese kommerziell vertreibst) und ein Schaden angerichtet wird, kannst du dafür belangt werden. Auch wenn du vielleicht jegliche Gewährleistung oder Haftung ausschließt. Alleine dieser Tread hier, der offenkundig auf massive Sicherheitsmängel hinweist, sollte ausreichen um jeglichen Ausschluss in den AGBs aufzuheben!
Bitte Mirko, kümmere dich darum! Das ist kein Zustand. Jetzt hast du eh schon massives Glück, dass die MP0-Crew dir \"hilft\" und Hinweise liefert!
Kontaktier diese Gruppe doch mal und lass dir zeigen wo es hapert. Oder willst du es wirklich warten, bis sich irgendwelche Script-Kiddies austoben?
gruß
the_scrat
... na dann ... Ist schon etwas länger her der Thread aber das Thema denken wir, ist immer noch aktuell. Heute wollen wir nicht erneut auf die Sicherheitsproblematik des SWM eingehen, sondern die Gelegenheit nutzen und die schlampig gewartete Boardsoftware hier kurz erwähnen.Kritiken sind immer willkommen, auch Verbesserungsvorschläge, insofern diese umsetzbar und für einen Großteil der Nutzer sinnvoll sind.
Irgendwo haben wir gelesen, dass der Admin nicht die Software wechseln will, da dann ja die ganzen Threads verloren gehen würden. Keine Ahnung wo das stand. Jedenfalls scheint der Admin neben einer neuen Software auch nicht interessiert an updates für die Boardsofware zu sein. So wird eine Software eingesetzt, die seit 2006 offiziell für SQL-Injection angriffe anfällig ist: http://www.cvedetails.com/cve/CVE-2006-3078/
So ist es z.B möglich die gesamte Userdatenbank auszulesen oder an private Nachrichten (mit womöglich sensiblen Inhalten zu gelangen). Zwar werden Passwörter nicht durch den User festgelegt und gehasht gespeichert, aber trotzdem sind die paar tausend Mailadressen für spammer sehr attraktiv.
Genaue Anleitungen ersparen wir uns, ebenso sind keine vollständigen Datensätze in unserem besitz
Wir wünschen uns wirklich einfach nur mehr Achtsamkeit bei der IT-Sicherheit. schaut euch die Nachrichten an! Fast jeden Tag prahlen irgendwelche Script-Kiddies mit derartigen Sicherheitslücken wie sie hier vorzufinden sind und die Unternehmen sind ruiniert.1:mirko_admin:web...er@wt-rate.com:25b8a625a4e...
15198:the_scrat:thexs...@....com:80e037a3254407fad7...
15644:segelschule:chri...@rho...al.com:183ee720c901b7e1e4...
15645:vfqeznumkp:yng...@oyc...q.com:65302005dd21b1...
15646:Schotte2000:scho...@gmx.de:e1c9b9141f96f80b...
15647:aweilix:wei...@gmx.net:ab3b913c10a2e7bce...
15648:guenter2011:arsiv...@gmx.de:b1253f048dd25826...
15650:jmel:j.mel...@sol...n.de:c5106dd8574894c...
15651:FS-Franz:f.schin...@aon.at:b5a6c37af79e...
15652:cookiecake:kuch...@gmail.com:9bbf80cf68f...
15653:claudiacarolina:cl...@gmx.ch:598222d74fdf167bb4df4fdf...
15654:montjoshua:super...@artwor...ia.de:6cb2ceb71a277b4...
MP0
Die Software wird für den Menschen gemacht, wenn der meint PHP 4.1 zu verwenden, dann muss die jeweilige Software dies unterstützen. Natürlich muss man sich irgendwann mal von alten PHP-Versionen trennen, nur eben jetzt noch nicht, da kleine Webspace-Kunde den Provider nicht zwingen kann eine höhere PHP-Version zu verwenden, mal von einer Kündigung abgesehen.ein sehr interessantes Thema, welches eigentlich ja schon längst überfällig war. Daher dank an die MP0-Crew.
Dass der verwendete Code nicht auf der höhe der Zeit ist, darüber sind wir uns ja hoffenltich alle einig. Er macht das, was er soll.
Leider finde ich solche Aussagen wienicht so toll. Es gibt auch Leute die nutzen heute noch Windows 98 oder NT Rechner.mysql_real_escape_string() gibt es erst am PHP 4.3, deswegen habe ich das bisher auch nicht verwendet, es gibt halt noch PHP 4.1er Nutzer
Aber im Web-Bereich, vorallem wo auch noch Kundendaten hinterlegt sind, sollte man auf solche Leute nicht umbedingt den größten Wert legen. \"Hacker\" werden wegen einer alten Version auch nicht auf alte Techniken zurückgreifen um es sich schwerer zu machen.
Wenn es Leute gibt, die noch mit 4.1 unterwegs sind, gut, stell Ihnen eine alte Version zur Verfügung die offiziell nicht mehr supported wird.
Ebenfalls wird mysql_real_escape_string seit geraumer Zeit verwendet aber eben nur wenn es diese Funktion auch gibt, ansonsten wird diese als PHP Funktion simuliert, ist natürlich langsamer.
Wie gesagt benutzerfreundlich sollte die Sache schon sein... Du müsstest mal meinen Software-Support machen, dann wüsstest du spätestens nach 1 Monat was ich mit \"benutzerfreundlich\" meine und auf was für Probleme der Normal-Nutzer stösst.Auch wenn ich sowas lese wieDa wird aus Gründen der \"Bequemlichkeit\" ein künstliches Sicherheitsleck geschaffen, kein großes, aber zumindest in der Hinsicht, dass JEDER eine funktionsfähige Admin-E-Mailadresse sieht!!!Ja das ist extra so gemacht, damit mal als Nutzer sieht wohin die E-Mail geht. Einige haben massig Postfächer, ich auch, damit weiss man nach Eingabe des Nutzernamens nicht, wohin die E-Mail geht.
Passwörter im Klartext abspeichern? Heute sollte eigentlich nun jeder wissen was er tun muss, wenn er sein Passwort neu anfordert und stattdessen einen Link inkl. Token bekommt, über den er binnen eines Zeitintervals ein neues Passwort setzen kann.
Es passiert ja auch erstmal nichts. Natürlich kann man mit so etwas blödsinn machen, z.B. über 3 Ecken aufs Online-Banking zugreifen und irgendeine Lücke im Online-Banking ausnutzen.Was ich leider garnicht verstehe ist eine Äußerung über den Sachverhalt des XSS und des <script>alert()</script>??? Dir ist schon klar, dass man aus dem BEISPIEL \"alert\" auch ganz anderes sachen machen kann?! Runterspielen würde ich diese Lücke jedoch nicht mit \"gibt nur ne Meldung aus und gut ists\".ja aber es passiert nichts, der gibt nur die Meldung aus und und gut ist es.
Bei diesem Thema gehen immer die Meinungen auseinander. Ich stehe auf dem Standpunkt bei Scripten muss man nicht bei jedem Aufruf einen Stapel Klassen erzeugen, die prozedurale Programmierung reicht für die Auswertung von Formulareingaben vollkommen aus. Klassen werden nur dort verwendet, wo es auch wirklich Sinn macht.
Ich wusste zwar, dass es gravierende Sicherheitsmängel in der Software gab. Als der PHP Code noch einfach zu lesen war, konnte man sich davon ja gut überzeugen. Prozedurale Programmierung....
Kritiken sind immer willkommen, auch Verbesserungsvorschläge, insofern diese umsetzbar und für einen Großteil der Nutzer sinnvoll sind.Trotzdem finde ich es gut, wie Mirko reagiert und mit der Kritik umgeht. Es wäre schön, wenn dieser Thread bzw. die Initiatoren der MP0-Crew zukünftig für ein wenig mehr Sicherheit innerhalb der Software sorgen.
Hallo,
ein sehr interessantes Thema, welches eigentlich ja schon längst überfällig war. Daher dank an die MP0-Crew.
Dass der verwendete Code nicht auf der höhe der Zeit ist, darüber sind wir uns ja hoffenltich alle einig. Er macht das, was er soll.
Leider finde ich solche Aussagen wie
Aber im Web-Bereich, vorallem wo auch noch Kundendaten hinterlegt sind, sollte man auf solche Leute nicht umbedingt den größten Wert legen. \"Hacker\" werden wegen einer alten Version auch nicht auf alte Techniken zurückgreifen um es sich schwerer zu machen.
Wenn es Leute gibt, die noch mit 4.1 unterwegs sind, gut, stell Ihnen eine alte Version zur Verfügung die offiziell nicht mehr supported wird.
Auch wenn ich sowas lese wie
Passwörter im Klartext abspeichern? Heute sollte eigentlich nun jeder wissen was er tun muss, wenn er sein Passwort neu anfordert und stattdessen einen Link inkl. Token bekommt, über den er binnen eines Zeitintervals ein neues Passwort setzen kann.
Was ich leider garnicht verstehe ist eine Äußerung über den Sachverhalt des XSS und des <script>alert()</script>
Ich wusste zwar, dass es gravierende Sicherheitsmängel in der Software gab. Als der PHP Code noch einfach zu lesen war, konnte man sich davon ja gut überzeugen. Prozedurale Programmierung....
Trotzdem finde ich es gut, wie Mirko reagiert und mit der Kritik umgeht. Es wäre schön, wenn dieser Thread bzw. die Initiatoren der MP0-Crew zukünftig für ein wenig mehr Sicherheit innerhalb der Software sorgen.
Gruß
the_scrat
ein sehr interessantes Thema, welches eigentlich ja schon längst überfällig war. Daher dank an die MP0-Crew.
Dass der verwendete Code nicht auf der höhe der Zeit ist, darüber sind wir uns ja hoffenltich alle einig. Er macht das, was er soll.
Leider finde ich solche Aussagen wie
nicht so toll. Es gibt auch Leute die nutzen heute noch Windows 98 oder NT Rechner.mysql_real_escape_string() gibt es erst am PHP 4.3, deswegen habe ich das bisher auch nicht verwendet, es gibt halt noch PHP 4.1er Nutzer
Aber im Web-Bereich, vorallem wo auch noch Kundendaten hinterlegt sind, sollte man auf solche Leute nicht umbedingt den größten Wert legen. \"Hacker\" werden wegen einer alten Version auch nicht auf alte Techniken zurückgreifen um es sich schwerer zu machen.
Wenn es Leute gibt, die noch mit 4.1 unterwegs sind, gut, stell Ihnen eine alte Version zur Verfügung die offiziell nicht mehr supported wird.
Auch wenn ich sowas lese wie
Da wird aus Gründen der \"Bequemlichkeit\" ein künstliches Sicherheitsleck geschaffen, kein großes, aber zumindest in der Hinsicht, dass JEDER eine funktionsfähige Admin-E-Mailadresse sieht!!!Ja das ist extra so gemacht, damit mal als Nutzer sieht wohin die E-Mail geht. Einige haben massig Postfächer, ich auch, damit weiss man nach Eingabe des Nutzernamens nicht, wohin die E-Mail geht.
Passwörter im Klartext abspeichern? Heute sollte eigentlich nun jeder wissen was er tun muss, wenn er sein Passwort neu anfordert und stattdessen einen Link inkl. Token bekommt, über den er binnen eines Zeitintervals ein neues Passwort setzen kann.
Was ich leider garnicht verstehe ist eine Äußerung über den Sachverhalt des XSS und des <script>alert()</script>
??? Dir ist schon klar, dass man aus dem BEISPIEL \"alert\" auch ganz anderes sachen machen kann?! Runterspielen würde ich diese Lücke jedoch nicht mit \"gibt nur ne Meldung aus und gut ists\".ja aber es passiert nichts, der gibt nur die Meldung aus und und gut ist es.
Ich wusste zwar, dass es gravierende Sicherheitsmängel in der Software gab. Als der PHP Code noch einfach zu lesen war, konnte man sich davon ja gut überzeugen. Prozedurale Programmierung....
Trotzdem finde ich es gut, wie Mirko reagiert und mit der Kritik umgeht. Es wäre schön, wenn dieser Thread bzw. die Initiatoren der MP0-Crew zukünftig für ein wenig mehr Sicherheit innerhalb der Software sorgen.
Gruß
the_scrat
ja aber es passiert nichts, der gibt nur die Meldung aus und und gut ist es.Original von heimi:
Ich bin über das XSS Problem gestolpert und dann auf diesen Thread via google aufmerksam geworden. Habe dann etwas mit der demo gespielt und muss leider sagen, dass:
- das xss auf der Loginseite existiert noch immer, HTML wird da nicht escaped. Als Beispiel mal \"><script>alert(\"Verwundbar.\")</script><input eingeben
Macht er nicht mehr, der wandelte alle Strings in Zahlen um, erst dann werden diese an die Datenbank übergeben, damit man keinen \"Unsinn\" machen kann.- die Typisierung scheint nicht zu greifen, sql inject wird zwar bei dem angesprochenen Beispiel verhindert, aber Problem ist grundsätzlich: wenn ein Integer erwartet wird (die id einer message zB), dann sollte da kein String erlaubt sein, auch wenn dieser dann untersucht wird ob er ein \"select\" enthält. blacklisting ist immer problematisch, es sollten whitelists für jedes Formularfeld existieren.
Das kann man nicht umgehen, außer man baut halt wirklich komplizierte lange Keys ein, die dann intern in die jeweilige ID umgewandelt werden.- automatisierte Anmeldung ist auch noch immer möglich, s.o. durch raten der Id
Ja das ist extra so gemacht, damit mal als Nutzer sieht wohin die E-Mail geht. Einige haben massig Postfächer, ich auch, damit weiss man nach Eingabe des Nutzernamens nicht, wohin die E-Mail geht.- die pw vergessen Funktion verrät zwar nicht das passwort, das steht in der mail, wohl aber die Adresse des Admins: \"das pw wurde an admin@sonstwo\" gesendet
Das wird sowieso nicht mehr im Klartext gespeichert.- ob der Nutzer ein \"freundliches\" Passwort wählt \"geheim\" oder ein kryptisches \"aZsd!\" ist doch egal, solange die im Klartext in der DB abgelegt sind. Da sollten ausschliesslich Hashes drin stehen.
Ich bin über das XSS Problem gestolpert und dann auf diesen Thread via google aufmerksam geworden. Habe dann etwas mit der demo gespielt und muss leider sagen, dass:
- das xss auf der Loginseite existiert noch immer, HTML wird da nicht escaped. Als Beispiel mal \"><script>alert(\"Verwundbar.\")</script><input eingeben
- die Typisierung scheint nicht zu greifen, sql inject wird zwar bei dem angesprochenen Beispiel verhindert, aber Problem ist grundsätzlich: wenn ein Integer erwartet wird (die id einer message zB), dann sollte da kein String erlaubt sein, auch wenn dieser dann untersucht wird ob er ein \"select\" enthält. blacklisting ist immer problematisch, es sollten whitelists für jedes Formularfeld existieren.
- automatisierte Anmeldung ist auch noch immer möglich, s.o. durch raten der Id
- die pw vergessen Funktion verrät zwar nicht das passwort, das steht in der mail, wohl aber die Adresse des Admins: \"das pw wurde an admin@sonstwo\" gesendet
- ob der Nutzer ein \"freundliches\" Passwort wählt \"geheim\" oder ein kryptisches \"aZ$3sd!\" ist doch egal, solange die im Klartext in der DB abgelegt sind. Da sollten ausschliesslich Hashes drin stehen.
- das xss auf der Loginseite existiert noch immer, HTML wird da nicht escaped. Als Beispiel mal \"><script>alert(\"Verwundbar.\")</script><input eingeben
- die Typisierung scheint nicht zu greifen, sql inject wird zwar bei dem angesprochenen Beispiel verhindert, aber Problem ist grundsätzlich: wenn ein Integer erwartet wird (die id einer message zB), dann sollte da kein String erlaubt sein, auch wenn dieser dann untersucht wird ob er ein \"select\" enthält. blacklisting ist immer problematisch, es sollten whitelists für jedes Formularfeld existieren.
- automatisierte Anmeldung ist auch noch immer möglich, s.o. durch raten der Id
- die pw vergessen Funktion verrät zwar nicht das passwort, das steht in der mail, wohl aber die Adresse des Admins: \"das pw wurde an admin@sonstwo\" gesendet
- ob der Nutzer ein \"freundliches\" Passwort wählt \"geheim\" oder ein kryptisches \"aZ$3sd!\" ist doch egal, solange die im Klartext in der DB abgelegt sind. Da sollten ausschliesslich Hashes drin stehen.
Gibt es tatsächlich Leute, die den SuperWebMailer installieren und einrichten können, aber ein simples Passwort nicht aus einer Email herauskopieren können?Original von Mirko:
Nur einige können halt nichts aus einer E-Mail kopieren oder fehlerfrei abtippen, dann klingelt bei mir das Telefon, nur helfen kann ich in dem Fall auch nicht mehr.Also, meine Passwörter sind immer kryptisch und es ist Jedem zu wünschen, dass er auch kryptische und keine \"freundliche\" Passwörter verwendet.Das mit Passwort wird jetzt auf jeden Fall geändert, dann muss halt der Nutzer erstmal mit einem kryptischen Passwort leben und kann es später immernoch auf einen freundlicheren Wert ändern.
Kann ich nicht glauben.