A 25 legveszélyesebb programozási hiba listája

Bug

Több mint 30 nemzetközi vállalat és szervezet egyetértésével született meg az a lista, amely a 25 legveszélyesebbnek ítélt programozási hibát tartalmazza. Azokét a hibákét, amelyek olyan biztonsági problémákhoz vezethetnek, amelyeket a rosszindulatú támadók kihasználhatnak.

A Heise Security cikke szerint a listán szereplő hibák közül kettő is elég volt ahhoz, hogy több mint 1,5 millió betörést írjanak a számlájára 2008-ban. A hibák közül számos olyan van, amelyet a fejlesztők nem értenek elég jól, ezért a lista elkészítésének célja, hogy oktassa a fejlesztőket arra, hogy hogyan óvakodhatnak ezen hibáktól.

A kezdeményezés mögött a Mitre és a SANS intézet áll. A támogatást a US Homeland Security National Cyber Security Division-től és az NSA-tól kapták, amelyek részt vettek a lista összeállításában. A közreműködő vállalatok, szervezetek közt van a CERT, a Microsoft, az Oracle, a Red Hat, az Apple és Symantec.

A projekt hosszútávú céljai:

  • a szoftverek még biztonságosabbá tétele azáltal, hogy a gyártó igazolja, hogy szoftvere mentes a 25 legveszélyesebb bugtól
  • a szoftvereket tesztelő eszközök ismerjék fel ezeket a hibákat
  • az oktatók felkészítése arra, hogy még biztonságosabb programozási módszereket oktassanak
  • útmutató biztosítása a munkáltató számára, amelynek segítségével az el tudja dönteni, hogy a programozók ezen hibáktól mentes kódot írnak-e vagy sem

A munkacsoport a hibákat három kategóriába sorolta: nem biztonságos interakció a komponensek közt, rizikós erőforrás-kezelés, "porózus" védelemek.

A részletek itt olvashatók. A lista egészében megtalálható itt található.

( mogorva v | 2009. 01. 14., sze – 10:46 )

Nagyon helyes.
Tanítanak mostanság vhol olyasmit, hogy "Ezek azok a típushibák, amiket jó lenne elkerülni"? Vagy jöjjön rá majd mindenki a munkája során.

Jobb helyeken el szoktak mondani a temahoz kapcsolodo veszelyeket.
Pl. BME infon C-bol elhangzik a buffer overflow (eloadason, meg amig tartottam ott labort, addig laboron is biztosan). Adatbazisokbol az SQL injection-t is szoktak emlegetni (foleg a PHP-s laboron). Az "Improper Input Validation" tobb eloadason is elojon. A titkositas elonyei meg adatbiztonsag eloadason jon elo.
A BSC kepzessel nem vagyok tisztaban, de nekunk meg szerepeltek ezek. Nyilvan csak az epp temahoz kapcsolodo hibak, egy XSS sebezhetosegnek annyi koze van a C-hez, mint mondjuk a kozgazhoz.

Azert 25 felsorolt hiba legtobbje annyira gaz, hogy igazi tehetseg kell hozza, hogy valaki elkovessen ilyet.

--
I don't always dress in a T-shirt and jeans. Sometimes people give me awards, and I dress like a penguin instead. - Linus Torvalds

"BME infon C-bol elhangzik a buffer overflow (eloadason, meg amig tartottam ott labort, addig laboron is biztosan)"

Azert ez igy tulzas. Olyan szinten hangzik el (legalabbis nekunk ugy hangzott), hogy nem hasznalunk strcpy-t, mert irgumburgum, de azert ez igy eleg harmatos.
Masreszt meg C-ben sem csak stack overflow letezik (hanem pl. format string, integer overflow, double free, nullptr deref, race condition, ...), ezekrol egy szo sem esett.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

( takemeaw | 2009. 01. 14., sze – 11:01 )

eleg lett volna megkerdezni Hungert :)

( Botond | 2009. 01. 14., sze – 11:04 )

Ez tetszett: If you use security features that require good randomness, but you don't provide it, then you'll have attackers laughing all the way to the bank.

Ismerős: egyik munkahelyemen titkosítással is foglalkoztam. Olyan algoritmusokat használtunk, amelyeket 100 év alatt sem lehetett volna feltörni.

Az egyik okostojás meg amikor véletlen magot kellett generálni (128 byteos), kiolvasta az aktuális időt és feltöltötte vele.

Fél nap alatt feltörte egy biztonsági vállalat, mert megsaccolták, hogy mikor indulhatott el a szerver...

Nem mondom, jót röhögtem rajta.

( woodspeed | 2009. 01. 14., sze – 11:19 )

Ahogy gyorsan átfutottam, ugyanazt tartalmazza csak picit részletesebben, mint az OWASP top 10 listája, ami szintén a MITRE információin alapul. Ilyen kezdeményezést az OWASP a webes alkalmazásoknál már végez magyarázatokkal és megoldásokkal.
Akit még érdekelnek ilyen kimutatások azok itt még olvashatnak pár ilyen kimutatást: http://jeremiahgrossman.blogspot.com/2008/12/its-unanimous.html
Az OWASP címe meg: http://www.owasp.org/
Számomra egy kicsit zavaró, hogy most web alkalmazásokat nézünk vagy minden alkalmazást, de majd elolvasom lassan is.:)

( zsolt | 2009. 01. 14., sze – 13:51 )

Mivel konkrétan tartalmazza az egyes injection fajtákat, SMTP-injection-t nem ártott volna megemlíteni, mivel mostanában állítólag elég népszerű.

Arról van szó, hogy pl. email címként vagy névként a támadó komplett SMTP header-eket ad meg, aztán pl a regisztrációs levél helyett egy csomó spam megy ki.

Robotokkal elég jól lehet így spammelni regisztrációs oldalakon.