A felhasználók azonosítása minden webes rendszer kritikus része. Különösen igaz ez akkor, ha olyan rendszert fejlesztesz, aminek a forráskódja nyilvánosan elérhető. Nyilt forráskódú rendszereknél általában előnyként szoktuk értékelni, hogy megismerhető a forráskód, mert a jó szándékú fejlesztők és biztonsági kutatók sokkal könnyebben rátalálnak biztonsági hiányosságokra.

A jótékony homály Link to heading

Nem jó gyakorlat, de a rendszer biztonságát valamennyire tudja fokozni, ha a külvilág nem tudja megismerni az implementáció részleteit. Így a hibákra gyakran csak időigényes próbálkozások árán derül fény. Ez sokszor olyan költséges, hogy nem éri meg időt és energiát szánni rá akár jó, akár rossz szándékkal áll neki a biztonsági kutató vagy egy valamiféle hasznot remélő támadó.

Tényleges biztonság Link to heading

Ha a kódod nyilvános, nem alapozhatsz arra, hogy a jótékony homály elfedi az implementációd hiányosságait, ezért rá vagy kényszerítve arra, hogy ténylegesen biztonságos megoldásokkal állj elő, ami megvédi a felhasználóid és a saját adataid.

Tájékozódj! Link to heading

Legyél naprakész, hogy milyen támadási formák népszerűek éppen, amik érinthetik az alkalmazást, amit fejlesztesz. A Rust egy biztonságos nyelv és nagyon sok mindent megkövetel, amitől biztonságosabbá válik a programod, de a logikai hibáktól nem fog megvédeni!

Nézd át újra! Link to heading

Fejlesztés közben elkerülhetetlenül találkozol új dolgokkal, folyamatosan tanulsz új koncepciókat és találsz hasznos könyvtárakat, amik javítják a kódod minőségét, ezért időről időre rédemes újra átnézned a kódodat, amit korábban írtál, mert esély van rá, hogy az új információkkal felvértezve jelentősen javíthatod azok biztonságát és/vagy funkcionalitását.

Automatizálj! Link to heading

Ha minden egyes módosításnál újra és újra végig kell nézned az összes biztonsági és egyéb funkciót, hamar eljutsz arra a pontra, hogy inkább hozzá sem nyúlsz azokhoz a részekhez, amik már egyszer működtek, mert újra végigpróbálni az egészet költséges és időigényes. A modern szoftverrel szemben az az elvárás, hogy folyamatosan megfeleljen az új kihívásoknak és igényeknek, ezért a legritkább esetben készül csak olyan kód, amihez nem kell többet hozzányúlni. A folyamatos tesztelés segít elkerülni, hogy az elkerülhetetlen változtatások során újabb biztonsági rések vagy egyéb hibák kerüljenek a kódodba.

És miért írom mindezt? Link to heading

Az utóbbi napokban elkedztem újra átnézni a webes alkalmazásom felhasználó azonosítással foglalkozó részét és átszerveztem úgy a kódot, hogy egy központi helyen végezze el a JWT validációját, hogy elkerüljem, hogy több helyen létezzen erre különböző implementáció. Az átszervezés egyik következménye az lett, hogy sokkal könnyebben tudtam teszteket írni erre a logikára, amit meg is tettem.

A tesztelés során kiderült, hogy a könyvtár, amit használok a JWT generálásra az alapértelmezett validátorral nem ellenőrzi a JWT nbf mezőjét, ami arra hivatott, hogy ellenőrizze, hogy a JWT-t nem lehet idő előtt felhasználni. Ennek igazából az én felhasználási esetemben nincsen túl sok jelentősége, de ha már használom ezt a mezőt, akkor működjön rendesen.

Aminek viszont van jelentősége, hogy ezekkel a tesztekkel, ha valaki megkérdezi, hogy honnan tudom hogy működik a token generálás és ellenőrzés a rendszeremben, akkor rá tudok mutatni a tesztekre, amik ezt minden élesítés előtt újra és újra automatikusan kipróbálják.

Legyetek biztonságban, akkor is ha nyílt forráskódú rendszert fejlesztetek!

Ha elolvastad ezt a bejegyzést írj egy e-mailt, hogy tudjam, hogy valaki olvassa a bejegyzéseimet, mert egyelőre nincsen semmilyen forgalomfigyelő ezen az oldalon! :))