Ben megjelent tanulmány 2018. október az Empirical Software Engineering magazinban Sebastian Baltes és Stephan Diehl akadémikusok kiderült, hogy a kódrészlet a kérdésre adott válasz Verem túlcsordulás 2010 szeptemberében, Andreas Lundblad, Java fejlesztő a Palantirnél, ez a leggyakrabban használt Java kódrészlet a közösségi platformon.
Azonban, egy múlt heti bejegyzésben, Lundblad elmagyarázta, hogy a kód hibás, és helytelenül konvertálja a bájtok számát ember által olvasható formátumokban. A szóban forgó kód több mint ezer ajánlást halmozott fel, és számos projektben szerepel, és a GitHub adattáraiban körülbelül 7 ezerszer szerepel.
Figyelemre méltó, hogy a hibát a felhasználók nem találták meg akik ezt a kódot használták a projektjeikben, hanem a tipp eredeti szerzője.
A figyelembe vett kód olvasható formában konvertálta a bájtméretet, például 110592 konvertálta "110.6 kB" vagy "108.0 KiB". A kódot a korábban javasolt tanács variánsaként javasolták, logaritmusokkal optimalizálva, amelyben az értéket úgy határozták meg, hogy a ciklus kezdeti értékét elosztották «10 18, 10 15, 10 12, 10 19, 10 6, 10 3 és 10 0 " , akkor is, ha az osztó nagyobb, mint az eredeti érték bájtokban.
Az optimalizált verzió pontatlan számításai miatt (hosszú érték túlcsordulás), nagyon nagy számok feldolgozásának eredménye (exabájt) nem felelt meg a valóságnak.
Lundblad kifejtette, hogy a kód triviális konverziós hibát tartalmazott, amely csak kissé pontatlan fájlméret-becslést eredményezett. Ennek ellenére a becslések szerint ennél sokkal rosszabb lett volna.
A kód tartalmazhatott biztonsági rést, például. Ha ez lenne a helyzet, hónapokat vagy éveket kellett volna igénybe venni az összes sérülékeny alkalmazás kijavításával, támadásnak téve a felhasználókat.
A tanács szerzője megpróbálta felhívni a figyelmet a problémára példákat használni a forrás hivatkozása és licenc megadása nélkül.
„Több emberi kódolót érintő együttműködési munkamenetek során a CWE (Common Weakness Enumeration) utasításainak megfelelően manuálisan értékeltük az egyes kódrészeket a biztonsági rések szempontjából.
A legalább egy GitHub által üzemeltetett projektben használt 72,483 69 beolvasott kódrészletből összesen 29 sebezhető kódrészletet találtunk, amelyek XNUMX típusba sorolhatók. A vizsgált kódrészletek közül sok még nincs javítva "- állítják a kutatók jelentésükben.
A 69 sebezhető kódrészlet a Stack Overflow oldalon található összesen 2859 GitHub projektben használták fel újra. A Stack Overflow megosztott kódrészleteinek minőségének javítása érdekében kifejlesztettek egy böngészőbővítményt, amely lehetővé teszi a Stack Overflow felhasználók számára, hogy biztonsági réseket keressenek a kivonatokban, amikor letöltik őket a platformra.
A kutatók figyelmeztetése ellenére azonban a fejlesztők elemzés nélkül másolják a Stack Overflow kódot a projektjeikbe.
Ashkan Sami, informatikai docens, mérnöki és informatikai az iráni Shiraz Egyetemen mondta
„A kutatás kísérlet volt annak megvizsgálására, hogy a hibás kód miként kerül át a Stack Overflow-ról a GitHub-ra. Alapvetően azt próbáltuk megmutatni, hogy a Stack Overflow kód használata anélkül, hogy azt alaposan megvizsgálnánk, alkalmazás sebezhetőségéhez vezethet ”- mondta Sami. A tanulmány egy 2017-es tudományos cikkre is hivatkozik.
E cikk szerint a Stack Overflow-ra feltett 1161 bizonytalan kódrészletet használtak fel a Google Playen elérhető 1.3 millió Android-alkalmazásban.
Egy korábbi tanulmány mellett a fejlesztők 46% -a, akik a szerző megadása nélkül használták a StackOverflow kódot, 75% -a nem tudta, hogy a kód CC CC-SA licenc alá tartozik, és 67% nem tudta, hogy ez magában foglalja a hozzárendelés szükségességét.
Más tanulmányok adatai szerint a mintakód használata nemcsak a kód hibáinak kockázatával jár, hanem a sérülékenységekkel is.
Például a StackOverflow-on 72483 69 C ++ kódminta elemzése után a kutatók 0.09 mintában (ami XNUMX%) súlyos sérülékenységeket azonosítottak, amelyek szerepelnek a legnépszerűbb ajánlások listáján.
forrás: https://programming.guide