La tecnologia .NET enfront de J2EE ,la teva seguretat i la dels teus clients

La tecnologia .NET de Microsoft ofereix importants avantatges enfront de J2EE de Sun El juny de 2000 l'empresa de Redmond va presentar un entorn independent del llenguatge concebut per facilitar el desenvolupament d'aplicacions per a Windows capaces de treballar i comunicar-se de forma segura i senzilla. Vuit anys després el 70% dels desenvolupadors espanyols utilitza .NET Les xifres no enganyen. En l'actualitat la presència d'aquest entorn de programació de Microsoft en el mercat de les eines de desenvolupament d'aplicacions per a Windows és aclaparadora. I és que aquesta plataforma s'ha consolidat com una alternativa eficaç a J2EE (Java 2 Platform Enterprise Edition) de Sun (https://www.sun.com/java) que, a més, proporciona importants avantatges a l'hora de dissenyar aplicacions distribuïdes. ¿La clau? Els seus dos pilars essencials: les eines i els serveis web. A les entranyes de .NET Els components que conformen aquest entorn de desenvolupament es denominen .NET Framework i consisteixen en el CLR (Common Language Runtime) o llenguatge comú en temps d'execució, una jerarquia de biblioteques de classes i suport per a diferents tipus d'aplicacions, entre les quals contempla eines modelades amb l'arquitectura client-servidor tradicional, així com aplicacions i serveis web. A més, .NET proporciona biblioteques que faciliten l'accés a bases de dades i codi de gestió d'XML, no en va aquest metalenguatge s'ha posicionat en aquesta plataforma com un estàndard de facto per a la interoperabilitat d'aplicacions. El CLR es troba al cor de l'entorn, de fet és una màquina virtual encarregada de proporcionar una capa d'abstracció entre el bytecode de .NET i la plataforma hardware sobre la qual s'executa (per exemple, l'arquitectura x86 i compatibles). Aquesta capa, equivalent a la màquina virtual de Java en l'entorn J2EE, té implicacions serioses pel que fa al desenvolupament i la seguretat de les aplicacions. En essència, el CLR evita que el desenvolupador accedeixi a baix nivell a la plataforma, sent aquest component l'únic que pot, per exemple, accedir a la memòria i gestionar directament els punters. A més, el codi desenvolupat per a la plataforma .NET s'executa sota certs rols de seguretat configurables que varien si és de confiança (trusted) i també en funció de la seva procedència (la intranet, Internet, etc.). Molts dels atacs que han patit els sistemes operatius Windows han començat a desaparèixer (entre ells, el conegut i infame desbordament de buffer) pel fet que ara el programador no té accés a la gestió nativa de la memòria de manera directa. És evident que tenir aquesta capacitat, aquesta capa extra que abstrau de la manipulació directa del hardware (igual que ocorre en l'entorn Java), té el seu cost en el temps d'execució, màxim si les aplicacions que escrivim són distribuïdes. Qualsevol compilador que generi codi per a la plataforma .NET ha de fer-ho en un llenguatge intermedi conegut com a IL (Intermediate Language), que al seu torn s'ajusta a una especificació que aglutina les pautes que han de complir els llenguatges .NET (CLS o Common Language Specification). L'IL obtingut es traduirà a codi natiu usant estratègies just-in-time, per la qual cosa la sobrecàrrega de temps patida per aquesta capa intermèdia no resulta excessiva. Una plataforma plurilingüe Com vam mencionar abans, el Framework .NET és independent del llenguatge utilitzat, el que significa que els que escollim per a les nostres aplicacions han de ser traduïts a un llenguatge binari comprensible per la plataforma. Per aquesta raó, els desenvolupadors que utilitzen els serveis d'aquesta plataforma poden emprar diversos llenguatges d'alt nivell i fer-los operar entre si. Microsoft ha creat compiladors per a Visual Basic, C++ i C#, encara que també existeixen compiladors per a aquesta plataforma que no han estat creats per Microsoft. La neutralitat del llenguatge ha incrementat molt l'atractiu de la tecnologia .NET, especialment quan es considera el cost que és necessari afrontar per migrar des d'altres plataformes. De fet, la migració des de J2EE és pràcticament immediata, ja que una aplicació Java pot convertir-se sense massa esforç en un programa .NET utilitzant compiladors creuats. És més, qualsevol grup de desenvolupadors Java pot adoptar C# com a llenguatge sense greus conseqüències. C# és el llenguatge abanderat per Microsoft com a estendard per als programadors .NET i, alhora, l'eina amb què persegueix la captació de desenvolupadors d'altres plataformes. No en va, per atraure programadors procedents de l'entorn Java, Microsoft va crear una iniciativa denominada JUMP (Java Users Migration Path), que significa alguna cosa així com «el camí que ha de seguir un desenvolupador Java per programar en .NET». En qualsevol cas, Java i C# són dos llenguatges similars, sobretot a nivell semàntic, una capacitat que permet l'existència d'aplicacions que faciliten la conversió entre ambdós llenguatges. ¿És més segur .NET que J2EE/Java? La plataforma .NET és, sense cap mena de dubte, un marc d'execució molt més segur que l'entorn estàndard que proporcionava Windows. Això no vol dir que no existeixi la possibilitat que es donin forats de seguretat; de fet, hi ha molts problemes d'aquesta índole als quals s'han d'enfrontar els desenvolupadors. Tot i així, és just dir que manca de molts errors de seguretat que Java sí que va patir. És més, és evident que Microsoft ha après dels errors que va cometre Sun als seus inicis, encara que això també pot ser contraproduent perquè no ha iniciat el seu camí des de zero, i aquesta falta d'experiència pot ser també motiu de desconfiança. Per molt cuidat que estigui el desenvolupament de la plataforma .NET, i, de fet, ho està, es pot arribar a la conclusió que realment el responsable de les potencials situacions de perill és el propi desenvolupador, que en moltes ocasions ignora els principis bàsics de la programació segura. Aquells programadors que creen aplicacions web poc segures amb VBScript i ASP ben segur que escriuran aplicacions potencialment insegures quan desenvolupin amb Visual Basic en ASP.NET (un component del Framework .NET que fa possible l'existència d'aplicacions i serveis web). El CLR no proporciona protecció contra el codi que conté defectes o que exposa de manera innecessària informació privada o comprometedora. Les biblioteques de classes de .NET estan dotades de nombroses característiques de seguretat que s'empren per garantir que les aplicacions seran el més segures i robustes possible. En l'àmbit de les utilitats web un exemple d'aquestes capacitats és la possibilitat de codificar en HTML totes les dades per evitar els atacs XSS o cross-site scripting (que aprofiten les vulnerabilitats del sistema de validació de l'HTML encastat), i proporcionar mètodes senzills però segurs a l'hora de construir consultes SQL dinàmiques per evitar atacs per injecció de SQL. A més, el control i la gestió de les sessions en ASP.NET s'han fet omnipresents. D'aquesta forma, a més del control proporcionat, també es permet l'escalat o creixement d'aplicacions web des d'un servidor a un conjunt d'ells, emmagatzemant les variables de sessió en màquines de bases de dades SQL-Server. SOAP i els serveis web Una característica clau de la plataforma .NET és el suport d'XML com a mitjà per a la interacció entre aplicacions i serveis web. Aquests últims exposen fragments de la lògica de negoci de l'aplicació fora dels tallafocs, encara que normalment fan ús de SOAP (Simple Object Access Protocol), un protocol que facilita l'intercanvi de dades codificades en XML i la realització de crides a procediments remots (invocació de funcions o mètodes d'altres aplicacions, ja siguin locals o remotes). L'entorn .NET proporciona biblioteques que asseguren el transport de les dades a través d'un protocol (com per exemple HTTP) i la seva seguretat emprant certificats digitals i facilitant així la creació de serveis web. El CLR, per la seva part, garanteix la robustesa de l'aplicació que processa les dades rebudes a través d'un servei web. No obstant això, utilitzar SOAP per comunicar un component .NET amb un altre J2EE no garanteix que aquest procés es dugui a terme sense dificultats. L'organització per a la Interoperabilitat de Serveis Web (WSI) treballa per resoldre aquests inconvenients, un problema sobre el qual és necessari reflexionar a l'hora de portar un servei web a .NET. Afrontant la migració Quan es transporta una aplicació de considerables dimensions d'una plataforma a una altra, ben segur que hi haurà problemes amb el codi. En alguns casos el codi amb què han estat desenvolupats els components usats per l'aplicació a migrar no està disponible o fins i tot el hardware al qual pretenem migrar imposarà les seves pròpies condicions, fent que en nombrosos casos no sigui possible. Les aplicacions que usen codi de baix nivell per comunicar-se amb altres components de la lògica no poden ser portades a l'entorn gestionat o managed que ofereix el CLR. Per aquesta raó, Microsoft ha inclòs certa funcionalitat en aquest últim component que li permet, en determinades circumstàncies, executar codi no gestionat (unmanaged) precedit per la sentència unsafe. Aquesta paraula clau és molt interessant des del punt de vista de la seguretat. Suposem que una aplicació web gestiona la petició i entrada de dades dels usuaris amb C# (codi gestionat). Després de ser processada, aquesta informació és transmesa a un codi no gestionat que accedeix a la memòria compartida d'un component desenvolupat per tercers. Aquest element s'encarrega de la comunicació amb el servidor de l'empresa. Sota aquest escenari el codi que s'executa en la secció unmanaged pot contenir errors, per la qual cosa un usuari del sistema podria arruïnar tota l'aplicació i, fins i tot, executar codi arbitrari. Per aquesta raó, la paraula clau unsafe ha de ser evitada en la mesura del possible, ja que cancel·la totes les opcions de seguretat que la plataforma i el CLR ofereixen a les aplicacions. El Framework .NET també es veu perjudicat per la temptació d'empaquetar aplicacions completes desenvolupades en C++ amb aquesta paraula clau i proclamar que han estat portades, obrint enormes forats de seguretat injustament atribuïts a .NET. Aquesta tècnica és popular entre els desenvolupadors que van justos de temps per complir els terminis imposats pels clients. Prevenint atacs Quan es desenvolupa codi que ha d'executar-se en el client és important recordar que l'usuari pot manipular i interrompre l'execució independentment del llenguatge en què s'hagi escrit (Java, un llenguatge .NET, C++, C, etc.). Amb paciència i temps el codi pot ser sotmès a tècniques d'enginyeria inversa que mostren detalls rellevants, per la qual cosa es recomana no obviar els consells de codificació segura i adoptar criteris sensats, com no incloure en els executables informació sensible, especialment contrasenyes. Tant els bytecodes de Java com els ensamblats de .NET poden ser fàcilment sotmesos a tècniques d'aquest tipus, fins i tot de manera més senzilla que els executables d'una plataforma nativa. Això es deu al fet que tant .NET com Java posseeixen una capa abstracta intermèdia que es recolza en una especificació senzilla i neta, per la qual cosa «entendre» els executables per a aquestes plataformes (existeixen eines com dotfuscator per dificultar aquestes pràctiques) és més senzill que «descompilar» els executables natius (que s'executaran directament en els processadors). Des de la perspectiva de la seguretat del client, un usuari pot establir regles que atorguin diferents privilegis a distintes porcions del codi. El que s'executa en un entorn restringit i controlat es diu que es processa en un sandbox o caixa de sorra. Un usuari pot triar executar automàticament codi que ha estat signat digitalment per certes companyies i, d'aquesta forma, atorgar tots els privilegis sobre la seva màquina a qualsevol codi que provingui de la intranet d'aquestes empreses. D'aquesta manera, tota aplicació que provingui d'un entorn no identificat serà etiquetada com a codi hostil i la seva execució es durà a terme en un entorn restringit i molt controlat. No obstant això, s'han documentat molts atacs l'origen dels quals s'atribueix a errors d'implementació en els sandbox de diversos distribuïdors de màquines virtuals de Java que solen estar íntimament relacionats amb els carregadors de classes. I és que si es pot amagar o falsejar la identitat del carregador que proporciona el codi a executar en el client, llavors és possible permetre que el codi d'un proveïdor no autoritzat es pugui fer passar per codi d'un proveïdor de confiança, aconseguint així l'accés a tots els privilegis en el sistema de l'usuari. De moment no s'han donat aquest tipus d'atacs en la plataforma .NET. Un creixement imparable L'entorn de desenvolupament de Microsoft proporciona moltes millores en la seguretat i facilita sensiblement la implementació d'aplicacions distribuïdes. Tot i que la plataforma de desenvolupament J2EE de Sun és bastant més madura que el Framework .NET, els de Redmond estan apostant fort i s'estan fent amb suports clau de tercers, molt importants en el sector. Els avantatges d'executar codi gestionat són innegables i el CLR ha après dels atacs patits per Java, evitant d'aquesta forma una gran part de les debilitats conegudes fins a la data. No obstant això, és important recordar que els defectes i errors en la implementació de cada desenvolupador són indetectables, i potser els atacants estan més interessats a explotar aquestes debilitats per accedir a les dades de l'empresa que en aconseguir accés al servidor en què s'està executant l'aplicació.