Logikai hibák szoftverekben

A szoftverek mára a modern világ láthatatlan tartóoszlopaivá váltak: irányítják a közlekedési lámpákat, kezelik a banki tranzakciókat, és életmentő orvosi műszereket vezérelnek. Míg egy fizikai szerkezet vagy egy félresikerült építészeti elem hibája azonnal szembetűnik, a kódban rejlő logikai hibák gyakran teljesen észrevétlenek maradnak a katasztrófáig. Nem a lefordíthatatlan szintaktikai hibákról van szó, amelyeket a fordítóprogram azonnal kiszúr, hanem azokról a tervezési tévedésekről, amikor a program pontosan azt csinálja, amit leírtunk neki, csak épp nem azt, amire a valóságban szükség lenne. 

A logikai hibák észrevétele

Manapság több cég is futtat úgynevezett "bug bounty" programokat, amiknek a lényege, hogy szigorú előírások mellett, de engedélyt adnak tesztelőknek, hogy próbáljanak sérülékenységeket találni a szoftvereikben, pénzjutalom ellenében. 

Ennek az az oka, hogy a logikai hibákat jellemzően nem gép, hanem ember veszi észre. Egy tapasztalt tesztelő vagy etikus hacker úgy közelít egy alkalmazáshoz, mint egy rosszindulatú felhasználó: nem a dokumentált folyamatot követi, hanem azt keresi, mi történik, ha valaki a lépéseket felcseréli, egy mezőt negatív értékkel tölt ki, vagy két kérést pontosan egyszerre indít el. Az automatizált eszközök ezt a fajta kreatív, kontextusfüggő gondolkodást ma még nem tudják pótolni, hiszen nem ismerik az adott üzleti folyamat mögötti szándékot, csak azt látják, hogy a kód szintaktikailag helyes és lefut. 

Miért emberközpontú a védekezés, és hol segít az AI?

A logikai hibák felismerése alapvetően emberközpontú feladat marad, hiszen ehhez meg kell érteni egy folyamat mögötti szándékot, üzleti célt és kontextust, ezt egy algoritmus önmagában nem látja át. A mesterséges intelligencia ugyanakkor egyre inkább partnerré válik ebben a munkában: felgyorsítja a felderítést, szokatlan bemeneteket javasol, segít feltérképezni az API-kat és a lehetséges felhasználói útvonalakat, így a tesztelő gyorsabban juthat el a valóban érdekes, gyanús esetekhez. A HackerOne 2025-ös jelentése szerint a megkérdezett biztonsági kutatók mintegy 70%-a már használ AI-alapú eszközöket a felderítés és a tesztelés felgyorsítására. Megszületett az úgynevezett "bionikus hacker" fogalma, aki az emberi kreativitást AI-sebességgel ötvözi. Ugyanakkor a kutatók 58%-a szerint az AI ma még nem veszi észre megbízhatóan az üzleti logikai hibákat vagy az egymásra épülő, láncolt támadási útvonalakat, és mindössze 12%-uk gondolja úgy, hogy a technológia a jövőben teljesen helyettesítheti az emberi munkát. Az AI tehát ma inkább gyorsító és segítő szerepet tölt be, nem önálló döntéshozót: annak megítélése, hogy egy viselkedés valóban visszaél-e a rendszer logikájával, továbbra is emberi belátást igényel. 

Számokban: mekkora valójában a probléma?

A logikai hibák üzleti súlyát jól mutatják a legfrissebb adatok is. A HackerOne kilencedik éves jelentése szerint a platformon futó bug bounty programok 2025-ben összesen 81 millió dollárt fizettek ki a résztvevő kutatóknak, ami 13%-os növekedés az előző évhez képest; a szervezetek a becslések szerint minden egy bounty-ra költött dollár után átlagosan 15 dollárnyi kárt kerültek el, ami összesen mintegy 3 milliárd dollár elkerült veszteséget jelent. A jelentés azt is jelzi, hogy a klasszikus, automatizált eszközökkel könnyen felderíthető hibák, mint a cross-site scripting vagy az SQL-injection aránya csökkenőben van a bejelentések között, miközben a jogosultsági és hozzáférés-vezérlési hibák, amelyek jellemzően logikai tervezési hiányosságokból fakadnak, egyre gyakoribbá válnak. Hasonló tanulságot hordoz a curl nyílt forráskódú projekt tapasztalata is: miután egyre több, AI által generált, felszínes hibabejelentés érkezett, a ténylegesen megerősített sérülékenységek aránya 5% alá esett Jó példa arra, hogy a bejelentések puszta mennyisége önmagában nem old meg semmit, a logikai hibák megbízható felderítéséhez továbbra is mélyebb, emberi szintű megértésre van szükség. 

1. Starbucks: az "ingyen kávé"

2015-ben egy biztonsági kutató mindössze néhány dollárnyi Starbucks ajándékkártyával mutatott rá egy súlyos logikai hibára. A kártyák közötti egyenlegátvezetés funkciója nem kezelte megfelelően, ha ugyanazt az átvezetést két böngészőből, szinte egy időben indították el.A rendszer mindkét kérést végrehajtotta, miközben az egyenleget csak egyszer vonta le. Az úgynevezett versenyhelyzet (race condition) kihasználásával elméletileg korlátlan mennyiségű egyenleg volt előállítható. A hiba nem az adatbázis felépítésében vagy a jogosultságkezelésben rejlett, hanem abban, hogy a fejlesztők nem számoltak azzal, mi történik, ha ugyanaz a művelet párhuzamosan, kétszer fut le. 

2. Az Ariane 5 rakéta: amikor a régi kód új környezetben hibázik

Az Európai Űrügynökség Ariane 5 rakétája 1996-os szűzindításakor néhány másodperccel a felszállás után szétesett. A vizsgálat kiderítette, hogy a hibát egy olyan szoftvermodul okozta, amelyet még a korábbi, lassabb Ariane 4 rakétához írtak, és amely egy nagy sebességértéket egy túl kicsi méretű változóba próbált beírni. A kód önmagában hibátlanul futott a korábbi rendszerben, a logikai hiba abban rejlett, hogy senki nem gondolta újra a feltételezéseket egy megváltozott üzemi környezetben. A hiba néhány másodperc alatt egy több százmillió dolláros rakéta és a rajta lévő műholdak elvesztéséhez vezetett. 

3. A DAO-eset: az okosszerződés, amely szó szerint azt tette, amit megírtak neki

2016-ban az Ethereum blokkláncon futó DAO nevű befektetési alap okosszerződéséből mintegy 60 millió dollár értékű kriptovalutát vontak ki egyetlen támadás során. A támadó nem tört fel semmilyen jelszót, és nem szerzett jogosulatlan hozzáférést. Egyszerűen kihasznált egy logikai sorrendi hibát: a szerződés előbb engedélyezte az újbóli pénzkivonási kérést, mielőtt frissítette volna a felhasználó egyenlegét, így ugyanaz a kivonás egymás után többször is lefuttatható volt. A kód pontosan azt csinálta, amire megírták, csak épp a tervezők nem gondoltak bele minden lehetséges végrehajtási sorrendbe. 

Hogyan csökkenthető a logikai hibák kockázata?

A jó hír az, hogy a logikai hibák nem elkerülhetetlenek, csupán más típusú odafigyelést igényelnek, mint a klasszikus, automatizált eszközökkel felderíthető sérülékenységek. 

1. Üzleti logika alapú tesztelés

A funkcionális teszteseteket nem elég a "helyes" felhasználói útra megírni. Érdemes szisztematikusan végiggondolni, mi történik szélsőséges, szokatlan vagy egyenesen rosszindulatú bemenetek esetén: negatív mennyiségek, üres mezők, túl nagy számok, vagy a lépések felcserélt sorrendje. 

2. Emberi szemmel végzett kódellenőrzés

A code review során nem csak a kód helyességét, hanem az üzleti szabályok tényleges érvényesülését is át kell tekinteni. Egy második fejlesztő szeme gyakran olyan feltételezésbeli hibát vesz észre, amit az eredeti szerző a saját logikájában már nem lát. 

3. Bevitel- és határérték-ellenőrzés minden rétegben

A kliensoldali validáció önmagában nem elég, hiszen könnyen megkerülhető. Minden kritikus üzleti szabályt szerver oldalon, az adatbázis-tranzakciók szintjén is érvényesíteni kell. 

4. Penetrációs tesztelés és bug bounty programok

Ahogy a fenti esetek is mutatják, a legsúlyosabb logikai hibákat jellemzően etikus hackerek, biztonsági kutatók vagy tapasztalt tesztelők találják meg, nem automatizált szkennerek. A rendszeres, célzott penetrációs tesztelés és a jól szabályozott bug bounty programok ezért nélkülözhetetlen kiegészítői a fejlesztési folyamatnak. 

5. Folyamatos monitorozás és anomáliadetektálás

Egyetlen védelmi intézkedés sem tökéletes. Érdemes olyan riasztási mechanizmusokat kiépíteni, amelyek jelzik, ha egy folyamat a szokásostól eltérő mintázatot mutat, például ugyanaz a tranzakció szokatlanul rövid időn belül többször lefut, vagy egy egyenleg a vártnál gyorsabban nő. 

A biztonság nem áll meg a szintaxisnál

A logikai hibák rávilágítanak arra, hogy a szoftverbiztonság nem merül ki abban, hogy a kód lefordul-e, és nem talál-e benne hibát egy automatizált eszköz. A valódi kockázat gyakran ott bújik meg, ahol a fejlesztő és az üzleti oldal feltételezései eltérnek a valóságtól. Ott, ahol a rendszer pontosan azt teszi, amire megírták, csak épp nem azt, amire szükség lenne. 

Éppen ezért a logikai hibák elleni védekezés nem egyetlen eszköz vagy egyetlen ellenőrzőlista kérdése, hanem szemléletmódé: a fejlesztőknek, tesztelőknek és biztonsági szakértőknek együtt, kreatívan kell végiggondolniuk, hogyan lehetne egy rendszert a tervezettől eltérő módon használni. Azok a szervezetek, amelyek ezt a szemléletet a fejlesztési folyamat szerves részévé teszik  (a kódellenőrzéstől a célzott penetrációs teszteken át a folyamatos monitorozásig), jóval kisebb eséllyel szembesülnek azzal, hogy egy apró, észrevétlen tervezési hiba komoly anyagi vagy biztonsági következményekkel jár.