Securitatea in .Net Framework - Aplicatie pentru user management

Academia de Studii Economice

Facultatea de Cibernetica, Statistica si Informatica Economica

Master Securitate Informatica

Securitatea in .Net Framework

Aplicatie pentru user management

Introducere

Multe probleme de securitate pot aparea din cauza unor comportamente neprevazute ala programelor de calculator. Aceste comportamente pot rezulta din mai multe tipuri de cause, cele mai multe depasiri de buffer de memorie, erori de validari ale inputurilor si greseli de configurari.

Depasirile de buffer de memorie apar cand un proces incearca sa acceseze o zona de memorie care nici macar nu este zona a spatiului de memorie aferent procesului sau cand aceasta zona nu este ceea ce se asteapta sa fie. Exemple pot fi situatiile cand un proces suprascrie accidental o valoare in memoria heap, cauzand vicierea variabilelor apartinand procesului sau cand un proces suprascrie o valoare pe stiva, cauzand astfel o diversiune, care conduce la executarea unei alte portiuni de cod decat cea care trebuie executata.

Erorile de validare a inputurilor apar cand un proces nu-si verifica destul de bine formatul inputurilor, provocand terminarea anormala a executiei programului. Un exemplu poate fi atunci cand un proces preia un nume de fisier ca argument, dar nu verifica daca acesta este unul valid. Aceasta ar putea conduce la suprascrierea unuia din fisierele de sistem importante, si este cunoscut ca un atac destul de ademenitor.

Configurarile implicite ale software-ului cauzeaza adesea presupuneri largi despre calculatorul tinta. Acest lucru poate conduce la o slaba securizare a informatiei confidentiale, precum si la executarea "nefireasca" a codului.

In contextul securitatii, aceste probleme pot afecta un sistem informatic in mai multe feluri, speculand mai multe brese:

confidentialitatea informatiei: informatia continuta sau procesata de sistemul informatic poate fi disponibila entitailor (persoane, programe) neautorizate.

integritatea informatiei: informatia continuta sau procesata de sistemul informatic poate fi modificata de entitati neautorizate, cauzand nonsensuri si posibile alte brese de securitate.

disponibilitatea informatiei: un proces care ruleaza pe un sistem informatic poate fi atat de serios afectat astfel incat sa nu mai fie disponibil. Specularea acestui tip de vulnerabilitatea se numeste Denial of Service (DoS).

In aceasta lucrare se incearca trecerea in revista a provocarilor de securitate care apar in timpul proiectarii si dezvoltarii de prgrame si schitarea modului in care Microsoft .NET Framework furnizeaza solutii acceptabile pentru aceste probleme, prin intermediul arhitecturii sale de securitate.

Securitatea - caracteristica .NET

Arhitectura bazata pe managed code specifica .NET Framework, in care programatorul nu mai poate poate intreprinde actiuni low-level, ofera o solutie restrictiva la problema securitatii aplicatiei. Aceasta controleaza in mod transparent comportamentul codului, chiar si in cele mai vitrege conditii, astfel incat riscurile inerente tuturor tipurilor de aplicatii, atat la nivel client, cat si la nivel server, sunt mult reduse.

La un nivel inalt, .NET Framework ofera dezvoltatorilor si administratorilor [******]:

control modular asupra securitatii aplicatiilor si resurselor;

set de utilitare usor de utilizat pentru implementarea de rutine robuste pentru autentificare, autorizare si criptare;

elimina multe din riscurile majore la care securitatea trebuie sa faca fata, riscuri datorate defectelor de cod (cum ar fi buffer overflows);

muta sarcina de a lua decizii critice de securitate (cum ar fi daca sa ruleze sau nu o anumita aplicatie sau la ce resurse ar trebui ca aplicatia sa aiba acces) de la utilizatori catre dezvoltatori si administratori

Cu toate acestea, .NET Framework nu poate (fiind chiar imposibil) sa ia in considerare toate riscurilor si sa lupte singur imptriva amenintarilor la adresa securitatii aplicatiilor. In acest sens, Brian A. LaMacchia, Software Architect la Microsoft, prezinta 10 sfaturi mai putin tehnice pentru imbunatatirea securitatii [LAMA05]:

Cunoaste-ti partenerii (dezvoltatori, administratori, utilizatori). Nu conteaza cat de bun este un sistem de securitate daca acestia il ignora. Iata cateva motive simple pentru care acestia ar putea face asa ceva:

a.      este mai dificil de dezvoltat intr-un mediu conform unui model de securitate;

b.     sistemul este prea greu de administrat; nu se poate imagina usor un sistem de politici de securitate sau aplicarea sa in conditiile lumii reale;

c.      sistemul este prea restrictiv - nu-i lasa prea usir sa-si duca munca la bun sfarsit.

Cunoaste-ti propriii dezvoltatori. Mai exact, trebuie intelese capacitatile si limitele acestora. Apare astfel intrebarea: sunt capabili toti dezvoltatorii sa integeleaga si sa asimileze modelul de securitate? Cel mai performant model de securitate din lume devine ineficient in momentul in care dezvoltatorii care trebuie sa-l utilizeze nu sunt antrenati corespunzator pentru a-l utiliza. In acelasi timp nu este nevoie ca toti dezvoltatorii sa poata scrie cod in care se trateaza probleme critice de securitate. In concluzie, instruirea dezvoltatorilor este cheia, acestia trebuind sa intre in contact cu sistemul destul de devreme pentru a-i putea face fata.

A avea incredere totala in verificator, costa. Corectitudinea verificatorului type-safety din MSIL (Microsoft Itermediate Language) a fost in topul preocuparilor inca din primele faze de dezvoltare ale CLR (Common Language Runtime). Cum se poate verifica corectitudinea verificatorului. Prin folosirea a inca unui verificator si comparea rezultatelor. Sau prin folosirea a trei verificatoare si compararea rezultatelor fiecaruia cu ale celorlalte doua.

Vizibilitatea nu inseamna securitate. Limbajele orientate-obiect au notiunea de vizibilate (private, friend, protected, public). Dezvoltatorii pot fi confuzi si pot tinde sa creada la aceste reguli ale vizibilitatii ca la o garantie a securitatii. Ei bine, in .NET Framework nu este chiar asa, iar dezvoltatorii trebuie instruiti sa faca diferenta intre vizibilitate si securitate.

Utilizatorii confunda identitatea cu increderea. .NET Framework a introdus conceptul de strong names ca modalitate de identificare a codului dintr-un assembly. Aceste strong names utilizeaza chei publice ca prefixuri de namespace-uri. Strong name-urile sunt valide numai daca sunt semnate cu cheia privata corespunzatoare. Strong names reprezinta un mecanism de identificare, nu unul de garantare a increderii. Totusi multi dezvoltatori l-au vazut ca pe un "crypto-protected name" si au inceput scrierea politicilor de securitate in functie de acesta, fara a mai crea si un mecanism de incredere.

E dificil sa ascunzi secrete intr-un mediu guvernat de GarbageCollector. .NET Framework ii invata pe dezvoltatori ca nu trebuie sa aiba in grija managementul memoriei intr-un mediu in care exista GarbageCollector-ul, dar lucrurile nu stau chiar asa. Trebuie avuta totusi in vedere curatarea manuala a datelor sensibile, imediat ce nu mai este nevoie de ele.

Lucrul asincron este foarte important. Modelele asinconde devin din ce in ce mai importante (programarea multithreading). Daca modelele de programare asincrona devin predominante, mecanismele alternative de furnzare a controlului modular devin mai atractive ("infectarea" datelor, controlul fluxului de informatii).

Alegerea modelului de aplicatie potrivit. O singura platforma API poate suporta mai multe modele de aplicatie. Sistemele de securitate corespunzatoare trabuie sa functioneze pentru toate aceste modele.

Mediile de dezvoltare, depanare si instalare trebuie sa fie compatibile. Daca dorim dezvoltatori care sa scrie cod partial-trust, atunci ei trebuie sa fie capabili sa testeze si sa depaneze codul intr-un maediu asemenator. Trebuie de asemenea sa la furnizam utilitare care sa-i ajute sa determine cum va rula codul in contexte limitate de executie.

Nu-i poti multumi mereu pe toti. Orice sistem de securitate ar fi ales, s vor gasi utilizatori care sa se planga. Acest lucru se intampla mai ales cand exista nivele de securitate etajate, iar sistemul de pe nivelul superior nu ofera suport pentru acces la sistemul de pe nivelul inferior.

Arhitectura de securitate .NET Framework

Inainte de a prezenta detalii despre securitatea in .NET Framework, e binevenita o trecere in revista a componentelor de baza ale acesteia:

CLR (Common Language Runtime)

Bibiliotecile de clase

Assembly-urile

Common Language Runtime

CLR reprezinta "creierul" care coordoneaza executarea codului. Astfel, din perspectiva securitatii, CLR-ul impune .NET Framework-ului resrictii la executarea codului si previne comportamentul neprevazut. Mai precis, CLR realizeaza compilarea JIT ("just-in-time") la rularea codului managed. JIT "traduce" codul managed in cod nativ inainte de a-l executa. Din momentul in care JIT genereaza codul in cadrul CLR, acesta din urma este unicul in masura sa-i asigure securitatea., ceea ce nu poate fi facut cu codul executat in mediu nativ.

Bibliotecile de clase

Bibliotecile de clase din .NET Framework sunt o colectie de de clase reutilizabile, sau tipuri de date, pe care dezvoltatorii le pot folosi sa scrie programe care vor fi executate prin intermediul CLR. Acestea implementeaza multe caracteristici importante de securitate, inclusiv permisiuni (ex. dreptul de a accesa una sau mai multe resurse), mecanisme de autentificare si protocoale si primitive criptografice. Marea majoritate a aplicatiilor poate beneficia de aceasta securitate pur si simplu utilizand aceste biblioteci.

Assembly-urile

Un assembly este un executabil sau un DLL compilat folosindu-se unul din compilatorele de limbaje din .NET Framework. Asembly-urile pot fi scrise aproape in orice limbaj de programare major, cum ar fi Visual Basic, C#, C++, J#, Perl sau COBOL. Astfel dezvoltatorii pot programa in limbajul cel mai potrivit pentru setul de sarcini si abilitati ale sale, care va folosi aceeasi infrastructura de securitate, indiferent de alegerea lor. Assembly-urile contin codul pe care runtime-ul il executa sub form de MSIL. Am discutat mai inainte cum JIT din CLR "traduce" MSIL in cod nativ, furnizand un avantaj unic, aplicand codului caracteristicile de securitate. Asembly-urile mai contin metadate, pe care CLR le utilizeaza la localizareasi incarcarea claselor, organizarea instantelor in memorie, resolvarea invocarilor de metofr, generarea codului nativ, impunerea securitatii si stabilirea granitelor contextului runtime. Prin intermediul assembly-urilor, CLR si bibliotecile de clase implementeaza arhitectura codului managed a .NET Framework.

Acum, despre arhitectura securitatii in .NET Framework, aceasta cuprinde mai multe elemente:

Evidence-based security

Code access security

The verification process

Role-based security

Cryptography

Application Domains

La nivel schematic, securitatea arata in felul urmator [******]:

Securitatea la nivel declarativ sa face prin intermediu claselor de tip atribut, iar la nivel cea imperativ, programatic.

Code Access Security (CAS)

Permissions

Code groups

CLR examineaza toate modulele de cod din ierarhie. Cand un modul este marcat ca Exclusive, atunci CLS opreste verificarea apartenentei modulului la grupuri. Mai departe CLR determina seturile de permisiuni pentru fiecare modul. Daca modulul este un membru al grupului marcat ca exclusiv, numai setul de permisiuni al grupului respectiv este luat in considerare, altfel CLR calculeaza permisiunile ca reuniune a tuturor seturilor de permisiuni ale grupurilor din care modulul face parte.

Calculul permisiunilor

Concluzii

Asa cum s-a aratat in aceasta lucrare, .NET Framework implementeaza transparent un model destul de bun de insfrastrunctura de securitate prin componente cheie ale arhitecturii sale de securitate. Oricum, aceasta tot nu elimina nevoia unei proiectari serioase a aplicatiei. Asa cum orice mediu de dezvoltare a aplicatiilor, in momentul implementarii de cod sunt implicate obiecte care implementeaza permisiuni specifice, particulare, mecanisme de autorizare sau orice altfel de functionalitate relevanta de securitate, dezvoltatorul trebuie sa fie familiarizat cu arhitecura de securitate .NET Framework, in sensul asigurarii ca principiile prezentate sunt respectate.

Bibliografie

[MURI05] Nicholas John Murison, .NET Framework Security, 2005

[LAMA05] .NET Framework Security:Lessons Learned from Five Years of Shipping Partially-Trusted Code, 2005

[******] https://www.codeproject.com/KB/security/dotNetSecurity.aspx, The .NET Framework Security Model

[******] Security in the Microsoft® .NET Framework