BEKK Open » Teknologi

Riktig beskyttelse mot Cross Site Scripting- og SQL-injection-angrep

Erlend Oftedal — Fri, 25 Jun 2010 12:11:49 +0000

De siste årene har vi sett flere massive SQL-injection- og Cross Site Scripting (XSS)-angrep mot store siter. Twitter hadde nylig en XSS-feil og i begynnelsen av juni var det et stort angrep mot siter som kjørte en bestemt annonsekomponent. Beskyttelse mot denne type angrep, krever at man tenker på kontekst når man skriver kode.

Validering av input er ikke løsningen
Tidligere snakket man ofte om at manglende validering av input var årsaken til disse feilene. Dette er dessverre ikke riktig. Validering av input handler om å sjekke at input er riktig i forhold til domenet. Dette vil riktignok stoppe mange angrep, men på langt nær alle. Et godt eksempel er navnet “Ken-Martin O’Conner”. Dette etternavnet inneholder flere tegn som også er kontrolltegn i SQL. For å kunne godta dette navnet må man ved validering av input godta bånde bindestrek og fnutter. Dermed vil man også tillate et angrep som ' OR '' LIKE '' --. Man kan selvsagt forsøke å gjøre valideringen enda strenger, men man risikerer kjapt å avvise gyldig input.

Jeg sier ikke at validering av input er unødvendig – det er bare ikke løsningen på dette problemet.

Kontekst og escaping
Problemet ved både XSS- og SQL-injection-feil er at data flyter fra en kontekst og over i en annen. Ved overgang fra f.eks. javakode til SQL, må vi sørge for at vi beholder semantikken. Skal vi sette inn en datastreng i en SQL-spørring, må vi sørge for at det forblir en streng. Dette gjør vi ved å foreta output escaping. For SQL er løsningen enkelt og greit å ta i bruk parameteriserte spørringer (prepared statements). Bruker vi prepared statements og gir inn parametrene i etterkant, vil rammeverket håndtere escaping av kontrolltegn for oss.

For XSS er det desverre noe vanskeligere. Når data forlater vår applikasjon og går over til noe browseren skal tolke, er det nemlig flere mulige kontekster. Vi kan skrive ut innhold i javascript, javascript i HTML, mellom HTML-tagger, i HTML-attributter osv. Og flere av disse kontekstene må behandles forskjellig. Vi kan begynne med input som skrives ut mellom HTML-tagger. Dette er den enkleste konteksten. Vi kan bruke dette eksempelet:

Du søkte på "her kommer inputten"

For å hindre kjøring av script her, må vi sørge for at input ikke kan åpne nye tagger, f.eks. en ... ...

Her er det kanskje lett å tenke at det holder å legge til en backslash forann eventuelle enkle fnutter (' blir til \'), men vi må huske at vi er i en såkalt dobbel-kontekst: Javascript-kontekst inni en HTML-kontekst. Vi må derfor også passe oss for HTML-tegn. Her er et eksempel på hvorfor man må escape for begge kontekster.


For mer informasjon om de forskjellige XSS-kontekstene, se OWASP XSS Prevention Cheat Sheet.
For .NET finnes det et bibliotek kalt Web Protection Library. Dette biblioteket har en komponent som heter AntiXSS, som kan escape for forskjellige kontekster. For Java kan man f.eks. benytte encoderen i ESAPI.
Oppsummert

Beskyttelese mot disse angrepene må gjøres med kontekstbasert escaping idet vi bytter fra en kontekst til en annen.



Hvorfor trenger DIN bedrift en strategi for sosiale medier?
Rune F. Åsprang — Wed, 16 Jun 2010 09:38:00 +0000
Norske virksomheter har brukt noen år på å bestemme seg for å bruke sosiale medier. Fra ”forbudstiden” i 2006-2007, da flere bedrifter nedla forbud mot bruk av Facebook i arbeidstiden (se her for et eksempel – det føles lenge siden nå, gjør det ikke?), har nå de aller fleste norske bedrifter bestemt seg for å ha et bevisst forhold til sosiale medier. Dialog som angår bedrifter pågår i sosiale medier og bedriftene ønsker altså å ha et bevisst forhold til dette, men hva gjør man så? Trenger bedriftene en egen strategi for tilstedeværelse i sosiale medier?
I en nylig publisert undersøkelse fra Dataforeningen konkluderes det med at 8 av 10 norske bedrifter har bestemt seg for å bruke sosiale medier – dette er 25 % mer enn for et halvt år siden. Undersøkelsen sier videre at 74% prosent av norske virksomheter har hatt sosiale medier som tema for diskusjon i ledergruppen. 67% av respondentene i undersøkelsen mener at virksomheter som ikke har en strategi for sosiale medier vil møte problemer. Det er altså ingen tvil om at holdningene til sosiale medier er i kraftig endring i norske bedrifter!
Skeptisk?
Motargumentene mot store norske virksomheters tilstedeværelse i sosiale medier vil alltid være tilstede. Frykt for at brukerne på sosiale medier er negative, angst for delekultur og åpenhet og spørsmål rundt personvern og IT-sikkerhet er vanlige motargumenter mot å ta skrittet ut i de sosiale medienes verden. Men veier fordelene opp for ulempene?
Sosiale medier har sine fordeler!
En bevisst tilstedeværelse i sosiale medier gir mulighet til å utnytte markedets engasjement for selskapets merkevare(r) til selskapets fordel. Dialog i sosiale medier fostrer innovasjon – ideer  til forbedring oppstår lettest gjennom dialog og samspill. Sosiale medier er som skapt for dette. Bedrifter som lytter til varepraten i sosiale medier, og bruker dette aktivt i sin forretningsutvikling, utvikler produkter som kundene vil betale for!
Sosiale medier byr på en unik mulighet til å synliggjøre bedriftens handlekraft og smidighet. Hvilke andre muligheter har en bedrift til å fortelle markedet daglig om hva man gjør for å utvikle bedre produkter og tjenester og hvordan man jobber for sine kunder? Benytter man seg av mulighetene de sosiale mediene gir bygger man etter min mening omdømme med en effektivitet som tidligere var umulig.
Trenger man en strategi for sosiale medier da?
Varepraten og dialogen om virksomheter går i de sosiale mediene uansett, man må forholde seg til disse mediene enten man vil eller ikke. Edgar Valdmanis i Dataforeningen oppsummerer dette på en glimrende måte: ”Dine ansatte er der, dine kunder er der, dine leverandører er der. Hvis du neglisjerer dette, er det på egen risiko!”
Store norske virksomheter bør derfor investere tid og ressurser i å utarbeide en strategi for sin tilstedeværelse i sosiale medier. Strategien bør gjøres lett tilgjengelig for alle ansatte – enkelhet og evnen til å fatte seg i korthet er suksessfaktorer i så måte. Som et minimum bør en strategi for tilstedeværelse i sosiale medier klart definere hva man ønsker å oppnå (mål), hva man skal gjøre (satsingsområder) og hvor man skal gjøre det (Twitter? Facebook? Egen blogg? Eget nettsamfunn?).
Investering i strategi vil tilbakebetales!
Investeringen i en strategi for tilstedeværelse i sosiale medier vil tilbakebetales gjennom økt effekt av ressursbruk på sosiale medier og økt seriøsitet i sosiale medier.
Økt effekt av ressursbruken på sosiale medier oppnår man gjennom at strategien gir en klar retning og et fokus til satsingen i sosiale medier. Dette forenkler prioritering av ressursbruken på sosiale medier og man unngår bruk av ressurser på områder der forventet effekt er lav.
Bedrifter som har en strategi for tilstedeværelse i sosiale medier opplever økt grad av seriøsitet i sosiale medier blant de ansatte. Ansatte som er trygge på at ledelsen har en plan for bedriftens tilstedeværelse i sosiale medier unngår å ”ta ansvar” for å svare på bedriftens vegne når de finner det for godt. Wimpgate og Warnerfail er eksempler de fleste bedrifter forsøker å unngå.
For å etablere en profesjonell tilstedeværelse i sosiale medier trenger man altså en strategi som definerer fokus for tilstedeværelsen. Det å definere fokus handler mer om å velge bort enn å velge. Hva vil vi oppnå med vår tilstedeværelse i sosiale medier? Hva skal vi gjøre i sosiale medier? Hvordan skal vi fremstå? Hvilke kanaler skal vi bruke? Hvilke avdelinger eller forretningsområder skal være ansvarlige?
Dette er sentrale spørsmål som må besvares i en strategi for tilstedeværelse i sosiale medier. Og ja, jeg mener at DIN bedrift trenger en strategi for tilstedeværelse i sosiale medier!



Komponentbaserte webrammeverk: Tapestry 5
Thomas Fossum — Thu, 03 Jun 2010 15:17:30 +0000
Nytt prosjekt, nye muligheter!
Når man planlegger et utviklingsprosjekt for web vil dette som oftest innebære et valg av webrammeverk. Det er etterhvert blitt svært mange å velge blant, og det kan være en utfordring å få oversikt over hva som skiller de ulike rammeverkene. Tradisjonelle action-baserte webrammeverk som Struts2 og Spring MVC har modne og velprøvde API, og blir ofte valgt fordi man her har erfaring fra før og fordi rammeverkene støttes av en stor community. Men blant alternativene som bør vurderes finnes en rekke komponent-baserte rammeverk med en mer høynivå tilnærming. Disse rammeverkene lover rask og effektiv utvikling med et minimum av konfigurasjon, og konfigurerbare, kraftige komponenter som holder på sin egen tilstand og gir rik funksjonalitet rett ut av boksen. Rammeverkene er ment å være utviklervennlige, med utstrakt implementasjon av best pactices.
Tapestry er et open source komponent-basert webrammeverk som har vært under utvikling siden starten av 2000-tallet. Med versjon 5 har rammeverket fått mye oppmerksomhet og positiv omtale. I likhet med Wicket er det nå tatt inn som et Apache-prosjekt, noe som betyr at kildekoden er tilgjengelig med Apache Software Licence 2.0.
Hvorfor skal så du vurdere dette rammeverket kontra tradisjonelle action-baserte webrammeverk?
Utviklerne bak Tapestry har definert fire egenskaper som de anser som de viktigste for et rammeverk:

Enkelhet – å utvikle webapplikasjoner skal ikke trenge å være så komplisert. Mye kompleksitet blir håndtert av rammeverket, som utvikler skal du få fokusere på forretningslogikk.


Konsistens – Rammeverket skal ha en konsistent oppførsel, med komponenter som er “self contained”, altså holder på sin egen tilstand. Webapplikasjoner lagd med Tapestry skal ha en uniform struktur og utviklere skal kunne bygge på best practices.


Effektivitet – Applikasjoner basert på Tapestry skal ha god ytelse og skalerbarhet. Utviklingsprosessen skal også være så effektiv som mulig.


Tilbakemelding – Rammeverket skal gi god og relevant informasjon til utvikler hvis feilsituasjoner oppstår.

Hvordan er så dette implementert i Tapestry 5?
Enkelhet
En webapp lagd i Tapestry består av et sett med sider som håndteres av rammeverket. En side består av en template (med en eller flere gjenbrukbare komponenter) og en tilhørende javaklasse med samme navn. Javaklassen er en POJO uten avhengigheter til andre deler av rammeverket; ingen superklasse som må extendes, ingen interface må implementeres.
Denne understøttende javaklassen tilsvarer en Controller i et action-basert rammeverk, og håndterer events som kommer fra viewet. Dette ligner mye på måten tradisjonelle desktop-applikasjoner fungerer, og innebærer et høyere nivå av abstraksjon fra request/response-modellen som f.eks Struts2 og Spring MVC bruker. Urler og request-parametere er erstattet av metoder og egenskaper ved side-objekter. Komponenter er også bygget opp på samme måte; en template og en javaklasse med samme navn, uten avhengigheter. Bruken av POJOs gjør det lett å lage egne testbare komponenter, samt å utvide eksisterende komponenter.
Så hvordan kan Tapestry sette sammen templates og tilhørende javaklasser når disse ikke arver fra en rammeverkspesifikk superklasse eller implementerer bestemte interfaces? Tapestry bruker bytecode weaving til å legge til tapestryspesifikk kode ved runtime. Dette skjer ved at sider og komponenter bruker annotations for å beskrive hvordan rammeverket skal håndtere koden. En kan også bruke navnekonvensjon på metoder som lytter på events, og dermed redusere bruken av annotations. Den utstrakte bruken av annotations og navnekonvensjoner øker lesbarheten og reduserer mengden boilerplate kode.
En siste viktig detalj mht enkelhet er at konfigurasjon gjøres programatisk i en egen javaklasse. Dette gir svært lite deklarasjon i XML å forholde seg til, kun web.xml. Tapestry kommer med en defaultkonfigurasjon som man kan utvide og endre ved behov.
Konsistens
Et viktig designprinsipp for Tapestry er “convention over configuration”. Sider, komponenter, templates, services etc må ligge i bestemte kataloger, og følge bestemte navnekonvensjoner. Det man tjener på dette er redusert behov for konfigurasjon, samt en konsistent struktur på webapplikasjonen.
Alle komponenter er self-contained og kan plasseres på hvilken som helst side. De holder sin egen state uten behov for parametere.
Effektivitet
I likhet med andre komponentbaserte webrammeverk er Tapestry svært velegnet til prototyping og rask utvikling av webapplikasjoner.
Kraftige, gjenbrukbare komponenter gir mye funksjonalitet ut av boksen, og disse er enkle å modifisere og utvide. Det er også enkelt å utvikle egne komponenter. Rammeverket kommer med bl.a URL-håndtering, mulighet for tilstandshåndtering på klient eller server, inputvalidering, internationalization, AJAX-støtte og feilrapportering innebygget, og integrasjon mot en rekke kjente rammeverk som Spring og Hibernate er inkludert.
Som utvikler ønsker man å produsere mest mulig funksjonalitet raskest mulig, med færrest mulig feil. Code-test-deploy roundtrip bør derfor være så kort som mulig, og rammeverket må understøtte testdrevet utvikling. Nettopp effektivitet og testbarhet er blant Tapestrys sterkeste kort.
Med live class reloading av alle komponent-klasser trenger man ikke redeploye aplikasjonen for å se resultatet av en endring i koden. Tapestry har en egen classloader som ser etter endringer i koden, og dette muliggjør høy produktivitet. Ettersom komponentene i Tapestry håndterer sin egen tilstand og eventhandling abstraherer bort mye kompleksitet kan utviklere heller konsentrere seg om forretningslogikk. Tapestry er også velegnet for TDD, med sider og komponenter som er POJOs uten avhengigheter til rammeverket.
Et annet viktig prinsipp for Tapestry er “static structure, dynamic behavior”.

Med dette menes at strukturen til en gitt side er statisk mens logikken i komponentene gjør at sidene likevel er dynamiske. Med en statisk instans av strukturen for en side kan denne pooles av rammeverket. Dette gjør at en side som aksesseres flere ganger vil gjenbrukes, noe som er gunstig både for ytelse og skalering. Tapestry lagrer mindre data i HttpSession enn andre komponentbaserte rammeverk som JSF og Wicket, fordi bare data fra en side lagres, ikke hele side-instansen.
Tilbakemelding
Når en feilsituasjon oppstår vil Tapestry gi utvikler en detaljert og informativ feilmelding. Feilmeldingen vil referere til riktig kodelinje i den originale kildekoden, med et utsnitt av den aktuelle kodebiten og en mulig feilårsak og løsning.
Så er alt bare gull og Tapestry 5 et soleklart valg i ditt neste prosjekt?
Det er endel aspekter man bør være klar over når man vurderer Tapestry.
Rammeverket har fått endel pepper for manglende bakoverkompatibilitet ved major releases. Versjon 5 er en omfattende omskrivning ift v4, og en migrering av et eldre prosjekt vil være tidkrevende. Nå loves det fra utviklerne at man f.o.m v5 ikke skal få dette problemet så lenge selve grunnkonseptene ikke endres.
Komponenter som håndterer sin egen tilstand gjør at man kan få mye data i session scope og dermed stort minneforbruk; dette er en generell problemstilling for komponentbaserte webrammeverk. Tapestry håndterer dette vha førnevnte side-pooling og lagring kun av data for en side i session. Man kan også optimalisere applikasjonen ved å sette en grense for antall sider i session.
Bruken av en pool med side-instanser begrenser også den potensielt uheldige effekten for ytelse som runtime bytecode weaving kan ha. Sider vil ta kun ta lenger tid å laste ved førstegangs aksess, så dette er ikke et større problem i Tapestry enn f.eks i JSP.
Feilsøking i generert tapestrykode kan være frustrerende. Koden du har skrevet blir vevd sammen med tapestrykode runtime, og en bug kan ligge i koden fra rammeverket. Du har da muligheten til å sette loglevel til DEBUG, og få ut logg for den endelige, genererte koden.
Lærekurven kan være bratt hvis man tidligere kun har skrevet webapplikasjoner i action-baserte rammeverk. Erfaring fra utvikling av desktop-applikasjoner vil være relevant for det programmeringsparadigmet man bruker i Tapestry. Dokumentasjonen er blitt mye bedre med versjon 5, og veien til den første Hello World-applikasjonen er ikke lang.
Tapestry har færre brukere og aktive commiters enn f.eks Struts2, Spring MVC og JSF, men community er i vekst nå som Tapestry er blitt et Apacheprosjekt.
Konklusjon
Hvis du skal vurdere webrammeverk til en applikasjon med et rikt GUI og ønsker å utvikle dette uten bruk av plugins må komponentbaserte webrammeverk vurderes. Med Apache i ryggen og en økende brukermasse er Tapestry 5 et webrammeverk i positiv utvikling.
Tapestry gir deg et bibliotek med kraftige, utvidbare og godt dokumenterte komponenter, og sikrer en rask utviklingssyklus med live class reloading. Rammeverket forenkler utvikling av rike GUI for web og er godt egnet for testdrevet utvikling. For å oppnå enkelhet ved utvikling må man ofre noe fleksibilitet. Ved å akseptere de valg som er gjort i rammeverket får man konsistens, på bekostning av ubegrenset mulighet til å implementere egne patterns.
Tapestry 5 bør være på lista når webrammeverk skal velges i ditt neste prosjekt.



Automated functional testing of iPhone apps with iCuke
Aslak Hellesøy — Wed, 02 Jun 2010 12:05:20 +0000
Seeing the downloads of the open source BDD/Acceptance Testing tool Cucumber skyrocketing is great, but seeing what insane extensions the community comes up with is even greater.
UK-based super hacker and long time Cucumber contributor Rob Holland announced iCuke yesterday. iCuke is a Cucumber extension that lets you write automated functional tests for iPhone apps. Here is a little teaser…

iCuke from Aslak Hellesøy on Vimeo.
For questions about iCuke, please use the iCuke mailing list.



Det lønner seg å dele: GoOpen 2010
Jon Grov — Tue, 04 May 2010 21:07:41 +0000
Nasjonalt kompetansesenter for fri programvare, ofte kalt Friprogsenteret, arrangerer hvert år konferansen GoOpen. Flere av våre kunder tjener på pragmatisk og effektiv bruk av fri programvare. Se vår direktør for kundeutvikling, Jon Fageraas, fortelle hvorfor dyp kunnskap om både fri programvare og etablerte kommersielle produkter er nødvendig for å være en god leverandør.


Blant konferanseforedragene var Avinors erfaringer med offentliggjøring av data (som du også kan lese mer om her),  Norwegians sofistikerte og sammensatte arkitektur for flyreservasjon, samt NAVs nye stillingssøk basert på søkemotoren Solr. Sistnevnte ble filmet, se foredraget til NAVs portalansvarlig Magnus Børnes Hellevik sammen med Carl Christensen lenger ned.
GoOpen 2010: Avinor
GoOpen 2010:  Norwegian
GoOpen 2010: NAV
Stor takk til Friprogsenteret, og ikke minst til bidragsyterne, for at presentasjonene er gjort tilgjengelig.



Om arkitektur og hvordan den blir til
Vidar Kongsli — Mon, 12 Apr 2010 07:13:44 +0000
I mitt tidligere innlegg “Om arkitektur” forsøkte jeg å si noe om hva  arkitektur innen informasjonsteknologi betyr og hvilket fokus  arkitekturarbeidet bør ha. Jeg forsøkte å analysere hva ordet arkitektur  kommer av og hvordan den klassiske tolkningen av ordet gikk ut på.  Videre forsøkte jeg å trekke paralleller til hvordan arkitektur bør  tolkes innen informasjonsteknologi. Minst like viktig er det å se på  hvordan en arkitektur blir til, og ikke minst hvilke oppgaver en  arkitekt bør ha i så henseende. I dette innlegget forsøker jeg å komme  med noen tanker rundt dette.
“Jeg har sett mange gode arkitekturer som aldri ble noe av”
Dette sitatet (fritt etter hukommelsen) hørte jeg fra en foreleser på en  konferanse for en tid tilbake. Min første tanke var: “var arkitekturen god hvis den  ikke ble noe av”? Hvis vi igjen skal se på gode, gamle Vitruvius som jeg  nevnte i mitt forrige innlegg; oppfyller arkitekturen som ikke ble noe  av ikke prinsippene firmitatis utilitatis venustatis? Ikke var  den robust, ikke var den nyttig for brukerne og den fikk aldri sjansen  til å vise sin skjønnhet. Vel. Mer fruktbart er det kanskje å spørre seg  hvorfor en arkitekturplan aldri ble noe av. Det kunne være at den ble  for dyr, det kunne være at den ikke løste utfordringene den skulle eller  det kunne være at den ikke hadde tilstrekkelig forankring i  organisasjonen. Like viktig som hva en arkitektur består av, er hvordan  den ble til.
Arkitektur ikke bare en arkitekts anliggende
Arkitektur er et tverrfaglig område. Det omhandler forretningen  (hvilken funksjonalitet er ønsket, og hvilken verdi gir den?),  økonomi/finans (hva er kostnadene? Oppstartskostnader vs. operasjonelle  kostnader, osv.) og ikke minst teknologi (modenhet, tilgjengelighet,  osv.). En god arkitekturprosess krever forankring og involvering fra  ulike deler av organisasjonen og jo mer eierskap de involverte føler, jo  større er sjansen for å lykkes. Et eksempel på dette er smidige  utviklingsprosjekter, der arkitekturspørsmål bør kunne diskuteres og  løses i utviklingsteamet. I den grad man har arkitekturprinsipper som  går på tvers av prosjekter, bør man sikre tilstrekkelig involvering på  tvers av prosjekter, f.eks. gjennom at arkitekter dedikeres til  prosjektene og kan jobbe tett med utviklingsteamene.
Arkitektur og “Big Design Up Front”  – BDUF
I mitt tidligere innlegg pekte jeg på at arkitektur er en delmengde av  design i den forstand at design kan skje på alle granularitetsnivåer og  kan gjerne omhandle en moduls eller applikasjons interne organisering,  mens arkitektur fokuserer på helheten og eksterne kvaliteter. I smidige  prosjekter ønsker man å unngå det man kaller “big design up front“,  altså at design skjer før utviklingen eller implementasjonen starter.  Dette er et prinsipp som brukes uavhengig av hvilke smidige metoder som  benyttes, men jeg syns Lean Software Development er nærmest å forankre  prinsippet teoretisk. I mine øyne er fravær av BDUF en følge av tre  Lean-prinsipper: 1) vektlegge læring, 2) ta avgjørelser så sent som  mulig og 3) mindre avfall, “eliminate waste”. Ved å kjøre  designprosessen som en del av utviklingsprosessen kan man ta med seg  læring inn i designprosessen. Videre kan man utsette designavgjørelser  lengre slik at man har mer informasjon og kunnskap tilgjengelig som  beslutningsgrunnlag og dermed forhåpentligvis ta en bedre avgjørelse enn  man kunne gjort tidligere. Til sist, hvis design gjøres samtidig som  implementasjonen, sparer man unødig ressursbruk til dokumentasjon i og  med at de involverte har informasjonen i mente allerede. Mer om  dokumentasjon senere…
Spørsmålet er om regelen om å unngå “big  design up front” også gjelder for arkitektur? Ja og nei. Noen  arkitekturavgjørelser må ofte tas før man starter implementasjon. Dette  kan for eksempel være hvilken implementasjonsplattform man ønsker å  bruke (Java EE eller .NET, for eksempel). Det som er viktig i slike  sammenhenger, er som jeg nevnte i forrige avsnitt at man utsetter  avgjørelser som er vanskelig å omgjøre så lenge som mulig. Spesielt  viktig er det også å utsette avgjørelser som introduserer mye  kompleksitet så lenge som mulig fordi kompleksitet ofte introduserer  avhengigheter. Disse bidrar så til å krympe mulighetsrommet for  arkitekturen. Med andre ord får man mindre frihetsgrader. I den grad man  kan gjøre det, bør man fatte avgjørelser som kan omgjøres for å unngå å  male seg inn i et hjørne. Et godt innlegg om det å utsette avgjørelser  finner du her.
Et dokument er ikke arkitektur
“Leveransen fra arkitekturprosessen er et arkitekturdokument”. “I følge  rammeverk X skal leveransen fra arkitekturprosessen være et Y-diagram,  en Z-modell, … , samt en forretningmodell”.  Lyder kjent? Å ha noe  håndfast (i den grad man kan omtale et elektronisk dokument som  håndfast, man kan i det minste skrive det ut for å få noe håndfast) å  vise til som resultat av en investering gir en god og varm følelse. I  klassisk transaksjonstankegang er dette viktig fordi det er et synlig  bevis for hva man har fått igjen, og et sett arkitekturprinsipper som  eksisterer inni hodene på folk ikke gir den samme følelsen av å ha fått  noe tilbake.
Å benytte et rammeverk for arkitektur som definerer  et sett av dokumenter som skal produseres gir også troverdighet som det  er behagelig å lene seg på. Dette er selvfølgelig vissvass. Et  arkitekturrammeverk er et tomt skall uten innhold, og det er innholdet  som er viktig.
Arkitektur består av en del fokusområder /  kvaliteter (eksempelvis firmitatis utilitatis venustatis). Disse  er i stor grad ideer eller prinsipper, og det er veldig vanskelig å  formidle ideer og prinsipper i dokumenter. Enklere er det derimot å  overføre ideer muntlig, og enda bedre; hvis man selv har vært med på å  komme frem til disse har man en enda bedre forståelse (og ikke minst et  større eierskap). Dokumenter er den dårligste kommunikasjonsformen, og  burde brukes når andre former ikke er tilgjengelige. Dette kan være  tilfelle på grunn av avstand til brukere; både organisatorisk,  geografisk og i tid. Som jeg nevnte i forrige avsnitt; den  organisatoriske avstanden bør minimeres gjennom involvering, og som jeg  nevnte i avsnittet om BDUF, avstanden i tid bør minimeres ved å utsette  arkitekturavgjørelsene så lenge som mulig.
Oppsummering
Gjennom disse to innleggene om arkitektur har jeg vært innom flere  aspekter som kan oppsummeres som følger:

Arkitektur fokuserer  på helheten og på eksterne kvaliteter (hva som er eksternt varierer dog  avhengig av perspektivet)
Arkitektur består av en del  kvalitetsområder eller prinsipper, eksempelvis firmitatis utilitatis  venustatis
Arkitekturarbeid er en tverrfaglig prosess der  involvering fra ulike deler av organisasjonen er viktig
Arkitektur  bør utvikles gradvis, parallelt med implementasjon der man underveis  nyttiggjør seg lærdom man opparbeider seg
Leveransen fra  arkitekturarbeid bør ikke defineres i form av dokumenter.  Kommunikasjonsformen bør tilpasses situasjonen.




Om arkitektur
Vidar Kongsli — Tue, 06 Apr 2010 11:05:58 +0000
Innen IT-bransjen finner man “arkitektur” overalt. Vi har  systemarkitektur, databasearkitektur, data-arkitektur,  løsningsarkitektur, sikkerhetsarkitektur, integrasjonsarkitektur, og vi  har 3-lagsarkitekturer. Beveger man seg på spesifikke plattformer har  man J2EE-arkitektur og .NET-arkitektur. Nå om dagen sliter bransjen  (skal vi tro tidsånden) med monolittiske arkitekturer, og løsningen er  en tjenestebasert arkitektur. Betimelige spørsmål er hva arkitektur  egentlig er, hva kjennetegner god arkitektur og hvordan oppnår man den?
Arkitektur  fokuserer på helheten
Selv om man skal være forsiktig med å trekke  paralleller mellom arkitektur i IT-verdenen og den klassiske betydningen  av arkitektur, er det interessant å studere etymologien for å få en  forståelse av hva ordet har blitt brukt til og hva det har representert  tidligere. Ordet arkitektur stammer fra gresk “arkitekton” (via latin  “architechtura”) og er sammensatt av de to ordene “ὰρχι” (hoved- eller  sjef-) og “Τεκτονική” (håndtverker, bygger). En arkitekt er altså en  “sjefsbygger”.
Om arkitektur står det også å lese at den ble ofte  kalt moderkunsten fordi den fokuserte på helheten (kilde:  kunsthistorie.com). Dette er noe vi kan kjenne igjen daglig bruk av  arkitektur i vår bransje. Arkitektur handler om helheten, de store  linjene. Man kan snakke om “overliggende arkitektur”, selv om det  muligens er smør på flesk, men det gir ikke noen mening å snakke om  “detaljert arkitektur”. Man kan derimot snakke om “detaljert design”;  til forskjell fra arkitektur er design noe som kan gjelde ulike  granularitetsnivåer. Forskjellen mellom arkitektur og design er at  arkitektur fokuserer på helheten og et systems eksternt synlige,  ikke-funksjonelle kvaliteter, mens design gjerne kan omhandle interne  kvaliteter. Eksempelvis er intern kodeorganisering som noe som omhandler  design, men ikke arkitektur. Derimot er valg av plattform, f.eks. J2EE  eller .NET, noe som anligger arkitektur i og med at det sannsynligvis er  et valg som har noe å si for eksterne egenskaper. Dette er forøvrig  også en del av designet, og derav følger at arkitektur er en delmengde  av design.
Den klassiske arkitekturen – firmitatis utilitatis  venustatis
I min noe vilkårlige og overfladiske omgang med  klassiske verker er jeg funnet “De architectura” (“Om arkitektur”) av  Vitruvius. “De architectura” er antikkens mest kjente referanse for  definisjon av arkitektur. Den er inndelt i ti seksjoner og omhandler alt  fra byplanlegging, materialkunnskap og vanntilførsel til bruk av  maskiner. Vitruvius mener at en god bygning må etterleve de tre  prinsippene firmitatis utilitatis venustatis som kan oversettes  (av meg, via engelsk) som:

Styrke (eller robusthet) – den  skal være bygd på et solid fundament og bygd av nøye utvalgte materialer
Funksjonalitet  (eller brukbarhet) – gjennom en fornuftig sammensetning av dens deler  slik at delene kommer til sin rett
Skjønnhet – den skal ha  et fint utseende og fremstå som en helhet der alle delene er  proporsjonert i forhold til hverandre

Er dette  prinsipper som også gir mening i vår bransje? Som jeg nevnte  innledningsvis, er det lett å gå seg vill i alle arkitekturbegrepene.  Fra nå av omtaler jeg “arkitektur innen informasjonsteknologi” kort og  godt som “arkitektur”, og når jeg omtaler arkitektur i klassisk forstand  som “bygningsarkitektur” eller “klassisk arkitektur”.
Klassiske  prinsipper anvendt i vår hverdag
Styrke (eller robusthet)
For  en bygning er det lett å være enig i at den må ha et tilstrekkelig  solid fundament og at den må være bygd av egnede materialer. For et  IT-system er ikke dette like intuitivt. Når det gjelder programvare  (“mykvare”) skal denne være myk og formelig for å kunne imøtekomme  fremtidige krav som oppstår gjennom systemets livssyklus. I motsetning  til styrke i form av fasthet eller ubevegelighet, er “endringsvennlighet” (eng.  “changeability”) en kvalitet som vi ønsker i arkitekturen  vår. Samtidig er det sjelden mulig å ha en arkitektur som er åpen for  alle mulige endringer, noen fundamenter må være fastere enn andre.  Utfordringen består i å forutse hvilke endringer som er sannsynlig kommer  og hvilke som er usannsynlige. Klarer man det, kan man sørge for at  designvalg ikke påvirker endringsvennligheten i negativ retning.  Man  kan muligens også snakke om at en arkitektur er “robust og slitesterk” i  den forstand at den skal kunne imøtekomme nye bruksmønster og at den  skal være skalerbar og anvendbar i ulike situasjoner. Jeg tør også påstå  at jo lavere kompleksitet arkitekturen har, jo større er  sannsynligheten for at den blir anvendbar i fremtiden.
Funksjonalitet  (eller brukbarhet)
Prinsippet utilitatis er noe som i mine  øyne er direkte overførbart til vår bransje. “Nytteverdi” er muligens et  enda bedre ord for denne egenskapen. Høy nytteverdi oppnås ved at  systemets ulike deler spiller sammen slik at hver enkelt del er  formålstjenlig og virker sammen i en helhet. Ikke vanskelig å være enig i  dette, utfordringen man har som arkitekt er ofte å sørge for et riktig  utvalg av komponenter og integrere disse slik at de spiller godt sammen.
Skjønnhet
Skal  vi anvende prinsippet om venustatis i vår hverdag, må vi kanskje  ha et litt videre perspektiv en visuell skjønnhet. (Uten at jeg skal  påstå at Vitruvius kun refererte til visuell skjønnhet.) Er skjønnhet  noe som vi arkitekter vanligvis fokuserer på?  Burde vi? Og hva er  “skjønnhet” i en arkitektur? I “Zen of Python“, som omhandler  designprinsipper for programmeringsspråket Python, sier Tim Peters at  “beautiful is better than ugly”. Dette hjelper oss kanskje ikke så mye  nærmere svaret. La oss heller snu om på det og si at skjønnhet er det  som behager og gleder folk, hva nå enn det er. Og hvem er folk? Jo, det  er sluttbrukere, arkitekter, driftspersonell og utviklere (blant andre).  “Vakker i sin enkelhet”, sier man ofte, og i mine øyne er enkelhet  viktig i en arkitektur. Er arkitekturen enkel og lett å forstå, så er  den “vakker i sin enkelhet”.
Som vi ser er de klassiske  prinsippene for arkitektur absolutt anvendbare på informasjonsteknologi,  og jeg tør påstå at de også gir verdi gjennom å hjelpe til gi innsikt i  hva man bør vektlegge.
Moderne prinsipper for arkitektur
Hvis  vi så forlater antikken og stiger inn i nåtiden så finnes det andre  oppfatninger om hva arkitektur omhandler. Her er en liste fra “Beautiful  architecture”  som jeg syns er nyttig:

Funksjonalitet – hvilken  funksjonalitet som systemet tilbyr brukerne
Endringsvennlighet –  hvilke endringer kommer til måtte gjøres i fremtiden, og hvilke  endringer er ikke sannsynlige?
Ytelse – hva vil systemets ytelse  være?
Kapasitet – Hvor mange samtidige brukere skal systemet  betjene? Hvor store datamengder skal det behandle?
Økosystem –  hvordan vil systemet samhandle med andre systemer i økosystemet det skal  produksjonssettes i?
Modularitet – hvordan deler man opp jobben  med å utvikle systemet og i særdeleshet; hvordan kan systemet  modulariseres slik at modulene kan utvikles uavhengig av hverandre og  samtidig imøtekomme hverandres krav presist og enkelt?
Byggbarhet  – Kan systemet bygges som et sett av komponenter som kan implementeres  og verifiseres uavhengig av hverandre? Hvilke komponenter burde  gjenbrukes fra andre produkter og hvilke burde anskaffes fra eksterne  tilbydere?
Produktifisering – hvis systemet skal eksistere i  ulike versjoner, hvordan kan det utvikles som en produktlinje?
Sikkerhet  – Hvordan kan informasjonssikkerheten ivaretas?

Denne  listen inneholder en del fellespunkter med de vi fant hos Vitruvius. I  tillegg tilføyer den en del punkter som er spesifikke for  informasjonsteknologi. Jeg syns dette er en nyttig liste; den har et  passe detaljnivå og er ikke for lang.
Oppsummering
Arkitektur  omhandler helheten i et system, til forskjell fra design. Arkitektur  adresserer eksterne kvaliteter, på ulike nivåer. Arkitektur innen  informasjonsteknologi og klassisk arkitektur har noen felles prinsipper  som bør vektlegges. I tillegg til dette har arkitektur innen  informasjonsteknologi noen prinsipper som er spesifikke for fagområdet.



Testing external services using Mockito in Cuke4Duke
Eirik Wang — Mon, 01 Mar 2010 21:24:34 +0000
When developing a system, you often end up in situations where you are depending on external components like web services. In this post I’ll show you how you can use Mockito for mocking up fake responses, and verifying behaviour when using Cuke4Duke.
Lets start with a simple scenario. We want to verify that we call a web service with the correct parameters after processing a message. For this scenario I have created the interface of the web-service we want to verify behaviour from.
First we have to create a mock of the web service interface in spring config. We do this in spring so we can autowire the mock into services.

 id="sampleWsPortType" class="org.mockito.Mockito" factory-method="mock">
     value="no.bekk.ws.SampleWsPortType"/>
>

The next step is to make a cucumber step for verifying that the service is called

@StepDefinitions
public class WsSteps {
    @Resource(name = "sampleWsPortType")
    private SampleWsPortType sampleWsPortType;
    ......
    @Then("the person service receives person with name '(.*?)' and age '(.*?)':")
    public void personServiceReceivesInput(String name, Integer age) {
        ArgumentCaptor<WsPerson> capturedPerson = ArgumentCaptor.forClass(WsPerson.class);
        verify(sampleWsPortType).addPerson(capturedPerson.capture());
        assertEquals(name, capturedPerson.getValue().name);
        assertEquals(age, capturedPerson.getValue().age);
    }
}

You can then use this step definition in a cucumber test.

  Scenario: Post person data and verify that it is sent to the web service with correct parameters
    When I post the line '29;Ola Normann'
    Then the person service receives person with name 'Ola Normann' and age '29'


The next step is mocking response from the service. Use this when you are in need of data from a web service in your code. Open-ID integration for example.  


We do this using a Given step in cucumber. 

  Scenario: I want to get the correct age for a person.
    Given the web service returns '29' when queried for the age of 'Ola Normann'
    When I submit a request for the age for 'Ola Normann'
    Then the result is '29' returned

To get this working we have to add a step definition to mock the return. We do this with Mockito’s “when” statement.

    @Given("the web service returns '(.*?)' when queried for the age of '(.*?)'")
    public void personServiceShouldReturn(Integer age, String name) {
        when(sampleWsPortType.getAge(eq(name))).thenReturn(age);
    }




Kan en nettbank være sosial?
Lars Kristian Flem — Wed, 10 Feb 2010 12:00:59 +0000
Ofte kan den sosiale dimensjonen tilføre noe nytt og gjøre en tjeneste mer attraktiv å bruke. Hvordan tenker studenter rundt personlig økonomi og sosiale nettjenester?
Vi var i Trondheim i forrige uke, og besøkte studenter ved Institutt for Produktdesign på NTNU for å holde workshop i forbindelse med iD-uken 2010. Vi tenkte at “sosial nettbank” kunne være et artig tankeeksperiment for en workshop når man møter 50 engasjerte produktdesignstudenter. Vi tok med oss kortstokken og følgende tenkte case til Trondheim:

Visjon og mål
Ved å dra nytte av mekanismer fra sosiale nettmedier, skal banken få økt konkurransefortrinn og bli markedsleder innen forvaltning av personlig økonomi i løpet av 1 år.
 
Gjennom informasjon om egne, venners og andres transaksjoner skal våre kunder øke kunnskap om egen økonomi og eget forbruk
Hårete mål og investeringsvilje med andre ord. Denne banken skulle være annerledes.
Vi benyttet metodekortstokken som utgangspunkt for aktivitetene. Målet var å skape flest mulig uvanlige koblinger i en idéfase, og til slutt presentere konsept og funksjonalitet som en papirprototype.

Studentene fikk presentert caset rett før de gikk over i en kreativ idéfase. For å tvinge frem konkrete forslag til funksjonalitet, ble studentene fasilitert med strenge tidsrammer. Gjennom assosiasjonslek og idéspinning i korte, intense intervaller, kom studentene opp med flere ti-talls idéer i hver gruppe. Deretter fikk de i oppgave å prioritere konseptene de kom frem til opp mot Sosialbankens mål og visjon.

Papirprototypen skulle kommunisere konseptet og ved å spille ut sekvenser av funksjonene med papirskisser, skulle studentene demonstrere hvordan oppgaveflyten kunne fungere.

Vi tror nettbanker har mye å hente på sosiale mekanismer. Det studentene viste oss, var ikke bare hvordan nettbanken kan integreres med eksisterende sosial programvare, som Facebook, men også hvordan nettverkseffekter kan gi grupper av venner gunstigere renter eller mindre gebyrer jo flere de blir. De mente det også ville gi banken flere, nye kunder raskt.
De viste oss hvor “stress” det kan være å dele utgifter: Hvorfor kan jeg ikke bare sende korttransaksjonen min til de vennene som var med på taxituren, la banken regne ut hva det blir på hver, også kan de trykke OK? “Jeg kan legge til venner i nettbanken og de kan forhåndsgodkjenne at jeg får lov til å sende dem krav på et sånt utlegg.”
Eller hva med en kalenderoppføring som krever at du har gjort innbetalingen for å kunne være med? Som forteller deg om innbetalingen er registrert i stedet for at du må skanne gjennom listen med alle transaksjonene dine?
Studentene foreslo “kollektiv økonomi” og “privat økonomi” i nettbanken, som hjelp til å holde oversikt over om du skylder eller fordrer penger til vennene i nettverket ditt. Det hadde vært genialt for bokollektiv som deler utgifter uten å ha felles økonomi.
De skisset på kollektive spareplaner til sommerens reise, hvor progresjonsbarer forteller hvem av vennene som har spart mest, og hvor mye de totalt sparer av hva de trenger. De blir motivert av å spare når de ser hva vennene sparer.
Dette er løsninger på behov studentene har i sin hverdag, og skissene deres støtter opp under hvordan de er vant med å løse oppgaver på nett. Det er lekent og fornuftig for kunder i deres målgruppe, og de argumenterte for klare konkurransefortrinn for banker som er villige til å tenke nytt rundt forvaltning av sosiale mikroøkonomier. En bank må ivareta personvern og transaksjonssikkerhet, men studentene ble oppfordret til å ikke la seg begrense av det i denne runden. En tilsvarende sesjon kunne vært brukt til å utforske den dimensjonen.
Hva syntes de om teknikkene? Tilbakemeldingene vi fikk etter øvelsene var at de kreative øvelsene var engasjerende, samtidig som tidsstyringen hjalp gruppene å holde fokus. De så anvendelsen som relevant i egne studier. Vi håper studentene kan evaluere enda flere av metodekortene og har sendt kortstokk oppover så de kan teste og gjøre seg flere erfaringer. Workshopen var nyttig for oss for å få innspill til metodene vi bruker – det er noe vi kan tenke oss å gjøre mer.
Ta kontakt med oss om du ønsker å høre eller se mer fra workshopen. Vi snakker gjerne med deg om hvordan disse tankene eller øvelsene kan passe med dine behov. I løpet av kort tid kan idéer bli til noe konkret som kan demonstreres for beslutningstakere, videreutvikles, testes på brukere eller skape grunnlag for videre idéutvikling.
Helle har erfaring med å designe brukervennlige løsninger for flere av BEKK’s kunder og holder engasjerende workshops. Lars K. er som tidligere bankmann over middels opptatt av nettbanker. Han jakter på oppgavefokus og løsninger som setter brukeren i sentrum.



Cross Site Scripting i flash
Erlend Oftedal — Tue, 09 Feb 2010 13:49:01 +0000
Det har vært en del skriverier om sikkerhetsfeil i flash filer i det siste, f.eks. “Serious web vuln found in 8 million Flash files” og “XSS vulnerabilities in 34 millions flash files”. Det viser seg at dette ikke er et nytt problem, men snarere ett man ikke har fokusert på tidligere. Og her snakker vi da om feil i selve filene, ikke sikkerhetshull i selve flash-avspilleren.
XSS i flash?

Problemene oppstår stort sett fordi flash-filmen tar inn parametere fra HTML/javascript. Disse parametrene brukes deretter uten å valideres først. Det kanskje vanligste eksempelet er at man ønsker å gjøre det enkelt å endre hvor brukeren skal sendes til når brukeren klikker på flashen. Dette kalles gjerne clickTag, og koden i selve flashen kan se slik ut:

on (release) {
   getURL (_root.clickTAG, "_blank");
}

Problemet med dette oppstår fordi man kan linke direkte til flash-filen og gi inn parametere som url-parametere slik:
http://url/til/flash-fil.swf?clickTAG=http://her/skal/brukeren
I et angrep, kan dette utnyttes slik:
http://url/til/flash-fil.swf?clickTAG=javascript:alert("xss")
Man kan altså spesifisere en “javascript:” url, og dermed vil javascriptet kjøres nå brukeren trykker på linken.
Denne URLen kan så spres til potensielle offer via f.eks. falske eposter, twitter eller instant messaging. Siden URLen peker på et domene man stoler på, er det større sjanse for at offeret klikker på linken, men det vil selvsagt også avhenge av både av innholdet i flash og epost/melding.
Hva kan jeg gjøre?

For å hindre denne typen angrep, bør man gjøre inputvalidering på de data man tar inn. En første idé er kanskje at man skal sjekke at URLen ikke starter med “javascript:”, men denne formen for blacklisting har flere problemer. For det første kan det skrives på mange måter (javascript, JAVASCRIPT, jaVaScriPT), og i tillegg kan man f.eks. ha mellomrom først (” javascript:”). Videre kan man også ha f.eks. data URLer og Flash sin egen “asfunction:”.

Det er derfor bedre å bruke whitelisting, og heller si hva man tillater URLene å starte med. På Adobes “Designer’s Guide: Building Macromedia Flash Banners with Tracking Capabilities” foreslås følgende kode:

on (release) {
   if (_root.clickTAG.substr(0,5) == "http:") {
      getURL(_root.clickTAG, "_blank");
   }
}

Denne tillater kun URLer som begynner med “http:”. Man kan utvide denne til å støtte flere typer, f.eks. slik:

on (release) {
   if (_root.clickTAG.substring(0,5)== "http:" || _root.clickTAG.substring(0,6)== "https:" || _root.clickTAG.substring(0,1)== "/") {
      getURL (_root.clickTAG, "_blank");
   }
}

Denne støtter både http, https og server-relative URLer (må begynne med slash). I de fleste tilfeller bør man gjøre dette enda strengere, ved å kun tillate URLer som peker på eget domene.
Jeg vil lære mer

Adobes guide – creating secure flash apps
A Lazy Pen Tester’s Guide to Testing Flash Applications
OWASP Flash Security Project
Video av “Blinded by flash” (slides) – Prajakta Jagdale – Blackhat DC 2009
Neat, New, and Ridiculous Flash Hacks – Mike Bailey – Blackhat DC 2010