Blogg

Det här är vår webblogg. Vi skriver om saker i största allmänhet och om internet och webbutveckling i synnerhet. Prenumerera på RSS-flödet eller utforska arkivet.

Senaste inläggen

Ny webbplats för Safety Seal

Vi mjukstartar det nya året här i bloggen med berätta att företaget Safety Seal har fått en ny webbplats som vi varit med om att utveckla. Arbetet utfördes i samarbete med allstars it & media och vår del låg i att ta fram en ny design och producera ett antal HTML/CSS-mallar. Kolla in det färdiga resultatet här.

Skärmdump på Safetyseal.se

Har du fastnat?

Tidigare i veckan gjorde jag ett litet test som bland annat innebar att jag behövde fylla i massa uppgifter i ett formulär. När jag fyllt i all information och tagit mig till slutet av sidan, så fanns tre knappar att trycka på: »OK«, »Avbryt« och »Jag har fastnat«.

Formulär med 'Jag har fastnat'-knapp

Just det, en Jag har fastnat-knapp! Jag kunde självklart inte hålla fingrarna borta, utan testade att klicka för att se vad som hände. Men tyvärr var det inget sexigare än en knapp som tömde formuläret — och jag fick börja om från början igen.

Har aldrig förstått meningen med att ha en knapp som rensar formuläret. Och om man nu nödvändigtvis måste ha en sådan bör man i alla fall tydligt ange vad knappen gör. För övrigt kan man ju också fundera över hurvida en knapp som tömmer formuläret är till någon hjälp eller ej om man nu verkligen har fastnat (vad det nu innebär?).

Använd din egen URL som OpenID

OpenID

Jag älskar idén med OpenID och hoppas verkligen att det slår igenom på allvar. Det vore minst sagt skönt att kunna använda samma inloggning på alla webbplatser. Den senaste tiden har jag satt mig in i den tekniska biten bakom OpenID lite mer, eftersom vi valt att integrera OpenID-stöd på Wishlistr. Och nu tänkte jag bjuda på ett enkelt sätt att använda din egen URL som ditt OpenID.

Låt säga att jag vill ha adressen »http://digitalvenues.se« som mitt OpenID. Egentligen innebär det då att jag måste implementera en egen OpenID-server för att hantera verifieringen av min indentitet. Vilket kan vara lite krångligt och omständligt, även fast det idag finns bra ramverk för detta.

Ett enklare sätt är att använda en extern part som tillhandahåller en OpenID-tjänst, så som till exempel MyOpenID och sedan delegera autentiseringsförfrågningarna dit, när de kommer till digitalvenues.se. Det enda som behövs för detta är följande kodsnutt i HTML-dokumentets <head>-sektion på digitalvenues.se:


<link rel="openid.server" href="http://www.myopenid.com/server" />
<link rel="openid.delegate" href="http://mittkonto.myopenid.com/" />

Fördelen med detta är — förutom att jag enkelt kan använda en URL jag själv äger — att jag får mer kontroll över mitt OpenID. Om jag någon gång skulle vilja byta till en annan OpenID-tjänst av någon anledning så behöver jag bara uppdatera koden på min sida som talar om till vem jag vill överlämna autentiseringen. Vilket är bra mycket enklare än att uppdatera eller skaffa nya konton på alla de webbplatser där jag identifierar mig med mitt OpenID.

Tillgänglighet inget för Femman

Kanal 5

I veckan lanserade Kanal 5 sin nya webbplats. En webbplats som enligt dem själva kommer att bli »Sveriges bästa tv-sajt«. Istället för att enbart fokusera på sitt eget tv-utbud vill Femman skapa en mötesplats för alla som älskar tv — i alla former. Konkurrenter som SVT, TV4 och TV3 ges nästan lika mycket utrymme på webbplatsen som Kanal 5 själva och man lockar besökare genom att utlova en daglig dos av tv-relaterade nyheter. Ett intressant och modigt upplägg, utan tvekan. Men jag vet inte jag, hittills har nyheterna mest bestått av kändisskvaller och den nya designen med sina grälla färger och gigantiska reklambanners är ett steg tillbaka jämfört med den gamla.

Men det är först när man tar en titt under huven som den riktiga besvikelsen infinner sig. Femman anger att det är ett XHTML Transitional-dokument, men W3C:s validator håller inte riktigt med, »Failed validation, 1449 Errors«, säger den. Och koden är faktiskt en enorm röra av <div>, <span> och <table>. Någon form av semantik är svårt att hitta överhuvudtaget, och slår man av CSS-filerna ser man att sidan helt saknar en logisk uppbyggnad. En snabbcheck med Fangs skvallrar också om hur jobbigt det blir om man skulle försöka sig på att surfa på sidorna med en skärmläsare. När man dessutom använder sig av en URL-struktur som tycks arbeta efter principen »ju längre och mer kryptisk desto bättre« är det inte svårt att lista ut att nya Kanal5.se knappast kommer bli en favorit hos Google och andra sökmotorer.

Skärmdump på nya Kanal5.se

Ovan: Kanal 5:s nya webbplats, lanserad under devisen »We Love TV«.

Något annat som slår en är mängden JavaScript. Hela 51 externa skript och nästan lika många direkt i XHTML-koden. Tillsammans med 5 flashobjekt, 99 bilder, 12 CSS:er blir det en del att hämta för webbläsaren för att kunna visa sidan. Med den mängden JavaScript blir man ju genast nyfiken på hur det fungerar om man slår av JavaScript-stödet i webbläsaren. Relativt okej faktiskt (vilket inte var fallet tidigare i veckan). Saker som webb-tv och kommentarer fungerar visserligen inte men jag upplever ändå sidan som bättre utan JavaScript för jag slipper reklam och sidorna laddar snabbare. Så frågan man ställer sig är självklart: är verkligen alla drygt 700 kB av JavaScript som finns nödvändig?

Femman kanske älskar tv. Men någon större kärlek till webben verkar de ju inte ha. Det är sorgligt att se att man fortfarande, år 2007, kan komma undan med att koda en webbplats så illa.

Uppdatering 2007-10-04: Femman verkar gjort en del uppdateringar senaste tiden. Mängden JavaScript har bland annat reducerats till 8 externa filer nu. Ett steg i rätt riktning!

Så förhindrar du CSRF-attacker

Cross-Site Request Forgeries (CSRF) är en form av attack, riktad mot webbplatser, som hamnat lite i skuggan av den mer kända metoden Cross-Site Scripting (XSS). Men det kanske den inte borde ha gjort. CSRF-attacker kan både vara svårare att stoppa och göra mer skada än XSS-attacker. Dessutom är de flesta webbsidor sårbara när det kommer till CSRF. Amazon är till exempel det, Digg har likaså varit det precis som Google Adsense. Så om du inte aktivt jobbat med att förhindra CSRF-attacker är din webbtjänst med största sannolikhet också sårbar.

Vad är CSRF?

Man kan säga att CSRF är en form av attack som utnyttjar förtroendet en webbplats har gentemot en användare. Det är alltså lite av motsatsen till vad XSS är, där en användares förtroende till en webbplats istället utnyttjas.

Rent praktiskt fungerar en CSRF-attack som så att en angripare kan få din webbapplikation att utföra funktioner som om det var en anförtrodd (det vill säga inloggad) användare som startade funktionen. Faktum är att själva funktionen startas av den anförtrodda användaren, fast utan dennes vetskap. Angriparen skickar nämligen den förfalskade begäran om att starta funktionen genom att tvinga en anförtrodd användares webbläsare att göra förfrågan.

Jag vet, det här låter ju riktigt avancerat. Men med lite grundkunskaper om hur HTTP fungerar och ett lagom dumt och förenklat exempel är det enklare att förstå.

Låt säga att det finns en webbplats där du som inloggad medlem kan beställa bananer och äpplen. Koden för beställningsformuläret ser ut så här:


<form action="/kop.php" method="post">
<select name="frukt">
    <option name="banan">Bananer</option>
    <option name="applen">Äpplen</option>
</select>
Antal: <input type="text" name="antal" />
<input type="submit" value="Köp!" />
</form>

Och sidan som processar beställningen, skriven i PHP, ser förenklat ut ungefär så här:


if(user_is_loggedin()) {

    buy_fruits($_REQUEST['frukt'], $_REQUEST['antal'], $_SESSION['userid']);

}

Innan beställningen läggs kollar vi alltså att användaren är inloggad, så man kan koppla beställningen till en användare. Säkrare en så kan det väl inte bli — varje gång vet vi att det är en inloggad och godkänd användare som lagt beställningen, eller? Nej, exemplet ovan är så klart skapat för att visa på hur enkelt man kan utföra en CSRF-attack. I det här fallet räcker det med att en person besatt av att beställa tonvis med bananer åt folk infogar följande kod på sin egen webbplats:


<img src="http://www.fruktsajten.se/kop.php?frukt=bananer&antal=10000" />

Om du besöker attackerarens webbplats, där kodraden ovan finns, samtidigt som du är inloggad på fruktbeställningswebbplatsen kommer alltså din webbläsare, utan din vetskap, beställa ett gäng bananer.

Som du kanske förstår så blir sådana här typer av attacker svåra att upptäcka och stoppa. Eftersom själva förfrågan faktiskt kommer från en betrodd användares webbläsare. Dessutom är ju såklart inte CSRF-attacker begränsade till bananbeställning utan praktiskt taget allt som en inloggad användare kan göra skulle också attackeraren kunna utföra — posta kommentarer, sätta betyg, byta lösenord, beställa saker och så vidare.

Speciellt viktigt att skydda sig mot sådana här typer av attacker blir det för webbplatser som erbjuder någon form av mer permanent inloggning, som till exempel Amazon och Flickr har, där användaren kan vara inloggad på en webbplats även om det var en månad sedan han/hon senast besökte tjänsten.

Hur skyddar man sig?

Det är svårt att ge ett hundraprocentigt skydd mot sådana här typer av attacker. Men det finns mycket man kan göra för att minska risken.

Till att börja med bör man se till att man alltid använder POST istället för GET i formulär och Ajax-anrop, så långt det är möjligt. Samt att man i sin kod ser till att det är en POST-förfrågan som kommer och inget annat. Detta ger inte på något sätt ett tillfredsställande skydd, men försvårar det något för den som tänker utföra en attack, och skulle faktiskt vara skydd nog för att förhindra den enkla attacken i exemplet ovan.

Ett bättre skydd mot CSRF-attacker får man genom att försöka säkerställa att användaren använt formuläret i fråga för att skicka förfrågningen till servern. Det kan man göra genom att alltid generera en ny slumpad sträng när sidan laddas, som man sedan både sparar i en session och skickar med i formuläret när det postas. Innan man processar formuläret kollar man sedan att strängen i sessionen överensstämmer med den som kom via postningen av formuläret.

Så om vi återigen tar exemplet ovan och försöker göra det lite mer säkert skulle koden för formuläret kunna se ut så här:1


<?php
// Generera en slumpad sträng
$token = md5(uniqid(rand(), true));
// Spara strängen i sessionen
$_SESSION['token'] = $token;
?>

<form action="/kop.php" method="post">
<select name="frukt">
    <option name="banan">Bananer</option>
    <option name="applen">Äpplen</option>
</select>
Antal: <input type="text" name="antal" />
<input type="hidden" name="token" value="<?= $token ?>" />
<input type="submit" value="Köp!" />
</form>

Och sidan som processar beställningen skulle förenklat kunna se ut som så här:


if(user_is_loggedin()) {

    // Kolla att strängen som finns i sessionen överensstämmer med den som kom via formuläret
    if(isset($_SESSION['token']) && $_SESSION['token'] === $_POST['token']) {

         buy_fruits($_POST['frukt'], $_POST ['antal'], $_SESSION['userid']);

     }

}

Genom att införa dessa ändringar kan vi med större säkerhet veta att förfrågningen kommer från en betrodd användare som använt »rätt« formulär — och på så sätt har vi skyddat oss bättre mot CSRF.

Slutligen: Kan man bli ännu säkrare?

Det finns utan tvivel många saker man kan göra för att förbättra säkerheten ytterligare. Till exempel kan man tidsbegränsa formuläret så att det inte får gå mer än 5 minuter från det att formuläret laddats till dess att postningen av den samma sker. Vilket är vanligt vid inloggning på Internet-banker till exempel. Men vill man vara riktigt säker kan man använda sig av CAPTCHA’s eller ännu bättre: be användaren om lösenordet för att kunna posta formuläret.

Hur som helst. Någon form av skydd bör man implementera varje gång man låter en användare lägga till, ta bort och redigera saker på en webbplats. Vissa saker är dock mer känsliga än andra och kanske behöver ägnas en extra tanke.



  1. Raden som genererar en slumpad sträng är lånad från Chris Shiflett som bland annat skrivit boken Essential PHP Security. ↩

Gratis övervakning av din webbplats

Just nu kan du få ett års medlemskap på Pingdom helt gratis. Pingdom är en tjänst, skapad av Sam Nurmi (samme man som grundade Loopia) som övervakar webbplatser och informerar dig, via e-post eller SMS, så fort någon av dina övervakade webbplatser ligger nere. Vi använder själva Pingdom för att övervaka våra webbplatser och kan varmt rekommendera tjänsten om du har en eller flera webbplatser där upptiden är av stor vikt. Normalt sätt kostar tjänsten drygt 800 kronor per år, men nu kan du alltså få första året gratis. Och det finns ingen hake heller. Eller ja, du måste använda Firefox. Använder du någon annan webbläsare så får du snällt betala … (Men skynda på, erbjudandet gäller bara en dag till och max 1000 personer).

När vi ändå är inne på Sam Nurmi och Pingdom måste jag också passa på att tipsa om Firefox-tillägget Mr Uptime från samma företag. Mr Uptime är perfekt att ha vid tillfällen då du gång på gång försöker komma åt en webbplats som verkar ligga nere. Med Mr Uptime behöver du inte längre ödsla tid på sådant eftersom detta tillägg då kan lägga sig i bakgrunden och försöka nå webbplatsen åt dig. När webbplatsen är uppe och snurrar igen säger Mr Uptime till och du har förhoppningsvis fått massa annat nyttig gjort under tiden.

Nya Allstars Runners

Här om veckan lanserade Allstars IT & Media den nya versionen av Allstars Runners — ett slags community för löpare där man bland annat kan läsa om lopp, föra träningsdagbok, lägga upp bilder och diskutera med likasinnade. Vi assisterade Allstars under utvecklandet och hjälpte dem att plocka fram en ny design och nya HTML/CSS-mallar. Om du är intresserad av löpning bör du definitivt kolla in sajten.

Skärmdump på Allstarsrunners.se

‹ Mer i arkivet

Bloggarkivet