Securitatea în API-urile publice

[DarkyAngel]

De foarte multe ori descarcam un API ( Application Programming Interface ) de pe web, sau un SDK ca "Facebook SDK" fara sa ne îngrijoram despre oricare din problemele de securitate care pot interveni din practici necorespunzatoare de codare, care sunt încorporate în API. De multe ori , orice analiza de cod a oricarui din aceste API va arata ca exista deficiente în implementarea API-ului, care cresc suprafata si riscul de atac pentru o companie care foloseste aceste API. Partea din orice program de securitate pentru orice companie care foloseste API-uri publice trebuie sa faca un review complet al API-ului, si cum poate fi exploatat din cauza codului scris necorespunzator de persoana care a construit API-ul.

Multi programatori si ingineri de securitate care fac analiza de cod stiu ca "mostrele de cod" sunt adesea nerecomandate pentru utilizarea în productie. Asta a fost o regula standard de când Microsoft Safety exista, si multiple atacuri care au exploatat "monstrele de cod" care au fost lasate ca o parte a instalatiei IIS pe mii de webservere din toata lumea.

Ceea ce rar auzim, este despre riscurile asociate cu folosirea publica a API-urilor disponibile prin orice sursa. În timp ce cel mai mare repository de API-uri publice exista pe internet, aproape fiecare companie care ofera un API de asemenea ofera si un SDK ( Software Development Kit ) cu exemple despre cum sa faci functii particulare. Din pacate, acestea sunt exact ca "monstrele de cod", si nu vei stii niciodata calitatea "monstrelor de cod" sau riscurile despre potentialele efecte pe care aceste monstre le pot avea în codul tau. Deficientele din API-uri permit unui hacker sa înteleaga felul în care logica serverului lucreaza, si îi lasa hackerului timp sa lucreze la o cale efectiva sa sa deturneze API-ul sa faca ceva ce developerul nu a intetionat sa se întâmple. Testarea API-urilor publice, sau API-urile care vin cu SDK-uri specifice pentru aplicatii web, trebuie sa fie parte a oricarei companii de securitate si a programelor de evaluare si testare. În timp ce e comun pentru companiile care scriu cod sa faca testari de asigurare a calitatii, multe companii care folosesc API-uri publice nu folosesc teste de asigurare a calitatii ca sa se asigure ca , codul a fost scris corect, si poate rula în siguranta.

O modalitate de a testa cel putin asemblarile Dot NET este sa folosesti FX Cop, care e o unealta de analizare a codului dotnet statica de la Microsoft. O poti descarca ca parte a SDK-ului pentru Dot NET si este recomandat ca amândoi, programatorii si inginerii de securitate care evalueaza codul pentru securitate sa învete cel putin sa foloseasca aceasta unealta.

Ca un exemplu de folosirea analizei de cod static pentru a descoperi anumite defecte "programatice", ne vom uita la SDK-ul Dot Net Facebook, care poate fi descarcat de pe Facebook C# SDK - Download: 5.2.1 . Acest SDK are o multime de exemple de cod în el , pentru analiza statica, deci programatorii sau inginerii de securitate pot incepe sa vada felul cum functioneaza codul static, si câteva greseli comune în API-urile publice, sau "codurile monstra" care vin cu multe SDK-uri.

Este un SDK relativ recent pentru data scrierii ( Octombrie 2011 ). Aceste SDK-uri sunt updatate des cu continut nou, sau noi capabilitati, deci daca faci asta, atunci vei vrea sa fii sigur ca descarci ultimul SDK si rulezi o analiza de cod static impotriva API-urilor care le vei folosi sau asambla in package, daca faci asta doar sa înveti ceva interesant sau sa înveti cum sa faci analiza de cod static. Odata ce ai descarcat Microsoft SDK incluzand ultimul Dot NET framework, vei avea FXCop instalat. În acest caz noi folosim FXCop 10.0.0, desi acest program este frecvent updatat.

Trebuie s? dai click dreapta pe MyFXCopProject ca s? adaugi targeturi, sau s? introduci orice DLL pe care vrei s?-l revizuie?ti pentru securitate ca parte din analiza ta de cod static. Pentru acest exemplu vom introduce MOQ.DLL din SDK-ul Facebook, folosind versiunea 3.5 a acestui DLL.

FacebookCSharpSDK\Source\packages\Moq.4.0.10827\lib\NET35\Moq.dll

Face?i click pe "Analyze" ?i FXCop va trece prin DLL c?utând gre?eli de programare comune. FXCop se bazeaz? pe un baz? de date de stiluri de codare ?i practici bune de codare pentru a face analiza. În multe cazuri este o bun? unealt? pentru a descoperi probleme de baz?, dar se merit? de asemenea s? folosi?i alte unelte de analizare a codului static precum ?i în cazul în care analiza de cod indic? c? sunt multe defecte peste care poate trece. Folosind aceast? unealt? , de?i este un bun indicator de cât de bine programatorul care a scris API-ul a urmat practici bune de codare, sau a în?eles cum programul folosit pentru a scrie cod s-a schimbat sau segmente din el sunt dep??ite de-a lungul timpului.

Odata ce analiza este complet?, FXCop va oferi o idee gradat? despre ce defecte sau errori a întâlnit în obiectul dot net ( în acest caz un DLL ) ?i despre ce sunt defectele.

Sunt diferite c?i în care FXCop indic? severitatea aspectelor particulare ale codului, ?i apoi le d? un nivel de certitudine, sau cum ar putea într-adev?r s? existe acea eroare într-un program.

Po?i s? sortezi rapid de la cel mai mare nivel de defect cu setul de cod ?i apoi s? revizui?i fiecare aspect individual al defectelor. Dac? nu ave?i un "programming background", ar fi bine s? lucra?i cu un programator astfel încât compania poate tria defectele individual , în func?ie de modul cum programatorii lucreaz?, sau folosi?i asta pentru a semnala bug-uri dac? cumpania voastr? folose?te un mecanism de raportare ?i g?sire a bugurilor intern. În orice caz, orice defect critic este ceva ce trebuie revizuit de un programator profesionist, care este familiar cu codul ?i cu compania pentru a ajuta trierea erorilor programatice care vor fi raportate cu aceast? unealt?.

This is the sorted view, a non-breaking fix means that the compiler will throw a warning, while a breaking issue might halt or influence the compilation of the program. Because we are working with a DLL, it compiled, but might leave a hook for a hacker to access the call, and cause the program to error out and provide debug information that should not be provided to anyone but programmers.

Because we have a breaking issue noticed by FXCop, we will look at that first to see what the issue is, and if it is fixable, or worth testing further, or sending to the bug tracking system used by a company. Again, working with a programmer on this is always a good idea of the security engineer has not done static code analysis or is not a programmer.

Aceasta este vederea "sortat?", un defect "non-breaking" înseamn? c? compilerul va ar?ta o avertizare, în timp ce un defect "breaking" poate opri sau influen?a compilarea programului. Pentru c? noi lucr?m cu un DLL, este compilat, dar s-ar putea l?sa un cârlig pentru un hacker s? fac? call, ?i s? cauzeze programul s? dea eroare, ?i s? furnizeze informa?ii de debug care nu ar trebui furnizate dec?t programatorilor.

Pentru c? avem un defect "breaking" observat de FXCop, ne vom uita la acela primul pentru a vedea ce defect este, ?i dac? este fixabil, sau merit? testare în continuare, sau raportarea la sistemul de bug tracking folosit de o companie. Din nou, lucr?nd cu un programator la asta e întotdeauna o idee bun? , dac? "inginerul de securitate" nu a f?cut analiz? de cod static sau nu este un programator.

Ce spune acest lucru este c? este o eroare critic? , cu o certitudine de 33%. Este etichetat ca "breaking", dar noi ?tim programul deja compilat. FXCop se uit? pentru un atribut de securitate în informatii de serializare ( poate fi un token de securitate, sau ceva ce este ce este "pasat" direct "call"-ului independent a DLL-ului ) . Este foarte probabil ca un token de securitate serializat s? fie trecut în acest "call" din alt DLL sau dintr-un formulat web, cum ar fi login, sau alte informa?ii. Analiza de cod ar trebui s? arate ce date sunt transmise în acest "call" din alte sec?iuni a codului pentru a fi sigur c? cel pu?in un token de securitate este trecut în informa?iile de serializare. Aceast? eroare de asemenea indic? aceea?i concluzie, c? este un token undeva care este trimis c?tre acest obiect.

Adaug? urm?torul atribut de securitate în "AbstractInvocation.GetObjectData(SerializationInfo, StreamingContext)" ca s? potrive?ti un LinkDemand în metoda de baz? ‘ISerializable.GetObjectData(SerializationInfo, StreamingContext)’: [securityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.SerializationFormatter)] .

Asta e ceva ce necesit? o continu? analiz? de cod a întregului proces în timpul "spargerii" astfel încât dependen?a poate fi rezolvat?. Fie un token e trecut de la LinkDemand sau nu, dac? nu atunci aceasta ar trebui prezentat ca un bug programatorului care folose?te API-ul.

Unele erori sunt simple erori de capturare. Trebuie s? existe întotdeauna o func?ie de capturare a erorilor robust?, dar acest lucru este adesea trecut cu vederea în cazul erorilor programului. Capturarea erorilor de cod este o parte fundamentala a program?rii, dar de asemenea una din cele mai trecute cu vederea sec?iuni când program?m cod. Erorile "necapturate" pot conduce la informa?ii dezv?luite utilizatorului sau unui hacker care le poate da mai multe informa?ii despre cum a fost configurat serverul web, sau cum func?ioneaz? defapt serviciul web în rela?ie cu data care este prezentat? acestuia.

Modific? "AttributeDisassembler.Disassemble(Attribute)" pentru a captura o excep?ie mai precis? decât ‘Exception' sau retrimite excep?ia.

Câteodat? scrierea codului de capturare a erorilor poate fi extraordinar de plictisitor, dar un bun cod de capturare a erorilor poate ?ine hackerul sau chiar utilizatorul casual de la confruntarea problemelor care expun configura?ii internale ale webserverului critice sau importante, sau data care poate conduce la un foarte bun hack care expune baza de date, sau webserverul în sine. Acesta este felul de erorii pe care hackerii îl caut? în mod special pentru c? pot în?elege mai bine logica din spatele serverului, ?i cum lucreaz? API-ul cu data serverului. În timp ce un API public nu e un lucru r?u, cu codul surs? pe care o analiz? de cod static îl poate rula, deschide u?i la g?sirea suprafe?elor de atac. Orice cod , ca un API public, abilitatea hackerilor sau indivizilor r?u-inten?iona?i care ?tiu aceast? informa?ie despre API-urile publice ?i configura?ia lor deschide u?i pentru hackuri mai interesante, sau scurgeri de date mult mai interesante din sistem decât de?in?torii au inten?ionat. În unele cazuri poate conduce la abilitatea de a scrie un virus care atac? exploit(-urile) g?site de-a lungul analizei de cod.

Revizuirea fiec?rui API care este folosit de o companie ar trebui s? fie parte a oric?rui proces de securitate a informa?iilor. API-urile introduc riscuri similare cu folosirea codului "mostr?" care este inclus cu seturi de programe specifice. În timp ce API-urile sunt foarte folositoare în construirea "mashup"-urilor sau consumând date în moduri noi, dac? API-ul nu este programat corespunz?tor sau las? tipuri specifice de date deschise astfel încât poate fi cauzat? o eroare, atunci un user al API-ului poate fi în pericol de a risca informa?ii prin scurgeri de date. API-urile sunt parte a eco-sistemului WEB 2.0, ?i ca atare cresc imprimarea hackingului în multiple sisteme care func?ioneaz? pe baza acestor API-uri. Unit??ile de securitate ?i business trebuie s? în?eleag? cum API-ul a fosdt scris, ce implica?ii de securitate are, ?i cum este cel mai bine s? gestionezi aceste riscuri.

În?elegând "call"-urile ascunse din API-uri ne ajut? s? în?elegem logica rul?rii aplica?iei web 2.0. În timp ce Javascript folosind xHR ( XML HTTP Requests), ?i firebug este o cale a în?elegerii logicii aplica?iei web 2.0, de asemenea în?elegerea analizei de cod static a API-ului Web 2.0 sau a oric?rui API face mult mai u?or s? în?elegi suprafa?a de atac disponibil?, precum ?i furnizarea abilit??ii de "mockup" a codului ?i practicarea atacurilor efective înainte s? mearg? 'mainstream' ?i s? se opreasc? pe internet ca ultimii 2 viru?i de internet care au afectat MySpace ?i Twitter înc? de la începutul lumii Web 2.0.

Mai mult ca orice alt? surs? de cod public, abilitatea hackerului sau unui individ r?u-inten?ionat de a desc?rca cod nu este restric?ionat?. Hackerii care fac analiz? de cod static ?i apoi simuleaz? pe un webserver atacurile pe care vor s? le fac? este o cale de a perfec?iona hackul astfel încât compania sau connexiunile sociale pot fi exploatate mai târziu. Reverse engineering pe API-uri este un proces des întâlnit la hackeri folosit pentru a determina cât de u?or ar fi s? atace oricare parte a suprafa?ei Web 2.0 pentru a câ?tiga informa?ii adi?ionale, a fura informa?ii personale sau s? se infiltreze în sistemele utilizatorilor folosind aceste API-uri.

În timp ce func?ionalitatea unui API este fixat? la ceea ce un provider de servicii inten?ioneaz? de a da persoanelor care folosesc aceste API, utilizarea API-urilor necorespunz?tor securizate sau programate face 'hackingul' Web 2.0 mult mai interesant, ?i mult mai plauzibil, astfel încât mul?i oameni folosesc aceste API-uri, ceea ce face un hack eficient într-o gam? larg? de utilizatori.