By default, when sending an HTTP Authentication header, Weblogic will check its own security realms for users matching the username and password. If there is no match, a 401 UNAUTHORIZED response is sent directly back to the client, without ever hitting your web application code. That takes care of the security, i guess…

This might sound like a good idea, except for those cases when your application is able to handle its own authentication. How can your application handle security when the request never hits your code?

Another problem, as i see it, is that Weblogic enforces this security model even for web application that are configured with no security at all. You can use your web application as much as you like, as long as you don’t send any HTTP Authentication headers. But when you decide to send an HTTP Authentication header like that, just for fun or when navigating from another website after being authenticated, Weblogic decides on your applications behalf that you are no longer worthy enough to use your application. That sucks…

The solution
The solution? Yes, you can bypass the security model of Weblogic, at least for those applications that does not rely on the web containers security. It took me many weeks of frustration before I found a solution to my problem, but I got there…

Shutdown your admin server and open the config/config.xml file for editing. Add the following XML code into the <security -configuration> node:

<enforce-valid-basic-auth-credentials>
    false
</enforce-valid-basic-auth-credentials>

Start the admin server again. Then you need to restart all the application servers to make the change take effect. Restart them one by one to avoid downtime… you are of course running a cluster right?

Da bestemte jeg meg for å teste Perl-applikasjonen min for sikkerhetshull. Denne applikasjonen er svært enkel. Den har ett HTML-skjema med ett input-felt, og data fra dette feltet blir listet ut på forsiden. “Shout” heter det, enkelt og greit. Jeg fyrte avgårde alle testene i XSS Me mot dette skjemaet og fikk ørten sikkerhetsvarslinger i retur. Dette løste jeg riktignok med en enkel pipe igjennom html-filteret til Template Toolkit.

Vi utforsket dette videre. Kameraten min smalt opp et lite PHP-script som tok innholdet fra et textarea-felt og viste det uendret ut på HTML-sida. Vi fant fort ut at PHP gjorde noe magisk bak scenen, som PHP så gjerne ofte gjør; magic quotes heter det. Men jeg lurte jæveln…


<script>
 window.location=String.fromCharCode(104)
  + String.fromCharCode(116)
  + String.fromCharCode(116)
  + String.fromCharCode(112)
  + String.fromCharCode(58)
  + String.fromCharCode(47)
  + String.fromCharCode(47)
  + String.fromCharCode(103)
  + String.fromCharCode(111)
  + String.fromCharCode(111)
  + String.fromCharCode(103)
  + String.fromCharCode(108)
  + String.fromCharCode(101)
  + String.fromCharCode(46)
  + String.fromCharCode(99)
  + String.fromCharCode(111)
  + String.fromCharCode(109);
</script>


Denne koden dekoder tallene til tegn, setter dem sammen til en tekststreng, tilordner tekststrengen til “document.location”. Javascriptet sender deg så videre til en ny nettside, rett og slett til http://google.com.

Ironisk nok klarte jeg å redirecte meg selv til google da jeg skulle ta en titt på preview’n på dette innlegget. Glemte visst å enkode HTML-taggene, tenke seg det…

Vi ønsker at alle brukere av våre tjenester skal registreres i en sentral brukerdatabase. Vi ønsker derimot ikke å lage store endringer i eksisterende løsninger, spesielt ikke “hyllevare”-produkter. Mange hyllevareprodukter har allerede støtte for OpenID, men det kan vi ikke bruke uten endringer. Da mister vi oversikt over hvor mange brukere vi har, brukerne får ingen sentral profil på tvers av systemene og de må skrive inn sin OpenID-adresse og trykke “Logg inn med OpenID” på alle systemene våres. Derfor har vi behov for en tilpasset utgave av OpenID som fungerer innenfor vårt domene av webløsninger.

Først er det viktig å skille mellom vår løsning for SSO mellom egne tjenester og OpenID for SSO mellom eksterne tjenester. Vi trenger begge til å fungere sammen. I vår SSO-løsning ønsker vi ikke at brukeren skal måtte skrive inn sitt brukernavn på alle systemene. Fordi noen av systemene ligger på separate domener og ikke kan dele cookies blir vi nødt til å ha “Logg inn”-knapper på alle systemene, selv om brukeren allerede er logget inn.

Eksempelet
Vi gjør et eksempel ved at en bruker skal logge inn på et forum. Ved å trykke på “Logg inn” blir man sendt til en sentral side hvor man kan registrere seg eller logge inn. Vi kaller denne for profiltjenesten. Med denne linken sendes også en URL som viser hvor brukeren kom fra. Når brukeren er registrert, verifisert (med enten e-post eller SMS) og logget inn blir brukeren sendt tilbake til foumet, der han klikket “Logg inn”. URL-en som brukeren sendes tilbake til inneholder nå også en parameter med brukernavnet sitt samt et token som vi skal bruke for å kontrollere at brukeren faktisk er innlogget. Det som skjer så er at forumet henter profildata fra profiltjenesten for å fylle ut navn, e-post og andre profildata som forumet har behov for. Dette er en funksjonalitet som finnes i OpenID-løsninger.

Dette gir oss en tre-veis autentisering. Brukeren stoler på oss (ja, ikke sant…) eller sin OpenID-tilbyder, profilsiden vår vet at det er riktig bruker som har logget inn og forumet stoler på profilsiden vår og kan verifisere at brukerens token er korrekt.

To samspillende løsninger
Så, hva gjør vår SSO-løsning forskjellig fra OpenID? Ikke så mye, men ganske forskjellig for det, fra brukerens ståsted. For det første er det intet felt for å skrive inn sitt OpenID-navn i våre systemer, heller ikke noe brukernavn- og passord-felter. Det er bare en “Logg inn”-knapp. Denne knappen fører til vår profil- og innloggingsside, ikke til brukerens OpenID-tilbyder. Her logger brukeren inn, enten med en OpenID-konto fra et eller annet sted i verden eller et brukernavn og passord mot vår egen brukerdatabase. Dette betyr at forumet som brukeren opprinnelig prøvde å logge inn på ikke vet brukernavnet til brukeren, faktisk ingenting om brukeren. Derfor må profilsiden vår fortelle forumet hvilken bruker som faktisk har logget inn, når brukeren sendes tilbake.

Da jeg sa at vår SSO-løsning og OpenID må holdes klart adskilt så mente jeg det. Våre systemer har ikke OpenID, da de ikke godtar innlogging fra OpenID-tilbydere. De godtar kun innlogging via vår profilside. Allikevel er det en OpenID-løsning, men en tilpasset OpenID-løsning, og alt som minner om OpenID for sluttbrukere er strippet bort. Det er egentlig ikke lenger OpenID lenger.

OpenID
Så hva med OpenID? Profilsiden støtter OpenID. Brukere trenger ikke å lagre noe passord i vår brukerdatabase. De logger inn via sin OpenID-tilbyder, og oppretter så en profilkonto hos oss med navn, telefonnummer, epost og what-not som vi kan ha behov for. Vi kan godt kreve aktivering av profilen ved å sende dem en kode på SMS eller epost, slik at vi får en viss kontroll over brukerne våre og vite at det er levende personer som står bak profilene. Når brukerne er logget inn på profilsiden vår har de logget inn som på en hvilken som helst annen OpenID-støttet nettside på Internett. Når brukerne så går til de andre systemene våre vil de autentiseres mot vår profilside, på samme måte som OpenID fungerer.

Alt virket tilsynelatende fint, men jeg kunne ikke flytte eller kopiere filer i Subversion repositoriet over HTTPS. Jeg fikk feilmelding 502 Bad Gateway hver gang jeg prøvde å sjekke inn endringer hvor jeg hadde brukt svn move eller svn copy.

Så da var det bare å bytte til HTTP hver gang jeg skulle flytte og kopiere filer, men dette blir slitsomt i lengden og er lite produktivt. Sikkert er det heller ikke. Derfor har jeg ofte brukt ukryptert forbindelse for enkelte av prosjektene.

Jeg kom i går over en artikkel som beskrev problemet med å flytte filer i Subversion, og som kom med noen løsningsalternativer. Problemet mitt lå i Apache og mod_ssl, at Apache ikke ser hvilken port forespørselen kom på. Selv om det var brukt https og port 443, så trodde Apache at forbindelsen gikk over port 80. Dette fant jeg ut ved å åpne https://localhost/status-info i links på webserveren og der stod det port 443. Derimot viste https://hovenko.no/status-info/ at forbindelsen gikk over port 80.

Løsningen var å flytte konfigurasjonsparameterene SSLCertificateFile og SSLCertificateKeyFile ut av den oprinnelige SSL VirtualHost-seksjonen slik at de ble globale, og så legge inn SSLEngine on i alle VirtualHost-seksjoner som lytter på port 443.

SSLCertificateFile /etc/apache2/ssl/datafeel.no-cert.pem
SSLCertificateKeyFile /etc/apache2/ssl/datafeel.no-key.pem

<VirtualHost *:443>
ServerName hovenko.no
SSLEngine On
# …
</VirtualHost>

Det mest skumle med en slik ordning er dersom dataene kommer på avveie, også kjent som identitetstyveri. Dersom denne loven trår i kraft bør dataene beskyttes minst like “sikkert som (nett)banken”, for alle stoler på nettbanken sin, ikke sant…?

Den konstruktive siden
For å veie opp for min skepsis, så får jeg komme med et forslag. Siden jeg selv er tekniker, så blir dette et forslag for hvordan man kan løse dette på en teknisk måte for å begrense konstnadene for leverandørene, spesielt for å forhindre at terskelen for å starte opp nye selskaper blir for stor. Vi kan ikke tillate at en slik lov blir et middel for å presse de mindre leverandørene ut av markedet!

Først og fremst, dataene bør lagres et sentralt sted, hos en ny offentlig instans. Kostnadene for denne instansen og alt lagringsbehov bør dekkes av staten. Det må benyttes kryptografi for å beskytte dataene. Alle data kan krypteres med to nøkler, én som besittes av den offentlige instansen og én av leverandøren som berøres av denne loven. Kun disse to nøklene til sammen kan gi tilgang til dataene. For at en inntrenger skal kunne gjøre noe som helst med dataene må man få tak i både nøkkelen fra den offentlige instansen og nøkkelen fra en av leverandørene. Selvsagt må det utarbeides strenge regler for håndtering av disse nøklene, og man må alltid tenke på at mennesket er det svakeste punktet når det gjelder sikkerhet og konfidensialitet.

Dette løser to problemstillinger. Én, den gjør det vanskeligere å gjennomføre identitetstyveri. To, den gjør at kostnadene som faller på leverandørene ikke øker så dramatisk at det presser ut de mindre leverandørene eller skremmer bort nykommere.

Dette er et statlig initiativ som er dyrt, veldig dyrt, og det er derfor ikke rimelig at leverandører skal pålegges denne kostnaden. Hvor staten skal ta disse pengene fra tør jeg ikke tenke på. Min mening er uansett at bedre sykehus og bedre veier kan redde flere liv enn hva dette direktivet kan. Direktivet kan kanskje hjelpe til å dømme noen kriminelle, men da har allerede skaden skjedd. Jeg har ingen tro på at dette kan redde noen liv i det hele tatt.

Den siste utvei
Forslaget over er bare et teknisk forslag til hvordan man kan implementere dette direktivet. Jeg mener derimot at det ikke bør gå så langt. Det bør ikke implementeres.

Drammen Venstre skriver på Torget og mener at personvernet er truet:

For at direktivet ikke skal bli implementert i Norge må et flertall i Stortinget for første gang i historien benytte seg av reservasjonsretten i EØS-avtalen.

Og det er akkurat det, truet. Dette er et svært omstridt lovforslag, og Danmark har allerede benyttet omlag 250 millioner kroner for å implementere dette, og dette gjelder kun mobiltrafikk i landet. Jeg synes Norge bør benytte seg av retten vi har i dette tilfellet, for vi kan ikke dasse etter alle andre og godta alt som skjer rundt oss. Ett sted går grensa, og jeg synes den går akkurat her. Vi bør vise resten av verden at dette ikke er veien å gå for å bekjempe kriminalitet og terrorisme.

Det finnes et mylder av slike communities, hvor de største er Youtube, Microsoft Live Spaces, MySpace og Facebook, hvorav sistnevnte har skutt i været det siste året. Nettby er også en populær tjeneste her i Norge. Kanskje er du registrert på og har benyttet alle disse nevnte tjenestene, og kanskje enda flere.

Det disse sidene alle har til felles er at de skal bygge opp dine sosiale nettverk. Du legger ut informasjon om deg selv, som navn, adresse, telefonnummer, epost og annen kontaktinformasjon, blant annet for MSN Messenger, IRC, Jabber og Skype. Du laster opp private bilder og videoer av deg selv, dine venner, fra fester du har vært på og steder du har besøkt. Dette kan enten vises av alle som besøker nettstedet eller du kan velge at kun dine venner kan se det du har lagt ut.

Høres ikke dette flott og fint ut? Du kan holde oversikt over dine kontakter på et nettsted som du har tilgang til hvor enn det er Internettforbindelse. Du kan raskt og enkelt vise bildene fra festen i går til alle dine venner, organisere bildene i album, skrive kommentarer på bildene og merke av hvem det er som er blitt tatt bilde av.

Så, hva er baksiden av det hele? En viktig ting å huske på er at Internett fanger “alt”. Det som først legges opp er vanskelig å fjerne. Bilder og sider blir mellomlagret i flere ledd, alt fra nettlesere, proxy-servere, søkemotorer og backup hos tilbyderne av nettsidene.

Du har kanskje benyttet deg av flere forskjellige nettsamfunn tidligere. Har du egentlig noen oversikt over hvilke? Bruker du alle fortsatt? Har du oversikt over hva du har skrevet på profilene dine over alt? Hvilke bilder du har lastet opp hvor? Hvilke kontakter du har på de forskjellige stedene?

Har du noen gang tenkt på sikkerheten på disse nettstedene? Det finnes sikkerhetshull i applikasjoner på PC-en din, kanskje du har tettet de fleste, og kanskje noen nye blir funnet neste uke. Det er ingen unntak fra nettbaserte applikasjoner. Faktisk kan det være vanskeligere å beskytte slike applikasjoner, fordi du rett og slett ikke kan sikre dine data ved å dra ut nettverksledningen fra PC-en din. Alt ligger på Internett, tilgjengelig for nesten 7 milliarder mennesker.

Mange har advart mot Facebook, at det krenker privatlivet til både deg og dine venner. Forretningshemmeligheter kan havne i urettmessige hender, enten man gjør det bevisst eller ikke. Dette er kanskje enda mer skummelt nå, etter at det ble mulig å utvikle applikasjoner som integreres i Facebook. De kan virke harmløse, men de har full tilgang til din profil og alle dine venners profiler. Her settes din sikkerhet på prøve. Ditt og dine venners privatliv kan leses av et program som utviklerne av Facebook over hodet ikke har noen kontroll over.

Facebook skal nå begynne å analysere brukernes profiler for å lage målrettet reklame mot deg. Da du registrerte deg godtok du vilkårene som Facebook har satt. Disse vilkårene vil kort fortalt ta fra deg det meste av rettigheter du trodde du hadde. Alt du laster opp vil Facebook kunne bruke til nærmest hva de vil, som å selge det videre til partnere. Med andre ord kan Facebook gjøre penger på det du laster opp, for eksempel flotte landskapsbilder.

Her følger et utdrag fra Facebooks “Terms of Use”, hvor “User Content” beskriver informasjon og filer du laster opp og “the Company” beskrives som Facebook:
By posting User Content to any part of the Site, you automatically grant, and you represent and warrant that you have the right to grant, to the Company an irrevocable, perpetual, non-exclusive, transferable, fully paid, worldwide license (with the right to sublicense) to use, copy, publicly perform, publicly display, reformat, translate, excerpt (in whole or in part) and distribute such User Content for any purpose on or in connection with the Site or the promotion thereof, to prepare derivative works of, or incorporate into other works, such User Content, and to grant and authorize sublicenses of the foregoing.

Jeg synes dette er litt skremmende å tenke på. Jeg er selv en Facebook-bruker. Jeg ble dratt med inn i stormen. Og, som de aller fleste andre, så leste heller ikke jeg disse vilkårene… ikke før idag. Jeg mener selv at jeg har et stort fokus på sikkerhet, men jeg er ikke paranoid nok til å lese absolutt alle vilkår som jeg godtar.

Man behøver ikke å nappe ut kabelen, hogge i stykker modemet, rømme til fjells og bli huleboer for å sikre sitt privatliv, men man bør tenke seg om et par ganger over hva man legger ut om seg selv på slike nettsamfunn.