Säkerhet

Läs mer om WordPress grundläggande programvarusäkerhet i denna kostnadsfria vitbok . Du kan också ladda ner den i PDF-format.

Översikt

Detta dokument är en analys och beskrivning av utvecklingen av programvaran i WordPress-kärnan och de relaterade säkerhetsprocesserna, samt en undersökning av den säkerhet som finns direkt inbyggd i programvaran. Beslutsfattare som utvärderar WordPress som innehållshanteringssystem (CMS) eller ramverk för webbapplikationer bör använda detta dokument för sin analys och för sitt beslutsfattande. Vidare kan utvecklare använda dokumentet för att bekanta sig med säkerhetskomponenterna och bästa praxis för denna programvara.

Informationen i detta dokument är uppdaterad för den senaste stabila releasen av programvaran, WordPress 4.7 när dokumentets publicering, men bör kunna betraktas som relevant även för de senaste versionerna av programvaran då bakåtkompatibilitet är ett stort fokus för WordPress utvecklingsteam. Specifika säkerhetsåtgärder och förändringar kommer att dokumenteras när de läggs till i kärnprogramvaran i specifika releaser. Vi rekommenderar starkt att man alltid bör köra den senaste stabila versionen av WordPress för att säkerställa en så säker användarupplevelse som möjligt.

Sammanfattning

WordPress är ett dynamiskt innehållshanteringssystem med öppen källkod som driver miljontals webbplatser, webbapplikationer och bloggar. Det driver för närvarande mer än 43 % of av de 10 miljoner största webbplatserna på Internet. WordPress användarvänlighet, utbyggbarhet och mogna utvecklings-community gör det till ett populärt och säkert val för webbplatser av alla storlekar.

Från starten år 2003 har WordPress ständigt härdats för att dess kärnprogramvara ska kunna hantera och motstå vanliga säkerhetshot, inklusive tio-i-topp-listan som tagits fram av OWASP (Open Web Application Security Project/Öppet projekt för säkerhet i webbtillämpningar) som vanliga säkerhetssårbarheter, vilka diskuteras i detta dokument.

WordPress säkerhetsteam, i samarbete med kärnledningsteamet för WordPress och med stöd från den globala WordPress-communityn, arbetar med att upptäcka och lösa säkerhetsproblem i kärnprogramvaran som finns tillgänglig för distribution och installation via WordPress.org, samt rekommendationer och dokementering av bästa praxis kring säkerhet för tredjepartsutvecklare av tillägg och teman.

Webbplatsutvecklare och administratörer bör ägna särskild uppmärksamhet åt korrekt användning av kärnans API:er och den underliggande serverkonfigurationen, vilka har gett upphov till många vanliga sårbarheter, samt säkerställa att alla användare har starka lösenord för sin åtkomst till WordPress.

En översikt över WordPress

WordPress är ett kostnadsfritt innehållshanteringssystem (CMS, Content Management System) med öppen källkod. Det är den mest använda CMS-programvaran i världen och driver mer än 43 % av de 10 miljoner största webbplatserna¹vilket ger det en uppskattad marknadsandel på 62 % av alla webbplatser som använder ett CMS.

WordPress är licensierat under General Public License (GPLv2 eller senare) som ger fyra grundläggande friheter, och kan betraktas som WordPress ”rättighetsförklaring”:

Friheten att köra programmet för vilket ändamål som helst.
Friheten att studera hur programmet fungerar och ändra det så att det gör det du önskar.
Friheten att distribuera vidare.
Friheten att distribuera kopior av din modifierade version till andra.

Ledningsteamet för WordPress-kärnan

WordPress är en meritokrati som drivs av ett kärnledningsteam under ledning av dess medskapare och ledande utvecklare Matt Mullenweg. Teamet överser alla aspekter av projektet, inklusive utvecklingen av kärnan, webbplatsen WordPress.org och community-initiativ.

Kärnledningsteamet består av Matt Mullenweg, fem ledande utvecklare och över ett dussin utvecklare av kärnan med permanenta rättigheter att bekräfta programkod i projektet. Dessa utvecklare har sista ordet i tekniska beslut och leder diskussioner kring arkitekturen och implementeringsarbetet.

WordPress har ett antal utvecklare som bidrar. Några av dessa är, eller har tidigare haft rätt att lägga till programkod i projektet medan andra troligen kommer att ha sådan rätt i framtiden. Dessa bidragande utvecklare är betrodda och erfarna bidragsgivare i WordPress, vilka har gjort sig förtjänta av ett riktigt gott anseende bland sina jämlikar. Vid behov har WordPress även gäst-committers. Det är personer som har fått åtkomst för att lägga till programkod, ibland för någon speciell komponent och ibland tillfälligt eller på försök.

Kärnan och de bidragande utvecklarna utgör huvudguidningen för WordPress-utveckling. Hundratals utvecklare bidrar med programkod till varje version av WordPress. Dessa bidragsgivare till kärnan är frivilliga som bidrar kodbasen i kärnan på ett eller annat sätt.

Release-cykeln för WordPress

Varje release-cykel för WordPress leds av en eller flera av utvecklarna av WordPress-kärnan. En release-cykel tar normalt cirka 4 månader från det första mötet där målen för omfattningen bestäms till den nya versionen lanseras.

En release-cykel följer följande mönster²:

Fas 1: Planering och säkerställande av att teamledare finns. Detta sker i chattrummet #core via Slack. Relaseledaren diskuterar funktioner som ska ingå i nästa utgåva av WordPress. Bidragsgivare i WordPress engagerar sig i denna diskussion. Releaseledaren pekar ut teamledare för var och en av de berörda funktionerna.
Fas 2: Utvecklingsarbetet inleds. Teamledarna sätter samman arbetsgrupper och arbetar med de funktioner de blivit tilldelade. Regelbundna chattar planeras för att säkerställa att utvecklingen inte stannar upp.
Fas 3: Beta. Beta-utgåvor publiceras och beta-testare ombeds att rapportera in eventuella fel. Ingen ny programkod för förbättringar eller önskemål om nya funktioner får läggas till efter denna punkt. Utomstående tilläggs- och temautvecklare uppmuntras att testa sin programkod mot de kommande förändringarna.
Fas 4: Relasekandidat (Release Candidate). Från denna stund stoppas kodändringar som skulle innebära ändrade eller nya strängar för översättning. Arbetet koncentreras enbart kring eventuella återinförda fel och problem som blockerar releasen ifråga.
Fas 5: Lansering. WordPress-versionen släpps och görs tillgänglig för uppdatering via adminpanelen i WordPress.

Versionsnumrering och säkerhetsreleaser

En huvudversion av WordPress känns igen på att den använder två nummer. Till exempel är 3.5 en större version, liksom 3.6, 3.7 eller 4.0. Det finns inget ”WordPress 3” eller ”WordPress 4” och varje huvudversion refereras till genom dess nummer, t.ex. ”WordPress 3.9”.

Huvudversioner kan lägga till nya användarfunktioner och API:er för utvecklare. Även om en ”huvudversion” i programvaruvärlden ofta innebär att du kan bryta bakåtkompatibiliteten, strävar WordPress efter att aldrig bryta bakåtkompatibiliteten. Bakåtkompatibilitet är en av projektets viktigaste filosofier, med målet att göra uppdateringar mycket enklare för både användare och utvecklare.

En mindre WordPress-version känns igen på det tredje numret. Version 3.5.1 är en mindre version, liksom 3.4.2³. En mindre utgåva är reserverad för att åtgärda säkerhetsproblem och kritiska fel. Eftersom nya versioner av WordPress släpps så ofta – målet är ny huvudversion var 4-5:e månad, och mindre versioner släpps efter behov – behövs inget annat än huvudversioner och mindre versioner.

Bakåtkompatibilitet mellan versioner

WordPress-projektet satsar hårt på bakåtkompatibilitet. Detta åtagande innebär att teman, tillägg och anpassad programkod fortsätter att fungera när programvaran i WordPress-kärnan uppdateras, något som uppmuntrar webbplatsägare att hålla sin WordPress-version uppdaterad med den senaste säkerhetsutgåvan.

WordPress och säkerhet

Säkerhetsteamet för WordPress

WordPress Security Team består av cirka 50 experter, inklusive ledande utvecklare och säkerhetsforskare – ungefär hälften är anställda av Automattic (som står bakom WordPress.com, den första och största WordPress-värdplattformen på webben), och ett antal arbetar inom webbsäkerhetsområdet. Teamet får råd från välkända och pålitliga säkerhetsforskare och webbhotellsföretag³.

WordPress säkerhetsteam samarbetar ofta med andra säkerhetsteam för att hantera problem i gemensamma beroenden, såsom att lösa sårbarheten i PHP XML-parsern, som används av XML-RPC API som levereras med WordPress, i WordPress 3.9.2⁴. Denna lösning på sårbarheten var ett resultat av en gemensam insats från både WordPress och Drupals säkerhetsteam.

Risker, processer och historik inom WordPress-säkerhet

WordPress säkerhetsteam tror på ansvarsfullt avslöjande genom att omedelbart varna säkerhetsteamet om alla potentiella sårbarheter. Potentiella säkerhetsproblem kan flaggas till säkerhetsteamet via WordPress HackerOne⁵. Säkerhetsteamet kommunicerar med varandra via en privat Slack-kanal och arbetar på en avskärmad, privat Trac-instans för att spåra, testa och åtgärda buggar och säkerhetsproblem.

Kvitto ges på varje säkerhetsrapport efter mottagande och teamet arbetar med att bekräfta sårbarheten och bedöma dess allvarlighetsgrad. Om sårbarheten bekräftas planerar säkerhetsteamet för en rättelse som löser problemet, vilken sedan kan inkluderas i en senare utgåva av programvaran WordPress eller kan distribueras som en omedelbar säkerhetsrelease, beroende på problemets allvarlighetsgrad.

För en omedelbar säkerhetsutgåva publiceras en rekommendation av säkerhetsteamet på WordPress.org News-webbplatsen⁶ där utgåvan tillkännages och ändringarna beskrivs i detalj. Krediter för ansvarsfullt avslöjande av en sårbarhet ges i meddelandet för att uppmuntra och förstärka fortsatt ansvarsfull rapportering i framtiden.

Administratörer av programvaran WordPress ser en notis om uppgradering i adminpanelen på sin webbplats när sådan finns tillgänglig, och efter en manuell uppgradering skickas användarna till skärmen ”Om WordPress” där uppgifter om ändringarna finns. Om administratörer har aktiverat bakgrundsuppgraderingar får de ett e-postmeddelande när uppgraderingen har genomförts.

Automatiska bakgrundsuppdateringar för säkerhetsreleaser

Från och med version 3.7 har WordPress infört automatiska bakgrundsuppdateringar för alla mindre versioner⁷, såsom 3.7.1 och 3.7.2. WordPress säkerhetsteam kan upptäcka, åtgärda och skicka ut automatiserade säkerhetsförbättringar för WordPress utan att webbplatsens ägaren behöver göra något, och säkerhetsuppdateringen installeras automatiskt.

När en säkerhetsuppdatering distribueras för den aktuella stabila versionen av WordPress kommer teamet bakom kärnan även att distribuera säkerhetsuppdateringar för alla utgåvor som klarar bakgrundsuppdateringar (sedan WordPress 3.7) så att dessa äldre, men fortfarande giltiga WordPress-versioner erhåller säkerhetsuppdateringar.

Enskilda webbplatsägare kan välja att stänga av automatiska bakgrundsuppdateringar med hjälp av en enkel ändring i webbplatsens konfigurationsfil, men teamet bakom kärnprogramvaran rekommenderar starkt att funktionen behålls oförändrad, liksom även att man kör den senaste stabila utgåvan av WordPress.

2013 OWASP tio-i-topp

Open Web Application Security Project (OWASP) är en online-community som ägnar sig åt säkerhet i webbapplikationer. OWASP:s topp 10-lista⁸ fokuserar på att peka ut de allvarligaste säkerhetsriskerna för ett brett spektrum av organisationer. De 10 största objekten väljs ut och prioriteras i kombination med konsensusuppskattningar av exploaterbarhet, detekterbarhet och konsekvensuppskattningar.

De följande avsnitten diskuterar API:erna, resurserna och de policyer som WordPress använder för att höja skyddet för kärnprogramvaran samt tillägg och teman från tredje part mot dessa potentiella risker.

A1 – Injektion

Det finns en uppsättning funktioner och API:er i WordPress som hjälper utvecklare att förhindra injicering av obehörig kod, och som hjälper dem att validera och sanera data. Bästa praxis och dokumentation finns tillgängliga⁹ om hur man använder dessa API:er för att skydda, validera eller sanera indata och utdata i HTML, URL:er, HTTP-headers och när man interagerar med databasen och filsystemet. Via filter kan administratörer dessutom ytterligare begränsa vilka filtyper som kan laddas upp.

A2 – Felaktigheter i autentisering och sessionshantering

WordPress-kärnan hanterar användarkonton och autentisering. Sådana uppgifter som användar-ID, namn och lösenord hanteras på serversidan samt med hjälp av behörighets-cookies. Lösenord i databasen skyddas med hjälp av standardiserade tekniker för ”saltning” och tänjning av lösenordskontroller. Sedan WordPress 4.0 förstörs alla befintliga sessioner i samband med utloggning.

A3 – Skriptanrop mellan webbplatser (XSS/Cross site scripting)

WordPress tillhandahåller en rad funktioner som kan bidra till att säkerställa att data från användaren är säkra¹⁰. Betrodda användare, dvs. administratörer och redaktörer på en enskild WordPress-installation, och endast nätverksadministratörer i WordPress Multisite, kan vid behov publicera ofiltrerad HTML eller JavaScript, t.ex. inuti ett inlägg eller på en sida. Obetrodda användare och innehåll som skickats in av användare filtreras som standard för att ta bort farliga enheter med hjälp av KSES-biblioteket, via funktionen wp_kses.

Som ett exempel upptäckte teamet bakom WordPress-kärnan före lanseringen av WordPress 2.3 att funktionen the_search_query() missbrukades av de flesta temaförfattare, som inte escapade funktionens utdata innan den användes i HTML. I ett mycket sällsynt fall att något bröt bakåtkompatibiliteten ändrades funktionens utdata i WordPress 2.3 så att den skyddades (escape) från början.

A4 – Osäkra direkta referenser till objekt

WordPress tillhandahåller ofta direkta objektreferenser, såsom unika numeriska identifierare för användarkonton eller innehåll synligt i URL- eller formulärfält. Även om dessa identifierare röjer direkt systeminformation, förhindrar WordPress omfattande system för behörigheter och åtkomstkontroll obehöriga förfrågningar.

A5 – Felkonfigurering med avseende på säkerhet

De flesta av säkerhetskonfigurationerna för WordPress är begränsade till en enda behörig administratör. Standardinställningarna för WordPress utvärderas kontinuerligt inom teamet bakom WordPress-kärnan. Och teamet tillhandahåller dokumentation och bästa praxis för att skärpa säkerheten för serverkonfigurationen för att köra en WordPress-webbplats¹¹.

A6 – Exponering av känsliga uppgifter

Lösenord för användarkonton i WordPress beargetas med ”salt” (slumpmässiga startvärden) och hashing (envägskryptering) baserat på Portable PHP Password Hashing Framework¹². WordPress behörighetssystem används för att kontrollera åtkomsten till privat information, såsom registrerade användares personuppgifter, kommentatörers e-postadresser, privat publicerat innehåll osv. I WordPress 3.7 inkluderades en mätare för lösenordsstyrka i kärnprogramvaran som ger ytterligare information till användare väljer ett lösenord och tips om hur de kan öka styrkan. WordPress har också en valfri konfigurationsinställning för att kräva HTTPS.

A7 – Brist på åtkomstkontroll till funktionsnivåer

WordPress kontrollerar korrekt auktorisering och behörighet för varje åtkomstbegäran till funktionsnivåer innan åtgärden utförs. Åtkomst eller visning av administrativa URL:er, menyer och sidor utan korrekt autentisering är djupt integrerat med autentiseringssystemet för att förhindra åtkomst från obehöriga användare.

A8 – Förfalskad begäran mellan olika webbplatser (CSRF, Cross Site Request Forgery)

WordPress använder kryptografiska tokens, så kallade nonce-värden¹³för att bekräfta avsikten med åtgärdsförfrågningar från inloggade användare för att skydda mot potentiella CSRF-hot. WordPress tillhandahåller ett API för generering av dessa tokens för att skapa och verifiera unika och tillfälliga tokens, och en token är begränsad till en specifik användare, en specifik åtgärd och ett specifikt objekt för en viss tidsperiod. De kan vid behov läggas till i formulär och webbadresser. Dessutom slutar alla nonce-tokens att gälla när du loggar ut.

A9 – Användning av komponenter med kända sårbarheter

Teamet bakom WordPress-kärnan övervakar noga de få inkluderade bibliotek och ramverk som WordPress inkluderar för kärnans funktionalitet. Tidigare har kärnteamet bidragit till flera tredjepartskomponenter för att göra dem säkrare, till exempel uppdateringen för att åtgärda en cross-site-sårbarhet i TinyMCE i WordPress 3.5.2¹⁴.

Vid behov kan teamet bakom kärnan besluta att göra en fork eller ersätta kritiska externa komponenter, t.ex. när SWFUpload-biblioteket officiellt ersattes av Plupload-biblioteket i version 3.5.2, och en säker fork av SWFUpload gjordes tillgänglig av säkerhetsteamet¹⁵ för de tillägg som på kort sikt fortsatte att använda SWFUpload.

A10 – Obekräftade omdirigeringar och vidarebefordringar

WordPress inbyggda åtkomstkontroll och autentiseringssystem skyddar mot försök att omdirigera användare till oönskade destinationer, eller automatiska omdirigeringar. Denna funktionalitet görs också tillgänglig för plugin-utvecklare via ett API, wp_safe_redirect()¹⁶.

Ytterligare säkerhetsrisker och -problem

XXE (XML eXternal Entity/extern XML-entitet) bearbetningsattacker

Vid XML-bearbetning inaktiverar WordPress inläsningen av anpassade XML-entiteter för att förhindra attacker både via External Entity och Entity Expansion. Utöver PHP:s kärnfunktionalitet tillhandahåller WordPress inte någon ytterligare säker API för XML-bearbetning för tilläggsförfattare.

SSRF-attacker (Server Side Request Forgery/förfalskning av förfrågan på serversidan)

HTTP-förfrågningar som utförs av WordPress filtreras för att förhindra åtkomst till loopback (anrop av den egna servern) och privata IP-adresser. Vidare tillåts åtkomst endast till vissa standardiserade HTTP-portar.

Säkerhet för WordPress-tillägg och -teman

Standardtemat

WordPress kräver att ett tema är aktiverat för att kunna visa innehåll i frontend. Standardtemat som levereras med WordPress-kärnan (för närvarande ”Twenty Twenty-Three”) har granskats och testats ingående ur säkerhetssynpunkt av både temautvecklarna och kärnutvecklingsteamet.

Standardtemat kan fungera som en startpunkt för utveckling av ett anpassat tema och webbplatsutvecklare kan skapa ett barntema som innehåller vissa anpassningar men förlitar sig på standardtemat för de flesta funktionerna och för säkerheten. En administratör kan enkelt ta bort standardtemat om det inte behövs.

Filförvar för teman och tillägg på WordPress.org

Det finns över 50 000 tillägg och fler än 5 000 teman listade på webbplatsen WordPress.org. Dessa teman och tillägg har skickats in för att inkluderas, och granskas manuellt av volontärer innan de görs tillgängliga i arkivet.

Att tillägg och teman finns med i filförvaret är ingen garanti för att de är fria från säkerhetsproblem. Riktlinjer tillhandahålls för tilläggsförfattare att studera innan de skickar in sina tillägg för inkludering i arkivet¹⁷, och omfattande dokumentation om hur man utvecklar teman för WordPress¹⁸ finns på webbplatsen WordPress.org.

Varje tillägg och tema har möjlighet att ständigt utvecklas av tilläggets eller temats ägare, och alla senare rättelser eller nyutvecklade funktioner kan laddas upp till filförvaret och göras tillgängliga för dem som använder tillägget eller har installerat temat ifråga, med en beskrivning av den aktuella förändringen. Webbplatsadministratörer notifieras om tillägg som behöver uppdateras via sin adminpanel.

När en sårbarhet i ett tillägg upptäcks av WordPress säkerhetsteam kontaktar de tilläggets upphovsman och samarbetar för att rätta till problemet och publiicera en säker version av tillägget. Om tilläggets upphovsman inte reagerar eller om sårbarheten är allvarlig kommer tillägget/temat att lyftas bort från den publika katalogen och, i vissa fall, rättas och uppdateras direkt av säkerhetsteamet.

Temagranskningsteamet

Temagranskningsteamet är en grupp frivilliga, ledda av viktiga och etablerade medlemmar av WordPress-communityn, som granskar och godkänner teman som lämnats in för att inkluderas i WordPress officiella temakatalog. Temagranskningsteamet upprätthåller de officiella riktlinjerna för temagranskning¹⁹, testdata för Theme Unit Test²⁰och tillägg för temakontroll²¹och försöker engagera och utbilda WordPress temautvecklare kring bästa praxis för utveckling. Rekryteringen till gruppen överses av utvecklingsteamet för WordPress-kärnan.

Webbhotellets roll för säkerheten i WordPress

WordPress kan installeras på många olika plattformar. Även om WordPress-kärnan skapar goda förutsättningar för säker drift av en webbtillämpning, något som vi beskriver i detta dokument, är konfigurationen av operativsystemet och den underliggande webbserverstrukturen lika viktiga för att göra WordPress-tillämpningar säkra.

En notis om WordPress.com och WordPress-säkerhet

WordPress.com är den största WordPress-installationen i världen och ägs och förvaltas av Automattic, Inc. som grundades av Matt Mullenweg, WordPress-projektets medskapare. WordPress.com körs på WordPress kärnprogramvara och har sina egna säkerhetsprocesser, risker och lösningar²². Detta dokument avser säkerheten för den nedladdningsbara WordPress-programvaran med öppen källkod man kan köra på eget webbhotell, som finns tillgänglig från WordPress.org och kan installeras på vilken server som helst i världen.

Appendix

API:er i WordPress-kärnan

WordPress Core Application Programming Interface (API) består av flera enskilda API:er²³ vilka vart och ett täcker de funktioner som ingår i, och användningen av, en viss uppsättning funktioner. Tillsammans bildar dessa projektgränssnittet som gör det möjligt för tillägg och teman att interagera med, anpassa och utöka funktionaliteten i WordPress kärna på ett säkert och tryggt sätt.

Samtidigt som varje WordPress-API tillhandahåller bästa praxis och standardiserar sätten att interagera med och utöka programvaran i WordPress-kärnan är följande WordPress-API:er mest relevanta med avseende på att genomdriva och stärka säkerheten i WordPress:

Databas-API

Database API:et ²⁴som lades till i WordPress 0.71, tillhandahåller den korrekta metoden för åtkomst till data i form av namngivna värden som lagras i databaslagret.

Filsystem-API:et

Filesystem API:et²⁵, tillagt i WordPress 2.6²⁶skapades ursprungligen för WordPress egen funktion för automatiska uppdateringar. API:et för filsystemet abstraherar funktionaliteten som behövs för att läsa och skriva lokala filer till filsystemet på ett säkert sätt, på en mängd olika typer av servrar.

Detta görs genom klassen WP_Filesystem_Base och flera underklasser som implementerar olika sätt att ansluta till det lokala filsystemet, beroende på vad den specifika webbservern stödjer. Alla teman eller tillägg som behöver skriva filer lokalt bör göra detta med hjälp av WP_Filesystem-familjen av klasser.

HTTP API

HTTP-API²⁷, tillagt i WordPress 2.7²⁸ och utökat ytterligare i WordPress 2.8, standardiserar HTTP-förfrågningar för WordPress. API:et hanterar cookies, gzip-kodning och -avkodning, chunk-avkodning (om HTTP 1.1 används) och olika andra HTTP-protokollimplementeringar. API:et standardiserar förfrågningar, testar varje metod innan den skickas och, baserat på din serverkonfiguration, använder den lämpliga metoden för att utföra förfrågan.

Rättigheter och nuvarande användar-API

API:et för behörigheter och aktuell användare²⁹ är en uppsättning funktioner som hjälper till att verifiera den aktuella användarens behörigheter och befogenhet att utföra alla uppgifter eller operationer som begärs, och kan skydda ytterligare mot att obehöriga användare får åtkomst till eller utför funktioner de inte har behörighet till.

Licens avseende innehållet i vitpappret

Texten i detta dokument (med undantag för WordPress-loggan och varumärket) är licensierad under CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. Du kan kopiera, modifiera, distribuera och framföra arbetet, även för kommersiella ändamål, allt utan att be om tillstånd.

Ett särskilt tack till Drupals vitbok om säkerhetsom gav oss en del inspiration.