Le cartelle dei plugin dovrebbero includere un file index.php vuoto?

16

WordPress stesso, nella wp-contentcartella, include un file PHP vuoto che assomiglia a questo.

<?php
// Silence is golden.
?>

I plugin dovrebbero includere anche un file vuoto come questo per impedire alla gente di visualizzare il contenuto di una directory? Che dire delle cartelle aggiuntive nei temi, come una includesdirectory?

plugin-development theme-development

— chrisguitarguy
fonte

1

sì, probabilmente è una buona idea. Non ho mai capito perché WP non abbia Options –Indexesnel bundle htaccess, quindi questi file non sarebbero necessari ...

— onetrickpony

17

No, non dovrebbero. Se un plugin ha delle vulnerabilità solo perché qualcuno potrebbe vedere la sua struttura di directory è rotta. Questi bug dovrebbero essere corretti.
La sicurezza attraverso l'oscurità è un bug per se stessa.

Spetta al proprietario del sito consentire o vietare la navigazione nella directory.

Un secondo problema è rappresentato dalle prestazioni: WordPress esegue la scansione di tutti i file PHP nella directory principale di un plug-in per trovare le intestazioni del plug-in. Ciò consente di avere più plug-in nella stessa directory, ad es /wp-content/plugins/wpse-examples/.

Significa anche che i file PHP inutilizzati in quella directory stanno sprecando tempo e memoria quando WordPress è alla ricerca di plugin. Un file non farà molto male, ma immagina che questo stia diventando una pratica comune. Stai creando un vero problema nel tentativo di riparare un immaginario.

— fuxia
fonte

2

"Spetta al proprietario del sito consentire o vietare la navigazione nella directory." Questo è probabilmente il punto chiave.

— chrisguitarguy,

e la mia domanda principale è: perché non i file dei plugin principali non sono scritti index.php? potrebbe essere una soluzione ottimale

— T.Todua,

10

Sto per dire SÌ. La sicurezza attraverso l'oscurità funziona se sei più oscuro dei tuoi vicini :) (scherzando, ma c'è del vero).

La realtà è che i robot / scanner ora compilano gli elenchi dei plugin direttamente da wordpress.org e scansionano direttamente l'URL del plugin, eseguendo il fingerprinting delle versioni per exploit noti e mantenendo le informazioni in un database come riferimento.

Quindi quale preferiresti avere, un bot non è in grado di raccogliere informazioni sulla tua installazione o lasciarlo all'autore del plug-in per assicurarti di essere sicuro. Che ne dici di entrambi.

ps. Su una nota a margine ci sono stati 186 exploit segnalati dai plugin wordpress.org l'anno scorso. (* Riportato ..).

— Wyck
fonte

1

Gli scanner di exploit non verificano se il plug-in esiste. Tentano di eseguire l'exploit durante la prima richiesta. Un vuoto index.phpnon proteggerebbe nulla, otterresti solo un falso senso di sicurezza.

— fuxia

Ma lo fanno, wp-scan (una delle tante) impronte digitali oltre 2200 plugin per esempio, e usa alcune impronte digitali decenti per rilevare le versioni (dimensione del file, aggiunte di file, ecc.).

— Wyck,

Ho ripulito dozzine di siti WordPress compromessi. Quasi sempre la prima richiesta è stata un vero attacco. È ragionevole: perché perdere tempo con una scansione dettagliata se è possibile verificare la vulnerabilità nella prima richiesta? Traccia i tuoi 404 per vederlo. :)

— fuxia

1

Sono d'accordo, questo dovrebbe spettare all'utente finale e non all'autore. Ma non penso nemmeno che faccia male. Volevo solo aggiungere un contrappunto poiché hai detto "no".

— Wyck,

1

contrassegnato questo come accettato a causa del dibattito sui commenti!

— chrisguitarguy,

1

Dal momento che il core di WordPress fa questo, ha senso che i plugin seguano l'esempio. Mentre tutto ciò può essere protetto con varie impostazioni lato server, non fa male avere un valore predefinito (probabilmente perché lo fa il core di WordPress).

— BFTrick
fonte

0

Come ha sottolineato la fuxia, c'è un inconveniente delle prestazioni nell'avere un .phpfile extra che WordPress cerca nei plugin. Un index.htmlprobabilmente sarebbe una scelta migliore. Naturalmente, l'opzione migliore sarebbe quella di vietare la navigazione nella directory attraverso il web server.

Inoltre, la sicurezza attraverso l'oscurità non va bene.

— Alex H
fonte