Názory k článku
Zranitelnost přihlašovací stránky Joomla!
-
Palo (neregistrovaný)
Prosim vas ktory server umoznuje nasledovne LDAP query? Ako je mozne ze na takyto dotaz ('password=c*') vrati LDAP server OK?!?!? Vsetky mne zname servre ukladaju iba hashValue hesla. Lebo keby to bola pravda tak potom nemame problem s Joomla serverom ale hlavne s LDAP serverom!!!!
(&(uid=Admin)(userPassword=s*))
(&(uid=Admin)(userPassword=se*))
(&(uid=Admin)(userPassword=sec*)) -
Lol Phirae (neregistrovaný)
A ještě závěrem bych si dovolil udělit kyselou prdel vývojářům Joomly. Tyhle bezpečnostní opravy vydané pouze jako nová minor verze jsou skutečně výborné, ještě jsem nezažil release, kde by ten upgrade na X.X.x na X.Y.0 nebyl alespoň někde fatálně pojebaný a neskončil mnohahodinovým pátráním a vrtáním se v rozesrané instalaci/databázi.
-
Nevim jak ostatni, ale treba konkretne Drupal je oproti WP uplne jinde v tomhle smeru. Je tady security team, je dost vylepseny workflow ohledne security issues(jako pouceni z Drupalgedonu), mame "covered by security team" status pro stable releases modulu/sablon. Ale hlavne je tam uvnitr te aplikace API prakticky na vsechno takze SQL injection nebo XSS vyrobit je pri dodrzeni zakladnich pravidel dost obtizne (a pri jejich nedodrzeni zase dobre nalezitelne). Kdo to trochu sleduje tak vi, ze za celou historii Drupalu byla jedina 0-day critical security issue(CVE-2014-3704) v jadre(plus jedna nedavno v modulu Coder, ktery vsak neni rozhodne pouzivany amater - zde bylo poprve a zatim jedinkrat pouzito nove workflow z hlediska oznamovani critical security issues). Zazil jsem jednou jedinkrat web hacknuty pres jinou diru - a ta nebyla v Drupalu samotnem nybrz CKEditoru.
Na rozdil od WP kde je to samy XSS/SQL-i je v drupalu drtiva vetsina security problemu dostupna jen s podminkou, ze user ma nejaka administracni prava.
