WordPress-roller og rettigheter: add_role, add_cap og sikkerhet

WordPress har en komplett tilgangskontrolliste innebygd, og nesten ingen bruker den. Rettighetsfeilen vi oftest ser på kundenettsteder er ikke et upatchet programtillegg, men en innholdsskribent med Administrator-rollen fordi noen en gang trengte at hen omorganiserte en meny. Denne guiden går gjennom hva API-et for roller og rettigheter faktisk gjør på kildekodenivå: hvor dataene ligger, hvorfor add_role() stille ignorerer det andre kallet ditt, hva en sjekk på rollenavn egentlig løses til, og hvilke rettigheter som er bredere enn navnet antyder.

Les mer om sikkerhetsrevisjon av WordPress hos WPPoland.

Én enkelt endring gjør nesten hele jobben: slutt å nevne roller i betingelsene dine, og nevn rettigheten koden trenger. Resten av guiden handler om hva det koster i praksis, og det er grunnlaget for arbeidet til enhver WordPress-utvikler som tar sikkerhet på alvor.

#1. Forskjellen på rolle og rettighet i WordPress

Rettighetssystemet i WordPress bygger på to begreper som bør holdes fra hverandre før du skriver noen logikk for tilgangskontroll.

#Rettighet (capability, cap)

En spesifikk tillatelse til å gjøre én ting. Rettigheter er de atomære enhetene i systemet. Eksempler: edit_posts, publish_pages, install_plugins, manage_options og edit_theme_options.

Rettigheter kan være primitive (lagret direkte i rolleraden) eller metarettigheter (løst under kjøring av map_meta_cap() ut fra konteksten). For eksempel er edit_post en metarettighet som løses til edit_posts eller edit_others_posts, avhengig av om brukeren er forfatteren av innlegget.

#Rolle

En samling rettigheter gruppert under et navn. WordPress lagrer settet og evaluerer strengen.

Standardsettene er mindre enn mange tror. Ifølge dokumentasjonen for roller og rettigheter har Redaktør 26 rettigheter og Forfatter sju: read, upload_files, edit_posts, edit_published_posts, publish_posts, delete_posts, delete_published_posts. Bidragsyter har tre: read, edit_posts, delete_posts. En Bidragsyter kan ikke laste opp en fil, og derfor ender “bare gjør hen til Bidragsyter” i en sak om mediebiblioteket.

Redaktør er det interessante tilfellet. På en enkeltinstallasjon har rollen unfiltered_html, altså kan en Redaktør lagre en <script>-tagg i innholdet. I multisite nektes denne rettigheten alle unntatt superadministratorer, slik map_meta_cap() viser:

if ( defined( 'DISALLOW_UNFILTERED_HTML' ) && DISALLOW_UNFILTERED_HTML ) {
    $caps[] = 'do_not_allow';
} elseif ( is_multisite() && ! is_super_admin( $user_id ) ) {
    $caps[] = 'do_not_allow';
} else {
    $caps[] = 'unfiltered_html';
}

Dette har ikke Redaktør: edit_theme_options, list_users, edit_users, manage_options eller noe som har med programtillegg å gjøre.

#Sjekk rettigheter i stedet for roller

Sjekk rettigheter, aldri rollenavn.

// FEIL - gjør aldri dette
if ( current_user_can( 'administrator' ) ) { ... }

// RIKTIG - sjekk alltid rettigheter
if ( current_user_can( 'manage_options' ) ) { ... }

Den første linjen er ikke en syntaksfeil, den er noe verre: den gir riktig svar nettopp i tilfellet du testet. Årsaken er en sammenslåing helt til slutt i WP_User::get_role_caps():

$this->allcaps = array();
foreach ( (array) $this->roles as $role ) {
    $the_role      = $wp_roles->get_role( $role );
    $this->allcaps = array_merge( (array) $this->allcaps, (array) $the_role->capabilities );
}
$this->allcaps = array_merge( (array) $this->allcaps, (array) $this->caps );

$this->caps er det rå brukermetafeltet wp_capabilities, og nøklene der er rollenavn. Derfor havner administrator => true i allcaps side om side med ekte rettigheter og består sjekken ved et uhell. Dokumentasjonen for current_user_can() sier det slik: å sjekke bestemte roller i stedet for en rettighet støttes bare delvis og frarådes, fordi det kan gi upålitelige resultater.

Tre måter dette biter på, alle tre sett på ekte nettsteder:

1. Du lager en egendefinert rolle med manage_options slik at en kunde kommer inn på innstillingssiden din. current_user_can('administrator') er false for hen, og din egen side returnerer 403 til brukeren den ble laget for.
2. En rettighet gitt direkte på brukerobjektet, uten tilknyttet rolle, består enhver rettighetssjekk og stryker på enhver rollesjekk.
3. I multisite kortslutter WP_User::has_cap() for superadministratorer før allcaps blir sett på, og returnerer true for alt som ikke er do_not_allow. Der skiller en rollesjekk ikke ut noe som helst.

#2. Hvordan lage en egendefinert rolle i WordPress

Før du skriver en, sjekk om plattformen allerede har den. WooCommerce legger til shop_manager og customer ved installasjon, og ifølge rolledokumentasjonen deres kan Butikkleder allerede administrere produkter, ordrer, kuponger og kundekontoer. Å bygge en parallell “butikkleder” dupliserer en rolle som vedlikeholdes i et annet prosjekts utgivelsessyklus.

Når du virkelig trenger en, ser det slik ut:

add_role(
    'editorial_lead',
    'Redaksjonsansvarlig',
    [
        'read'                 => true,
        'upload_files'         => true,
        'edit_posts'           => true,
        'edit_others_posts'    => true,
        'edit_published_posts' => true,
        'publish_posts'        => true,
        'delete_posts'         => true,
        'moderate_comments'    => true,
    ]
);

To ting ved dette kallet går ikke fram av signaturen.

Den skriver én gang og ignorerer deg deretter. Plugin-håndboken sier at etter første kall er rollen og rettighetene lagret i databasen, og at påfølgende kall ikke gjør noe, heller ikke å endre rettighetslisten. Du redigerer arrayet, deployer, og ingenting endres. Hver endring av rettigheter trenger derfor en eksplisitt migrering:

const EDITORIAL_LEAD_VERSION = 3;

function wppoland_sync_editorial_lead() {
    if ( (int) get_option( 'wppoland_editorial_lead_version' ) === EDITORIAL_LEAD_VERSION ) {
        return;
    }

    remove_role( 'editorial_lead' );
    add_role( 'editorial_lead', 'Redaksjonsansvarlig', [ /* ... */ ] );

    update_option( 'wppoland_editorial_lead_version', EDITORIAL_LEAD_VERSION );
}
register_activation_hook( __FILE__, 'wppoland_sync_editorial_lead' );
add_action( 'admin_init', 'wppoland_sync_editorial_lead' );

Kopien på admin_init betyr noe i multisite og i deployer som aldri utløser en aktiveringskrok. Versjonssjekken er det som holder koden unna den varme stien, og håndboken advarer om at det å fjerne og opprette rollen på nytt uten betingelse svekker ytelsen betraktelig.

remove_role() rører ikke brukerne. Den fjerner nøkkelen fra opsjonsraden. Hver bruker der metafeltet wp_capabilities fortsatt sier editorial_lead => true, beholder den nøkkelen, WP_Roles::is_role() returnerer nå false for den, og den løses dermed aldri til rettigheter. Brukeren sitter igjen med en streng som ikke gir noe. Tildel brukerne på nytt før du fjerner en rolle, eller umiddelbart etterpå.

Hvor raden faktisk ligger. WP_Roles::for_site() bygger nøkkelen som $wpdb->get_blog_prefix( $this->site_id ) . 'user_roles'. På et enkeltnettsted med standardprefikset blir det wp_user_roles. På underside 3 i et nettverk blir det wp_3_user_roles, og derfor er en rolle lagt til på én underside usynlig på den neste. Vil du ha rollene definert i kode og aldri skrevet til databasen, definer den globale $wp_user_roles i wp-config.php: WordPress bruker den da, og ifølge kjernereferansen blir rolleopsjonen verken oppdatert eller brukt.

#Rolleetiketter på flerspråklige nettsteder

Det andre argumentet til add_role() er den synlige etiketten, og WP_Roles::add_role() lagrer den i opsjonsraden akkurat slik den kommer inn. Pakker du den inn i __(), blir det lagret strengen på det språket som var aktivt ved aktiveringen, ikke på språket til den som senere åpner brukerskjermen. Ved visning sender wp_dropdown_roles() etiketten gjennom translate_user_role(), som oversetter med konteksten User role og tekstdomenet default. Det dekker kjernerollene, der strengene ligger i WordPress-katalogen, og dekker ikke etiketten til programtillegget ditt. På et flerspråklig nettsted lagrer du slug og etikett på engelsk, og du bygger ikke logikk på etiketten: slugen er den stabile identifikatoren.

#3. Hvordan legge til rettigheter i en eksisterende rolle

get_role() pluss add_cap() er den minste endringen når en standardrolle nesten passer:

$role = get_role( 'editor' );
if ( $role ) {
    $role->add_cap( 'edit_theme_options' );
}

Bruk den samme versjonssjekken som i seksjon 2. WP_Role::add_cap() tar nøyaktig to parametere, add_cap( $cap, $grant = true ), og den andre avgjør om rettigheten gis eller eksplisitt nektes, ikke om raden skrives. Det finnes ingen tredje parameter her. Formen med tre argumenter hører til WP_Roles::add_cap( $role, $cap, $grant ), en annen klasse, og det er metoden WP_Role::add_cap() delegerer til. Den metoden tildeler rettigheten og kaller update_option() hver gang use_db er true, ved hvert kall. Ingen argumenter undertrykker skrivingen, så å kjøre add_cap() på init uten vakt betyr et forsøk på å skrive opsjonen ved hver forespørsel.

#Rekkevidden til edit_theme_options i blokktemaer

Det større problemet med akkurat den linjen er rekkevidden. edit_theme_options er den klassiske løsningen for “la Redaktør styre menyene”, og i et klassisk tema gjør den omtrent det: Utseende for widgets, menyer, tilpasning og topptekst. I et blokktema er det en annen rettighet. Kjernedokumentasjonen omtaler den nå som hovedrettigheten WordPress sjekker når det avgjøres om en bruker kan åpne og administrere maler fra nettstedsredigeringen, og advarer om at den ikke er begrenset utelukkende til nettstedsredigeringen og kan gi tilgang til andre administrative funksjoner knyttet til temaet.

Det betyr at Redaktøren du ville la omorganisere en meny, nå har nettstedsredigeringen: maler, maldeler, globale stiler og navigasjon. Det er en bredere tildeling enn switch_themes, som bare eksponerer Utseende og Utseende > Temaer.

Hvis det du faktisk vil ha er en rolle for nettstedsredigeringen, lister dokumentasjonen opp hva som trengs: edit_theme_options for tilgangen og navigasjonsmenyen, pluss edit_posts, edit_pages og edit_others_posts for å administrere maler, read for forhåndsvisning og upload_files for medier.

Feilen er stille her, fordi nettstedsredigeringen snakker med REST-API-et. Endepunktene for maler og maldeler sjekker edit_theme_options; endepunktene for innlegg og sider gjør sine egne sjekker. En rolle som kan åpne nettstedsredigeringen, men mangler edit_others_posts, får et panel som laster og så feiler ved lagring. Les nettverksfanen etter 401- og 403-svar før du legger til rettigheter i blinde: REST-feilkoden navngir tillatelsen som feilet.

#Betingede rettigheter med user_has_cap

Noen regler passer ikke i en rolle, fordi de avhenger av objektet: en Redaktør som ikke skal røre innleggene i en bestemt kategori, for eksempel. Til det finnes filteret user_has_cap. WP_User::has_cap() bruker det etter map_meta_cap(), med fire argumenter: $allcaps (det brukeren har), $caps (primitivene sjekken krever), $args (den forespurte rettigheten i $args[0], bruker-ID i $args[1] og som regel objekt-ID i $args[2]) og WP_User-objektet.

add_filter( 'user_has_cap', function ( $allcaps, $caps, $args, $user ) {
    if ( 'edit_post' !== ( $args[0] ?? '' ) || empty( $args[2] ) ) {
        return $allcaps;
    }
    if ( has_term( 'legal', 'category', $args[2] ) && empty( $allcaps['manage_options'] ) ) {
        foreach ( $caps as $cap ) {
            $allcaps[ $cap ] = false;
        }
    }
    return $allcaps;
}, 10, 4 );

Tre detaljer i kildekoden avgjør om dette fungerer. Filteret ser bare sjekker som har med objekt-ID, så current_user_can( 'edit_posts' ) går rett gjennom uten at regelen slår inn. Det kjører ved hver rettighetssjekk, så den tidlige utgangen på første linje er ikke valgfri. Og i multisite når det ikke superadministratorer: has_cap() returnerer true for dem før filteret brukes, som vist i seksjon 6.

#4. Hvordan tilbakestille roller i WordPress

Versjonen av dette skriptet som sirkulerer, og som tidligere utgaver av denne artikkelen inneholdt, er en ekstern rettighetseskalering:

// Ikke deploy dette.
function wppoland_reset_roles() {
    if ( ! isset( $_GET['reset_roles_secret_key'] ) ) return;

    require_once( ABSPATH . 'wp-admin/includes/schema.php' );
    populate_roles();
}
add_action( 'init', 'wppoland_reset_roles' );

isset() sjekker at parameteren finnes, ikke at den er riktig. Enhver uautentisert besøkende som legger ?reset_roles_secret_key til en hvilken som helst URL på nettstedet, gjenoppretter standardrettighetene, og det inkluderer å gi tilbake alt du med vilje hadde tatt fra Redaktør eller Forfatter.

#Hvordan tilbakestille roller med wp role reset

wp role reset kjører på den samme kjernefunksjonen og er autentisert gjennom shell-tilgangen:

wp role reset --all
wp role reset editor

Den gjør dessuten mer enn populate_roles() alene, og forskjellen betyr noe ved feilsøking. populate_roles() kaller populate_roles_160() til og med populate_roles_300(), og disse funksjonene kaller bare add_role() og add_cap(). Det finnes ikke ett eneste remove_cap() i dem. Kalt direkte gjenoppretter den fjernede rettigheter og lar alle som et programtillegg har lagt til, stå. WP-CLI sammenligner i tillegg med en ren installasjon, og derfor ser utdataene slik ut:

Restored 1 capability to and removed 0 capabilities from 'administrator' role.

Egendefinerte roller forblir urørt uansett vei. Er problemet på nettstedet en dårlig laget egendefinert rolle, løser en tilbakestilling det ikke.

#Hvordan inspisere roller med WP-CLI før tilbakestilling

Tilstanden du feilsøker, er en opsjonsrad:

wp option get wp_user_roles --format=json | jq '.editor.capabilities'
wp cap list editor
wp user list --field=user_login --role=administrator

Den siste er kommandoen det er verdt å kjøre på ethvert nettsted du arver. Et antall administratorer som overrasker deg, er funnet.

#5. Hvordan sikre roller i WordPress

#A. Hvordan gå gjennom administratorkontoer i WordPress

Minste privilegium er ikke en ny rolle, det er en kortere administratorliste. Kjør wp user list --role=administrator på nettstedene du vedlikeholder. Byråkontoer, en frilanser som har sluttet og supporttilgangen til et programtillegg fra for to år siden er de vanlige beboerne.

Om det klassiske rådet om ikke å kalle brukeren ‘admin’: installasjonsprogrammet har bedt om brukernavn siden WordPress 3.0, så hullet som gjenstår er enumerering. REST-endepunktet for brukere returnerer id, name, url, description, link, slug og avatar_urls uten autentisering. roles og capabilities ligger i konteksten edit og eksponeres ikke, men slug er user_nicename, som WordPress avleder fra innloggingsnavnet med mindre noen endrer det. Det er en liste over brukernavn, ikke et sikkerhetsbrudd, og å begrense antall forsøk i innloggingsskjemaet er kontrollen som veier tyngst.

#B. Hvordan slå av filredigering med DISALLOW_FILE_EDIT

Å ta edit_themes fra Administrator er en rettighetsendring som noen kan reversere. En konstant i wp-config.php sjekkes inne i map_meta_cap() og kan ikke overstyres med en tildeling:

define( 'DISALLOW_FILE_EDIT', true );

DISALLOW_FILE_EDIT mapper edit_files, edit_plugins og edit_themes til do_not_allow. DISALLOW_FILE_MODS går lenger og blokkerer installasjon og oppdatering av programtillegg og temaer fra kontrollpanelet, og slår av filredigeringen som en bivirkning. På et nettsted som deployes fra Git er DISALLOW_FILE_MODS den ærlige innstillingen, fordi oppdateringene kommer gjennom deploy-pipelinen.

DISALLOW_UNFILTERED_HTML fungerer på samme måte og er verdt det på ethvert redaksjonelt nettsted der Redaktører ikke trenger å lime inn script-tagger.

#C. Hvordan mappe metarettigheter i egendefinerte innholdstyper

register_post_type() setter map_meta_cap til null som standard, ikke til false. WP_Post_Type::set_props() gjør denne null-verdien om til true når capabilities er tom og capability_type er post eller page, av hensyn til kompatibilitet med oppførselen i 3.0 (kjerneticket #14122), og faller tilbake til false i alle andre tilfeller. En egen capability_type som den nedenfor ender dermed på false med mindre du sier noe annet. Oppgi begge argumentene:

register_post_type( 'book', [
    'capability_type' => [ 'book', 'books' ],
    'map_meta_cap'    => true,
] );

Array-formen er ikke pynt. Med en enkel streng legger WordPress til en s for å lage flertallet, noe som gir storys for story. Referansen for register_post_type() nevner arrayet som måten å oppgi et alternativt flertall på.

capability_type => 'book' genererer metarettighetene edit_book, read_book, delete_book og primitivene edit_books, edit_others_books, delete_books, publish_books, read_private_books. Seks andre, read, delete_private_books, delete_published_books, delete_others_books, edit_private_books og edit_published_books, genereres bare når map_meta_cap er true, fordi bare map_meta_cap() bruker dem. Det er grunnen til at flagget finnes. Uten det løser map_meta_cap() metarettigheten edit_book til selve strengen edit_book, uten å se på hvem som er forfatter eller om boken er publisert, så den som har denne rettigheten, redigerer alles bøker.

En annen standardverdi å følge med på: create_posts mappes til edit_books med mindre du definerer den. Vil du ha en rolle som redigerer eksisterende bøker, men aldri oppretter en, må du si det i capabilities-arrayet.

#D. Hvor current_user_can skal sjekkes i handlere og REST-ruter

Sjekken hører hjemme ved operasjonen, ikke i menyen. add_menu_page() tar imot en rettighet og bruker den til å skjule en lenke, men beskytter ikke handleren. Hver admin-post-handler, hver AJAX-callback og hver REST-rute trenger sin egen current_user_can(), og REST-ruter trenger den i permission_callback, ikke inne i handleren. Siden WordPress 5.5 logger register_rest_route() en _doing_it_wrong()-melding når permission_callback mangler, og for en rute som virkelig er offentlig, er den dokumenterte verdien __return_true.

For alt som virker på et bestemt objekt, send med objektet: current_user_can( 'edit_post', $post_id ) går gjennom map_meta_cap() og løser eierskapet. current_user_can( 'edit_posts' ) gjør ikke det, og svarer på et spørsmål om innholdstypen i stedet for om akkurat det innlegget.

#E. Tilgangsrevisjon og atskilte miljøer

En revisjonslogg som følger innlogginger, rolleendringer og sensitive handlinger, forteller deg hvem som ga hva og når. Programtillegg som WP Activity Log dekker den funksjonen, og du kan også bygge det med WordPress-kroker.

Roller i utvikling, staging og produksjon gjennomgås hver for seg. En rolle som er fornuftig i utvikling, med ekstra rettigheter for feilsøking, kan være farlig i produksjon.

#6. WordPress-rettigheter i multisite og programtillegg

#Nettverksrettigheter i Multisite

I WordPress Multisite-installasjoner virker rettigheter på to nivåer: enkeltnettsted og nettverk. Ifølge dokumentasjonen for roller og rettigheter finnes disse ti bare for superadministratoren: create_sites, delete_sites, manage_network, manage_sites, manage_network_users, manage_network_plugins, manage_network_themes, manage_network_options, upgrade_network og setup_network.

Det som overrasker, går i motsatt retning. Administratoren på en underside mister rettigheter hen har på et enkeltnettsted. Den samme dokumentasjonen lister update_core, update_plugins, update_themes, install_plugins, install_themes, delete_themes, delete_plugins, edit_plugins, edit_themes, edit_files, edit_users, add_users, create_users, delete_users og unfiltered_html som rettigheter som i multisite bare superadministratoren har. De fjernes ikke fra rolleraden: map_meta_cap() gjør dem om til do_not_allow med betingelsen is_multisite() && ! is_super_admin( $user_id ), den samme du så i seksjon 1 for unfiltered_html. Derfor endrer det ingenting å legge install_plugins til Administrator-rollen på en underside.

WP_User::has_cap() håndterer superadministratoren før allcaps konsulteres og før filteret user_has_cap brukes: hvis resultatet fra map_meta_cap() ikke inneholder do_not_allow, returnerer den true. For å ta noe fra en superadministrator må du filtrere map_meta_cap og legge til do_not_allow, ikke user_has_cap.

For å sjekke en tillatelse på et annet nettsted i nettverket innførte WordPress 6.7 current_user_can_for_site( $site_id, $capability ), som erstatter current_user_can_for_blog(), nå i deprecated.php. Plugin-håndboken viser fortsatt det gamle navnet.

#Rettigheter i WooCommerce, BuddyPress og bbPress

Programtillegg som WooCommerce, BuddyPress og bbPress legger til sine egne rettigheter i systemet. Når du planlegger rollearkitekturen for et nettsted som bruker disse programtilleggene, må du ta hensyn både til de innebygde WordPress-rettighetene og til rettighetene programtilleggene legger til.

#Members og User Role Editor for å administrere roller

Programtilleggene Members og User Role Editor gir grafiske grensesnitt for å administrere roller og rettigheter. Likevel er det i profesjonell utvikling å foretrekke å styre rollene med versjonert kode, slik at endringer i tillatelser går gjennom den samme gjennomgangen som enhver annen endring.

#Oppsummering

Roller er lagring. Rettigheter er beslutningen. Alt ovenfor følger av det skillet:

• Sjekk rettigheter, aldri rollenavn: current_user_can('administrator') løses gjennom en sammenslåing av nøkler fra brukermeta og returnerer false for hver egendefinerte rolle du lager.
• Behandle add_role() og add_cap() som migreringer mot en databaserad, med versjonssjekk, ikke som konfigurasjon du redigerer og deployer på nytt.
• Les den faktiske rekkevidden til en rettighet før du gir den. edit_theme_options betyr nettstedsredigeringen i et blokktema, ikke bare menyskjermen.
• Gjenopprett med wp role reset --all, aldri med en uautentisert spørringsparameter, og husk at den lar egendefinerte roller være urørt.
• Sett map_meta_cap => true på hver egendefinerte innholdstype som har mer enn én forfatter.

Se også tjenestene våre for vedlikehold av WordPress for å holde nettstedet ditt sikkert og optimalisert.