Daily Archives: June 4, 2014

Obfuskeret computerkode der fylder omkring en megabyte. Et kig i den foreløbige test-kode til den kommende NemID JavaScript imponerer ikke umiddelbart internetaktivisten og datalogen Christian Panton, der blandt andet er kendt for at hacke sit Rejsekort. Nu har han startet et softwareprojekt på nettet, der er designet til at reducere kompleksiteten og dermed også filstørrelsen på NemID JS.

Senest har Christian Panton været i vælten, for at lave sin egen udgave af NemID uden Java – netop ved brug af JavaScript i stedet. Et par måneder før den officielle lancering af NemID JS, der er sat til 1. juli. Et initiativ, der fik en kølig modtagelse af leverandøren af NemID, Nets.

Christian Panton er faldet over testkoden på en demo-hjemmeside ved PortalProtect. Det beskrives som en sikkerhedsinfrastruktur til blandt andet portaler. Løsningen fungerer med forskellige login-metoder – herunder NemID. Firmaet er ejet af Asseco Denmark A/S, som over for Version2 bekræfter, at JavaScript-koden på NemID JS-demosiden kommer fra Nets. Testkoden bruger Asseco Denmark A/S til at forberede PortalProtects kunder til, når NemID JS går live.

I forhold til testkoden til den kommende NemID JS, som Christian Panton har kigget på, hæfter han sig ved, hvor obfuskeret JavaScript-koden bag NemID er gjort. Obfuskering vil sige, at koden bevidst er gjort svært gennemskuelig for at camouflere, hvad der sker i softwaren. En af pointerne kan være, at eksempelvis kriminelle får sværere ved at finde og udnytte sikkerhedshuller. Der er dog delte meninger om, i hvor høj grad, obfuskering giver øget sikkerhed, da det kan lade sig gøre at omgå obfuskeringen. Og noget kunne tyde på, at obfuskering i tilfældet NemID JS kan være skønne spildte kræfter.

I hvert fald har Christian Panton nu startet et projekt på webhosting-tjenesten for softwareprojekter GitHUB med navnet obfuscated-id. Det er et program, der har til formål at de-obfuskere NemID JS-koden. Altså fjerne de tiltag, der er lagt i koden for at gøre den så uforståelig som mulig. Han mener, obfuskeringen både får koden til at fylde langt mere, end den burde, og samtidigt gør det sværere at finde fejl.

»Jeg googlede for lidt tid siden mig frem til en hjemmeside som havde en demo af NemID/JS. Da jeg tidligere har kigget på Java-versionen, var det interessant for mig at kigge på, hvordan den kommende løsning virker,« skriver Panton i en mail og fortsætter:

»Jeg fik næsten kaffen galt i halsen da jeg opdagede hvor meget energi der havde været brugt til obfuscation af JavaScript-versionen. Især fordi det netop var et af kritikpunkterne ved den nuværende løsning. For at automatisere analysen af de næsten én megabyte store JavaScript filer, så skrev jeg en simpel deobfuscator til at fjerne nogle af de lag af kompleksitet der er lagt ind over. På den del af koden jeg har analyseret indtil nu, reducerer den desuden filstørrelsen med ca. 33%.«

Hvad kan de-opfuskatoren nu, og hvad skal den kunne?

»Det er ikke forfærdeligt meget kode, og det eneste, jeg i øjeblikket gør, er at lave en række reduktioner af kompleksitet. Der var blandt andet funktioner hvor tekststrenge blev gemt, som nu kan læses i koden med det blotte øje,« skriver Christian Panton og fortsætter:

»Den fremtidige udvikling bliver fokuseret på at skrælle mere kompleksitet af.«

Hvad er dit foreløbige indtryk af NemID JS?

»Jeg synes, det er meget positivt, at vi bevæger os væk fra Java. Jeg har kun set hvad jeg må formode er en test-version, så det vil jeg hellere svare på når det går live og jeg har fået lidt mere tid til at kigge på det,« skriver Christian Panton.

Version2 har spurgt NemID-leverandøren Nets og Digitaliseringsstyrelsen, myndigheden der på statens vegne har indgået kontrakten med Nets om NemID-løsningen, om følgende:

• Har Nets/Digitaliseringsstyrelsen nogen kommentarer til, at der nu ligger et open source projekt på GitHub, der er designet til at fjerne den kompleksitet, som bevidst er lagt ind i NemID JS?

• Kan Nets/Digitaliseringsstyrelsen bekræfte, at koden i NemID JS bevidst er gjort kompliceret?

• Vurderer Nets/Digitaliseringsstyrelsen, at øget kode-kompleksitet, giver øget sikkerhed?

• Mener Nets/Digitaliseringsstyrelsen, det er hensigtsmæssigt, set ud fra et driftsmæssigt perspektiv, at kode-kompleksiteten i NemID JS lader til at være særdeles omfattende?

• Mener Nets/Digitaliseringsstyrelsen, det er hensigtsmæssigt, at borgerne skal bruge båndbredde og cpu-kraft på at håndtere NemID JS, der lader til at have en omfattende størrelse, som følge af bevidst indbygget kode-kompleksitet?

• Påtænker Nets/Digitaliseringsstyrelsen at foretage sig noget for at mindske kode-kompleksiteten i den endelige NemID JS-udgave, der er sat til at blive frigivet 1. juli?

Kontorchef i Digitaliseringsstyrelsen Cecile Christensen sender i en mail bolden videre til Nets:

»Vi stiller krav om et højt niveau af sikkerhed i den nye JS-klient. Vi forventer, at koden har den nødvendige kompleksitet, men heller ikke mere. Det er ofte sådan, at opretholdelse af høj sikkerhed tilfører en vis kompleksitet til systemer og kode,« skriver hun og fortsætter:

»Den konkrete tekniske udvikling af systemet ligger hos Nets, og vi må derfor henvise til Nets for en mere detaljeret besvarelse af spørgsmål til selve koden eller andre tekniske detaljer – i det omfang Nets kan svare på dette uden at gå på kompromis med sikkerheden.«

Kommunikationskonsulent ved Nets Ulrik Marschall oplyser, at virksomheden ikke ønsker kommentere på NemID JS inden det bliver officielt frigivet, og Nets har ej heller nogen kommentarer til Christian Pantons NemID de-obfuscator på GitHub.

Fakta

NemID JavaScript er betegnelsen for den kommende udgave af NemID, som fungerer uden Java-platformen. Flere har kritiseret, at NemID i den nuværende form er afhængig af Java. Kritikken har blandt andet gået på, at sikkerhedshuller i Java i sig selv kan gøre en computer usikker, og desuden virker Java og dermed NemID typisk ikke på mobiltelefoner og tablets. Med til historien om NemID og Java hører opdateringen fra Oracle, der står bag Java, som sidste år bevirkede at NemID i tre døgn ikke fungerede hos de brugere, der havde fulgt gængs sikkerhedspraksis og opdateret til den seneste Java. Senere kom det frem, at Nets ikke havde testet om NemID ville virke med den nye opdatering fra Oracle.

Digitaliseringsstyrelsen forventer, at NemID JS, trods problemer i forbindelse med en planlagt pilottest, som planlagt bliver lanceret 1. juli.

Så er vi godt i gang med NDC Oslo konferencen. Igen i år har vi valgt at deltage på konferencen, fordi vi mener at bredden på konferencens emner gør, at alle dem der deltager fra Schultz kan finde interessante talks. Og igen i år er programmet sprængfyldt med interessante emner og talere. Her er alt fra funktionel programmering og C#/C++ over gadgets til mere bløde emner som agile processer og UX/Design.

De første to dage er pre-konferencen, hvor der er workshops som varer 1-2 dage. Her tilmelder man sig et forløb og går i dybden med nogle emner. Hos Schultz beskæftiger vi os meget med sikkerhed i web applikationer, og vi varetager vedligeholdelsen af Digitaliseringsstyrelsens SAML komponenter til NemLog-in. Derfor har de fleste tilmeldt sig workshoppen med de to sikkerhedsguruer Brock Allen og Dominick Baier. Her er der sikkerhedsnørderi for alle pengene og de nyeste teknologier som OWIN og Katana bliver pillet fra hinanden og sat sammen igen. Vi har også haft et team på funktionel programmeringsworkshop.

Sikkerhedsworkshop af Dominic Baier og Brock Allen

Der sker en masse cool ting hos Microsoft for tiden og ASP.NET gennemgår i disse måneder en stor forandring.

Claims-baseret model

Microsoft har siden lanceringen af ASP.NET for mange år siden skiftet fokus i forhold til sikkerhed og siden 2010 har de understøttet en Claims-baseret model gennem Windows Identity Foundation. En Claims-baseret model er en abstrakt model, hvor et claim beskriver noget om en given bruger. Det kunne være brugerens navn, rolle, gruppetilhørsforhold, e-mail og lignende. Windows Identity Foundation startede som et stand-alone produkt, men er siden .NET 4.5 blevet en del af frameworket, og ASP.NET applikationer benytter nu Claims-modellen som underliggende sikkerhedsmodel. Claims-modellen har den store fordel for os udviklere, at den er så tilpas abstrakt, at den nemt tillader mapning mellem forskellige autentifikationsmetoder og bruges fx når vi laver en web applikationen som tillader login på sociale tjenester som Google, Facebook og Twitter.

OWIN og Katana

Udover det store spring med en Claims-baseret model er Microsoft også begyndt at skille hele ASP.NET frameworket fra hinanden med introduktionen af OWIN og Katana (Katana er meget symbolsk navnet på et Samurai sværd). ASP.NET har vokset sig stort og bloatet gennem tiden og indeholder alt for megen funktionalitet i forhold til måden, vi i dag bygger web-løsninger på, hvor vi benytter mere lightweight frameworks som MVC og Web Api. Det har Microsoft indset, og derfor er de begyndt at skille ASP.NET ad i mindre dele og prøver dermed at lave Legoklodser i forskellige størrelser, som kan sættes sammen til en løsning. Vi synes, det er den helt rigtige vej for Microsoft og ASP.NET frameworket. Det er tydeligt, at de fortsætter med det i forbindelse med den nylige introduktion af ASP.NET vNext, hvor også .NET stakken bliver splittet op i mindre Legoklodser.

OWIN er en simpel pipeline-model som kan modtage et http request og afsende et http response. Den indkommende request sendes igennem en pipeline af såkaldte middleware komponenter, som hver håndterer requestet. Den nye sikkerhedsmodel er implementeret som middleware, og det gør hele modellen meget nem at udvide, hvor nye sikkerhedsmodeller kan kobles ind i pipelinen.

Fremtidsperspektiverne er meget interessante for ASP.NET og .NET, og det bliver nemmere for os som udviklere at kode sikre ASP.NET løsninger og at give brugerne af disse løsninger en nem mulighed for at logge ind med Google, Facebook og Active Directory. For os hos Schultz vil det være oplagt at lave OWIN middleware til at understøtte NemLog-in.

Skrevet af: Jonas, Kim, Stefan og William.

Funktionel programmerings workshop af Venkat Subramanam

Funktionel programmering er meget oppe for tiden og har affødt interesse for et hav af forskellige funktionelle programmeringssprog som Scala, Clojure, Erlang, Haskell og F#. Hvis du vil med på vognen med funktionel programmering, skal du så skifte programmeringssprog og stak? Flere af disse sprog henvender sig rigtig godt til det funktionelle paradigme, da det nu engang er det, de er bygget op omkring. Men Venkat Subramanam’s tilgang til funktionel programmering i denne workshop er ikke, at vi skal starte med at finde et nyt sprog at kode i. Vi kan i stedet starte med at tænke funktionelt i det sprog, vi er vant til at arbejde med. Sprog som C# og Java har nemlig i dag faciliteterne til, at du kan arbejde funktionelt.

Derfor er Venkat’s tilgang til denne workshop også: “Hvilket sprog koder du i til hverdag?”. Under workshoppen har der kørt eksempler i primært C# og Java, da der var flertal for disse sprog blandt deltagerne, men der har også været adskillige eksempler i JavaScript, Ruby og F#.

Et radikalt anderledes paradigme

Funktionel programmering er et radikalt anderledes paradigme end objektorienteret, og sprogene er typisk designet som enten et funktionelt, objektorienteret eller mixet sprog.
Til dagligt arbejder vi i C#, og selvom C# understøtter muligheden for funktionel programmering via Action og Func, vil sprogets objektorienterede design hele tiden tillade dig, at du træder ved siden af. Derfor tror vi også, det er vigtigt at forstå, hvad der faktisk er motivationen bag den funktionelle tilgang, så du kan holde dig på den funktionelle sti.

Den helt grundlæggende metode til funktionel programmering er, at man skal designe “pure functions”. Dette er metoder/funktioner, der givet det samme input, til hver en tid vil returnere det samme output. De kan ikke være afhængige af delt tilstand såsom member variable i et objekt eller tid. En metode skal være enkapsuleret af udelukkende dets input variable. Et andet vigtigt punkt er, at data er immutable, altså en funktion må ikke ændre i tilstand – heller ikke i input parametre, udelukkende returnere nye data.

Som vi ser det, er det fire umiddelbare store fordele ved denne tilgang
* Koden bliver nemmere at teste. Du tvinger dig selv til at anvende en metode der er meget præcis omkring, hvad den skal bruges til, for at kunne udføre sit arbejde
* Det bliver sværere som udvikler ikke at tage stilling til parallelisering af sin kode. Med den funktionelle tilgang bliver dette til en triviel opgave, da du ikke har shared state!
* Du skulle begynde at se færre fejl i din kode. Mange af de fejl vi får introduceret, skyldes ofte, at vi piller ved tilstanden af objekter/data på kryds og tværs i en metode, og så er det, at man liiige misser en lille uskyldig metode, der ændrer en variabel, man ikke havde forventet
* Din kode bliver mere koncis og enkel at overskue, når metoder ikke har side effects, men kæder atomare operationer sammen

Vores udgangspunkt som .NET udviklere har været, at funktionelle programmeringssprog i høj grad er noget, der gør sig gældende i den finansielle verden, eller andre regnetunge områder. Typisk kan man observere, at dele af ens applikation måske ville drage fordel af at blive refaktoreret i et funktionelt programmeringssprog, såsom regelmotorer og heuristik over store datasæt. Desværre bliver man hurtigt forpustet ved tanken om at introducere nye moving parts, nye sprog og risiko.

Jeres erfaringer?

Vi er nysgerrige efter, om nogen af jer læsere har erfaring med at indføre funktionel programmering i projekter – eller måske introducere komponenter skrevet funktionelt, i et i forvejen objektorienteret program? Har det ændret på, hvordan I tilgår jeres løsninger?

Skrevet af Allan og Anders

Følg os frem til fredag på denne blog og på twitter #ver2ndc