NetAcademia

A legjobbakat tanítjuk!

Magyarországon is elérhető a biztonságos fejlesztés módszertana

2016. február 23. 17:57 - Fóti Marcell NetAcademia

Otthonok biztonsági kameráinak felügyeletét átvevő hackerek, banki vagy éppen Facebook-profil azonosítókat ellopó számítógépes bűnözök „munkáját” nehezítheti meg egy új, külföldön már bizonyított fejlesztési módszertan. A NetAcademia Oktatóközpontban mostantól hazánkban is elérhető Certified Secure Programmer képzés révén a webes, asztali, illetve mobil alkalmazások is biztonságosabbá tehetők.

Mark Zuckerberg Facebook-profiljának feltörése, egy biztonságikamera-gyártó megoldásának megkerülése, melynek köszönhetően több száz lakásról került ki élő videofolyam az internetre, mind friss példaként szolgálnak arra, hogy a programozók által elkövetett hibák milyen károkat tudnak okozni. A vállalatok tudják ezt, ezért egyre komolyabb erőforrásokat szánnak meglévő rendszereik biztonsági tesztelésére. Az EC-Council etikus hacker tanfolyamát hazánkban kizárólagosan képviselő NetAcademia Oktatóközpont adatai szerint például Magyarországon már közel 1000-en szerezték meg a Certified Ethical Hacking minősítést, melynek segítségével a már kész alkalmazásokban tárhatók fel a kritikus biztonsági rések. Ugyanakkor a tudatos megelőzés, a biztonsági rések fejlesztési fázisban történő kizárása egyelőre úgy tűnik, hogy nincs fókuszban.

Alapvető problémát jelent, hogy a fejlesztők képzése jellemzően nem terjed ki arra, hogyan készítsünk megbízhatóan működő, biztonságos alkalmazásokat, s ez a fajta tudás sokszor még elvárásként sem fogalmazódik meg a projektek, illetve az állásinterjúk során” – mondja Fóti Marcell, a NetAcademia Oktatóközpont ügyvezető igazgatója. Márpedig az, hogy valami biztonságos lesz-e, kizárólag a fejlesztőn, illetve az őt foglalkoztató vállalaton múlik.

60-szor többe kerül az utólagos javítás

Egy szoftver biztonsági réseinek utólagos betömése ráadásul rendkívül költséges. Ha egy kész, piacon lévő alkalmazásban kell a hibákat javítani, az iparági tapasztalatok alapján 60-szor kerül többe, mintha már a tervezés fázisában befoltoznák a kritikus lyukakat, s akkor még nem esett szó az okozott erkölcsi és anyagi károkról” – tette hozzá Balássy György, a tanfolyam oktatatója, a Microsoft regionális igazgatója. Így az etikus hacker tanfolyamokat is jegyző EC-Council adatai sem meglepőek, miszerint a kritikus biztonsági hibák 34 százaléka egyszerűen nem kerül javításra. Az EC-Council ezért egy új tanfolyamot és kapcsolódó minősítést dolgozott ki Certified Secure Programmer .NET néven, melynek keretében a biztonságos programozás módszertanát sajátíthatják el a résztvevők.

Hazánkban a NetAcademia Oktatóközpontban elérhető tanfolyam hallgatói megismerik a .NET keretrendszer és a ráépülő alkalmazások biztonsági szempontból gyenge pontjait, és elsajátítják a biztonságcentrikus alkalmazástervezés és -fejlesztés szemléletét. „A több mint 100 gyakorlati támadási technika kivédésén túl a fejlesztők így képessé vállnak arra, hogy már a rendszer tervezésének fázisában befoltozzák a potenciális biztonsági réseket” – mondta Fóti Marcell. A képzés 20 százalékban elméleti, 80 százalékban gyakorlati – konkrét programozási feladatok végrehajtását megcélzó – órákból áll, segítségével a webes, asztali, illetve mobilalkalmazások is biztonságosabbá tehetők.

TOP 10 webes támadási forma

A Certified Secure Programmer .NET tanfolyamot kidolgozó EC-Council adatai alapján a leginkább nagyvállalatok által használt .NET környezetben az alábbi támadástípusok a legelterjedtebbek. Ezek egytől egyig kivédhetők a biztonságos programozási ismeretek birtokában.

  1. Cross-Site Scripting (XSS): A leggyakoribb olyan hiba, ami akár úgynevezett „deface”-eléshez, vagyis a weboldal lecseréléséhez is vezethet. Ha látványos hackelést látunk, XSS-sérülékenység lehet a háttérben.
  2. Information leakage: Mások számára hozzáférhetetlen adatok elérhetősége illetéktelenek számára, trükkös adatlekérésekkel.
  3. Content spoofing: A támadó módosítja, meghamisítja a böngésző által megjelenített tartalmat, ezáltal például elhitetve a felhasználóval, hogy van még pénze a bankszámláján – miközben már rég leemelték a rendelkezésre álló összeget.
  4. Insufficient authorization: A fejlesztő rosszul valósította meg a jogosultságellenőrzést, így a támadó olyan helyekre is bejut, ahol nem lenne semmi keresnivalója. Jó példa erre egy ismert nemzetközi botrány, amikor egy földhivatali adatbázisba bárki vihetett fel új régiót a neten keresztül, ha tudta a megfelelő URL-t.
  5. SQL injection: A támadó egy adatbeviteli mezőbe úgynevezett SQL-kódot ír be, ami a szerveroldalon lefutva halálos sebet is ejthet az alkalmazáson.
  6. Predictable resource location: Megjósolható, hogy a (web)szerveren hol találhatóak a támadó számára értékes információk. Tipikus példa erre a Citibank weboldalának 2011-es feltörése, amikor egy URL-azonosító átírásával a felhasználók egymás bankszámlájában gyönyörködhettek.
  7. Session fixation: A támadó előre meghatározza az áldozat munkamenet-azonosítóját, így később könnyen el tudja téríteni a munkamenetet, meg tudja személyesíteni a felhasználót, eljárhat a nevében.
  8. Cross-site request forgery: A támadónak sikerül elérnie, hogy a felhasználó böngészője a felhasználó nevében, az ő jogosultságaival, de a tudta nélkül kommunikáljon egy webszerverrel.
  9. Insufficient authentication: A rosszul megvalósított bejelentkezés kijátszható, így a hacker esetleg valós bejelentkezés nélkül is hozzáfér a rendszer fizetős szolgáltatásaihoz.
  10. HTTP response splitting: A támadó megszakítja a webszervertől érkező HTTP választ, több részre bontja, amit azután a webböngésző hibásan dolgoz fel.

 

Kapcsolódó webcímek: 
A biztonságos programozás tematikája: http://www.netacademia.hu/Info/ECSP
Az EC-Council hivatalos ismertetője: http://www.eccouncil.org/Certification/ec-council-certified-secure-programmer-dotnet

Szólj hozzá!

A bejegyzés trackback címe:

https://netacademia.blog.hu/api/trackback/id/tr858399178

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.