Az elmúlt időszakban nem voltam túlzottan aktív sem a blogon, sem pedig a Facebook oldalon. Június 21-én indult a hackerek éjszakája nevű akció, és még nem ért véget. Jelenleg még 3 site várja hogy befejezzem a vizsgálatokat. Az akció egyébként úgy néz ki, hogy hozza a várt eredményeket. Az eddig vizsgált rendszerek esetében mindig találtam magas besorolású hibát.
Bár tény, hogy az egyik jelentkezőnek tényleg nagyon tutin volt összerakva az egyedi rendszere, mégis elcsúsztak egy banánhéjon – önhibájukon kívül.
Félelmek
Egészen meglepődtem rajta, hogy a jelentkezők közül senki sem vállalta fel – még a felkínált további 50%-os kedvezmény ellenére sem – hogy a rendszer javítása után publikáljam az eredményeket. Ez fájó pont, mert vallom, hogy minden sérülékenységből lehet, sőt kell is tanulni. Fájó pont, mert ezek a hibák nyugodtan publikálhatóak lennének a javítás után.
Ráadásul mindenkinek elmondtam, hogy nem úgy tárom ország-világ elé, hogy „Hehe, az XY Kft. sem tudta rendesen megcsinálni a weboldalát”, hanem egyfajta tanításként, esetleg egy interjú keretein belül, ahol egyszerűen arról beszélgettünk volna egy kamera társaságában, hogy miért volt hasznos egy ilyen vizsgálat, és milyen hibákat sikerült kiszűrni vele.
Csak én gondolom úgy, hogy ha valaki auditáltatja a rendszerét, és javítja a hibákat, akkor ez pozitív dolog? Ha valaki tudja a választ, írja meg!
Hiába a jó framework
Bebizonyosodott az is az elmúlt hetekben, hogy egy megbízhatónak tituált keretrendszer használata még nem garancia semmire. Hiába használ a fejlesztő Symfony, vagy Laravel keretrendszert, ha közben olyan aknákat helyez el a rendszerben, amire a frameworknek nincs hatása. Hiába van jó alap, ha nem ellenőriz jogosultsági szinteket. Sőt, hiába ír valaki hibátlan kódot, ha szerver szinten vannak olyan problémák, amit látva először nem hittem el hogy valóban biztonsági rést találtam, és nem csak egy honeypot-ba futottam bele.
Összességében elmondható, hogy egy jó keretrendszer megkönnyítheti a munkát, felgyorsíthatja a fejlesztés menetét, de a biztonságon nagyjából semmit nem fog emelni.
Tipikus hibák
Nem meglepő módon még mindig tarolnak az OWASP TOP 10-es listában lévő sérülékenységek. Közte van az SQL Injection, a Cross-site scripting. Ráadásul sokszor látszik hogy a fejlesztő(k)nek már van tudásuk arra, hogy kivédjék az ilyen jellegű támadásokat, ám amikor közeledik az átadási határidő, vagy valamit gyorsan kell megcsinálni, akkor valahogy kimaradnak ezek az ellenőrzések. Így lehetséges, hogy egy rendszer 95%-ban védett mondjuk SQLi ellen, de ott az a fránya 5%, aminek a segítségével ki lehet húzni a teljes adatbázist.
De persze nagy számban előfordulnak olyan alapvető problémák, mint a https:// hiánya, amit pár éve még rá lehetett fogni arra, hogy egy SSL tanúsítvány beszerzése nyűg és költség. Ma viszont, amikor a Let’s Encrypt segítségével ingyenesen és 2 perc alatt lehet tanúsítványt kérni az oldalra és áttérni a titkosított kapcsolatra, egyszerűen nem értem hogy miért használ még bárki titkosítatlan kapcsolatot?
A Cookie attribútumok csak egy oldal esetében voltak jól beállítva, a biztonság emeléséhez szükséges header-ek pedig sehol.
Van fény az alagút végén…
Azért hogy jót is mondjak: az idei eresztésben nem volt olyan oldal, ami egyszerű szövegként tárolt volna jelszavakat. Ez különösen nagy érdem akkor, amikor az SQL injection támadás még mindig tarol. Persze hozzá kell tennem, hogy a támadás során kinyert jelszóhashekből (úgy látszik most a bcrypt a menő), volt olyan, hogy mindösszesen 4 óra leforgása alatt több felhasználó jelszavát is visszafejtettem, egy egyszerű 4 magos notebook segítségével. És ez a tény rögtön húzza is magával a megállapítást, hogy az adott rendszerben nincs szinte semmi megkötés a jelszavak erősségére. Ha lett volna ilyen, és a felhasználók nem 4-6 kisbetűből (angol abc) álló jelszót választottak volna, akkor könnyen lehet, hogy nem derült volna fény a jelszavakra.
Az látom, hogy egyre nehezebb fogást találni egy-egy webalkalmazáson. Nem lehetetlen, de nehezebb mint 2 éve.