Sigurnost računarskih mreža (SRM)

1. Sigurnost računarskihmreža (SRM) • Tema: • Sigurnosni aspekti programiranja Sigurnosni aspekti programiranja

2. URLs: • Zvanična Web strana: • http://www.vets.edu.yu/smerovi/predmeti/SigurnostMreze.htm • Dodatni resursi: • http://www.conwex.info/draganp/teaching.html • Knjige: • http://www.conwex.info/draganp/books.html • Teme za seminarske radove: • http://www.conwex.info/draganp/SRM_seminarski_radovi.html Sigurnosni aspekti programiranja

3. Sigurnosni aspektiprogramiranja • Sadržaj poglavlja i predavanja: • 12.1 Uvodne napomene • 12.2 C/C++ i problem prekoračenja bafera • 12.3 Sigurnosni aspekti programiranja na jeziku Java • 12.4 .NET tehnologija i Security Development Lifecycle • 12.5 Zaštita softvera Sigurnosni aspekti programiranja

4. Potrebna predznanja • Programiranje • Za primenu: • Računarske mreže i protokoli • Operativni sistemi • Sistemsko programiranje • Strukture i modeli podataka, baze podataka Sigurnosni aspekti programiranja

5. Uopšteno o problemu • Pojam sigurne aplikacije odnosi se na • njenu otpornostprema različitim vrstama napada. • Poslednjih godinastatistike ukazuju na to • da se najviše sigurnosnih propustaodnosi na aplikacioni sloj. • Drugim rečima • pisanje sigurnogkoda je od vitalnog značaja • za održavanje sistemasigurnim. • Princip zatvorenog kôda • ne predstavlja ozbiljnuprepreku za napadača: • upotrebom disasemblera može seponovo doći do osnovnog kôda. • Nezaštićen program jetempirana bomba – • on funkcioniše dok su mu okolnostinaklonjene. • Ovakvo izlaganje igri slučaja • apsolutno jeneprihvatljivo • u bilo kojem ozbiljnom projektu. • Sigurnost sene sme zasnivati na spoljnoj sigurnosti mreže • na štetuunutrašnje sigurnosti kôda Sigurnosni aspekti programiranja

6. Uvodne napomene • Pravila „sigurnog programiranja“ • podrazumevaju određenaodstupanja • od programske jednostavnosti • a često i odnjegove efikasnosti • Argument za to je prilično ubedljiv: • uslučaju pada sistema, • do tada efikasan kôd više nikome nekoristi • Siguran kôd, između ostalog • korisnika štiti i odnjega samog • Neko može biti zloupotrebljen bez svogznanja i pristanka, • a da toga nije ni svestan • Takođe,sigurnost često rezultira • umanjenjem efikasnosti iperformansi • jednostavnosti i komfora • kao što je recimo islučaj sa sigurnošću u drugim oblastima • (vezivanje pojasau automobilu, • nošenje pancir prsluka ili šlema i slično) Sigurnosni aspekti programiranja

7. Kategorije napada • Prilikom projektovanja sigurne arhitekture za aplikaciju, treba uzeti u obzir moguće napade. Oni se mogu svrstati u sledeće kategorije: • 1. Subverzija aplikacije • Akcija koja prouzrokuje • izvršavanjenenameravane funkcionalnosti. • 2. Subverzija sistema i spoljnih aplikacija • Iskorišćavanjesigurnosnih propusta aplikacije • utiče na druge pokrenuteaplikacije ili sistemske resurse • Napad ne ugrožava samopokrenutu aplikaciju • nego se ta aplikacija često koristi i • kao kanal za napad na druge sisteme, aplikacije i operativnisistem. • Napadi ovog tipa često uključuju i izvršavanjedrugih aplikacija, • kao što je komandni interpreter uoperativnom sistemu UNIX, • ili iskorišćavanje veze koju jedruga aplikacija ostvarila sa mrežom. • 3. Prekidi funkcionalnosti • Svaki oblik odbijanja usluga, • ušta spada i grubo rušenje aplikacije. Sigurnosni aspekti programiranja

8. C/C++ i problemprekoračenja bafera • Bafer • memorijski prostor • ograničenog kapaciteta • predviđen zaskladištenje podataka. • Prekoračenje bafera • je anomalija • do koje dolazi kada proces ubafer upiše podatke • koji su zbirno veći od veličine tog bafera. • Posledica prekoračenja • je prepisivanje susednih memorijskihlokacija • tj. izmena vrednosti • upisanih u susedne memorijskelokacije. Sigurnosni aspekti programiranja

9. Prekoračenje bafera... • Podaci • koji su prepisani, tj. izmenjeni • mogu biti drugi baferi • promenljive ili podaci • koji obezbeđuju kontrolu toka programa. • Prekoračenje bafera • može izazvati krah • ili nepravilno izvršenjeprograma; • najčešća posledica je • ranjivost kôda • koju napadačimogu iskoristiti. Sigurnosni aspekti programiranja

10. Prekoračenje bafera... • Na primer: • prosleđivanjem određenog niza kao ulaznog podataka programu • napadač može prepuniti bafer • prepisati susedne memorijske lokacije • i omogućitiizvršenje (najčešće zlonamernog) kôda • podmetnutog u tom nizu. • Da bi u tomeuspeo: • napadač pažljivo formira ulazni niz karaktera • i precizno smešta novepodatke (povratnu adresu i kôd) • na određene adrese u memoriji • što dovodi doizvršavanja podmetnutog kôda. • U najgorem slučaju, • prekoračenje bafera • možedovesti do povećanja privilegija napadača • i kompromitovanja sistema (napadačpreuzima kontrolu nad računarom). Sigurnosni aspekti programiranja

11. Ozbiljnost • Godine 2001, crv poznat pod imenom Code Red slao je specijalne pakete ka serverima na kojima je pokrenut Microsoft Internet Information Services (IIS) 5.0, prouzrokujući prekoračenje bafera koje je crvu obezbeđivalo privilegije administratora (IIS5 je nespretno koristio administrativne privilegije neophodne za normalno pružanje servisa na TCP portu 80). • Godine 2003, crv SQLSlammer kompromitovao je računare na kojima je pokrenut Microsoft SQL Server 2000, izazivajući prekoračenje koje omogućava izvršenje podmetnutog koda; ovaj crv je, prema proceni kompanije Symantec, zarazio najmanje 22.000 računara. • Godine 2004. Sasser je, iskorišćavajući prekoračenje u LSA sigurnosnom podsistemu (Local Security Authority Subsystem Service) zarazio veliki broj računara na Internetu. Sigurnosni aspekti programiranja

12. Prekoračenje bafera... • Tehnički obrazovan zlonamerni korisnik koji je upoznat sa strukturom programa može iskoristiti prekoračenje bafera i izmanipulisati program na dva načina: • 1.prepisivanjem vrednosti promenljive koja je smeštena blizu bafera. • Tako se može izmeniti, na primer, vrednost nekog numeričkog podatka ili nekog drugog bafera, • što može dovesti do promene ponašanja programa u korist napadača. • 2.prepisivanjem povratne adrese na steku vrednošću koja pokazuje na adresu zlonamernog koda koji je podmenut. • Sledeći primer ilustruje ovaj način iskorišćenja slabosti. • Pretpostavite da napadač zna da će program prihvatiti svaki niz znakova sa ulaza i proslediti ga funkciji X koja će ga dalje iskopirati u bafer dužine 100 bajtova. • Napadač podmeće niz znakova dužine 104 bajta. Funkcija X će ovaj niz iskopirati u bafer i zahvaljujući četiri bajta viška, prepuniti ga i prepisati svoju povratnu adresu. • Nova povratna adresa ukazivaće na podmetnuti izvršni kôd, tj. na preostalih 100 bajtova smeštenih na steku. Sigurnosni aspekti programiranja

13. Stack prekoračenje Sigurnosni aspekti programiranja

14. Ranjive funkcije • Do prekoračenja bafera najčešće dolazi zbog lošeg rada sa znakovnim nizovima, a sledeće funkcije ga najčešće izazivaju na steku: • char *gets (char *buffer) – funkcija preuzima znakovni niz sa ulaza i smešta ga u promenjivu buffer, • char *strcpy(char *strDestination, const char *strSource) – funkcija kopira sadržaj promenjive strSource u promenljivu strDestination, • char *strcat (char *strDestination, const char *strSource) - funkcija dodaje jedan znakovni niz na kraj drugog niza koji se nalazi u baferu, • int sprintf (char *buffer, const char *format [, argument] ...) - ponaša se slično funkciji printf, s tim što je izlaz bafer a ne ekran. • Razmotrite, na primer, sledeću funkciju: • void func(char *str) • { • char buf[126]; • strcpy(buf,str); • } • Ukoliko je znakovni niz str duži od 126 znakova, biće pregaženi podaci na steku koji slede posle niza buf. Povratna adresa, koja se takođe nalazi na steku, može biti pregažena – i to specijalnom adresom koja označava početak nekog drugog, zlonamernog koda. Osnovni problem navedenog koda je funkcija strcpy(buf,str) koja kopira niz str u niz buf sve dok u nizu str ne dođe do „\0“ - što predstavlja oznaku za kraj znakovnog niza. Funkcija ne obraća pažnju na veličinu niza Sigurnosni aspekti programiranja

15. Sprečavanje • Najbolji način za sprečavanje prekoračenja bafera jeste pisanje pouzdanog koda u kome se proverava veličina svih ulaznih podataka prilikom poziva određenih funkcija. • Na primer, funkcija strcpy() ne obezbeđuje nikakvu sigurnost u kodu koji se piše, pa je zbog toga treba ređe koristiti. Ova funkcija je bezbedna samo kada se koristi u trivijalnim slučajevima, kao što je kopiranje znakovnog niza fiksne dužine u bafer. Sledeći kôd prikazuje kako se ova funkcija može bezbedno koristiti: • bool HandleInput(const char* input) { • char buf[80]; • if(input == NULL) { assert(false); return false; • } • if(strlen(input) < sizeof(buf)) strcpy(buf, input); • else return false; • return true; • } • Funkcija gets() je još jedna od nebezbednih. Ona čita podatke sa glavnog ulaza sve dok ne naiđe na znak “Line Feed” (0x10 – ’\n’) ili “Carriage Return” (0x13) . Ne postoji način da se sazna kada će se prekoračenje bafera pojaviti, pa ovu funkciju ne treba koristiti. Umesto nje se može upotrebiti funkcija fgets() ili C++ objektne funkcije za rad sa znakovnim nizovima. Sigurnosni aspekti programiranja

16. Prekoračenje celobrojnih vrednosti • Važno je napomenuti • da prekoračenje celobrojnih vrednosti ne vodi direktno • do prepisivanja određene memorijske lokacije • kao pri klasičnom prekoračenju bafera, • nego je opasno ukoliko se celobrojne vrednosti • koje su izazvale prekoračenje • koriste za određivanje veličine bafera pri radu sa funkcijama za kopiranje znakovnih nizova • kao što su: • memcpy() • strncpy() • sprintf() • memset() • itd. Sigurnosni aspekti programiranja

17. Java i C# - jezici bez prekoračenja • Kao što je već rečeno, do prekoračenja bafera ne može doći ukoliko je softver napisan na programskom jeziku Java. Da biste prepunili bafer, potrebno je da pokazivač pokazuje na nerezervisani deo memorije – na primer, na neku lokaciju van opsega koji je rezervisan za neki niz. • Međutim, Java jednostavno ne dozvoljava smeštanje podataka u memoriju koja prethodno nije na ispravan način alocirana (rezervisana). • U programskom jeziku C#, mogućnosti prekoračenja bafera takođe su svedene na minimum. • Microsoft je u integrisanom razvojnom okruženju .NET posvetio veliku pažnju sprečavanju problema prekoračenja bafera. • Ukoliko želite da pročitate nešto više o prekoračenju bafera i uopšte o sigurnosnim aspektima programiranja, preporučujemo vam knjige „Writing Secure Code, Second edition“ (Michael Howard i David LeBlanc) i „The Security Development Lifecycle“ (Michael Howard, Steve Lipner), u izdanju Microsoft Press-a. Sigurnosni aspekti programiranja

18. Vežbe • Detalji vezani za prekoračenje bafera, kao i praktičniprimeri, se obrađuju na vežbama iz ovog predmeta • Takođe, detaljniji opisi i objašnjenja se mogu naći u knjizikoja prati predmet i predavanja: • D. Pleskonjić, N. Maček, B. Đorđević, M. Carić: “Sigurnost • računarskih sistema i mreža”, Mikro knjiga, Beograd, 2007., ISBN: • 978-86-7555-305-2, knjiga – udžbenik • http://www.conwex.info/draganp/books_SRSiM.html • http://www.mk.co.yu/store/prikaz.php?ref=978-86-7555-305-2 Sigurnosni aspekti programiranja

19. Sigurnosni aspektiprogramiranja na jeziku Java • Programski jezik smatramo sigurnim ako obezbeđuje sledeće: • 1. otpornost prema zlonamernim programima • koji opterećuju resurse ili kraduinformacije • npr. trojanskim konjima ili virusima • 2. proveru identiteta strana koje komuniciraju • 3. mogućnost šifrovanja primljenih i poslatih podataka • 4. programski zahtevi ne smeju previše okupirati raspoložive resurse • 5. onemogućavanje zloupotreberegularnih naredbi jezika • u cilju opstrukcijenormalnog rada operativnog sistema • Java je programski jezik koji je nastao sa idejom da, između ostalog, odgovori i na navedene zahteve Sigurnosni aspekti programiranja

20. Sigurnosni aspektiprogramiranja na jeziku Java • Apleti su Java programi • koji se pozivaju iz Web čitača • i namenjeni su zakorišćenje na Internetu. • Kada stignu u korisnikov sistem, • apleti se smeštaju u poseban kontejner –takozvani sandbox– • koji predstavlja okruženje • u kome su dozvoljenasamo određena prava. • Postoji više vrsta takvih kontejnera s minimalnim ili prilično širokim pristupom resursima. • Javina virtuelna mašina • (Java Virtual Machine, JVM) • predstavlja Javaizvršno okruženje • Zahvaljujući njoj, prevedeni oblik programa može se izvršavati pod različitim operativnim sistemima. Potrebno je samo da za svaki operativni sistem postoji odgovarajaća JVM. • JVMje deo okruženja JRE • (Java Runtime Environment), • koje sadrži i nekeosnovne klase, • tj. klase koje pripadaju jezgru Jave (engl. core). • JRE ne sadrži prevodilac (engl. compiler) i program za otkrivanje grešaka (engl. debugger). Javin izvorni kôd prevodi se pomoću prevodioca javac i konvertuje u bajtkod (engl. bytecode) koji ne zavisi od platforme. Sigurnosni aspekti programiranja

21. Java platforma • Java raspolaže izuzetno bogatom familijom klasa koje služe kao posrednici između Java datoteka (aplikacije, apleti, servleti, zrna, JSP stranice) i Javine virtuelne mašine. • Taj skup gotovih klasa nazivamo interfejs za programiranjeaplikacija (engl. Application Programming Interface, API) Sigurnosni aspekti programiranja

22. Veza Jave i operativnog sistema-JVM Sigurnosni aspekti programiranja

23. JVM • Javinu virtuelnu mašinu čine tri komponente: • 1. Program za učitavanje klasa (engl. class loader) - Java klasa sa specijalnom funkcionalnošću, odgovorna za punjenje Javine virtuelne mašine bajtkodom. Dozvoljava ili odbija punjenje JVM bajtkodom. • 2. Verifikator bajtkoda (engl. class file verifier, bytecode verifier) služi za verifikaciju bajtkoda pre nego što se preda JVM. Drugim rečima, proverava se da li bajtkod sledi pravila jezika. Sve klase koje pripadaju jezgru Jave ili su instalirane na lokalnoj mašini, prestavljaju proverene (engl. trusted) klase. Sve ostale se tretiraju kako neproverene i moraju da se verifikuju. • 3. Upravljač sigurnosti (engl. security manager) proverava da li zahtev za sistemskim resursima može biti odobren. Ako zahtev nije odobren, javlja se izuzetak java.lang.SecurityException. Sigurnosni aspekti programiranja

24. Java Sigurnost-JVM • Spomenućemo još četiri pojma značajna za sigurnost: • 1. Kontroler pristupa (engl. access controller) – upravlja pristupom operativnom sistemu,za osnovne Java datoteke. • 2. Sigurnosni paket (engl. security package) – sadrži klase iz paketa java.security koje služe za proveru identiteta, tj. digitalni potpis. • 3. Baza ključeva (engl. key database) – označava sinonim za Keystore. • 4. Policy– alat koji služi za pristup datoteci sa pravilima. • U njoj su definisana prava pristupa sistemskim resursima • u zavisnosti od toga • da li je posmatrani kôd • lokalni ili potiče sa udaljene lokacije. Sigurnosni aspekti programiranja

25. Završne napomene za JAVU • Atributi klase ne treba da budu javni, već privatni, a u najgorem slučaju zaštićeni. Pristupa im se preko javnih metoda. • Čak bi i metode trebalo da budu privatne kad god je to moguće. Svaka metoda koja postoji samo da bi je koristile druge metode, treba da bude privatna. • Trebalo bi izbegavati upotrebu statičkih promenljivih jer su one pridružene klasi, a ne pojedinačnom objektu. Kako se do te klase može doći preko drugih klasa, samim tim se može doći i do statičkih promenljivih. • Nikad ne treba vraćati promenljiv objekat kao rezultat. Nizovi spadaju u promenljive objekte, pa nikako ne treba vraćati reference na njih jer to automatski znači pristup privatnim podacima. • Treba koristiti modifikator final (koji označava nepromenljivost objekta), sem ako postoje dobri razlozi za suprotno. Ukoliko klasa ili metod u njoj nije final, moguće je naslediti klasu ili redefinisati metodu, što napadaču daje nove mogućnosti. • Paketska dostupnost nije nikakva garancija sigurnosti, jer napadač može u paket ubaciti novu klasu preko koje su dostupni i ostali delovi paketa. • Upotrebu unutrašnjih klasa treba izbegavati jer kada se prevedu u bajtkod, postaju dostupne ostalim klasama u paketu. Takođe, privatna polja u okružujućoj klasi mogu postati dostupna preko unutrašnje klase. • Klase treba učiniti otpornim na kloniranje. Sigurnosni aspekti programiranja

26. Vežbe • Detalji vezani za sigurnosne aspekte programiranja najeziku Java, kao i praktični primeri, se obrađuju navežbama iz ovog predmeta • Takođe, detaljniji opisi i objašnjenja se mogu naći u knjizikoja prati predmet i predavanja: • D. Pleskonjić, N. Maček, B. Đorđević, M. Carić: “Sigurnost • računarskih sistema i mreža”, Mikro knjiga, Beograd, 2007., ISBN: • 978-86-7555-305-2, knjiga – udžbenik • http://www.conwex.info/draganp/books_SRSiM.html • http://www.mk.co.yu/store/prikaz.php?ref=978-86-7555-305-2 Sigurnosni aspekti programiranja

27. .NET tehnologija i SecurityDevelopment Lifecycle • Microsoft je bio predmet velikih kritika • u pogledu sigurnosti • njegove familije operativnih sistema Windows • kao i ostalihsoftverskih proizvoda i alata • i integrisanih okruženja zarazvoj softvera. • Tokom 2002. godine osnivač i direktorMicrosofta • Bill Gates je pokrenuo takozvanu • TrustworthyComputinginicijativu • koja je trebala da doprinese • poboljšanju sigurnosti Micorosoft proizvoda • Sa konceptom .NET i integrisanim razvojnim okruženjima koje je Microsoft izdao pod nazivom Visual Studio .NET, mnoge stvari su se promenile. Većina programera danas voli i koristi tehnologiju upravljanog (engl. managed)koda. Za većinu C++ programera ova tehnologija je bila zbunjujuća. Sigurnosni aspekti programiranja

28. .NET tehnologija i upravljanikod • Tehnologija upravljanog (engl. managed) kôda • Virtuelna mašina = Microsoftov .NET Framework • Common Language Runtime(CLR) • ili neka druga implementacija CLI specifikacije • (Monoprojekat ili DotGNU projekat) • CLR je Microsoftova implementacija CLI specifikacije. • Posredni jezik (engl. Intermediate Language, IL) • Neupravljani kôd (engl. unmanaged code) Sigurnosni aspekti programiranja

29. upravljani (engl. managed) kôd • U Microsoftovoj Windows terminologiji, upravljanikôd su računarske instrukcije koje se izvršavaju na virtuelnoj mašini usklađenoj sa CLI specifikacijom, kao što je Microsoftov .NET Framework Common Language Runtime(CLR) ili neka druga implementacija CLI specifikacije (Mono projekat ili DotGNU projekat). • Prevodioci za Visual Basic .NET (VB.NET) i C#proizvode samo upravljanikôd. Visual C++ .NET takođe može da napravi upravljanikôd – potrebno je da, kada pravite projekat, odaberete jednu od aplikacija čije ime počinje sa .Managed (na primer, .Managed C++ aplikacija). • Upravljani kôd je kôd na takozvanom posrednom jeziku • (engl. Intermediate Language, IL), • tj. nije mašinski kôd koji se može direktno izvršiti na računaru. • IL se smešta u datoteku koji se zove assembly, • zajedno s metapodacima koji opisuju klase, metode i atribute • (kao što su sigurnosni zahtevi) kôda koji ste kreirali. Sigurnosni aspekti programiranja

30. upravljani (engl. managed) kôd • Za razliku od upravljanog koda, neupravljani kôd (engl. unmanaged code) prevodi se direktno u mašinski kôd koji se izvršava na računaru na kom je preveden, ili na drugim računarima koji imaju procesor iz slične familije. • Taj kôd ne dobija uslugepoput sigurnosti i upravljanja memorijom od nekog nevidljivog izvršnog okruženja (engl runtime), već od operativnog sistema. Još važnije, on te usluge dobija ukoliko ih eksplicitno zatraži, obično pozivajući API koji obezbeđuje Windows SDK. Novije neupravljaneaplikacije dobijaju usluge operativnog sistema kroz COM pozive. Za razliku od ostalih Visual Studio .NET jezika, Visual C++ može da proizvede i neupravljani kôd. Kada pravite projekat i odaberete tip aplikacije čije ime počinje sa MFC, ATL ili Win32, vi u stvari pravite neupravljanuaplikaciju. • Da pojednostavimo – kada pravite .Managed C++ aplikaciju, proizvod je assembly datoteka sa nastavkom .exe, u koju su smešteni IL i metapodaci. Kada pravite MFC aplikaciju, proizvod je Windowsova izvršna datoteka s mašinskim kodom i, takođe, nastavkom exe. • Međutim, interna struktura ove dve datoteke potpuno je različita. Da biste pokrenuli upravljanu aplikaciju, neophodna je CLI virtuelna mašina, dok za pokretanje MFC aplikacije ona nije neophodna. • Unutrašnjost assembly datoteke (IL i metapodatke) možete pogledati pomoću IL disasemblera. Ukoliko probate da otvorite neupravljanu aplikaciju ovim disasemblerom, dobićete poruku da ona nema validno CLR zaglavlje. Sigurnosni aspekti programiranja

31. upravljani (engl. managed) kôd • Kada počnete da razvijate upravljanuaplikaciju, onda ste u prednosti jer upravljani kôd ima ugrađenu sigurnost kao obavezan deo. • Zaštitni mehanizmi su uključeni na pravim mestima, a skoro svaki API pozivprolazi kroz neku sigurnosnu proveru. Bitno je naglasiti da se ovde ne podrazumeva da će svemu što se prevede biti data dozvola da se i pokrene i izvrši. Mogu se uvesti različita ograničenja za različite situacije. • Na primer, u tradicionalnoj Windows NT sigurnosnoj politici odlučuje se da li će se nešto izvršiti ili ne, na bazi toga koji korisnik pokreće aplikaciju. • U .NET-u se ove odluke donose na osnovu identiteta koda, a ne na osnovu korisnika i to se zove Code Access Security (CAS). • To znači sledeće: da bi se odredilo sme li neki kôd da se izvrši ili ne, proveriće se stvari kao što su: odakle kôd dolazi, ima li identifikaciju koja pokazuje ko je njegov autor (npr. Authenticode certificate), koja je heš vrednost koda tj. da li je neovlašćeno menjan itd. To ne znači da je Windows sigurnost preskočena, naprotiv – ona i dalje važi. Ali .NET Security je dodatna nezavisna dimenzija koja „ograđuje“ sistem i štiti od pretnji i napada. Sigurnosni aspekti programiranja

32. Security DevelopmentLifecycle • Trustworthy Computing Security Development Lifecycle • uslobodnom prevodu – • životni ciklus razvoja softvera sa osvrtomna sigurnost • je proces razvoja softvera razvijen u Microsoftu. • Autori knjige „The Security Development Lifecycle“, • MichaelHoward i Steve Lipner, • radili su na konceptu koji je dobio ovo ime, • a poznat je pod skraćenicom SDL. Sigurnosni aspekti programiranja

33. Security DevelopmentLifecycle SDL • Ovaj koncept vodi kroz sve faze razvoja softvera • uključujući iobrazovanje i usmeravanje projektanata i programera, • projektovanje, razvoj, testiranje, isporuku (objavljivanje) iodržavanje, • tj. proces posle objavljivanja (engl. post-release). • Koncept podrazumeva analizu • mogućih napada i izloženosti • i prepočetka projektovanja aplikacije • kao i procenu rizika. • SDL navodi • listu zabranjenihAPI funkcija • koje mogu prouzrokovatisigurnosne probleme • i koje treba vremenom ukloniti iz nasleđenogkoda Sigurnosni aspekti programiranja

34. Standardni Microsoft procesrazvoja softvera • Standardni Microsoft proces razvoja softvera • obuhvata sledećefaze: • analiza zahteva (spisak zahteva, smernice za obezbeđivanjekvaliteta, dokumentovanje arhitekture projekta i formiranjepreliminarnog rasporeda) • projektovanje (specifikacije strukture i funkcionalnosti) • razvoj (razvoj novog kôda uz povremene provere i testiranje koda) • testiranje (provera kôda i ispravka grešaka) • objavljivanje (potpisivanje kôda i isporuka gotovogproizvoda) • održavanje i servisiranje (tehnička podrška krajnjimkorisnicima, sigurnosne zakrpe i servisni paketi) Sigurnosni aspekti programiranja

35. Standardni Microsoft procesrazvoja softvera Sigurnosni aspekti programiranja

36. SDL unapređenja • SDL unapređenja standardnog Microsoftovog procesa razvoja • (po fazama) susledeća: • Analiza zahteva. • Obuka članova razvojnog tima, • dodela savetnika za sigurnost, • razmatranje kakoće sigurnost biti implementirana u razvojni proces, • identifikacija ključnih sigurnosnih ciljeva, • razmatranje mogućnosti za uvećanje sigurnosti • uz što manje ometanje plana i rasporeda razvoja. • Projektovanje. • Definisanje globalne strukture softvera • posmatrane sa stanovišta sigurnosti. • Modeliranje pretnji. • Identifikacija i dokumentovanje komponenti i elemenata • čije je funkcionisanjeključno za sigurnost. • Ovim komponentama se dodeljuje najmanji mogući skup privilegija • neophodnih za izvršavanje Sigurnosni aspekti programiranja

37. SDL unapređenja • Razvoj. • Sprovođenje standarda za kodiranje i testiranje. • Programeri ne smeju da koriste funkcije iprocedure • koje mogu dovesti do sigurnosnih propusta. • Na primer, umesto funkcija za rad sanizovima • koje ne obraćaju pažnju na veličinu niza • koriste se sigurnije funkcije koje ne mogu dovesti • do ranjivosti tipa prekoračenja bafera. • Kôd se testira na više načina – • upotrebom takozvanih„fuzzing“ alata • (alati koji proizvode strukturiran ali neispravan ulaz za API • i mrežne funkcije • i na tajnačin pomažu u otkrivanju grešaka • koje mogu da dovedu do ranjivosti), • upotrebom alata zastatičku analizu kôda • (kao što su PREfix i PREfast) • i sprovođenjem revizije kôd • (razvojni tim „ručno“proverava izvorni kôd • i traži moguće sigurnosne propuste). Sigurnosni aspekti programiranja

38. SDL unapređenja • Testiranje. • Softver koji je funkcionalno kompletan • ulazi u takozvano preliminarno testiranje • (engl.beta testing). • Tokom ove faze • razvojni tim testira mogućnost proboja koda, • tj. reviziju koda koja jeznatno detaljnija • od one koja se obavlja u fazi razvoja • i prevashodno je usmerena na sigurnost. • Microsoft ovo testiranje opisuje terminom „security push“. Sigurnosni aspekti programiranja

39. SDL unapređenja - nastavak • Objavljivanje. • U fazi objavljivanja, • softver je izložen konačnoj sigurnosnoj proceni • (engl. FinalSecurity Review, FSR). • Cilj FSR je davanje odgovora na pitanje • „Da li je, posmatrano sa stanovištasigurnosti, softver spreman za isporuku krajnjim korisnicima?“ • Softver mora da bude u stabilnomstanju pre obavljanja FSR, • što znači da se u softveru mogu obaviti samo manje kozmetičke izmene, • ali nikako funkcionalne ili one koje se tiču sigurnosti. • FSR najčešće obavlja tim stučnjaka razvojnekompanije zadužen za sigurnost. • FSR nije situacija tipa „prošao/pao“, • niti za cilj ima otkrivanje svihsigurnosnih propusta, • već treba rukovodstvu kompanije da stvori sliku o implementaciji sigurnosti • uproces razvoja softvera • i da proceni kako će softver isporučen kupcima reagovati na napade. Sigurnosni aspekti programiranja

40. SDL unapređenja - nastavak • Ukoliko se u ovoj fazi pronane neka ranjivost • onda je potrebno da se, osim ispravljanja, • otkrijeuzrok u ranijim fazama razvojnog procesa • koji je doveo do tog sigurnosnog propusta. • Na osnovumože da se odredi da li je potrebno, • na primer, da se pojača obuku razvojnog tima vezana zasigurnost • ili da se promene alati za testiranje ranjivosti. Sigurnosni aspekti programiranja

41. SDL unapređenja - nastavak • Održavanje i servisiranje. • Sigurnost je proces, a ne završno stanje ili proizvod. • Čak i ako su uprethodnim fazama razvojnog procesa • uklonjeni svi sigurnosni propusti, • moguće je da će nakonobjavljivanja i isporučivanja softvera • biti otkrivene nove vrste napada, • odnosno da će softver koji jese u fazi objavljivanja • pokazao kao „siguran“ vremenom postati ranjiv. • Razvojni tim mora bitispreman da odgovori • na novootkrivene ranjivosti i da potrošačima, • tj. krajnjim korisnicima navreme isporuči • sve potrebne sigurnosne zakrpe koje će ukloniti te ranjivosti. • U ovoj fazi razvojnitim i tim stručnjaka zaduženih za sigurnost • uočavaju elemente koji su omogućili da softver postaneranjiv – • na osnovutoga, razvojni proces se modifikuje • tako da se spreči pojava ovakvih ranjivosti usoftveru • koji će se razvijati u budućnosti. Sigurnosni aspekti programiranja

42. SDL unapređenja - nastavak Sigurnosni aspekti programiranja

43. Zaštita softvera • Metode zaštite softvera • Zaštita softvera obuhvata softverske i hardverske metode. One se uglavnom svode na neku vrstu provere identiteta korisnika. Korisnik mora imati određen hardverski uređaj koji se spaja s računarom, ili neku šifru ili datoteku za registrovanje koja se od njega traži prilikom instaliranja programa. Po pravilu, podaci se čuvaju šifrovani. • Zaštita CD-a od kopiranja • Ključ za registraciju • Autorizacija • Zaštita programa pomoću registracione datoteke • Dongle Sigurnosni aspekti programiranja

44. Zaštita CD-a od kopiranja • Najjednostavniji oblik zaštite svodi se na proveru prisustva ispravnog CD-a u CD čitaču. Na taj način se može sprečiti kopiranje i pokretanje programa sa čvrstog diska računara, ali je nemoguće razlikovati originalni od ilegalno kopiranog CD-a. Pomenuti postupak ipak nije bezvredan jer sprečava uklanjanje sa originalnog CD-a slika, animacija, zvukova, DirectX upravljačkih programa i ostalih delova koji zauzimaju puno prostora a nisu neophodni za rad programa(najčešće neke igre). • Moguće je, takođe, namerno oštetiti CD na pogodno izabranom mestu, što može sprečiti njegovo kopiranje. Ipak, ta metoda nije preporučljiva jer razni korisni podaci mogu biti razbacani na disku, što znači da se oni ipak mogu pročitati. • Mnogo bolje rešenje je šifrovanje podataka, mada to onda remeti jednostavnost upotrebe. • Komplikovanije zaštite protiv kopiranja CD-a snimaju na njega informacije koje je nemoguće kopirati pomoću trenutno dostupnog softvera. Sigurnosni aspekti programiranja

45. Ključ (šifra) za registraciju • Verovatno najjednostavniji oblik zaštite je ugrađivanje programske funkcije koja od korisnika zahteva da unese određeni ključ za registraciju (engl. registration key). • Ta vrednost je uvek ista i ne zavisi ni od kakvih parametara kao što su korisnički podaci ili podaci o korisnikovom računaru. Pri takvoj zaštiti je dovoljno da pirat jednom pronađe registracionu šifru i objavi je na Internetu pa da svako može besplatno registrovati taj softver. • Najčešći način probijanja zaštite zasnovane na ključu za registraciju jeste prepravljanje dela koda za proveru šifre tako da se potpuno zaobiđe provera pa program normalno nastavlja s radom. • Da bi se sprečilo takvo probijanje zaštite, moguće je koristiti registracioni ključza dešifrovanje delova programskog koda. Ukoliko je deo koda šifrovan pomoću registracionog ključa, onda ga je moguće dešifrovati samo pomoću tog istog ključa. Čak i ako pirat uspe da premosti algoritam za proveru ključa prilikom upisivanja, program još uvek neće ispravno raditi. Šifrovani deo koda može se dešifrovati u memoriji neposredno pre nego što korisnik pokrene tu funkciju, a kada funkcija više nije potrebna – ponovno se šifruje. Ako program ima nekoliko šifrovanih delova, onda će najviše jedan od njih biti dešifrovan u memoriji u svakom trenutku, što piratima onemogućava snimanje dešifrovanog programskog koda iz memorije. Sigurnosni aspekti programiranja

46. Ključ za registraciju • Bolji način zaštite je generisanje registracione šifre pomoću parametara koji su sakupljeni iz podataka o korisniku ili tajno prikupljeni iz parametara korisnikovog računara. • Ovakav program generiše šifru iz korisničkih podataka i koristi podatke poput korisničkog imena, adrese, naziva kompanije i sl. Kada korisnik upiše svoju šifru, program proverava da li se šifra poklapa s izračunatom šifrom. • Program koji koristi podatke skupljene iz korisnikovog računara radi na sličan način, samo što umesto korisničkih podataka koristi razne podatke o korisnikovom računaru – poput serijskog broja diska, raznih postavki Windowsove baze Registry i sl. Iz prikupljenih vrednosti program računa neku vrednost i smešta je u skrivenoj datoteci na čvrstom disku računara. Korisnik mora proizvođaču softvera poslati generisani identifikacioni broj računara na osnovu kojeg mu proizvođač softvera vraća odgovarajuću šifru za registraciju softvera. Sigurnosni aspekti programiranja

47. Autorizacija • Autorizacija je jedan od najčešće korišćenih načina hardverske zaštite softvera. • Autorizacija funkcioniše na principu izazov – odgovor (engl. chalenge - response). • Jedinstverni broj koji predstavlja izazov generiše se prilikom instalacije programa pomoću: • serijskog broja isporučene kopije softvera • i prikupljenih podataka o hardveru računara i konfiguraciji operativnog sistema. • Nakon instaliranja, program je potrebno autorizovati. • U procesu autorizacije, • generisani broj (izazov) šalje se proizvođaču softvera • koji korisniku vraća autorizacijski kôd (odgovor) • koji odgovara generisanom serijskom broju hardvera. Sigurnosni aspekti programiranja

48. Zaštita programa pomoću registracione datoteke • Registracione datoteke imaju istu ulogu kao i ključevi za registraciju, a prednost im je količina informacija koju je moguće staviti u njih. • Registraciona datoteka može sadržati informacije o korisniku, šifru za proveru identiteta korisnika, ključeve za dešifrovanje šifrovanih delova izvršnog koda aplikacije i sl. • Registraciona datoteka je obično šifrovana tako da je nemoguće pročitati i promeniti njen sadržaj. U takvoj datoteci može biti zapisan deo izvršnog koda aplikacije tako da, ako datoteka ne postoji ili je neispravno dešifrovana, aplikaciji nedostaje deo koda i ne može ispravno raditi. • U registracionu datoteku je moguće smestiti podatke o hardveru korisnikovog računara, pa je potrebna jedinstvena datoteka za svaki računar. Kao i u slučaju registracionih šifara, iz aplikacije je moguće ukloniti deo koda koji proverava ispravnost registracione datoteke. Kako bi se to otežalo, provera ispravnosti datoteke ugrađuje se na više mesta u programu i informacije u datoteci se koriste za šifrovanje delova izvršnog koda. Sigurnosni aspekti programiranja

49. Spoljni hardverski ključ (dongle) • Spoljni hardverski ključ (engl. dongle) je uređaj koji se povezuje na računar preko serijskog ili paralelnog priključka u cilju sigurnog pokretanja određene aplikacije. Stariji tipovi donglea povezivali se se s računarom preko serijskog porta. Prilikom pokretanja softvera proveravalo se prisustvo samog uređaja i – u slučaju da ga nema – pokretanje se prekidalo. • Slabost ovakve provere ogledala se u napadu na deo programa koji proverava prisustvo dongle uređaja. Moderni dongle uređaji povezani su na računar poput malog USB uređaja. Umesto provere prisustva, na uređaju se nalazi ključ bez koga nije moguće pokrenuti aplikaciju. Kôd za proveru ispravnosti dongle uređaja može se šifrovati u aplikaciji, a isto tako se može šifrovati i sva komunikacija između aplikacije i dongle uređaja. • Ako je provera ključa ugrađena na više mesta u programu i ako su ti delovi koda šifrovani, može biti jako teško pronaći i ukloniti sve provere iz aplikacije. • Novije verzije dongle uređaja imaju ugrađenu EPROM memoriju u koju je moguće ubaciti programski kôd nekih funkcija programa. Funkcije u EPROM-u su šifrovane i dešifruju se direktno u radnu memoriju pri izvršavanju programa. Na taj način je bez originalnog donglea praktično nemoguće probiti zaštitu jer deo koda jednostavno nedostaje Sigurnosni aspekti programiranja

50. Komercijalna rešenja • FLEXlm (Flex License Manager) • HASP (Hardware Against Software Piracy) • PC Guard • SyncroSoft MCFACT Sigurnosni aspekti programiranja