Säkerhet

Läs mer om säkerheten i WordPress-kärnans programvara i detta fria vitpapper. Du kan även ladda ned det 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 system för innehållshantering (CMS, Content Management System) med öppen källkod och driver miljontals webbplatser, webbtillämpningar och bloggar. För närvarande används det av fler än 42 % av de 10 mijloner populäraste webbplatserna på internet. WordPress användbarhet, utbyggbarhet och fullmogna utvecklarkollektiv 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 innehållshanteringssystem (CMS/Content Management System) med fri och öppen källkod. Det är det mest använda CMS:et i världen och driver fler än 42 % av de 10 miljoner populäraste webbplatserna1, vilket ger det en uppskattad marknadsandel om 62$nbsp;% av alla webbplatser som använder ett CMS.

WordPress licensieras under General Public License (GPLv2 eller senare) som innebär fyra grundläggande friheter och kan betraktas som ”Grundläggande rättigheter”:

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

Kärnledningsteamet för WordPress

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önster2:

  • 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 anges av de två första talen. Till exempel är 3.5 en huvudversion, liksom 3.6, 3.7 eller 4.0. Det finns inte något som heter ”WordPress 3” eller ”WordPress 4” och varje huvudversion benämns med dess nummer, t.ex. ”WordPress 3.9”.

Huvudversioner kan lägga till nya funktioner för användare och API:er för utvecklare. Trots att det är vanligt i programvaruvärlden att ”huvudversion” innebär att du kan bryta bakåtkompatibilitet försöker WordPress att aldrig göra detta. Bakåtkompatibilitet är en av projektets viktigaste filosofier, med syftet att uppdateringar ska bli mycket enklare för både användare och utvecklare.

En mindre version av WordPress anges med ett tredje tal. Version 3.5.1 är en mindre version, liksom 3.4.23. Mindre versioner är endast avsedda att rätta sårbarheter i säkerheten och lösa kritiska problem. Eftersom nya versioner av WordPress släpps regelbundet – målet är en ny huvudversion med 4–5 månaders mellanrum och mindre versioner kommer när de behövs – 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 säkerhetsteam består av cirka 50 experter, däribland ledande utvecklare och säkerhetsforskare – cirka hälften är anställda på Automattic (företaget bakom WordPress.com, webbens första och största plattform för WordPress-system), och några arbetar inom webbsäkerhet. Teamet rådfrågar välkända och betrodda säkerhetsforskare och webbhotellsföretag3.

WordPress säkerhetsteam samarbetar ofta med andra säkerhetsteam för att lösa problem med gemensamma beroenden, till exempel när man löste en sårbarhet i XML-tolken i PHP, som används i API:et XML-RPC som medföljer WordPress, i WordPress 3.9.24. Lösningen av denna sårbarhet var ett resultat av gemensamma ansträngningar mellan säkerhetsteamen för både WordPress och Drupal.

Risker, processer och historik inom WordPress-säkerhet

Säkerhetsteamet för WordPress tror på ansvarsfullt avslöjande genom att man direkt informerar säkerhetsteamet om eventuella sårbarheter. Information om potentiella sårbarheter kan lämnas till säkerhetsteamet via WordPress HackerOne5. Internt kommunicerar säkerhetsteamet via en sluten Slack-kanal arbetar i en avgränsad och skyddad egen Trac-installation för uppföljning, testning, felrättning 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.

I händelse av en omedelbar säkerhetsrelease publicerar säkerhetsteamet en notis på nyhetsbloggen för WordPress.org6 där releasen kungörs och information ges om genomförda ändringar. I notisen ger man även erkännande för motsvarande ansvarsfulla avslöjande om sårbarheten för att uppmuntra och stärka ansvarsfulla avslöjanden även 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 införde WordPress automatiska uppdateringar i bakgrunden för alla mindre uppdateringar7 såsom 3.7.1 och 3.7.2. WordPress säkerhetsteam kan upptäcka, korrigera och distribuera säkerhetsuppdateringar för WordPress utan att webbplatsens ägare behöver göra något, och säkerhetsuppdateringen kommer att installeras automatiskt.

När en säkerhetsuppdatering distribueras för den aktuella stabila versionan av WordPress kommer teamet bakom kärnan även att distribuera säkerhetsuppdateringar för alla releaser 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

OWASP (Open Web Application Security Project/Öppet projekt för säkerhet i webbtillämpningar) är en online-community som ägnar sig åt säkerhet iwebbtillämpningar. OWASP:s tio-i-topp lista8 avser att räkna upp de allvarligaste säkerhetsriskerna för många olika typer av organisationer. De tio topplaceringarna väljs och prioriteras i kombination med en gemensamma värderingar av lätthet att utnyttja, sannolikhet för upptäckt och graden av påverkan.

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 tillgängliga i WordPress för att hjälpa utvecklare att säkerställa att obehörig kod inte kan injiceras samt hjälpa dem att validera och sanera data. Bästa praxis och dokumentation finns tillgängliga9 kring hur man använder dessa API:er för att skydda, validera eller sanera inmatade eller utmatade data i HTML, URL:er, HTTP-headers samt i samband med interaktion med databasen och filsystemet. Utöver detta kan administratörer via filterfunktioner 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 hjälpa till att säkerställa att data från användaren är säkra10. Betrodda användare, alltså administratörer och redaktörer på enstaka WordPress-installationer och för WordPress Multisite enbart nätverksadministratörer kan vid behov publicera ofiltrerad HTML eller JavaScript, t.ex. i ett inlägg eller på en sida. Obetrodda användare och innehåll från användare filtreras som standard för att avlägsna farliga objekt, med hjälp av biblioteket KSES via funktionen wp_kses.

Som ett exempel uppmärksammade teamet som underhåller WordPress-kärnan före releasen av WordPress 2.3 att funktionen the_search_query() användes på fel sätt av de flesta tema-utvecklarna, som inte rensade funktionens resultat innan det användes i HTML-kod. Det var ett mycket sällsynt fall där man i viss mån bröt bakåtkompatibiliteten, i och med att funktionens resultat från och med WordPress 2.3 ändrades till att vara filtrerat redan från början.

A4 - Osäkra direkta referenser till objekt

WordPress tillhandahåller ofta direkta objektreferenser, såsom unika nummer som identifierar användarkonton eller tillgängligt innehåll i URL:er eller i fält i formulär. Även om dessa ID-strängar avslöjar direkt systeminformation förhindrar det omfattande systemet för behörigheter och åtkomst varje obehörig begäran.

A5 - Felkonfigurering med avseende på säkerhet

Huvuddelen av åtgärderna för säkerhetskonfigurering av WordPress är begränsade till en enda behörigh administratör. Standardinställningarna i WordPress utvärderas ständigt av deltagare i teamet kring kärnan och teamet bakom WordPress-kärnan tillhandahåller dokumentation och bästa praxis för hur man bäst höjer säkerheten via konfigurationen av servrar som kör en WordPress-webbplats11.

A6 - Exponering av känsliga uppgifter

Lösenord för WordPress-användare bearbetas salt-värden och hash-algoritmer enligt ramverket Portabale PHP Password Hashing Framework12. Behörighetssystemet i WordPress används för kontroll av åtkomst till känslig information, såsom potentiellt identifierbara uppgifter om registrerade användare, e-postadresser till personer som kommenterat, privat publicerat innehåll m.m. I WordPress 3.7 inkluderades en mätare av styrkan hos lösenord i kärnprogramvaran för att ge mer information till användare när de väljer sitt lösenord och ge tips om hur lösenordsstyrkan kan höjas. Dessutom har WordPress en valfri konfiguration som kräver användning av 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 kryptologiska behörighetsflaggor, som kallas nonce-värden13, för att bekräfta avsikten bakom åtgärdsbegäran från auktoriserade användare som ett skydd mot möjliga CSRF-attacker. WordPress tillhandahåller ett API för att generera dessa åtkomstflaggor för att skapa och bekräfta unika och tillfälliga flaggor och de är begränsade till en viss användare, en viss åtgärd, ett visst objekt och en viss tidsperiod och kan vid behov läggas tid formulär och URL:er. Dessutom inaktiveras alla nonce-värden i samband med utloggning.

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

Teamet som underhåller WordPress-kärnan övervakar ingående det begränsade antalet bibliotek och ramverk som finns inkluderade i WordPress för kärnfunktioner. Tidigare har teamet bakom kärnan gjort bidrag till en rad tredjepartskomponenter för att höja deras säkerhet, såsom en uppdatering för att korrigera en sårbarhet mot anrop till annan webbplats i TinyMCE i WordPress 3.5.214.

Vid behov kan teamet bakom kärnan besluta att skapa en förgrenad version eller byta ut kritiska externa komponenter, till exempel när biblioteket SWFUpload officiellt ersattes av biblioteket Plupload i 3.5.2, och en säkrad förgrening av SWFUpload gjordes tillgänglig av säkerhetsteamet<15 för de tillägg som på kort sikt fortsatte att använda SWFUpload.

A10 - Obekräftade omdirigeringar och vidarebefordringar

WordPress interna åtkomstkontroll och autentiseringssystem skyddar mot försök att omdirigera användare till oönskade adresser eller mot automatiska omidirigeringar. Samma funktion är tillgänglig för tilläggsutvecklare via ett API, wp_safe_redirect()16.

Ytterligare säkerhetsrisker och -problem

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

Vid bearbetning av XML-kod inaktiverar WordPress inläsningen av anpassade XML-entiteter för att skydda mot attacker både med externa entiteter och entitetsexpansion. Utöver den inbyggda funktionaliteten i PHP tillhandahåller inte WordPress något ytterligare API för säker XML-bearbetning för tilläggsutvecklare.

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 ett tema för att kunna visa innehåll webbplatsens front-end. Standardtemat som levereras med WordPress (för närvarande ”Twenty Twenty-One”) har granskats ingående och testats med avseende på säkerhet både av temautvecklarteamet och av teamet som utvecklar programvarans kärna.

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 funktionerrna 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 fler än cirka 50 000 tillägg och 5 000 teman på webbplatsen WordPress.org. Dessa teman har skickats in för att inkluderas och granskas manuellt av frivilliga innan de görs tillgängliga i filförvaret.

Inkludering av tillägg och teman i filförvaret utgör ingen garanti att de är fria från sårbarheter. Det finns riktlinjer för tilläggsutvecklare som de bör följa innan de skickar in sina verk för inkludering i filförvaret17, och det finns omfattande dokumentation på webbplatsen WordPress.org om hur man utvecklar WordPress-teman18.

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 av frivilliga under ledning av djupt involverade och etablerade medlemmar i WordPress-communityn som granskar och godkänner teman för inkludering den officiella temakatalogen för WordPress. Temagranskningsteamet underhåller de officiella riktlinjerna för temagranskning19, testdata för enhetstester av teman20 och tillägg för temagranskning21 samt försöker engagera och utbilda alla som utvecklar teman för WordPress om bästa praxis för temautveckling. Insläpp av deltagare i gruppen granskas av personer som har rätt att bekräfta programkod i kärnan ur WordPress utvecklingsteam.

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 kommentar om WordPress.com och WordPress-säkerhet

WordPress.com är den största WordPress-installationen i världen och ägs och drivs av Automattic, Inc, som är grundat av MattMullenweg, WordPress-projeketets medskapare. WordPress.com körs på WordPress kärnprogramvara och har sina egna säkerhetsprocesser, risker och lösningar22. Detta dokument diskuterar säkerheten för WordPress som körs på egen server, är nedladdningsbar programvara med öppen källkod som finns på WordPress.org och får installeras på vilken server som helst i världen.

Appendix

API:er i WordPress-kärnan

WordPress-kärnans gränssnitt för tillämpningsprogrammering (API – Application Programming Interface) består av en rad olika API:er23, vilka vart och ett omfattar de funktioner som ingår i och utnyttjar en viss uppsättning funktioner. Sammantaget utgör de projektets gränssnitt, som låter tillägg och teman interagera med, förändra och utöka funktionerna i WordPress-kärnan på ett säkert och kontrollerat 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

Databas-API:et24, som tillkom i WordPress 0.71, tillhandahåller rätt metod för åtkomst till data i form av namngivna värden, vilka lagras i databaslagret.

Filsystem-API:et

Filsystem-API:et25, som tillkom i WordPress 2.626, skapades utsprungligen för WordPress egen funktion för automatiska uppdateringar. Filsystem-API:et abstraherar de funktioner som behövs för att säkert läsa och skriva filer mot det lokala filsystemet på en rad olika servertyper.

Den gör detta med hjälp av klassen WP_Filesystem_Base och flera underklasser, som implementerar olika sätt att ansluta till det lokala filsystemet, beroende på vad den lokala servern stöder. Alla teman eller tillägg som behöver skriva filer lokalt bör använda de olika WP_Filesystem-klasserna för detta ändamål.

HTTP API

HTTP-API27, som tillkom i WordPress 2.728 och utökades i och med WordPress 2.8, standardiserar HTTP-förfrågan för WordPress. API:et hanterar cookies, gzip-kodning och -avkodning, segmentavkodning (vid användning av HTTP 1.1) och en rad andra implementationer av HTTP-protokoll. API:et standardiserar förfrågningar, provar varje metod innan data skickas och, beroende på serverkonfigurationen, använder lämplig metod för att utföra förfrågan.

Rättigheter och nuvarande användar-API

API:et för behörigheter och aktuell användare29 är en uppsättning funktioner som hjälper till att kontrollera den nuvarande användarens behörigheter och åtkomst till att utföra någon uppgift eller åtgärd som begärs, vilken vidare kan hindra att obehöriga användare kommer åt eller utför funktioner, för vilka de saknar behörighet.

Licens avseende innehållet i vitpappret

Texten i detta dokument (med undantag för WordPress logga och varumärke) licensieras under CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. Du får kopiera, modifiera, distribuera och uppföra verket, även för kommersiella ändamål, helt utan att be om tillstånd för detta.

Ett tack riktar vi till Drupals vitpapper om säkerhet, som gav oss en del inspiration.

Ytterligare läsning

Skrivet av Sara Rosso

Bidrag från Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí, Dion Hulse, Mo Jangda, Paul Maiorana

Version 1.0 mars 2015

Fotnoter