Feiligens

Learje mear oer WordPress-kearnsoftwarefeiligens yn dit fergese wytboek. Jo kinne it ek downloade yn PDF-formaat .

Oersicht

Dit dokumint is in analyze en útlis fan 'e WordPress-kearnsoftwareûntwikkeling en har relatearre befeiligingsprosessen, lykas ek in ûndersiik fan' e ynherinte feiligens dy't direkt yn 'e software boud is. Beslútmakkers dy't WordPress evaluearje as in ynhâldbehearsysteem of webapplikaasjekader moatte dit dokumint brûke yn har analyze en beslútfoarming, en foar ûntwikkelders om dêr nei te ferwizen om har fertroud te meitsjen mei de feiligenskomponinten en bêste praktiken fan 'e software.

De ynformaasje yn dit dokumint is aktueel foar de lêste stabile release fan 'e software, WordPress 4.7 op' e tiid fan publikaasje, mar moat ek relevant wurde beskôge foar de meast resinte ferzjes fan 'e software, om't efterútkompatibiliteit in sterke fokus is foar de WordPress ûntwikkeling team. Spesifike befeiligingsmaatregels en feroarings sille wurde opmurken as se binne tafoege oan 'e kearnsoftware yn spesifike releases. It wurdt sterk oanmoedige om altyd de lêste stabile ferzje fan WordPress út te fieren om de feilichste mooglike ûnderfining te garandearjen.

Executive Summary

WordPress is in dynamysk iepen-boarne-ynhâldbehearsysteem dat wurdt brûkt om miljoenen websiden, webapplikaasjes en blogs te bemachtigjen. It jout op it stuit mear as 43% of de top 10 miljoen websiden op it ynternet. WordPress 'brûkberens, útwreidberens en folwoeksen ûntwikkelingsmienskip meitsje it in populêre en feilige kar foar websiden fan alle maten.

Sûnt syn oprjochting yn 2003 hat WordPress kontinu ferhurding ûndergien, sadat syn kearnsoftware mienskiplike feiligensbedrigingen kin oanpakke en mitigearje, ynklusyf de Top 10-list identifisearre troch The Open Web Application Security Project (OWASP) as mienskiplike feiligenskwetsberheden, dy't wurde besprutsen yn dit dokumint .

It WordPress Feiligens Team, yn gearwurking mei it WordPress Core Leadership Team en stipe troch de WordPress wrâldwide mienskip, wurket om feiligensproblemen te identifisearjen en op te lossen yn 'e kearnsoftware dy't beskikber is foar distribúsje en ynstallaasje by WordPress.org, en ek it bêste oanbefellen en dokumintearjen fan feiligens praktiken foar plugin- en tema-auteurs fan tredden.

Side-ûntwikkelders en behearders moatte spesjaal omtinken jaan oan it juste gebrûk fan kearn-API's en ûnderlizzende serverkonfiguraasje dy't de boarne west hawwe fan mienskiplike kwetsberens, en ek soargje dat alle brûkers sterke wachtwurden brûke om tagong te krijen ta WordPress.

In oersjoch fan WordPress

WordPress is in fergees en iepen boarne ynhâldbehearsysteem (CMS). It is de meast brûkte CMS-software yn 'e wrâld en it beheart mear dan 43% fan 'e top 10 miljoen websiden1, wêrtroch it in skatte 62% merkoandiel fan alle siden mei in CMS.

WordPress is lisinsearre ûnder de General Public License (GPLv2 of letter) dy't fjouwer kearnfrijheden leveret, en kin wurde beskôge as de WordPress "bill of rights":

  1. De frijheid om it programma út te fieren, foar elk doel.
  2. De frijheid om te studearjen hoe't it programma wurket, en it te feroarjen om it te meitsjen wat jo wolle.
  3. De frijheid om te fersprieden.
  4. De frijheid om kopyen fan jo oanpaste ferzjes te fersprieden oan oaren.

It WordPress Core Leadership Team

It WordPress-projekt is in meritokrasy, rinne troch in kearnliederskip, en laat troch har mei-skepper en leadûntwikkelder, Matt Mullenweg. It team bestjoert alle aspekten fan it projekt, ynklusyf kearnûntwikkeling, WordPress.org, en mienskipsinisjativen.

It Core Leadership Team bestiet út Matt Mullenweg, fiif leadûntwikkelders, en mear as in tsiental kearnûntwikkelders mei permaninte commit tagong. Dizze ûntwikkelders hawwe definitive autoriteit oer technyske besluten, en liede arsjitektuerdiskusjes en ymplemintaasjepogingen.

WordPress hat in oantal bydragende ûntwikkelders. Guon fan dizze binne eardere as hjoeddeistige committers, en guon binne wierskynlik takomstige committers. Dizze bydragende ûntwikkelders binne fertroude en veteranen bydragen oan WordPress dy't in protte respekt hawwe fertsjinne ûnder har leeftydsgenoaten. As it nedich is, hat WordPress ek gast-committers, persoanen dy't tagong krije ta commit, soms foar in spesifike komponint, op tydlike of proefbasis.

De kearn en bydragende ûntwikkelders liede primêr WordPress-ûntwikkeling. Elke ferzje drage hûnderten ûntwikkelders koade by oan WordPress. Dizze kearnbydragers binne frijwilligers dy't op ien of oare manier bydrage oan 'e kearnkoadebase.

De WordPress Release Cycle

Elke WordPress-release-syklus wurdt laat troch ien of mear fan 'e kearn WordPress-ûntwikkelders. In release-syklus duorret normaal sawat 4 moannen fanôf de earste scoping-gearkomste oant de lansearring fan 'e ferzje.

In frijlittingssyklus folget it folgjende patroan2:

  • Fase 1: Planning en befeiliging fan teamlieders. Dit wurdt dien yn 'e #core chatroom op Slack. De release lead besprekt funksjes foar de folgjende release fan WordPress. WordPress-meiwurkers wurde belutsen by dy diskusje. De release lead sil team leads identifisearje foar elk fan 'e funksjes.
  • Fase 2: Untwikkelingswurk begjint. Teamlieders sammelje teams en wurkje oan har tawiisde funksjes. Regelmjittige petearen wurde pland om te soargjen dat de ûntwikkeling foarút bliuwt.
  • Fase 3: Beta. Betas wurde frijlitten, en beta-testers wurde frege om te begjinnen mei it rapportearjen fan bugs. Gjin commits mear foar nije ferbetterings of funksje-oanfragen wurde fan dizze faze ôf útfierd. Plugin- en tema-auteurs fan tredden wurde stimulearre om har koade te testen tsjin de kommende feroarings.
  • Fase 4: Release Candidate. D'r is fan dit punt ôf in tekenrige befriezing foar oersetbere snaren. Wurk is allinich rjochte op regressions en blockers.
  • Fase 5: Start. WordPress ferzje wurdt lansearre en beskikber steld yn de WordPress Admin foar updates.

Ferzjenûmering en befeiligingsútjeften

In wichtige WordPress-ferzje wurdt diktearre troch de earste twa sekwinsjes. Bygelyks, 3.5 is in grutte release, lykas 3.6, 3.7, of 4.0. D'r is gjin "WordPress 3" of "WordPress 4" en elke grutte release wurdt ferwiisd troch syn nûmering, bygelyks "WordPress 3.9."

Grutte releases kinne nije brûkersfunksjes en API's foar ûntwikkelders tafoegje. Hoewol typysk yn 'e softwarewrâld, in "grutte" ferzje betsjut dat jo efterútkompatibiliteit kinne brekke, stribbet WordPress dernei om nea efterútkompatibiliteit te brekken. Efterút kompatibiliteit is ien fan 'e wichtichste filosofyen fan it projekt, mei it doel om updates folle makliker te meitsjen foar brûkers en ûntwikkelders.

In lytse WordPress ferzje wurdt diktearre troch de tredde folchoarder. Ferzje 3.5.1 is in lytse útjefte, lykas 3.4.23. In lytse release is reservearre foar it reparearjen fan kwetsberens foar feiligens en it oanpakken fan krityske bugs allinich. Sûnt nije ferzjes fan WordPress wurde sa faak frijlitten - it doel is elke 4-5 moannen foar in grutte release, en lytse releases barre as nedich - is d'r allinich ferlet fan grutte en lytse releases.

Ferzje Backwards Compatibility

It WordPress-projekt hat in sterke ynset foar efterkompatibiliteit. Dizze ynset betsjuttet dat tema's, plugins en oanpaste koade trochgean te funksjonearjen as WordPress-kearnsoftware wurdt bywurke, en stimulearje side-eigners om har WordPress-ferzje bywurke te hâlden nei de lêste feilige release.

WordPress en Feiligens

It WordPress Security Team

It WordPress Feiligens Team bestiet út sawat 50 saakkundigen ynklusyf leadûntwikkelders en feiligensûndersikers - sawat de helte is meiwurkers fan Automattic (makkers fan WordPress.com, it ierste en grutste WordPress-hostingplatfoarm op it web), en in oantal wurken yn it webfeiligensfjild. It team konsultearret mei bekende en fertroude feiligensûndersikers en hostingbedriuwen3.

It WordPress Feiligensteam wurket faak gear mei oare feiligensteams om problemen yn mienskiplike ôfhinklikens oan te pakken, lykas it oplossen fan de kwetsberens yn 'e PHP XML-parser, brûkt troch de XML-RPC API dy't ferstjoerd wurdt mei WordPress, yn WordPress 3.9.24. Dizze oplossing foar kwetsberens wie in gefolch fan in mienskiplike ynspanning fan sawol WordPress as Drupal feiligensteams.

WordPress Feiligensrisiko's, proses en histoarje

It WordPress Feiligensteam leaut yn Ferantwurde iepenbiering troch it befeiligingsteam fuortendaliks te warskôgjen fan mooglike kwetsberens. Potinsjele kwetsberens foar feiligens kinne wurde sinjalearre oan it Feiligensteam fia de WordPress HackerOne 5. It Feiligensteam kommunisearret ûnderinoar fia in privee Slack-kanaal, en wurket oan in ommuorre, privee Trac foar it folgjen, testen en reparearjen fan bugs en feiligensproblemen.

Elk befeiligingsrapport wurdt erkend by ûntfangst, en it team wurket om de kwetsberens te ferifiearjen en de earnst te bepalen. As befêstige, plannen it befeiligingsteam dan foar in patch om it probleem op te lossen dat kin wurde ynset foar in kommende release fan 'e WordPress-software of it kin wurde skood as in direkte befeiligingsútjefte, ôfhinklik fan' e earnst fan it probleem.

Foar in direkte befeiligingsútjefte wurdt in advys publisearre troch it Feiligensteam oan de WordPress.org Nijsside6 dy't de frijlitting oankundiget en de wizigingen yn detail beskriuwt. Kredyt foar it ferantwurde iepenbierjen fan in kwetsberens wurdt jûn yn it advys om trochgeande ferantwurde rapportaazje yn 'e takomst te stimulearjen en te fersterkjen.

Behearders fan 'e WordPress-software sjogge in notifikaasje op har side-dashboard om te upgrade as in nije release beskikber is, en nei de hânmjittich upgrade wurde brûkers omlaat nei it Oer WordPress-skerm dat de wizigingen yn detaillearret. As behearders automatyske eftergrûnfernijings ynskeakele hawwe, krije se in e-post neidat in upgrade is foltôge.

Automatyske eftergrûnfernijings foar befeiligingsútjeften

Begjinnend mei ferzje 3.7 yntrodusearre WordPress automatyske eftergrûnfernijings foar alle lytse releases7, lykas 3.7.1 en 3.7.2. It WordPress Security Team kin automatyske befeiligingsferbetterings foar WordPress identifisearje, reparearje en útdrukke sûnder dat de side-eigner wat oan har ein hoecht te dwaan, en de befeiligingsupdate sil automatysk ynstallearje.

As in befeiligingsupdate wurdt drukke foar de hjoeddeistige stabile release fan WordPress, sil it kearnteam ek befeiligingsupdates drukke foar alle releases dy't by steat binne om eftergrûnfernijings (sûnt WordPress 3.7), sadat dizze âldere, mar noch resinte ferzjes fan WordPress befeiliging krije ferbetterings.

Yndividuele side-eigners kinne der foar kieze om automatyske eftergrûnfernijings te ferwiderjen troch in ienfâldige feroaring yn har konfiguraasjetriem, mar it behâld fan de funksjonaliteit wurdt sterk oanrikkemandearre troch it kearnteam, lykas ek de lêste stabile release fan WordPress útfiere.

2013 OWASP Top 10

It Open Web Application Security Project (OWASP) is in online mienskip wijd oan befeiliging fan webapplikaasjes. De OWASP Top 10-list8 rjochtet him op it identifisearjen fan de meast serieuze applikaasjefeiligensrisiko's foar in breed skala oan organisaasjes. De Top 10-items wurde selektearre en prioritearre yn kombinaasje mei konsensusskattingen fan eksploitberens, detectabiliteit en rûzings fan ynfloed.

De folgjende seksjes besprekke de API's, boarnen en belied dat WordPress brûkt om de kearnsoftware en plugins en tema's fan tredden te fersterkjen tsjin dizze potensjele risiko's.

A1 - Ynjeksje

D'r is in set fan funksjes en API's beskikber yn WordPress om ûntwikkelders te helpen om te soargjen dat net autorisearre koade kin wurde ynjeksje, en har helpe om gegevens te falidearjen en te sanearjen. Best practices en dokumintaasje binne beskikber9 oer hoe't jo dizze API's brûke om ynfier- en útfiergegevens te beskermjen, te falidearjen of te sanearjen yn HTML, URL's, HTTP-headers, en by ynteraksje mei de databank en it bestânsysteem. Behearders kinne ek de triemtypen dy't fia filters uploade wurde fierder beheine.

A2 - Broken autentikaasje en sesjebehear

WordPress-kearnsoftware beheart brûkersakkounts en autentikaasje en details lykas de brûkersnamme, namme en wachtwurd wurde beheard op 'e serverkant, lykas ek de autentikaasjekoekjes. Wachtwurden wurde beskerme yn 'e databank mei standert sâlt- en stretchtechniken. Besteande sesjes wurde ferneatige by it ôfmelden foar ferzjes fan WordPress nei 4.0.

A3 - Cross Site Scripting (XSS)

WordPress leveret in ferskaat oan funksjes dy't kinne helpe te garandearjen dat troch brûkers levere gegevens feilich binne10. Fertroude brûkers, dat is behearders en redakteuren op ien WordPress-ynstallaasje, en netwurkbehearders allinich yn WordPress Multisite, kinne unfiltered HTML of JavaScript pleatse as se nedich binne, lykas binnen in post of side. Net-fertroude brûkers en troch brûkers yntsjinne ynhâld wurdt standert filtere om gefaarlike entiteiten te ferwiderjen, mei de KSES-bibleteek fia de funksje wp_kses.

As foarbyld hat it WordPress-kearnteam foar de frijlitting fan WordPress 2.3 opmurken dat de funksje the_search_query() misbrûkt waard troch de measte tema-auteurs, dy't de útfier fan 'e funksje net ûntkamen foar gebrûk yn HTML. Yn in heul seldsum gefal fan in bytsje brekkende efterkompatibiliteit, waard de útfier fan 'e funksje feroare yn WordPress 2.3 om foarôf te ûntkommen.

A4 - Unfeilige Direct Object Reference

WordPress leveret faak direkte objektreferinsje, lykas unike numerike identifiers fan brûkersakkounts of ynhâld beskikber yn 'e URL of formulierfjilden. Wylst dizze identifiers direkte systeemynformaasje iepenbierje, foarkomme WordPress 'rike tagongsrjochten en tagongskontrôlesysteem unautorisearre oanfragen.

A5 - Feiligens miskonfiguraasje

De mearderheid fan 'e WordPress-befeiligingskonfiguraasje operaasjes binne beheind ta ien autorisearre behearder. Standertynstellingen foar WordPress wurde kontinu evaluearre op it kearnteamnivo, en it WordPress-kearnteam leveret dokumintaasje en bêste praktiken om de feiligens foar tsjinnerkonfiguraasje foar it útfieren fan in WordPress-side te fersterkjen11.

A6 - Sensitive Data Exposure

Wachtwurden foar WordPress-brûkersaccounts wurde sâlt en hashed basearre op it Portable PHP Password Hashing Framework12. It tastimmingsysteem fan WordPress wurdt brûkt om tagong ta privee ynformaasje te kontrolearjen, lykas PII fan registrearre brûkers, e-mailadressen fan kommentators, privee publisearre ynhâld, ensfh Yn WordPress 3.7 waard in wachtwurdsterktemeter opnommen yn 'e kearnsoftware dy't ekstra ynformaasje leveret oan brûkersynstelling harren wachtwurden en hints op tanimmende sterkte. WordPress hat ek in opsjonele konfiguraasjeynstelling foar it fereaskje HTTPS.

A7 - Missing Funksje Level Access Control

WordPress kontrolearret op juste autorisaasje en tagongsrjochten foar alle tagongsfersiken foar funksjenivo foardat de aksje wurdt útfierd. Tagong of fisualisaasje fan bestjoerlike URL's, menu's en siden sûnder goede autentikaasje is strak yntegrearre mei it autentikaasjesysteem om tagong te foarkommen fan net autorisearre brûkers.

A8 - Cross Site Request Forgery (CSRF)

WordPress brûkt kryptografyske tokens, neamd nonces13, om fersiken fan yntinsje fan aksje te validearjen fan autorisearre brûkers om te beskermjen tsjin potinsjele CSRF-bedrigingen. WordPress leveret in API foar it generearjen fan dizze tokens om unike en tydlike tokens te meitsjen en te ferifiearjen, en it token is beheind ta in spesifike brûker, in spesifike aksje, in spesifyk objekt, en in spesifike tiidperioade, dy't kin wurde tafoege oan formulieren en URL's as nedich. Derneist wurde alle nonces ûnjildich makke by it ôfmelden.

A9 - Gebrûk fan komponinten mei bekende kwetsberens

It WordPress-kearnteam kontrolearret de pear opnommen bibleteken en ramten mei WordPress yntegreart foar kearnfunksjonaliteit nau. Yn it ferline hat it kearnteam bydragen levere oan ferskate komponinten fan tredden om se feiliger te meitsjen, lykas de fernijing om in cross-site kwetsberens te reparearjen yn TinyMCE yn WordPress 3.5.214.

As it nedich is, kin it kearnteam beslute om krityske eksterne komponinten te forken of te ferfangen, lykas doe't de SWFUpload-bibleteek offisjeel ferfongen waard troch de Plupload-bibleteek yn 3.5.2, en in feilige foarke fan SWFUpload beskikber steld waard troch it befeiligingsteam<15 foar dy ynstekkers dy't trochgean mei it brûken fan SWFUpload op koarte termyn.

A10 - Net falidearre trochferwizings en trochstjoeren

WordPress 'ynterne tagongskontrôle en autentikaasjesysteem sil beskermje tsjin besykjen om brûkers te rjochtsjen nei net winske bestimmingen of automatyske trochferwizings. Dizze funksjonaliteit wurdt ek beskikber steld foar plugin-ûntwikkelders fia in API, wp_safe_redirect() 16.

Fierdere feiligensrisiko's en soargen

XXE (XML eXternal Entity) ferwurkjen oanfallen

By it ferwurkjen fan XML, skeakelet WordPress it laden fan oanpaste XML-entiteiten út om oanfallen fan sawol eksterne entiteit as entiteitsútwreiding te foarkommen. Beyond de kearnfunksjonaliteit fan PHP, leveret WordPress gjin ekstra feilige XML-ferwurkings-API foar plugin-auteurs.

SSRF (Server Side Request Forgery) oanfallen

HTTP-oanfragen útjûn troch WordPress wurde filtere om tagong te foarkommen ta loopback en privee IP-adressen. Derneist is tagong allinich tastien foar bepaalde standert HTTP-poarten.

WordPress-plugin en temafeiligens

It standerttema

WordPress fereasket dat in tema ynskeakele is om ynhâld sichtber te meitsjen op 'e frontend. It standerttema dat ferstjoerd wurdt mei kearn WordPress (op it stuit "Twenty Twenty-Four") is om feiligensredenen krêftich hifke en hifke troch sawol it team fan tema-ûntwikkelders plus it kearnûntwikkelingsteam.

It standerttema kin as útgongspunt tsjinje foar ûntwikkeling fan oanpaste tema's, en side-ûntwikkelders kinne in bernetema oanmeitsje dat wat oanpassing omfettet, mar falt werom op it standerttema foar de measte funksjonaliteit en feiligens. It standerttema kin maklik wurde fuortsmiten troch in behearder as net nedich.

WordPress.org Tema en Plugin Repositories

D'r binne sawat 50. 000+ plugins en 5. 000+ tema's fermeld op de WordPress.org-side. Dizze tema's en plugins wurde yntsjinne foar opname en wurde mei de hân hifke troch frijwilligers foardat se beskikber steld wurde op it repository.

Opnimmen fan plugins en tema's yn 'e repository is gjin garânsje dat se frij binne fan feiligens kwetsberens. Rjochtlinen wurde levere foar plugin-auteurs om te rieplachtsjen foarôfgeand oan yntsjinjen foar opname yn 'e repository17, en wiidweidige dokumintaasje oer hoe't jo WordPress-tema-ûntwikkeling kinne dwaan18 wurdt levere op 'e WordPress.org-side.

Elke plugin en tema hat de mooglikheid om kontinu te ûntwikkeljen troch de plugin of tema-eigner, en alle folgjende fixes of funksje-ûntwikkeling kinne wurde upload nei it repository en beskikber steld foar brûkers mei dat plugin of tema ynstalleare mei in beskriuwing fan dy feroaring. Sitebehearders wurde op 'e hichte brocht fan plugins dy't moatte wurde bywurke fia har administraasjedashboard.

As in plugin-kwetsberens wurdt ûntdutsen troch it WordPress Security Team, kontakt opnimme se mei de plugin-auteur en wurkje gear om in feilige ferzje fan it plugin te reparearjen en frij te litten. As d'r in gebrek oan antwurd is fan 'e plugin-auteur of as de kwetsberens slim is, wurdt de plugin/tema út 'e publike map helle, en yn guon gefallen direkt fêststeld en bywurke troch it Feiligensteam.

The Tema Review Team

It Theme Review Team is in groep frijwilligers, ûnder lieding fan wichtige en fêstige leden fan 'e WordPress-mienskip, dy't tema's beoardielje en goedkarre dy't yntsjinne wurde om opnommen te wurden yn 'e offisjele WordPress Theme-map. It Theme Review Team ûnderhâldt de offisjele Theme Review Guidelines19, de Theme Unit Test Datas20, en de Theme Check Plugins21, en besiket de WordPress Theme-ûntwikkeldersmienskip te belûken en te ûnderwizen oangeande best practices foar ûntwikkeling. Ynklusyf yn 'e groep wurdt moderearre troch kearncommitters fan it WordPress-ûntwikkelteam.

De rol fan 'e hostingprovider yn WordPress Feiligens

WordPress kin ynstalleare wurde op in mannichte fan platfoarms. Hoewol WordPress-kearnsoftware in protte foarsjenningen leveret foar it betsjinjen fan in feilige webapplikaasje, dy't yn dit dokumint waarden behannele, is de konfiguraasje fan it bestjoeringssysteem en de ûnderlizzende webserver dy't de software host like wichtich om de WordPress-applikaasjes feilich te hâlden.

In opmerking oer WordPress.com en WordPress feiligens

WordPress.com is de grutste WordPress-ynstallaasje yn 'e wrâld, en is eigendom en beheard troch Automattic, Inc., dat waard oprjochte troch Matt Mullenweg, de mei-skepper fan WordPress-projekt. WordPress.com rint op 'e kearn WordPress-software, en hat syn eigen feiligensprosessen, risiko's en oplossings22. Dit dokumint ferwiist nei feiligens oangeande de sels-hosted, ynlaadbere iepen boarne WordPress-software beskikber fan WordPress.org en ynstalleare op elke server yn 'e wrâld.

Taheakke

Core WordPress API's

De WordPress Core Application Programming Interface (API) bestiet út ferskate yndividuele API's23, elk beslacht de funksjes belutsen by, en it brûken fan, in opjûne set fan funksjonaliteit. Mei-inoar foarmje dizze de projektynterface wêrmei plugins en tema's kinne ynteraksje mei, feroarje en útwreidzje WordPress kearnfunksjonaliteit feilich en feilich.

Wylst elke WordPress API bêste praktiken en standerdisearre manieren leveret om te ynteraksje mei en útwreidzje WordPress-kearnsoftware, binne de folgjende WordPress API's it meast relevant foar it hanthavenjen en ferhurdzjen fan WordPress-feiligens:

Databank API

De Database API24, tafoege yn WordPress 0.71, leveret de juste metoade foar tagong ta gegevens as neamde wearden dy't wurde opslein yn 'e databanklaach.

Filesystem API

De Filesystem API25, tafoege yn WordPress 2.626, waard oarspronklik makke foar de eigen automatyske updatefunksje fan WordPress. De Filesystem API abstrahearret de funksjonaliteit dy't nedich is foar it lêzen en skriuwen fan lokale bestannen nei it bestânsysteem om feilich te dwaan, op in ferskaat oan hosttypen.

It docht dit troch de WP_Filesystem_Base -klasse, en ferskate subklassen dy't ferskate manieren ymplementearje om te ferbinen mei it lokale bestânsysteem, ôfhinklik fan yndividuele hoststipe. Elk tema of plugin dat bestannen lokaal skriuwe moat, moat dat dwaan mei de WP_Filesystem-famylje fan klassen.

HTTP API

De HTTP API27, tafoege yn WordPress 2.728 en fierder útwreide yn WordPress 2.8, standardisearret de HTTP-oanfragen foar WordPress. De API behannelet cookies, gzip-kodearring en dekodearring, chunk-dekodearring (as HTTP 1.1), en ferskate oare HTTP-protokol-ymplementaasjes. De API standardisearret oanfragen, testet elke metoade foar it ferstjoeren, en, basearre op jo serverkonfiguraasje, brûkt de passende metoade om it fersyk te meitsjen.

Tastimmingen en aktuele brûkers API

De tagongsrjochten en aktuele brûkers-API29 is in set funksjes dy't sille helpe om de tagongsrjochten en autoriteit fan 'e aktuele brûker te ferifiearjen om elke oanfrege taak of operaasje út te fieren, en kinne fierder beskermje tsjin ûnautorisearre brûkers dy't tagong krije ta of funksjes útfiere dy't bûten har tastiene mooglikheden binne.

Wite papier ynhâld Lisinsje

De tekst yn dit dokumint (net ynklusyf it WordPress-logo of hannelsmerk ) is lisinsje ûnder CC0 1.0 Universal (CC0 1.0) Public Domain Dedication . Jo kinne it wurk kopiearje, wizigje, fersprieden en útfiere, sels foar kommersjele doelen, allegear sûnder tastimming te freegjen.

In spesjale tank oan Drupal's befeiligingswyt papier , dat wat ynspiraasje levere.

Oanfoljende lêzing

Skreaun troch Sara Rosso

Bydragen fan Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí, Dion Hulse, Mo Jangda, Paul Maiorana

Ferzje 1.0 March 2015

Fuotnoaten