Optimize Joomla SecurityMostanában egyre többször fordul elő, hogy innen is onnan is megkeresnek azzal, hogy nem jól működik a weboldal nézzek már rá. Számos esetben azt tapasztalom, hogy az oldal jelentősen el van hanyagolva. Amikor az érintetteknek erre rámutatok, akkor döbbenten néznek rám. Az embereknek – és sajnos sokszor a kivitelezők is ezt erősítik, hisz nem mondják el, hogy nincs vége az oldal elkészítésekor a munkának – azt hiszik egy weboldal fejlesztéssel kész és nincs több feladat.

Ezzel szemben az az igazság, hogy a biztonságos weboldal kialakítása már a tervezéskor elkezdődik, folytatódik a kivitelezés során, majd az átadást követően is folyamatosan kell vele foglalkozni, ha az elért biztonsági szintet fenn akarjuk tartani. Amennyiben ezt nem vesszük figyelembe, akkor tudomásul kell venni, hogy bármikor érkezhetnek a kéretlen látogatók. Tudom a válasz “eddig nem jöttek ergó nincs gond” nos ez csak szerencse kérdése, nem több…

Az alábbiakban a gondolatokat a Joomla szempontjából szedtem össze, de félreértés ne essék ez bármely weboldal kialakításakor szinte teljesen megegyezik. Külön kiemelném, hogy az egyedileg fejlesztett megoldások esetén a probléma még inkább fontos, mert – tisztelet a kivételnek –, de nem nagyon szoktak az egyedi fejlesztés során a fejlesztők ezzel foglalkozni (igen akár 30%al megdobja az időt és a költségeket).

More »

joomla-32.pngJómagam még csak most kezdek site migrációs oldalról kacsingatni a Joomla 3.x felé (igazából vártam a már majdnem végleges J! 3.2-t ezekhez) és így igencsak felkaptam a fejemet a Joomla Community Portal-n tegnap megjelent cikkre, mely a UPDATE ON 3.2.1 AND SECURITY ENHANCEMENTS címet viselte. Különösen akkor kezdtem el a szememet és a számat mozgatni (első pislogott, a második vigyorra futott) amikor megértettem miről is írnak. A teljes cikk fordításának nem sok értelmét látom hisz elolvasható a fenti linken, de a lényeget összefoglalnám:

  • A probléma a Joomla erős biztonsági jelszókezelésével lehetséges, amennyiben az oldal futtató környezetében nem áll rendelkezésre a PHP 5.3.7 vagy ennél nagyobb verziójú PHP motor.
  • Joomla 3.2 alapú éles oldal esetén – amennyiben minden rendben működik – teszt nélkül véletlen sem szabad kikapcsolni az erős jelszókezelési módot.
  • Joomla 3.2 alapú tesztelési, vagy fejlesztési oldal esetén előszeretettel kapcsolják be az új erős jelszókezelést, de költözéskor nem figyelnek már arra, hogy a PHP 5.3.7 vagy erősebb legyen. Az alacsonyabb PHP verziókban nem áll rendelkezésre az erős jelszókezeléshez szükséges kiszolgálói háttér, így annak eredménye egy nem stabil oldal lesz, ahol a bejelentkezéssel gond lesz. Tekintettel arra, hogy az erős jelszóról áttérni a gyengébbre (visszakódolni a hash-t) nem lehet, így ekkor a bejelentkezés nem fog működni.
  • Joomla 3.0/3.1 alapú éles oldal esetén nyugodtan telepítse a Joomla 3.2-s verziót és élvezze az előnyöket, de ne kapcsolja be az erős jelszókezelést a 3.2.1 patch megjelenéséig
  • Joomla 2.5 alapú éles oldal esetén nincs semmi teendője, mert a fent leírtak csak a 3.2 rendszerrel megjelent kódot érintik
  • Joomla 1.5 alapú éles oldal esetén ajánlott az áttérésre serkenteni a felhasználókat, mert a rendszer támogatása 2012 decemberében lezáródott. Természetesen a J! 1.5 oldalak ma is működnek, de ezekhez a projekt hiba- és security javításokat már nem készít

Mikor jelenik meg a Joomla 3.2.1?

Ennek dátuma jelenleg nem ismert, de a projekt erősen dolgozik rajta. Mindent megtesznek továbbá azért, hogy a most tapasztaltakat az ellenőrzési folyamatba beépítsék. Amennyiben bárki úgy érzi, hogy a tesztelési munkában szeretne részt venni akkor nézzen körül bátran a https://groups.google.com/group/jtesters oldalon.

Erős jelszó használatának letiltása

Amennyiben valaki nem tudja a fent említett funkció ki és bekapcsolása miként lehetséges, akkor képekkel tarkított leírást talál a http://docs.joomla.org/How_to_disable_the_Strong_Passwords_feature oldalon.

A weblogok feldolgozása eléggé régikeletű dolog, számos esetben írtam már különböző változatokat. Mostanság is ilyet késztettem, s ennek kapcsán előkerült egy érdekes jelenség, nevezetesen a UserAgentString ami alapvetően minden definíció szerint 255 karakterbe belefér, az most több mint 15 millió rekord feldolgozása során 2 alkalommal ennél hosszabb volt

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; ExaleadToolbar/1.0; SIMBAR={2BBA1CDF-4043-11E0-BC7F-5050506F4531}; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; BRI/2; Windows Live Messenger 14.0.8117.0416)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6.6; SIMBAR={556D6409-25AE-48AE-990D-7ADB2B0F302E}; .NET CLR 2.0.50727; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.1)

Lehetne mondani, hogy kit izgat? Viszont rögtön válaszolhatunk is, annak akinek ezt tömegesen és automatizáltan kell kezelni. Mostantól erre is figyelni kell és kész.

 

Erre sokszor lenne szükség:

Az OneShar.es szolgáltatás mindkét fenti félelemre válaszol. A maximum 1000 karaktert tartalmazó titkos üzenet elküldésekor már a szolgáltató szerverére is titkosítva érkezik a tartalom, amelyet csak a címzett tekinthet meg egy webes URL ismeretében. A fogadónál megnyíló üzenet ráadásul csak egyszer tekinthető meg, az URL újrafelhasználásakor vagy egy egyszerű oldalfrissítésnél is már csak hibaüzenetet kapunk.
A rendszer használata egyszerű: elsőként írjuk be az üzenetet az ablakba, majd nyomjuk meg a Create Link gombot az egyszer használatos URL generálásához.

A következő ablakban megkapjuk a címzettnek szánt megtekintési hivatkozást, amelyet az egérrel kijelölve, vagy a hivatkozás alatti linkre kattintva a vágólapra küldhetünk.