Sicherheitsrisiko unklar - mybb 1.2.13 - Druckversion +- MyBB.de Forum (https://www.mybb.de/forum) +-- Forum: Archiv (https://www.mybb.de/forum/forum-57.html) +--- Forum: MyBB 1.2.x und älter (https://www.mybb.de/forum/forum-27.html) +---- Forum: Installation/Aktualisierung (https://www.mybb.de/forum/forum-37.html) +---- Thema: Sicherheitsrisiko unklar - mybb 1.2.13 (/thread-9604.html) |
Sicherheitsrisiko unklar - mybb 1.2.13 - subTH - 31.05.2008 Hallo, ich versteh nicht ganz, warum die Änderungen des Patches auf 1.2.13 als "medium" bzw. "high" eingestuft sind: OK, PHP-Code: $attachment['filename'] PHP-Code: get_extension() Bei inc/datahandlers/user.php wurde versäumt den Sprachstring zu escapen. Aber angenommen jemand möchte eine SQL-Injection durchführen, würde das wahrscheinlich über ein Update seine Profils gemacht werden. Also schauen wir uns einmal usercp.php an: Bei einer Profiländerung wird ein "action=do_options" als POST ausgeführt. Dabei wird das Array PHP-Code: $user['language'] PHP-Code: validat_user() PHP-Code: verfiy_language() PHP-Code: language_exists() PHP-Code: language_exists() PHP-Code: file_exists() Ein SQL-Befehl wurde bis zu diesem Zeitpunkt nicht abgesetzt. Wo ist also das Risiko? Grüße subTH RE: Sicherheitsrisiko unklar - mybb 1.2.13 - Michael - 31.05.2008 Hallo, das große Problem ist, dass verschiedene Erweiterungen ebenfalls auf die vom MyBB bereitgestellten Klassen und Funktionen zugreifen. In der Datei usercp.php werden die Eingaben zwar validiert, aber das muss bei Mods nicht ebenfalls so sein. MySQL-Injektion ist theoretisch möglich und immer ein großes Risiko. RE: Sicherheitsrisiko unklar - mybb 1.2.13 - subTH - 31.05.2008 Alles klar, ich benutze keine Mods und hatte es deshalb nicht bedacht RE: Sicherheitsrisiko unklar - mybb 1.2.13 - StefanT - 01.06.2008 Die Lücken betreffen ja nicht nur SQL-Injection: Bei Änderung 1 und 2 (Zahlen wie in der manuellen Anleitung) ist XSS möglich. Diese Lücke ist für den Benutzer nicht ungefährlich, ist allerdings schon lange drin und wurde nicht benutzt. Daher wurde es als geringes Risiko eingeschätzt. Bei 3 ist SQL-Injection möglich. 4 dagegen erlaubt das Einbinden von falschen Dateien, was auch gefährlich sein kann. Deine Argumente stimmen zwar im Bezug auf SQL-Injection, wie du aber siehst, trifft es hier nicht vollständig zu. |