Tryggleik

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

Oversikt

This document is an analysis and explanation of the WordPress core software development and its related security processes, as well as an examination of the inherent security built directly into the software. Decision makers evaluating WordPress as a content management system or web application framework should use this document in their analysis and decision-making, and for developers to refer to it to familiarize themselves with the security components and best practices of the software.

The information in this document is up-to-date for the latest stable release of the software, WordPress 4.7 at time of publication, but should be considered relevant also to the most recent versions of the software as backwards compatibility is a strong focus for the WordPress development team. Specific security measures and changes will be noted as they have been added to the core software in specific releases. It is strongly encouraged to always be running the latest stable version of WordPress to ensure the most secure experience possible.

Executive Summary

WordPress is a dynamic open-source content management system which is used to power millions of websites, web applications, and blogs. It currently powers more than 32% of the top 10 million websites on the Internet. WordPress’ usability, extensibility, and mature development community make it a popular and secure choice for websites of all sizes.

Since its inception in 2003, WordPress has undergone continual hardening so its core software can address and mitigate common security threats, including the Top 10 list identified by The Open Web Application Security Project (OWASP) as common security vulnerabilities, which are discussed in this document.

The WordPress Security Team, in collaboration with the WordPress Core Leadership Team and backed by the WordPress global community, works to identify and resolve security issues in the core software available for distribution and installation at WordPress.org, as well as recommending and documenting security best practices for third-party plugin and theme authors.

Site developers and administrators should pay particular attention to the correct use of core APIs and underlying server configuration which have been the source of common vulnerabilities, as well as ensuring all users employ strong passwords to access 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 32% av dei største 10 millionar nettstadene1. Det gjev om lag 60% 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.

The WordPress Core Leadership Team

The WordPress project is a meritocracy, run by a core leadership team, and led by its co-creator and lead developer, Matt Mullenweg. The team governs all aspects of the project, including core development, WordPress.org, and community initiatives.

The Core Leadership Team consists of Matt Mullenweg, five lead developers, and more than a dozen core developers with permanent commit access. These developers have final authority on technical decisions, and lead architecture discussions and implementation efforts.

WordPress has a number of contributing developers. Some of these are former or current committers, and some are likely future committers. These contributing developers are trusted and veteran contributors to WordPress who have earned a great deal of respect among their peers. As needed, WordPress also has guest committers, individuals who are granted commit access, sometimes for a specific component, on a temporary or trial basis.

The core and contributing developers primarily guide WordPress development. Every version, hundreds of developers contribute code to WordPress. These core contributors are volunteers who contribute to the core codebase in some way.

The WordPress Release Cycle

Each WordPress release cycle is led by one or more of the core WordPress developers. A release cycle usually lasts around 4 months from the initial scoping meeting to launch of the version.

A release cycle follows the following pattern2:

  • Phase 1: Planning and securing team leads. This is done in the #core chat room on Slack. The release lead discusses features for the next release of WordPress. WordPress contributors get involved with that discussion. The release lead will identify team leads for each of the features.
  • Phase 2: Development work begins. Team leads assemble teams and work on their assigned features. Regular chats are scheduled to ensure the development keeps moving forward.
  • Phase 3: Beta. Betas are released, and beta-testers are asked to start reporting bugs. No more commits for new enhancements or feature requests are carried out from this phase on. Third-party plugin and theme authors are encouraged to test their code against the upcoming changes.
  • Phase 4: Release Candidate. There is a string freeze for translatable strings from this point on. Work is targeted on regressions and blockers only.
  • Phase 5: Launch. WordPress version is launched and made available in the WordPress Admin for updates.

Version Numbering and Security Releases

A major WordPress version is dictated by the first two sequences. For example, 3.5 is a major release, as is 3.6, 3.7, or 4.0. There isn’t a “WordPress 3” or “WordPress 4” and each major release is referred to by its numbering, e.g., “WordPress 3.9.”

Major releases may add new user features and developer APIs. Though typically in the software world, a “major” version means you can break backwards compatibility, WordPress strives to never break backwards compatibility. Backwards compatibility is one of the project’s most important philosophies, with the aim of making updates much easier on users and developers alike.

A minor WordPress version is dictated by the third sequence. Version 3.5.1 is a minor release, as is 3.4.23. A minor release is reserved for fixing security vulnerabilities and addressing critical bugs only. Since new versions of WordPress are released so frequently — the aim is every 4-5 months for a major release, and minor releases happen as needed — there is only a need for major and minor releases.

Version Backwards Compatibility

The WordPress project has a strong commitment to backwards compatibility. This commitment means that themes, plugins, and custom code continues to function when WordPress core software is updated, encouraging site owners to keep their WordPress version updated to the latest secure release.

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

The WordPress Security Team believes in Responsible Disclosure by alerting the security team immediately of any potential vulnerabilities. Potential security vulnerabilities can be signaled to the Security Team via the WordPress HackerOne5. The Security Team communicates amongst itself via a private Slack channel, and works on a walled-off, private Trac for tracking, testing, and fixing bugs and security problems.

Each security report is acknowledged upon receipt, and the team works to verify the vulnerability and determine its severity. If confirmed, the security team then plans for a patch to fix the problem which can be committed to an upcoming release of the WordPress software or it can be pushed as an immediate security release, depending on the severity of the issue.

For an immediate security release, an advisory is published by the Security Team to the WordPress.org News site6 announcing the release and detailing the changes. Credit for the responsible disclosure of a vulnerability is given in the advisory to encourage and reinforce continued responsible reporting in the future.

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 "core/twentynineteen") 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