Tryggleik

Lær meir om WordPress-kjerneprogramvara i dette tekniske dokumentet. Du kan òg lasta det ned som PDF.

Oversikt

Dette dokumentet analyserer og forklarar utviklinga og tryggingsprosessane til WordPress-kjernen, samt korleis tryggleik er bygd inn i programvara. Dei som skal ta avgjerder om WordPress som innhaldsstyringssystem eller rammeverk for nettprogram, kan bruka dette dokumentet når dei analyserer og tek avgjerder. Utviklarar kan bruka dokumentet til å gjera seg kjende med tryggingskomponentane og beste praksis for programvara.

Opplysingane i dette dokumentet er oppdaterte for den siste stabile utgåva av programvara, som er WordPress 4.7 då dette vart skrive. Opplysingane gjeld òg truleg dei siste utgåvene òg, fordi WordPress-utviklarane er opptekne av bakoverkompatibilitet. Me nemner spesifikke tryggleikstiltak og endringar, fordi dei blir tekne med i spesifikke utgåver. Me tilrår sterkt at du alltid køyrer siste utgåva av WordPress for å få den sikraste brukaropplevinga.

Kort samandrag

Wordpress er eit dynamisk, ope innhaldsstyringssystem som blir brukt på millionar av nettstader, nettprogram og bloggar. WordPress ligg no bak meir enn 38% av dei største topp 10 millionar nettstadene på internett. WordPress er allsidig, utvidbart og har eit modna utviklarmiljø, og er difor populært for nettstader av alle storleikar.

Sidan oppstarten i 2003 har WordPress vorte herda heile tida, slik at kjerneprogramma kan handtera og løysa vanlege trugsmål mot tryggleiken. Mellom dei er topp ti-lista fro Open Web Application Security-prosjektet (OWASP), som du kan lesa meir om her.

Trygginglaget i WordPress arbeider saman med kjerneutviklarane og det globale WordPress-brukarmiljøet for å finna og løysa tryggleiksproblem i programvara som er gjeven ut på WordPress.org. Dei lagar òg tilrådingar og dokumentasjon for tredjepartsutviklarar av bunader og innstikk, slik at dei kan læra gode framgangsmåtar når det gjeld tryggleik.

Dei som utviklar og styrer nettstader, bør vera spesielt merksame på å bruka API-ar og underliggjande tenaroppsett rett, særleg der det har vore tryggleiksproblem. Dei bør òg passa på at alle brukarar har sterke passord for å logga inn på WordPress.

WordPress, kort fortalt

WordPress er eit fritt og ope system for innhaldsstyring (CMS). Det er den mest brukte CMS-programvara i verda, og driv meir enn 38% av dei største 10 millionar nettstadene1. Det gjev om lag 62% marknadsdel av alle nettstader som bruker eit CMS-system.

WordPress er gjeve ut under General Public-lisensen (GPLv2 eller nyare), som gjev fire grunnleggjande fridomar, og fungerer som «grunnlov» for WordPress:

  1. Retten til å køyra programmet til eit kvart føremål.
  2. Retten til å studera korleis programmet verkar, og endra det til å gjera det du ynskjer.
  3. Retten til å spreia vidare.
  4. Retten til å spreia kopiar av den endra programvara di til andre.

Leiarlaget i WordPress

WordPress-prosjektet er eit meritokrati som blir drive av eit leiarlag under leiing av med-opphavsmann og hovudutviklar Matt Mullenweg. Laget styrer alle deler av prosjektet, inklusiv kjerneutviklinga, wordpress.org og brukarsamfunnsaktivitetar.

Leiarlaget er Matt Mullenweg, fem hovudutviklarar, og meir en eit dusin kjerneutviklarar med fast innsendingstilgang. Desse har siste ordet når det gjeld tekniske avgjerder, og leier drøftingar om arkitektur og utføring.

WordPress har mange utviklarar som bidreg. Nokre av dei er tidlegare eller noverande innsendarar, andre truleg framtidige innsendarar. Desse utviklarane er truverdige og røynde bidragsytarar til WordPress, og har fått høg vørdnad mellom andre utviklarar. Når det trengst, har WordPress òg gjesteutviklarar. Dei blir gjevne innsendingstilgang anten for ein viss komponent, eller som ei mellombels ordning.

Kjerneutviklarane, saman med andre utviklarar, styrer korleis WordPress skal utvikla seg. Hundrevis av utviklarar skriv kode til kvar versjon av WordPress. Desse er friviljuge som bidreg til hovudkoden på ein eller annan måte.

Utviklingssyklusen i WordPress

Kvar utgjevingssyklus i WordPress blir leidd av ein eller fleire av hovudutviklarane. Ein syklus varer vanlegvis rundt fire månader frå fyrste planleggingsmøte til utgjeving av den nye versjonen.

Utgjevingssyklusane fyljger dette mønsteret2:

  • Fase 1: Planleggja og rekruttera lagleiarar. Dette gjer me i #core-samtalerommet på Slack. Utgjevingsleiaren diskuterer funksjonar i den neste utgåva av WordPress. Bidragsytarane blir med i den diskusjonen. Utgjevingsleiaren peikar ut lagleiarar for kvar av funksjonane.
  • Fase 2: Utviklingsarbeidet byrjar. Lagleiarar samlar laga sine og arbeider på dei funksjonane die er tildelte. Det blir planlagt faste møte og samtaler for å sikra at utviklingsarbeidet går framover.
  • Fase 3: Beta. Me gjev ut beta-utgåver, og bed beta-testarar om å byrja å leita etter programfeil. Det kjem ikkje fleire nye funksjonar i denne fasen. Tredjepartsutviklarar blir oppmoda om å testa koden sin mot dei komande endringane.
  • Fase 4: Utgjevingskandidat. Strengene blir frosne for omsetjing frå no. Det blir lagt vekt på tilbakegangs- og blokkeringsfeil.
  • Fase 5: Utgjeving. WordPress-versjonen blir gjeven ut og gjort tilgjengeleg på WordPress-styrar for oppdateringar.

Versjonsnummer og tryggingsoppdateringar

Du kjenner att store WordPress-utgjevingar på dei to fyrste sifra i versjonsnummeret. 3.5 er ei stor utgjeving, og det same er 3.6, 3.7, eller 4.0. “WordPress 3” eller “WordPress 4” finst ikkje, og alle utgjevingar blir nemnde med versjonsnummeret, til dømes “WordPress 3.9.”

Store utgjevingar kan innhelada nye funskjonar for brukarane og API-ar for utviklarane. Det vanlege i annan programvare er at store utgjevingar kan bryta bakoverkompatibiliteten. WordPress legg vinn på å aldri gjera det. Bakoverkompatibilitet er ei av dei viktigaste retningslinene for dette prosjektet, og målet er å gjera oppdateringar enklast råd for både brukarar og utviklarar.

Det tredje sifferet i versjonsnummeret viser til små endringar i WordPress. Versjon 3.5.1 er ei lita endirng, til liks med 3.4.23. Små utgåver blir brukte for å retta tryggingsfeil og alvorlege programfeil. Sidan nye versjonar av WordPress blir gjevne ut så ofte (målet er kvar fjerde til femte månad, og småutgjevingar kjem imellom etter trong), treng me berre tal for store og små versjonsendringar.

Bakoverkompatibilitet

WordPress-prosjektet er sterkt opptekne av bakoverkompatibilitet. Det tyder at bunader, innstikk og eigen kode held fram å fungera når WordPress-programvara blir oppdatert. Det oppmodar dei som eig nettstader om å halda WordPress oppdatert til den siste sikre utgåva.

WordPress og tryggleik

Tryggleikslaget i WordPress

Tryggleikslaget i WordPress er om lag 50 ekspertar, mellom dei hovudutviklarar og tryggleiksforskarar — om lag halvparten er tilsette i Automattic (firmaet bak WordPress.com, den fyrste og største WordPress-plattforma på veven), og fleire andre jobbar innan vevtryggleik. Laget samarbeider med fleire velkjende tryggleiksforskarar og nettvertsfirma3.

Tryggleikslaget i WordPress samarbeider ofte med andre tryggleikslag for å løysa problem med felles program, slik som tryggleikshola i PHP XML-tolken, som blir brukt av XML-RPC API-et som fylgjer med WordPress, i WordPress 3.9.24. Dette holet vart tetta ved innsats frå tryggleikslaga i WordPress og Drupal.

Tryggleiksrisikoar, prosessar og historikk

Tryggleikslaget i WordPress trur på ansvarleg offentleggjering ved å seia frå til tryggleikslaget straks om potensielle tryggleikshòl. Du kan seia frå om risikoar og tryggleikshòl på WordPress HackerOne5. Tryggleikslaget kommuniserer internt på ein privat Slack-kanal, og arbeider på ein avstengd, privat Trac for å spora, testa og ordna feil og tryggleiksproblem.

Kvar tryggleiksrapport blir teken hand om når han blir motteken, og laget arbeider for å stadfesta hòlet og avgjera kor alvorleg det er. Viss det blir stadfesta, lagar tryggleikslaget ein plan for å lappa hòlet slik at problemet blir løyst. Avhengig av alvorsgraden blir løysinga lagt opp til neste vanlege utgåve av WordPress, eller lagt ut som straksoppdatering.

Når det gjeld straksoppdateringar grunna tryggleik, legg alltid tryggleikslaget ut ein artikkel på WordPress.org6 med melding om oppdateringa og detaljar om endringane. Me skriv kven som oppdaga tryggleikshòlet i artikkelen, og vil med det oppmoda til og forsterka forsvarleg rapportering i framtida.

Administratorar på WordPress-nettstader ser ei varsling på styringspanelet på nettstaden sin når det finst nye utgjevingar. Ved manuell oppgradering blir brukarar sende vidare til Om WordPress-sida, der det står detaljar om endringane. Om administratorar har skrudd på automatiske bakgrunnsoppdateringar, får dei ein epost etter at oppdateringa er fullførd.

Automatiske bakgrunnsoppdateringar for tryggleiksutgjevingar

Sidan versjon 3.7 har WordPress hatt automatiske bakgrunnsoppdateringar for alle mindre utgjevingar7, slik som 3.7.1 og 3.7.2. Tryggleikslaget i WordPress kan finna, fiksa og gje ut automatiske tryggleiksoppdateringar for WordPress utan at den som driv nettstaden treng å gjera noko, og oppdateringa vil installera seg automatisk.

Når det kjem ei tryggleiksoppdatering for den stabile utgåva av WordPress, vil kjernelaget òg gje ut tryggleiksoppdateringar for alle dei utgjevingane som kan få bakgrunnsoppdateringar (WordPress 3.7 og nyare), slik at desse eldre versjonane òg får tryggleiksoppdateringar.

Nettstadeigarar kan velja å fjerna automatiske bakgrunnsoppdateringar med ei enkel endring i oppsettsfila, men me tilrår sterkt å ha funksjonen på. Sameleis tilrår me å køyra siste stabile utgåva av WordPress.

Topp ti-lista frå OWASP 2013

Open Web Application Security Project (OWASP) er eit brukarmiljø på nettet som er opptekne av tryggleik i nettprogram. Topp ti-lista frå OWASP8 gjev dei ti alvorlegaste tryggingsrisikoane for eit breitt utval organisasjonar. Dei ti oppføringane er valde og prioriterte ut frå kor alvorlege risikoane er, kor lette dei er å utnytta og kor lette dei er å finna.

Avsnitta under diskuterer APIar, ressursar og retningsliner WordPress bruker for å styrka kjerneprogramma samt innstikka og bunadene frå tredjepartar mot desse potensielle farane.

A1 - innsprøyting

Det finst ei mengd funksjonar og APIar i WordPress som skal hjelpa utviklarar i å sikra at uautorisert kode ikkje blir sprøytt inn, og som skal hjelpa dei å sikra og vaska data. Du finn døme på god praksis og dokumentasjon9 på korleis du bruker desse APIane til å verna, godkjenna eller vaska inn- og utdata i HTML, adresser, HTTP-hovud, og når du samhandlar med databasen og filsystemet. I tillegg kan styrarar bruka filter til å avgrensa kva filtypar som er lov å lasta opp.

A2 - Øydelagt innloggings- og økthandsaming

Kjerneprogramvara i WordPress handterer brukarkontoar og innlogging. Detaljar som brukar-ID, namn og passord blir handtert av tenaren, så vel som innloggingsinfokapslar. Passorda er verna i databasen med standard saltings- og strekkingsteknikkar. Eksisterande økter blir sletta ved utlogging i WordPress etter versjon 4.0.

A3 - Krysskriptåtak (XSS)

Wordpress har ei rad funksjonar som kan hjelpa til å sikra at data frå brukarane er trygge10. Priviligerte brukarar, det vil seia styrarar og redaktørar på ein WordPress-installasjon, samt nettverksstyrarar på multinettstad-installasjonar, kan leggja ut ufiltrert HTML og Javascript slik dei treng, til dømes inni eit innlegg eller side. Uprivilegerte brukarar og innhald frå brukarar blir filtrert for å fjerna farleg innhald, med bruk av KSES-bibliotektet gjennom wp_kses-funksjonen.

Eit døme er at kjerneutviklarane, før dei ga ut WordPress 2.3, la merke til at the_search_query()-funksjonen ofte vart feilbrukt av dei som laga bunader, fordi dei ikkje verna resultatet av funksjonen for bruk i HTML. Difor vart resultata verna på førehand då WordPress 2.3 kom ut, og det er ei av få gonger me har brote bakoverkompatibiliteten.

A4 - usikker direkte objektreferanse

WordPress gjev ofte direkte koplingar til objekt, slik som unike nummerpeikarar for brukarkontoer eller innhald i adresser eller skjema. Desse peikarane gjev ut systeminformasjon, men det rikhaldige løyve- og tilgangskontrollsystemet i WordPress hindrar uvedkomande spørjingar.

A5 - Feil i tryggingsoppsettet

Det meste av tryggingsoppsettet i WordPress blir overlete til ein einaste styrar. Kjernelaget bak WordPress vurderer alltid standardinnstillingane i programmet, og gjev dokumentasjon og gode døme på korleis du best kan sikra tenaroppsettet på WordPress-nettstader11.

A6 - Eksponering av løynlege data

Brukarkontoar i WordPress blir salta og nøkkelkrypterte etter rammeverket Portable PHP Password Hashing Framework12. Tilgangssystemet i WordPress blir brukt til å kontrollera tilgang til private opplysingar, slik som epostadresser, privat innhald osb. I WordPress 3.7 kom det ein målar for passordstyrke som gav brukarane ekstra hjelp til å laga sterke passord. WordPress har òg tilleggsinnstillingar for å krevja HTTPS.

A7 - manglande kontroll på funksjonsnivåtilgang

WordPress sjekkar om det er ordentleg godkjenning og tilgangsløyve for alle spørjingar om funksjonsnivå før handlinga blir utførd. Tilgang eller visualisering av styringsadresser, menyar og sider utan skikkeleg godkjenning er tett knytt til innloggingssystemet for å hindra tilgang frå brukarar som ikkje skal ha tilgang.

A8 - Falskneri ved kryssnettstadspørjingar (Cross Site Request Forgery, CSRF)

Wordpress bruker kryptografiske teikn med namnet nonce13 for å godkjenna føremålet med handlingsspørjingar frå innlogga brukarar for å verna mot potensielle CSRF-trugsmål. WordPress tilbyr ein API som lagar og godkjenner unike og mellombelse teikn. Teiknet er avgrensa til ein bestemt brukar, handling, objekt eller tidsrom, og desse avgrensingane kan leggjast til skjema og adresser etter trong. I tillegg blir alle nonce-teikna ugyldige ved utlogging.

A9 - å bruka komponentar med kjende hol

Kjernelaget i WordPress held nøye oppsyn med dei få biblioteka og rammeverka som er inkludert i WordPress, og som syter for viktige funksjonar. Tidlegare har kjernelaget bidrege til fleire tredjepartskomponentar for å gjera dei sikrare, slik som oppdateringa som retta eit kryssdomene-problem i TinyMCE i WordPress 3.5.214.

Viss det trengst, kan kjernelaget koma til å gafla eller byta ut kritiske eksterne komponentar, slik som då SWFUpload-biblioteket offisielt vart erstatta av Plupload-biblioteket i 3.5.2, og ei trygg gafling av av SWFUpload vart gjort tilgjengeleg av tryggleikslaget<15 for dei innstikka som heldt fram å bruka SWFUpload.

A10 - uynskte omdirigeringar og vidaresendingar

Det interne tilgangskontroll- og godkjenningssystemet i WordPress vil verna mot forsåk på å styra brukarar til uynskte mål eller automatiske omdirigeringar. Desse funksjonane er òg tilgjengelege for utviklarar via eit API, wp_safe_redirect()16.

Fleire tryggleiksrisikoar og uroelement

XXE (XML eXternal Entity)-handsamingsåtak

Når WordPress handsamar XML, blir høvet for å lasta eigne XML-entitetar skrudd av for å hindra ekstern etntitet- og entitetsutvidings-åtak. WordPress tilbyd ikkje fleire tilleggssikringar for sikker XML ut over grunnfunksjonane i PHP for dei som lagar innstikk.

SSRF (Server Side Request Forgery)-åtak

HTTP-førespurnader frå WordPress blir filtrerte for å hindra tilgang til loop- og private IP-adresser. I tillegg blir det berre gjeve tilgang til visse standard HTTP-portar.

Tryggleik for WordPress-bunader og -innstikk

Standardbunaden

WordPress må ha ein bunad for å kunna visa innhaldet på nettstaden. Standardbunaden som fylgjer med WordPress (for tida "Twenty Twenty") er nøye utprøvd og sjekka for tryggleiksproblem, både av bunad- og kjerneutviklarane.

Standardbunaden kan vera eit godt utgangspunkt for å utvikla eigne bunader, og nettstadutviklarar kan laga underbunader som inneheld noko tilpassing, men elles lenar seg på standardbunaden når det gjeld dei fleste funksjonane og tryggleiken. Ein styrar kan enkelt fjerna standardbunaden om han ikkje trengst.

Bunad- og instikkatalogar på WordPress.org

Det finst meir enn 50  000 innstikk og 5  000 bunader på WordPress.org. Friviljuge ser gjennom desse innstikka og bunadene før dei blir gjort offentleg tilgjengelege i katalogen.

Sjølv om eit innstikk eller ein bunad ligg ute i katalogen, er ikkje det nokon garanti for at dei er feilfrie. Utviklarane har retningsliner som dei kan lesa før dei lastar opp noko til katalogen17, og det finst rikeleg med dokumentasjon om bunadutvikling på WordPress.org18.

Utviklarane har høve til å oppdatera kvart innstikk og bunad så ofte dei vil. Dei kan lasta opp feilrettingar eller nye funksjonar til katalogen, slik at dei blir tilgjengelege for brukarar som har installert innstikka eller bunadene. Brukarane vil sjå ei skildring av kva som er endra. Dei som styrer nettstadene, får melding på styringspanela om kva innstikk dei kan oppdatera.

Når tryggleikslaget i WordPress oppdagar problem med eit innstikk, kontaktar og samarbeider dei med produsenten for å gje ut ein sikker versjon av innstikket. Dersom ikkje produsenten svarar, eller alvorsgraden er høg, blir innstikket fjerna frå den offentlege katalogen. I nokre tilfelle blir innstikket retta og oppdatert direkte av tryggleikslaget.

Bunadlaget

BBunadlaget er ei gruppe friviljuge under leiing av hovudmedlemmer av WordPress-samfunnet. Dei ser gjennom og godkjenner bunader som skal vera med i den offisielle WordPress-bunadkatalogen. Bunadlaget vedlikeheld dei offisielle retningslinene for bunadkontroll19, testdata for bunader20 og bunadsjekk-programma21, og dei prøver å utdanna og hjelpa dei som lagar bunader til å gjera det på beste måte. Sentrale bidragsytarar til WordPress avgjer kven som blir med i laget.

Kva rolle nettverten spelar når det gjeld tryggleik i WordPress

Du kan installera WordPress på mange plattformer. Den grunnleggjande WordPress-programvara gjev gode høve for å driva ei sikker vevtenest, og det er skildra i dette dokumentet. Hugs at oppsettet av operativsystemet og vevtenaren som ligg under er like viktig som sjølve WordPress for å halda nettstaden sikker.

Litt om WordPress.com og tryggleik i WordPress

WordPress.com er den største WordPress-installasjonen i verda. Det er Automattic Inc. som driv nettstaden. Firmaet vart grunnlagt av Matt Mullenweg, som var med og starta WordPress. WordPress.com køyrer kjerneprogramvara i WordPress, og har i tillegg sine eigne tryggleiksprosessar, risikoar og løysingar22. Dette dokumentet handlar om WordPress-programvara du kan lasta ned og køyra sjølv på kvar ein vevtenar i verda.

Tillegg

Kjernegrensesnitt i WordPress

Dei viktigaste programmeringsgrensesnitta (Core Application Programming Interface, API) er laga av fleire ulike API23, der kvar av dei dekkjer funksjonane som er med i, og brukar, eit gjeve sett med funksjonar. Til saman lagar desse prosjektgrensesnittet som let innstikk og bunader samhandla med, endra og utvida kjernefunksjonane i WordPress på ein trygg måte.

Kvart API i WordPress gjev beste praksis og standardiserte måtar å kopla til og utvida kjerneprogramvara i WordPress, men desse APIa er dei viktigaste for å utøva og styrka tryggleiken i WordPress:

Database-APIet

Database-APIet24, som vart lagt til i WordPress 0.71, gjev rett metode for å få tilgang til data som namngjevne verdiar som er lagra i databaselaget.

Filsystem-APIet

Filsystem-APIetI25, som vart lagt til i WordPress 2.626, vart opphaveleg laga for den automatiske oppgraderinga i WordPress. Filsystem-APIet abstraherer ut funksjonane som trengst for å lesa og skriva lokale filer til filsystemet slik at det skjer trygt, og på ei rad vertstypar.

Dette skjer gjennom WP_Filesystem_Base-klassa og fleire underklasser som tek i bruk ulike måtar å kopla seg til det lokale filsystemet på, avhengig av versstøtte. Alle bunader eller innstikk som treng å skriva til filer lokalt, bør gjera det ved å bruka WP_Filesystem-klassefamilien.

HTTP-APIet

HTTP-APIet27, som vart lagt til i WordPress 2.728 og utvida i WordPress 2.8, standardiserer HTTP-spørjingar for Wordpess. API-et handterer infokapslar, gzip-koding og -dekoding, oppdelingsdekoding (viss HTTP 1.1) og annan bruk av HTTP-protokollen. API-et standardiserer spørjingar, testar kvar metode før sending, og brukar rett metode for å laga spørjinga, ut frå tenaroppsettet ditt.

Løyve og brukar-API

Løyva og brukar-APIet29 er eit sett med funksjonar som hjelper til med å stadfesta tilgangane til brukaren og retten til å gjera ei kvar oppgåve som blir spurt om, og kan verna mot at uautoriserte brukarar utfører noko som går ut over tilgangen deira.

Lisens for innhaldet i den tekniske dokumentasjonen

Teksten i dette dokumentet (utanom WordPress-logoen eller merkevara) er under CC0 1.0 Universal (CC0 1.0) Public Domain Dedication-lisensen. Du kan kopiera, endra, spreia og framføra verket, òg for kommersielle føremål, utan å spørja om løyve.

Særskilt takk tiltryggleiksdokumentet til Drupal, som gav inspirasjon.

Les meir

Skrive av Sara Rosso

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

Versjon 1.0 mars 2015

Fotnotar