Biztonságos programozás

A biztonságos programozás egy olyan szoftverfejlesztési  technika , amely megakadályozza a sebezhetőségek véletlen bejutását , valamint védelmet nyújt a rosszindulatú programokkal és az illetéktelen hozzáféréssel szemben . A szoftverhibák és logikai hibák a szoftversebezhetőség fő okai.

A biztonságos szoftver olyan szoftver, amelyet egy sor intézkedéssel fejlesztettek ki, amelyek célja a program sebezhetőségeinek megjelenése és megszüntetése [1] .

A biztonságos programozás feladata a felhasználói adatok megóvása a lopástól és sérüléstől, a rendszer feletti ellenőrzés fenntartása. A nem biztonságos programok potenciális célpontok a támadók számára, akik a meglévő biztonsági rések segítségével megtekinthetik, módosíthatják vagy törölhetik a meglévő információkat, befolyásolhatják a programok és szolgáltatások működését (indítás vagy leállítás), valamint rosszindulatú kódokat juttathatnak be a rendszerbe [2] .

Terminológia

Az angol szakirodalomban két kifejezést lehet biztonságos programozásnak fordítani.

A defenzív programozás egy olyan szoftverfejlesztési alapelv , amelyben a fejlesztők igyekeznek minden lehetséges hibát és meghibásodást figyelembe venni, azokat a lehető legnagyobb mértékben elkülöníteni, és ha lehetséges, meghibásodás esetén helyreállítani a program teljesítményét. Ez stabilabbá és kevésbé sebezhetővé teszi a szoftvert. Ennek az elvnek egy hardveres megvalósítása például egy watchdog időzítő , ellenőrzőösszeg számítás  - a csomag adatátviteli hibák észlelésére [3] .

A biztonságos kódolás egy technika olyan programok írására , amelyek ellenállnak a rosszindulatú programok és a behatolók támadásainak. A biztonságos programozás segít megvédeni a felhasználói adatokat a lopástól vagy a sérüléstől. Ezenkívül egy nem biztonságos program hozzáférést biztosíthat a támadónak a felhasználó szerverének vagy számítógépének vezérléséhez; A következmények az egy felhasználó szolgáltatásmegtagadásától az érzékeny információk kompromittálásáig , a szolgáltatás elvesztéséig vagy több ezer felhasználó rendszerének károsodásáig terjedhetnek [2] .

Fontosság

A rendszer biztonságának és működőképességének biztosításának kérdése a tervezési szakasz ( rendszertervezés ) szerves részét képezi) [4] . Az egyes informatikai termékekre és rendszerekre vonatkozó biztonsági követelményeket a meglévő és előre jelzett biztonsági fenyegetések, a követett biztonsági politika , valamint az alkalmazási feltételek figyelembevételével határozzák meg [5] . A biztonsági megoldások bevezetése a rendszer kifejlesztése után bonyolult és költséges. Ezért a biztonsági követelményeket kezdettől fogva figyelembe kell venni a rendszer teljes életciklusa során [4] .

Az információs rendszer fizikai és logikai szintre oszlik. Annak megértése, hogy pontosan mit kell védeni a külső tényezőktől, segít a védekezési intézkedések leghatékonyabb kiválasztásában és alkalmazásában. A szintek közötti világos határvonalat a fizikai határokkal rendelkező információs és információs technológiák bizonyos halmazát szabályozó biztonsági politikának kell meghatároznia . További bonyodalom, hogy ugyanaz a számítógép vagy szerver tud nyilvános és privát információkat is tárolni. Ennek eredményeként több biztonsági házirend is alkalmazható ugyanarra a gépre vagy ugyanazon a rendszeren belül. Ezért egy információs rendszer kidolgozásakor figyelembe kell venni a biztonsági határokat, és azokat a vonatkozó dokumentációban és rendszerbiztonsági szabályzatokban le kell írni [4] . Fejlesztőinek biztosítaniuk kell a rendszer biztonságát tervezés , fejlesztés , kezelés és konfigurálás , integráció során ., megfelelően tesztelje [6] .

Az elemzés (kézi vagy automatikus) és a biztonság költséges eljárás, amely növeli a szoftvertermékek összköltségét . Korábban a kockázatok teljes kiküszöbölése a biztonság közös célja volt. Ma már elismert tény, hogy minden kockázat kiküszöbölése nem költséghatékony. Minden javasolt ellenőrzési rendszer esetében költség-haszon elemzést kell végezni. Egyes esetekben a biztonságosabb rendszer előnyei nem indokolják a közvetlen és közvetett költségeket. Az előnyök nem csak a pénzbeli veszteségek megelőzését jelentik; Érdemes megfontolni például a hírnév elvesztését. A közvetlen költségek magukban foglalják a technológia beszerzésének és telepítésének költségeit; A közvetett költségek közé tartozik a rendszer teljesítményének csökkenése és az alkalmazottak további képzése [7] .

Alapelvek

Jelenleg számos technológia létezik a biztonságos szoftverek fejlesztésére . De van egy sor alapelv, amelyet minden megközelítés figyelembe vesz [8] :

Az utolsó négy minőség a megbízható számítástechnika (TwC) ( Eng.  Trustworthy computing ) („Computations that are trustworthy”) – a Microsoft Corporation kezdeményezéseinek alapja, amelynek fő feladata, hogy felhívja a fejlesztők figyelmét a ezen követelmények biztosítása a szoftverfejlesztés minden szakaszában [9] .

Számos szoftverbiztonsági elv létezik, amelyek többsége hasonló egymáshoz. Általánosításuknak tekinthetjük a fenti elveket [10] .

A sérülékenységek osztályozása és típusai

Osztályozók

A szabványosított biztonsági résleírások használata leegyszerűsíti az információbiztonsági szakemberek munkáját. Jelenleg számos népszerű osztályozó létezik [11] :

A modern kódelemzők és automatizált auditorok hasonló sebezhetőségi alapokat tudnak kihasználni. Ez növeli a termékbe vetett bizalom szintjét, és fontos lehet a szoftvertermékben található sebezhetőségekről szóló jelentéseknél is [13] .

Vannak más osztályozók is. A velük való munka során figyelni kell a szerzőkre, hiszen minden osztályozási rendszert e terület szakértőinek kell elkészíteniük [14] .

Metrikák

Minden program potenciális célpont a támadók számára. Miután az alkalmazásokban vagy szolgáltatásokban sebezhető pontokat találtak, megpróbálják felhasználni azokat bizalmas információk ellopására, adatok megsértésére, számítógépes rendszerek és hálózatok vezérlésére [15] . A sérülékenység tulajdonságainak leírására a szakértők a CVSS sebezhetőségi kockázati rendszert használják . Ez egy skála, amely alapján a pontszámokat adják. A mérőszámrendszert úgy alakították ki, hogy a sebezhetőségek kijavítását előnyben részesítse. Minden skála egy adott szemantikai szakaszra utal, amelyet metrikának neveznek. Három ilyen mérőszám létezik [16] [17] [11] :

Az utolsó két mérőszám segéd jellegű, és csak az alapmetrika mutatóinak beállítására szolgál, különféle sajátosságok figyelembevételével [18] .

A sérülékenységek típusai

A modern programok biztonságát veszélyeztető gyakori hibák listája [19] :

Lehetetlen felsorolni az összes ismert sebezhetőséget , mivel minden nap újak jelennek meg. Ez a lista olyan gyakori sebezhetőségeket tartalmaz, amelyeket könnyű elkövetni, de amelyek következményei katasztrofálisak lehetnek. Például a Blaster féreg terjedését mindössze két kódsoros hiba okozta [22] .

Védekezés

A hibák és sebezhetőségek elleni védekezés helyes stratégiája a megelőzés és a megelőzés. Ehhez a fejlesztőnek folyamatosan ellenőriznie kell a bemeneti adatokat. Például a puffertúlcsordulási támadások elleni védekezés legjobb módja annak biztosítása, hogy a bemeneti adatok ne haladják meg annak a puffernek a méretét, amelyben azokat tárolják. Az adatbázisba küldeni kívánt adatok ellenőrzést igényelnek a támadások, például az SQL-befecskendezés elleni védelem érdekében. Ha adatokat küldenek egy weboldalra, akkor azokat XSS ellen kell érvényesíteni . A túlzott számú ellenőrzés azonban megnehezíti a program forráskódjának fejlesztését, és új hibák megjelenéséhez vezethet, ezért ezt a stratégiát másokkal kell kombinálni [23] .

A hibavédelmi mechanizmusokat a fordítóprogram vagy az operációs rendszer biztosíthatja . A GCC fordító lehetővé teszi a _builtin_object_size () függvény használatával egy objektum méretét az objektumra mutató mutató segítségével, így használata biztonságosabbá teszi a másolási eljárást. Az MSVC a /RTCs jelző használatakor lehetővé teszi a fordítási idő ellenőrzését a helyi változók túlcsordulása, az inicializálatlan változók használata és a veremmutató-sérülések nem egyező hívási konvenciói miatt. A CRED (C range error detector) technológia és a verem védett szakasza előtti speciális betétek ( StackGuard , SSP ) alkalmazása részben lehetővé teszi a tömb túlcsordulásával és verem pusztításával kapcsolatos támadások észlelését és megelőzését [24] .

Az operációs rendszer a program végrehajtását is szabályozhatja. Ez a stratégia akkor lehet hasznos, ha a program forráskódja ismeretlen. Az ASLR (Address Space Schema Randomization) egy operációs rendszer biztonsági funkciója, amely megakadályozza tetszőleges kód futtatását. Az ASLR jelenleg Linuxon és Windowson is támogatott . A biztonsági szint növelése nem végrehajtható veremtechnológiák használatával érhető el: W^X, PaX [24] .

A webszolgáltatások elleni tipikus támadások az SQL injekció, az XSS, a CSRF és a clickjacking . A modern keretrendszerek segítenek a fejlesztőknek biztonságos webalkalmazások létrehozásában. A kész megoldások használata lehetővé teszi, hogy ne foglalkozzon a bejövő adatok számos ellenőrzésével: a HTTP kérések fejlécétől a tartalmukig. Biztonságosabb módszert biztosít az adatbázissal való munkavégzéshez is  - ORM [25] [26] .

Kár

A sebezhetőségekre vonatkozó információkat a támadók vírusok írására használhatják fel . Például az egyik első ismert hálózati féreg ( a Morris vírus ) 1988-ban kihasználta a Unix finger démon biztonsági réseit, például puffertúlcsordulást , hogy szétterjedjen a gépek között. Akkor a fertőzött autók száma körülbelül 6 ezer [27] volt , a gazdasági kár pedig az USA Számvevőszéke szerint 10 és 100 millió dollár között mozgott [28] .

2016 -ban a számítógépes vírusok 450 milliárd dolláros kárt okoztak a világgazdaságban [29] [30] .

2017-ben a WannaCry vírus okozta kárt 1 milliárd dollárra becsülték. Legalább 150 országban jelentettek fertőzést [31] [32] [33] . A vírus az EternalBlue exploitot használta, kihasználva az SMB protokoll puffertúlcsordulási sebezhetőségét [34] [35] [36] [37] .

Jegyzetek

  1. GOST R 56939-2016, 2016 , Kifejezések és meghatározások, pp. 2.
  2. 1 2 Bevezetés a biztonságos kódolási útmutatóba .
  3. Védekező programozás .
  4. 1 2 3 Mérnöki alapelvek az információtechnológiai biztonsághoz, 2004 , Biztonsági alapok. 2. alapelv, pp. 7.
  5. Informatikai biztonsági értékelési kritériumok, 2002 , Általános rendelkezések, pp. III-IV.
  6. Mérnöki alapelvek az információtechnológiai biztonsághoz, 2004 , Biztonsági alapok, pp. 6-8.
  7. Mérnöki alapelvek az információs technológia biztonságához, 2004 , Biztonsági alapok. 5. alapelv, pp. nyolc.
  8. Modern technológiák megbízható és biztonságos programok fejlesztéséhez, 2008 , pp. 25-26.
  9. Modern technológiák megbízható és biztonságos programok fejlesztéséhez, 2008 , pp. 26.
  10. Biztonságos programozás HOGYAN - Biztonságos szoftver létrehozása, 2015 , Biztonsági alapelvek, pp. 7-8.
  11. 1 2 Hacker magazin: Mérjük a sebezhetőségeket, 2009 , pp. 48-51.
  12. OSVDB: FIN, 2016 .
  13. Hacker Magazin: Sebezhetőségek mérése, 2009 , Osztályozók használata szkennerekben, pp. 51: „A modern automatizált auditorokat általában egy adott tudásbázisra szabják. Először is tekintélyes, másodszor pedig hasznos. Például, amikor valamelyik modern szabvány (NERC-CIP, PCI , FISMA, GLBA vagy HIPAA) szerinti tanúsításra készül, az adminisztrátor lehetőséget kap arra, hogy a könyvvizsgáló által kiállított dokumentumnak megfelelő mintajelentést kapjon.
  14. Hacker Magazin: Sebezhetőségek mérése, 2009 , Válogatott osztályozások, pp. 51: "Néha teljesen saját készítésű besorolásokat lehet látni a weben... Természetesen egy ilyen rendszernek nincs nagy súlya, mert valódi szakértőknek kell összeállítaniuk, akik értik a probléma lényegét."
  15. Bevezetés a biztonságos kódolási útmutatóba , egy pillantásra.
  16. Common Vulnerability Scoring System, 2006 , 86. o.
  17. CVSS: Specifikáció .
  18. CVSS: Specifikáció , 1.2. Pontozás: "Az alapmutató pontosítható időbeli és kontextuális mutatók kiszámításával, hogy jobban tükrözze a sebezhetőség által a felhasználó számára okozott kockázatot."
  19. A szoftverbiztonság 24 halálos bűne: programozási hibák és kijavításuk, 2009 , Bevezetés.
  20. Formátumkarakterlánc sebezhetőség keresési módszere, 2015 , Bevezetés: „Még a 90-es évek munkáiban is kimutatták, hogy a formátumkarakterlánc helytelen használata komoly szoftverbiztonsági sérülékenységekhez vezethet, például tetszőleges kódfuttatáshoz, jogosultságok kiszélesítéséhez és érzékeny adatok."
  21. The Protection of Information in Computer Systems, 1975 , h) Pszichológiai elfogadhatóság: „Nagyon fontos, hogy a felhasználói felület felhasználóbarát legyen, hogy a felhasználók intuitív módon és egyszerűen a megfelelő módon alkalmazzák a védelmi mechanizmusokat. Ha a felhasználó mentális ábrázolásai a védelmi célokról összhangban vannak a gyakorlatban használt mechanizmusokkal, a hibák száma minimálisra csökken. Ha a felhasználónak a védelemmel kapcsolatos elképzeléseit a specifikációk egy teljesen más nyelvére kell lefordítania, akkor elkerülhetetlenül hibázik.
  22. Biztonságos kódolás C és C++ nyelven, 2013 , 1.2. ábra. A W32.Blaster.Worm által kihasznált logika hibája: "A W32.Blaster.Worm féreg által kihasznált logikai hibák a 2. ábrán láthatók. 1.2. A hiba az, hogy a 21. és 22. sorban lévő while ciklus (amely a gazdagép nevének egy hosszú karakterláncból való kinyerésére szolgál) nincs eléggé lehatárolva."
  23. Biztonságos kódolás C és C++ nyelven, 2013 , 2.6 Futásvédelmi stratégiák: Bemeneti ellenőrzés.
  24. 1 2 Biztonságos kódolás C és C++ nyelven, 2013 , 2.6 Runtime Protection Strategies.
  25. Django Security .
  26. Ruby on Rails Security .
  27. Egy számítógépes víruskutató feljegyzései, 2005 , 3.1. táblázat, p. 90.
  28. Malware History, 2010 , The NSA versus Morris: $100 Million in Damage, p. 23.
  29. CNBC International: A kiberbűnözés 450 milliárd dollárjába kerül a világgazdaságnak .
  30. The New Paper: A kiberbűnözés tavaly 620 milliárd dollárjába került a világgazdaságnak .
  31. RBC: A WannaCry vírus okozta kárt 1 milliárd dollárra becsülték .
  32. 6abs: A WannaCry vírus okozta kár meghaladta az 1 milliárd dollárt .
  33. Hi-Tech Mail.ru: A szakértők rekord mennyiségű kárt neveztek meg a WannaCry vírustól .
  34. MS17-010: Az EternalBlue nagy, nem lapozható medencetúlcsordulása az SRV illesztőprogramjában .
  35. A WannaCry ransomware világszerte elterjedt támadásokban használatos .
  36. CNews: Vírusok gazdasági kárai .
  37. Nettó veszteségek: A kiberbűnözés globális költségének becslése .

Irodalom

További olvasnivalók

Linkek