Spostare wp-config al di fuori della radice Web è davvero vantaggioso?
-
-
Non è davveronecessarioinserire latua scelta di rispostee rifiutaretutte le altre risposte,all'interno dellatua domanda.Comepuoi vedere sotto,è a questo che serveil sistema di votazione stackexchange,per votare le risposte che hanno sensoper lepersone,mentre chipone le domande dovrebbe usareilmeccanismo della "risposta accettata"ei tuoi voti su/giù.It's really not necessary to plug your choice of answers and reject all other answers, inside your question. As you can see below, that's what the stackexchange voting system is for, to vote up the answers that make sense to people, whereas the question askers should be using the "accepted answer" mechanism and your own up/down votes.
- 2
- 2014-01-20
- Kzqai
-
Non lofaccioperil 99% delle domande che hoposto,ma hopensato chefosse appropriatoin questo caso specifico.Ci sono 8 risposte alla domanda,alcune delle quali sono abbastanza lunghe/complessee alcune delle quali hannomolti votipositivinonostante contenganoinformazioniimprecise onon aggiunganonulla alla conversazione.Penso che offrire una conclusione semi-autorevole sia utileper lepersone che leggonoilthreadper laprima volta.Come sempre,i lettori sono liberi diprendere una decisione;Sto solo offrendo lamia opinione come OP.I don't do that for 99% of the questions I've asked, but I thought it was appropriate in this specific case. There are 8 answers to the question, some of which are fairly lengthly/complex, and some of which have a lot of upvotes despite despite containing inaccurate info or not adding anything to the conversation. I think offering a semi-authoritative conclusion is helpful to people reading the thread for the first time. As always, readers are free to make up their own mind; I'm just offering my opinion as the OP.
- 7
- 2014-01-21
- Ian Dunn
-
@Kzqai: Lo "stackexchange voting system" è unprocesso democratico,e ipartecipanti spesso 1)non sono chiari su ciò che l'OP staeffettivamente chiedendo o cercando di risolveree 2)non capiscono la validità di una rispostaparticolare.Dopo che le risposte sono arrivatee i voti sono statiespressi,è **più che utile ** cheil PO chiarisca quelle risposte che hannofornito assistenza.Dopotutto,l'OP è l'unico che lo sa,e vorrei chepiù OP lofacessero.Sì,lepersone "votano le risposte che hanno sensoper lepersone",ma lasciamo che l'OP abbia l'ultimaparola su ciò che ha sensoper lui.@Kzqai: The "stackexchange voting system" is a democratic process, and the participants are often 1) unclear as to what the OP is actually asking or trying to solve, and 2) uncomprehending of any particular answer's validity. After the responses have trickled in and the votes have been cast, it is **more than helpful** to have the OP clarify those responses that provided assistance. After all, the OP is the only one who knows, and I wish more OPs did so. Yes, people "vote up the answers that make sense to people," but let's let the OP have the last word as to what makes sense to him.
- 2
- 2017-07-14
- Mac
-
8 risposta
- voti
-
- 2012-07-18
La cosapiùimportante è che
wp-config.php
contiene alcuneinformazioni sensibili:nome utente/password del database,ecc.Quindi l'idea: spostalofuori dalla root del documentoe non devipreoccuparti dinulla. Un utentemalintenzionatonon saràmaiin grado di accedere a quelfile da unafonteesterna.
Tuttavia,eccoilproblema:
wp-config.php
non stampamainulla sullo schermo. Definisce solo varie costanti utilizzate durante l'installazione di WP. Quindi l'unicomodoin cui qualcuno vedràil contenuto di quelfile è se aggirano l'interprete PHP deltuo server - ottengonoilfile.php
da visualizzare come solotesto. Se ciò accade,seigiànei guai: hanno accesso diretto altuo server (eprobabilmentei permessi di root)e possonofare quello che vogliono.Vado avantie dico che non c'è alcun vantaggionello spostare
wp-config
al difuori della root del documento da unaprospettiva di sicurezza ,peri motivi soprae questi :- Puoi limitare l'accesso alfiletramite la configurazione deltuo host virtuale o .htaccess,limitandoin modoefficace l'accessoesterno alfilenello stessomodoin cui lofarebbe spostarsi al difuori della radice del documento
- Puoi assicurarti chei permessi delfile siano rigorosi su
wp-config
perimpedire a qualsiasi utente senzaprivilegi sufficienti di leggereilfile anche se ottiene un accesso (limitato) altuo servertramite SSH. - Letueinformazioni sensibili,leimpostazioni del database,vengono utilizzate solo su un singolo sito. Quindi,anche se un utentemalintenzionato avesse accesso ataliinformazioni,l'unico sito cheinteresserebbe sarebbe l'installazione di WordPress a cui appartieneilfile
wp-config.php
. Ancorapiùimportante,quell'utente del database ha solo le autorizzazioniper leggeree scrivere sul database dell'installazione di WPe nient'altro,nessun accessoper concedere le autorizzazioni ad altri utenti. In altreparole,se un utentemalintenzionato ottiene l'accesso altuo database,sitratta semplicemente di ripristinare da unbackup (vedipunto 4)e cambiare l'utente del database - Esegui spessoilbackup. Spesso è untermine relativo: sepubblichi 20 articoli ognigiorno,farestimeglio aeseguireilbackup ognigiorno o ognipochigiorni. Sepubblichi una volta alla settimana,probabilmente è sufficienteeseguireilbackup una volta alla settimana.
- Haiiltuo sito sottoil controllo della versione ( come questo ),il che significa che anche se un utentemalintenzionato ha ottenuto l'accesso,puoi rilevarefacilmente lemodifiche al codicee ripristinarle. Se un utentemalintenzionato ha accesso a
wp-config
,probabilmente ha combinato qualcos'altro. - Leinformazioni del database sono davvero le uniche cose sensibiliin
wp-config
,e poiché stai attento a questo (vedipunti 3e 4),non è ungrossoproblema. I salie similipossonoesseremodificatiin qualsiasimomento. L'unica cosa che accade è cheinvalidai cookie degli utenti registrati.
Perme,spostare
wp-config
fuori dalla radice del documentopuzza di sicurezzaper oscurità,il che è davvero un uomo dipaglia.The biggest thing is the
wp-config.php
contains some sensitive information: your database username/password, etc.So the idea: move it outside the document root, and you don't have to worry about anything. An attacker will never be able to access that file from an external source.
Here's the rub, however:
wp-config.php
never actually prints anything to the screen. It only defines various constants that are used throughout your WP install. Thus the only way someone is going to see that contents of that file is if they circumvent your servers PHP interpreter -- they get.php
file to render as just plain text. If that happens, you're already in trouble: they have direct access to your server (and probably root permissions) and can do whatever they like.I'm going to go ahead and say there's no benefit to moving
wp-config
outside the document root from a security perspective -- for the reasons above and these:- You can restrict access to the file via your virtual host config or .htaccess -- effectively limiting outside access to the file in the same way that moving outside the document root would
- You can ensure the file permissions are strict on
wp-config
to prevent any user without sufficient privileges from reading the file even if they gain (limited) access to your server via SSH. - Your sensitive information, database settings, are only used on a single site. So even if an attacker gained access to that information, the only site it would affect would be the WordPress install to which the
wp-config.php
file belongs. More importantly, that database user only has permissions to read and write to that WP install's database and and nothing else -- no access to grant other users permissions. Meaning, in otherwords, if an attacker gains access to your database, it's simply a matter of restoring from a backup (see point 4) and changing the database user - You backup often. Often being a relative term: if you post 20 article every day, you better back up every day or every few days. If you post once a week, backing up once a week is likely sufficient.
- You have your site under version control (like this), which means even if an attacker gained access, you can easily detect code changes and roll them back. If an attacker has access to
wp-config
, they've probably messed with something else. - The database information is really the only sensitive stuff in
wp-config
, and because you're careful about it (see point 3 and 4), it's not a huge deal. Salts and such can be changed any time. The only thing that happens is that it invalidates logged in users' cookies.
To me, moving
wp-config
out of the document root reeks of security by obscurity -- which is very much a straw man.-
Sì,èpiù omeno quello che stavopensando.Sono contento di sapere chenon sono l'unico :) Vorrei lasciare la domanda apertaper un altrogiorno o duenel caso qualcuno avesse una controargomentazione convincente,mafinora questa sembra la rispostagiusta ame.Yeah, that's pretty much what I've been thinking. I'm glad to know I'm not the only one :) I'd like to leave the question open for another day or two just in case somebody has a compelling counter-argument, but so far this seems like the right answer to me.
- 2
- 2012-07-18
- Ian Dunn
-
Correzioneminore:non c'è alcun vantaggio di * sicurezza *nello spostareilfile wp-config.php dalla radice del documento.Ci sono altri vantaggi,chenon sono legati alla sicurezzae che si applicano solo a configurazioniinsolite.Minor correction: There's no *security* benefit to moving the wp-config.php file out of the document root. There are other benefits, which are not security related, and which only apply to unusual setups.
- 3
- 2012-08-12
- Otto
-
Ottima scelta. Modificato.Good call. Edited.
- 0
- 2012-08-12
- chrisguitarguy
-
Soloper sfatare unpossibilemito -non èpossibile,qualcosapotrebbe andare storto sul lato server -nel qual casoil codicephp viene stampato sullo schermo?Just to get a possible myth debunked - is it not possible, something might go wrong server side - in which case php code is printed to the screen?
- 4
- 2012-08-12
- Stephen Harris
-
Sicuro.Semod_phpnonfunzionava oi file PHPnon vengonopassati all'interprete PHP,èpossibile.Se staieseguendo una configurazione FCGI,la stessa cosa èpossibile sei file PHPnon vengonotrasferiti alprocessofcgiper l'interpretazione.Entrambiindicano alcuniproblemipiuttostograndi chenon èprobabile che accadano,tuttavia.Sure. If mod_php wasn't working or PHP files don't get passed to the PHP interpreter, it's possible. If you're running a FCGI set up, the same thing is possible if PHP files don't get handed off to the fcgi process for interpretation. Both of those point to some pretty large issues that aren't likely to happen, however.
- 0
- 2012-08-12
- chrisguitarguy
-
Penso che la domandaprincipale quinon sia se ci sia omeno qualche vantaggionello spostarlo,ma setali vantaggi superano omenoil rischio diespandere l'ambito openbase_dirperincludere la directorypadre,che spesso contienefile di registro,backup,unfileprivatodirectory di archiviazione,ecc. Continuo a chiedere a riguardo,e nessuno dei sostenitori dello spostamento di wp-configmi hamai dato una risposta.Quindi,a questopuntoprendoil loro silenzioper significare chei beneficinon valgonoil rischio.I think the core question here isn't whether or not there's some benefit to moving it, but whether or not those benefits outweigh the risk of expanding the openbase_dir scope to include the parent directory, which often contains log files, backups, a private file storage directory, etc. I keep asking about that, and none of the proponents of moving wp-config have ever given me an answer. So, at this point I'm taking their silence to mean that the benefits aren't worth the risk.
- 0
- 2012-09-13
- Ian Dunn
-
@IanDunn Ma lemigliori risposte sostengono di spostarlo completamente da quellagerarchiain una separata,che risolva latuapreoccupazioneperi logecc. Questa rispostanon risponde altitolo dellatua domanda "si stamuovendo ... davvero vantaggioso",dice soloaltremisure di sicurezza sono utilie cerca di rassicurartipernonpreoccuparti della sicurezza.Tuttipensano che la loro casa sia sicurafino a quandonon vengono svaligiati.Dopo di chefanno un lavoromigliore.Alcunepersonenon vengonomai svaligiate,anche se la loro sicurezza èbassa,ma ciònon significa che sia unbuon consiglio avere una sicurezzainferiore.@IanDunn But the best answers advocate moving it out of that hierarchy altogether into a separate one, which does address your concern about logs etc. This answer doesn't answer your question title "is moving ... really beneficial", it just says other security measures are beneficial, and tries to reassure you into not worrying about security. Everyone thinks their house is secure until they get burgled. After that they do a better job. Some people never get burgled, even though their security is low, but it doesn't mean it's good advice to have lower security.
- 3
- 2012-12-05
- AndrewC
-
AFAIK,non èpossibile spostarlo danessunapartetranne una directory sopra ABSPATH,perché è l'unicaposizionein cui WP lo cercherà.AFAIK, it's not possible to move it anywhere except one directory above ABSPATH, because that's the only location WP will search for it.
- 0
- 2012-12-05
- Ian Dunn
-
Nonimporta,Aaron ha aggiornato la sua risposta con una soluzione alternativa,utilizzando unfilefittizio wp-config.phpperincludere () quello vero.Nevermind, Aaron updated his answer with a workaround for that, by using a dummy wp-config.php file to include() the real one.
- 1
- 2012-12-06
- Ian Dunn
-
Questi sonobuonipunti,mailmioproblemapiùgrande con questi è che sono argomenti riparatori,non argomentipreventivi.Lamaggiorparte di questiparla di comenon sia ungrossoproblemaperché A)presumi che qualcuno abbiagestito correttamente l'utente dbe B) hai deibackup.Cosa succede quando utilizzi qualcosa come woocommerce omemorizziinformazioni sensibilineltuo database?Allora seifottuto.These are good points, but my biggest problem with these is that they're remedial arguments, not preventative arguments. Most of these talk about how it's not a huge deal because A) you assume someone handled the db user correctly and B) you have backups. What happens when you're using something like woocommerce or storing sensitive information in your database? Then you're screwed.
- 4
- 2014-06-16
- Goldentoa11
-
- 2012-07-13
Penso che quella di Max sia una risposta consapevole,e questo è un lato della storia.Il WordPress Codex hapiù consigli :
Inoltre,assicurati che solotu (eil server web)possiate leggere questofile (generalmente significa unpermesso 400 o 440).
Se usi un server con .htaccess,puoimetterloin quelfile (in in alto)pernegare l'accesso a chiunque lonavighi:
& lt;file wp-config.php > ordine consentire,negare negato datutti & lt;/files > Nota che l'impostazione dell'autorizzazione 400 o 440 su wp-config.phppotrebbeimpedire aiplugin di scriverlo omodificarlo.Un caso autentico,adesempio,sarebbe lamemorizzazionenella cache deiplug-in (W3 Total Cache,WP Super Cache,ecc.) Intal caso,sceglierei 600 (l'autorizzazionepredefinitaperi filein
/home/user
directory).I think Max's is a knowledgeable answer, and that's one side of the story. The WordPress Codex has more advise:
Also, make sure that only you (and the web server) can read this file (it generally means a 400 or 440 permission).
If you use a server with .htaccess, you can put this in that file (at the very top) to deny access to anyone surfing for it:
<files wp-config.php> order allow,deny deny from all </files>
Note that setting 400 or 440 permission on wp-config.php may prevent plugins from writing to or modifying it. A genuine case for example would be, caching plugins (W3 Total Cache, WP Super Cache, etc.) In that case, I'd go with 600 (the default permission for files in
/home/user
directory).-
Max è la risposta.+1 a lui.Sto semplicemente cercando diestenderlo.Max's is the answer. +1 to him. I am simply trying to extend it.
- 5
- 2012-07-13
- its_me
-
Aahan Krish,hai colpitonel segno.Grazieper l'aggiunta.Aahan Krish, you've hit the bull's eye. Thanks for the addition.
- 1
- 2012-07-13
- Max Yudin
-
Quindi,se usi htaccesspernegare le richieste HTTP a wp-config.php,non si ottiene lo stesso risultato di spostarlofuori dalla root del documento,ma senzaesporre log/backup/ecc.?So if you use htaccess to deny HTTP requests to wp-config.php, doesn't that achieve the same result as moving it outside the document root, but without exposing logs/backups/etc?
- 0
- 2012-07-13
- Ian Dunn
-
@IanDunn Dipende da quale sia la root del documento— ** (1) ** Se wordpress è ospitatoin una directoryin `public_html`,spostare` wp-config.php`fuori dalla directory significa che saràin `public_html`directory.In questo caso,dovrai usare le regole htaccesspernegare le richieste HTTP a wp-config.php.** (2) ** Se WordPress èinstallato direttamentenella directory `public_html`,un livello superiore=> lo sposterainella directory`/home/user`.In questo caso sei abbastanza sicuropoichéilfile è al difuori della radice del documento.È ancorapossibileimpostare le autorizzazioni delfile su 600 (o anche su 440 o 400più rigorosi).@IanDunn Depends on what the document root is— **(1)** If wordpress is hosted in a directory in `public_html`, moving `wp-config.php` outside the directory means that it's going to be in `public_html` directory. In this case, you'll have to use the htaccess rules to deny HTTP requests to wp-config.php. **(2)** If WordPress is installed directly under `public_html` directory, one level up => you'll be moving it into `/home/user` directory. In this case you are pretty safe as the file is outside the document root. You can still set the file's permissions to 600 (or even stricter 440 or 400).
- 4
- 2012-07-13
- its_me
-
@ IanDunn Come ho detto,questa è lamia comprensione dibasee non sono unesperto di sicurezza.:)@IanDunn Like I said, this is my basic understanding, and I am no security expert. :)
- 0
- 2012-07-13
- its_me
-
Nel cason. 1non si ottieneil vantaggio di sicurezzaprevisto.Ilpunto è spostarlofuori dalla radice del documento,non solo su di un livello.In case #1 you don't get the intended security benefit. The whole point is to move it outside the document root, not just up one level.
- 0
- 2012-07-14
- Ian Dunn
-
Nel caso # 2,dovrestiespandere l'ambito `open_basedir`per consentire a PHP di accedere atuttoin/home/user,il chemi sembra ungrossoproblema.Qualsiasi cosamemorizzata lì (log,backup,.bash_history,ecc.) Sarebbe accessibile a qualsiasi script PHPinfettoin esecuzionein/home/user/public_html.Sembra che sarebbemeglio lasciare wp-config su/home/user/public_html/wp-config.phpe utilizzare le regole htaccessperbloccare le richieste HTTP.Hai ancorail vantaggio dibloccare l'accessonell'evento (improbabile) che viene visualizzatoin testonormale,manonesponii file soprapublic_html.In case #2, you'd have to expand the `open_basedir` scope to let PHP access everything in /home/user, which seems like a huge problem to me. Anything stored there (logs, backups, .bash_history, etc) would be accessible to any infected PHP script running in /home/user/public_html. It seems like it'd be better to leave wp-config at /home/user/public_html/wp-config.php and use htaccess rules to block HTTP requests to it. You still get the benefit of blocking access in the (unlikely) event that it's displayed in plain-text, but you don't expose files above public_html.
- 0
- 2012-07-14
- Ian Dunn
-
- 2012-09-12
Qualcuno ci ha chiesto dibrillaree io risponderò qui.
Sì,l'isolamento di wp-config.php dalla directoryprincipale deltuo sito offre vantaggiin termini di sicurezza.
1- Seiltuogestore PHP viene danneggiato omodificatoin qualchemodo,letueinformazioni DBnon verrannoesposte. E sì,l'ho visto accadere alcune volte su host condivisi durantegli aggiornamenti del server. Sì,il sito verrà danneggiato durante quelperiodo,ma letuepassword rimarrannointatte.
2- Lemiglioripratiche consigliano sempre diisolarei file di configurazione daifile di dati. Sì,è difficilefarlo con WordPress (o qualsiasi app web),ma spostarlo verso l'alto crea unpo 'diisolamento.
3- Ricorda la vulnerabilità PHP-CGI,in cui chiunquepotrebbepassareil? -s a unfilee visualizzareil sorgente. http://www.kb.cert.org/vuls/id/520827
Allafine,questi sonopiccoli dettagli,ma aiutano a ridurre alminimoil rischio. Specialmente seti troviin un ambiente condiviso,dove chiunquepuò accedere altuo database (tutto ciò di cui habisogno è un utente/pass).
Manon lasciare chepiccole distrazioni (ottimizzazionipremature) sitrovino difronte a ciò che è veramentenecessarioper rendere un sito adeguatamente sicuro:
1- Tienilo sempre aggiornato
2- Utilizzapassword complesse
3- Limitare l'accesso (tramite autorizzazioni). Abbiamo unpost al riguardo qui:
http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html
grazie,
Someone asked us to shine in, and I will reply here.
Yes, there are security benefits from isolating your wp-config.php from the root directory of your site.
1- If your PHP handler gets broken or modified in some way, your DB information will not be exposed. And yes, I saw this happen a few times on shared hosts during server updates. Yes, the site will be broken during that period, but your passwords will be intact.
2- Best practices always recommend isolating configuration files from data files. Yes, it is hard to do that with WordPress (or any web app), but moving it up does a bit of isolation.
3- Remember the PHP-CGI vulnerability, where anyone could pass the ?-s to a file and view the source. http://www.kb.cert.org/vuls/id/520827
At the end, those are small details, but they do help to minimize risk. Specially if you are on a shared environment, where anyone can access your database (all they need is a user/pass).
But don't let small distractions (premature optimizations) get in front of what is really necessary to get a site properly secure:
1- Keep it always updated
2- Use strong passwords
3- Restrict access (via permissions). We have a post about it here:
http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html
thanks,
-
Ehi ragazzi,grazieper aver aggiuntoi vostripensieri.Penso che abbiamogià centrato lamaggiorparte di questipuntinelle altre rispostee nei loro commenti.1) Sì,èpossibile,ma raro;2) Sì,questo ha dei vantaggi,ma sonominimi;3) Sì,èpossibile,ma èimprobabile che queltipo di vulnerabilità si ripresenti,e proteggersi è unpo 'comegiocare a whac-a-mole,o costringere lepersone atogliersi le scarpenegli aeroportiperché qualcheidiota hanascosto unabombanel suoscarpa una volta.È reazionarioed èimprobabile che abbiabeneficifuturi.Hey guys, thanks for adding your thoughts. I think we already hits on most of those points in the other answers and their comments. 1) Yes, this is possible, but rare; 2) Yes, this has benefits, but they're minimal; 3) Yes, this is possible, but that type of vulnerability is unlikely to happen again, and protecting against it is kind of like playing whac-a-mole, or making people remove their shoes at airports because some jackass hid a bomb in his shoe once. It's reactionary and unlikely to have future benefits.
- 0
- 2012-09-12
- Ian Dunn
-
Nelle varie discussioni,la domanda è stata affinata da "Ci sono vantaggi?"a "Ok,ci sono alcuni vantaggi,ma superanoi rischi?"Il rischioprincipale a cuimi riferisco èilfatto che deviespandere l'ambito openbase_dirper consentire a PHP di accedere agli script al difuori della radice web.Molte configurazioni di hosting,comprese quelle che utilizzano Plesk,che èmolto,memorizzano registri,backup,aree FTPprivate che dovrebberoessereisolate dalla radice web,ecc. Nella directory sopra la radice web.Quindi,dare accesso PHP a quella directorypuòessere unagrave vulnerabilità.In the various discussions, the question was refined from "Are there any benefits?" to "Ok, there are some benefits, but do they outweigh the risks?" The main risk I'm referring to is the fact that you have to expand the openbase_dir scope in order to let PHP access scripts outside the web root. Many hosting setups -- including those that use Plesk, which is a lot -- store logs, backups, private FTP areas that are supposed to be isolated from the web root, etc in the directory above the web root. So, giving PHP access to that directory can be a serious vulnerability.
- 0
- 2012-09-12
- Ian Dunn
-
- 2012-07-13
Sicuramente SÌ.
Quando sposti wp-config.php fuori dalla directorypubblica,loproteggi dalla lettura utilizzandoilbrowser quandoilgestorephp vienemodificatoin modo dannoso (o accidentale!).
La lettura deltuo login/password DB èpossibile quandoil server è difficilmenteinfettatoper colpa di un amministratore zoppo.Addebitare unamulta all'amministratoree ottenere un server hostpiù curatoe affidabile.Anche sepotrebbeesserepiù costoso.
Definitely YES.
When you move wp-config.php outside public directory you protect it from reading using browser when php handler gets maliciously (or accidentally!) changed.
Reading your DB login/password is possible when server is hardly infected through a fault of lame administrator. Charge the administrator a fine and get a better-tended and more reliable server host. Though that may be more expensive.
-
Se un utentemalintenzionato ha accesso sufficientepermodificareilgestore PHP,seigiàfregato.Lemodifiche accidentali sonomolto rarenellamiaesperienzae intal caso sarebbefacile cambiare lapassword.Alla luce di queste cose,pensi ancora che valga lapena rischiare diesporre log/backup/ecc. A causa dell'ambito `open_basedir`esteso?If an attacker has enough access to change the PHP handler, you're already screwed. Accidental changes are very rare in my experience, and in that case it'd be easy to change the password. In light of those things, do you still think it's worth the risk of exposing logs/backups/etc because of the expanded `open_basedir` scope?
- 4
- 2012-07-13
- Ian Dunn
-
Non homai avuto accesso a `-rwx` a directory superiori a`public_html`,quindinon homai avutofamiliarità con `open_basedir`.Imiei registri sonoin una directory separata,cosìfannoi backup.Penso che sia quello che hannotuttigli host condivisi.I've never had `-rwx` access to directories higher than `public_html` so I never was familiar with `open_basedir`. My logs are in separate directory, so backups do. I think that's what all shared hosts have.
- 1
- 2012-07-13
- Max Yudin
-
Ipadroni di casa varianoenormemente;nonesiste una struttura di directory standard.Plesk (uno deipannelli di controllopiùpopolariper host condivisi)inseriscei login/var/www/vhosts/example.com/statistics/logse la radice del documento è/var/www/vhosts/example.com/httpdocs.Spostare wp-config.phpin/var/www/vhosts/example.com/wp-config.php richiederebbe l'accesso degli script all'intera directoryexample.com.Hosts vary wildly; there's no standard directory structure. Plesk (one of the most popular control panels for shared hosts) puts logs in /var/www/vhosts/example.com/statistics/logs and the document root is /var/www/vhosts/example.com/httpdocs. Moving wp-config.php to /var/www/vhosts/example.com/wp-config.php would require giving scripts access to the entire example.com directory.
- 0
- 2012-07-14
- Ian Dunn
-
Soloper curiosità,dove sono archiviatii tuoi loge backup,senonnella directory del dominio?Sono accessibilitramite unpannello di controllo o qualcosa delgenere?Just out of curiosity, where are your logs and backups stored, if not in the domain's directory? Are they accessed through a control panel or something?
- 0
- 2012-07-14
- Ian Dunn
-
Sì,tramite unpannello di controllo.Yes, through a control panel.
- 1
- 2012-07-14
- Max Yudin
-
Potrei sbagliarmi su questo,ma seiltuo servernon è sicuro,un collegamento simbolicopotrebbe leggereiltuo wp-config.phpindipendentemente da dove sitrova.Tutto ciò che un utentemalintenzionato deve sapere è dovepotrebbeessereilfilee se èpossibileil collegamento simbolico.Questapotrebbeessere una domandafuoritema,ma sembrerebbe che se cifosse unmodoper rinominare wp-config.php,sarebbe unmodoperprevenireilphishing.I may be wrong about this, but if your server is not secure, a symlink attack could read your wp-config.php regardless of where it is. All an attacker has to know is where the file could possibly be and if symlinking is possible. This maybe an off topic question, but it would seem if there was a way to rename the wp-config.php, that would be a way to prevent phishing for it.
- 0
- 2012-07-14
- MickeyRoush
-
Ilnome delfile `wp-config.php` è codificatoin` wp-load.php`,quindinon èpossibile cambiarlo senzamodificareil core.The filename `wp-config.php` is hardcoded into `wp-load.php`, so changing it isn't possible without modifying core.
- 0
- 2012-07-16
- Ian Dunn
-
- 2012-10-03
Voglio solo chiarire,per amor di discussione,che spostareiltuofile wp_config.phpnon significanecessariamente che devi spostarlo solonella directoryprincipale. Supponiamo chetu abbia una struttura come/root/html,dove html contiene l'installazione di WPe tuttoiltuo contenuto HTML. Invece di spostare wp_config.phpin/root,potresti spostarloin qualcosa come/root/secure ... che è siafuori dalla directory html chenonnella directory root del server. Ovviamente,dovresti assicurarti chephppossaessereeseguito anchein questa cartella sicura.
Poiché WPnonpuòessere configuratoper cercare wp_config.phpin una cartella dipari livello come/root/secure,devifare unpasso aggiuntivo. Ho lasciatoilfile wp_config.phpin/root/htmle hotagliato leparti sensibili (login al database,salt,prefisso dellatabella)e le ho spostatein unfile separato chiamato config.php. Quindi aggiungiil comando PHP
include
altuo wp_config.php,in questomodo:include ('/home/content/path/to/root/secure/config.php');
Questo èessenzialmente quello che hofattonellamia configurazione. Ora,sullabase della discussione di cui sopra,sto ancora valutando se ènecessaria o addirittura unabuonaidea. Ma volevo solo aggiungere che la configurazione di cui sopra èpossibile. Nonesponei tuoibackupe altrifile di roote,finché la cartellaprotettanon è configurata conilproprio URLpubblico,non è sfogliabile.
Inoltre,puoi limitare l'accesso alla cartellaprotetta creando unfile .htaccess con:
ordinenega,consenti negato datutti consenti da 127.0.0.1
I just want to clarify, for the sake of argument, that moving your wp_config.php file does not necessarily mean you have to move it only to the parent directory. Let's say you have a structure like /root/html, where html contains the WP installation and all of your HTML content. Instead of moving wp_config.php to /root, you could move it to something like /root/secure ... which is both outside the html directory and also not in the server root directory. Of course, you would need to make sure that php can run in this secure folder as well.
Since WP cannot be configured to look for wp_config.php in a sibling folder like /root/secure, you have to take an additional step. I left the wp_config.php in /root/html, and cut out the sensitive portions (database login, salt, table prefix) and moved them to a separate file called config.php. Then you add the PHP
include
command to your wp_config.php, like this:include('/home/content/path/to/root/secure/config.php');
This is essentially what I've done in my setup. Now, based on the above discussion, I am still evaluating whether it is necessary or even a good idea. But I just wanted to add that the above configuration is possible. It does not expose your backups and other root files, and so long as the secure folder is not set up with its own public URL, it is not browsable.
Furthermore, you can limit access to the secure folder by creating an .htaccess file in there with:
order deny,allow deny from all allow from 127.0.0.1
-
Ehi Michael,grazieper averlo condiviso.Tuttavia,l'haiprovatoin un ambiente realeper verificare chefunzioni?Penso che la direttiva `open_basedir`prenda unintero * albero *,quindiper accedere a`/root/secure` da `/root/html`,dovrestiimpostare` open_basedir` su `/root`.Hey Michael, thanks for sharing that. Have you tried it out in a real environment to verify it works, though? I think the `open_basedir` directive takes an entire *tree*, so in order to access `/root/secure` from `/root/html`, you'd have to set `open_basedir` to `/root`.
- 0
- 2012-10-03
- Ian Dunn
-
Perfarfunzionare latuaidea,penso che dovrestiimpostare la struttura della directory come `/root/httpdocs/config/access`,dove` httpdocs` contiene log,backup,ecc;`config` contiene` wp-config.php`e `access` contiene WordPresse tuttoil contenuto.Dovrestimodificare la configurazione di vhost,ecc. Per rimappare la radice del documentoin "accessibile".Tuttavia,non vedo alcun vantaggionelnegare semplicemente le richieste HTTP a wp-confignella configurazionepredefinita.In order to make your idea work, I think you'd need to setup the directory structure like `/root/httpdocs/config/accessible`, where `httpdocs` holds logs, backups, etc; `config` holds `wp-config.php`, and `accessible` holds WordPress and all content. You'd have to modify the vhost config, etc to remap the document root to `accessible`. I don't see any benefit over just denying HTTP requests to wp-config in the default setup, though.
- 0
- 2012-10-03
- Ian Dunn
-
Secondo http://www.php.net/manual/en/ini.core.php#ini.open-basedir: "In Windows,separa le directory con unpuntoe virgola. Sututtigli altri sistemi,separa le directory coni duepunti. Comemodulo Apache,i percorsi open_basedir dalle directorypadre vengono oraereditati automaticamente. "Quindipuoiimpostarepiù directory,non ènecessario che sianoin un unico albero.According to http://www.php.net/manual/en/ini.core.php#ini.open-basedir: "Under Windows, separate the directories with a semicolon. On all other systems, separate the directories with a colon. As an Apache module, open_basedir paths from parent directories are now automatically inherited." So you can set multiple directories, no need for them to be in a single tree.
- 1
- 2012-10-03
- Michael
-
L'ho appenaprovatoe sembra chetu abbia ragione.Tuttavia,non sono ancora sicuro del vantaggioper la sicurezza che questo ha sulnegare semplicemente l'accesso alfiletramite Apache.I just tested that out and it looks like you're right. I'm still not sure what security benefit this has over simply denying access to the file via Apache, though.
- 0
- 2012-10-03
- Ian Dunn
-
@IanDunn si è rivoltobene nella risposta di Aaron Adams@IanDunn addressed well in Aaron Adams' answer
- 0
- 2012-12-05
- AndrewC
-
Nontrovo convincente la sua argomentazione.Ho spiegatoperchénelmio commento alla sua risposta.I don't find his argument for that convincing. I've explained why in my comment on his answer.
- 0
- 2012-12-05
- Ian Dunn
-
- 2012-11-19
Ci sonomoltitemi eplugin scrittimale che consentono agli atatcker diiniettare codice (ricordailproblema di sicurezza con Timthumb). Sefossi un attaccante,perché dovrei cercare wp-config.php? Inserisci semplicemente questo codice:
var_dump( DB_NAME, DB_USER, DB_PASSWORD );
Puoiprovare anascondereiltuo wp-config.php. Finché WordPress rendetutte leinformazioni sensibili accessibili a livelloglobale,non ha alcun vantaggio dinascondereilfile wp-config.php.
Lapartenegativa di wp-config.phpnon è che contiene dati sensibili. Lapartenegativa è definirei dati sensibili come una costante accessibileglobale.
<"Aggiorna"
Voglio chiarirei problemi con
define()
e perché è una cattivaidea definirei dati sensibili come una costanteglobale.Esistonomoltimodiper attaccare un sito web. L'iniezione di script è solo unmodoper attaccare un sito web.
Supponendo cheil server abbia una vulnerabilità che consente a un utentemalintenzionato di accedere a un dump dellamemoria. L'attaccantetroverànel dump dellamemoriatuttii valori ditutte le variabili. Se si definisce una costante accessibileglobale,questa deve rimanerein memoriafino altermine dello script. Creando una variabileinvece di una costante,c'è unabuonaprobabilità cheilgarbage collector sovrascriva (o libera) lamemoria dopo che la variabilenon èpiùnecessaria.
Unmodomiglioreperproteggerei dati sensibili èeliminarliimmediatamente dopo averli utilizzati:
$db_con = new stdClass(); $db_con->db_user = 'username'; $db_con->password = 'password'; $db_con->host = 'localhost'; $db_handler = new Database_Handler( $db_con ); $db_con = null;
Dopo aver utilizzatoi dati sensibili,l'assegnazione a
null
sovrascriverài datiin memoria. Un utentemalintenzionato deve ottenereil dump dellamemoriaproprionelmomentoin cui$db_con
contienei dati sensibili. E questo è untempomoltobrevenell'esempio sopra (se la classe Database_Handlernonne salva una copia).There are a lot of bad written themes and plugins out there which allow atatckers to inject code (remember the security issue with Timthumb). If I would be a attacker, why should I search for the wp-config.php? Simply inject this code:
var_dump( DB_NAME, DB_USER, DB_PASSWORD );
You can try to hide your wp-config.php. As long as WordPress make all the sensitive information global accessible, it have no benefit to hide the wp-config.php.
The bad part in wp-config.php is not that it holds sensitive data. The bad part is to define the sensitive data as a global accessible constant.
Update
I want to clearify the problems with
define()
and why it is a bad idea to define sensitive data as a global constant.There are a lot of ways to attack a website. Script injection is only one way to atack a website.
Assuming the server has a vulnerability that let an attacker access a memory dump. The attacker will find in the memory dump all values of all variables. If you define a global accessible constant, it have to stay in memory until the script ended. Creating a variable instead of a constant, there is a good chance that the garbage collector will overwrite (or free) the memory after the variable is not longer needed.
A better way to protect sensitive data is to delete them immediately after using it:
$db_con = new stdClass(); $db_con->db_user = 'username'; $db_con->password = 'password'; $db_con->host = 'localhost'; $db_handler = new Database_Handler( $db_con ); $db_con = null;
After using the sensitive data, the assigning to
null
will overwrite the data in memory. An attacker have to get the memory dump just in the moment when$db_con
contains the sensitive data. And that is a very short time in the example above (if the class Database_Handler do not save a copy of it).-
Questa rispostanon affronta direttamente la domanda.Qualsiasi autore dipluginpuò avere unagiornata campale con WordPress seti convince ainstallareilproprio codicee haintenti dannosi.Non è diverso dall'installare volontariamente un virus sultuo sistema.Questo argomentopernon spostare wp-config.php èinutile.È come dire che l'installazione volontaria di un'autobombanellatua auto rendeinutile l'impostazione dell'antifurto.Tecnicamente veroma WTF?!?This response does not directly address the question. Any plugin author can have a field day with WordPress if they convince you to install their code and have malicious intent. It is no different than willingly installing a virus on your system. This argument to not move wp-config.php is pointless. This is like saying that willfully installing a car bomb in your car makes setting the car alarm useless. Technically true but WTF?!?
- 0
- 2012-12-06
- Lance Cleveland
-
No,non èinutile.La domanda è:possoproteggere l'account del databasenascondendo wp-config.php.E la risposta è chiaramente: No. È come se chiedessi "Possoproteggere lamia auto dalle autobombe con un allarmeper auto?" Non ci sono altri vantagginelnascondereilproprio wp-configperproteggere l'accesso al database o l'accessoftp.Entrambi sononell'ambitoglobale.Sono sicuro che ci sonopiùmodipergli aggressori di ottenere l'accesso alle variabiliglobali senzainiettare codice.No, it is not pointless. The question is: Can I protect the database account by hiding the wp-config.php. And the answer is clearly: No. It is the same as if you ask 'Can I protect my car against car bombs with a car alarm?' There is no other benefit by hiding your wp-config as of protecting database access or ftp access. Both are in the global scope. I'm sure there are more ways for attackers to get access to global vars without injecting code.
- 2
- 2012-12-06
- Ralf912
-
Non vedo "possoproteggere l'account del databasenascondendo wp-config.php"nella domanda originale.La domanda originaleera "ha senso spostareilfile wp-config.php".La risposta è assolutamente sì,IMO.È come chiedere se dovresti chiudere a chiave laporta di casa quandoesci.Dire "qualcunopuòfacilmente rompere unafinestraedentrare comunque,quindiperchépreoccuparsi"non risponde alpuntofondamentale della domanda.IMO,la domandapostaera questa: "Vale lapena lo sforzoextraper spostare wp-config.php? QUALSIASI vantaggionelfarlo?".Sì.Per lomenotiene fuorigli hackerpigri.I don't see "can I protect the database account by hiding the wp-config.php" in the original question. The original question was "does it makes sense to move the wp-config.php". The answer is absolutely yes, IMO. It is like asking if you should lock your front door when you go out. Saying "someone can easily break a window and get in anyway, so why bother" does not answer the fundamental point of the question. IMO the question asked was this, "Is it worth the extra effort to move wp-config.php? ANY benefit doing so?". Yes. At the very least it keeps out the lazy hackers.
- 0
- 2012-12-10
- Lance Cleveland
-
_Una dellemiglioripratiche di sicurezzapiù comuni ..._ Haiperso unpuntomolto (molto,molto)importante: a cosa èinteressato un aggressore?E *non * come hai designatoiltuo wp-config.php.Un attaccante èinteressato ai valori che hai definitoneltuofile wp-config.Prendendoiltuoesempio con laportaprincipale:nascondereiltuo wp-config è lo stesso come se chiudessi laportaprincipale,ma conservituttoiltuo orononprotettoin giardino.Tuttii valori definitiin wp-config sono definiti *globalmente *.Quindi sono *tutti * accessibili al difuori di wp-config.Anche senascondiiltuo wp-config,i valori sono ancorapresenti._One of the most common security best practices..._ You missed a very (very, very) important point: To what an attacker is interested? And it is *not* how do you styled your wp-config.php. An attacker is interessted in the values you defined in your wp-config. Grabbing your example with the front door: Hiding your wp-config is the same as if you will lock your front door, but store all your gold unprotected in the garden. All values defined in the wp-config are *globally* defined. So they are *all* accessible outside of wp-config. Even if you hide your wp-config, the values are still present.
- 2
- 2012-12-11
- Ralf912
-
Penso che coloro che sostengono lo spostamento stiano cercando diproteggersi da scenariin cui wp-config.phppotrebbeessere visualizzatoin testonormaletramite una richiesta HTTP,piuttosto che scenariin cuipotrebbeessereesposto ad altro codice PHPin esecuzione sull'host.I think those that argue in favor of moving it are trying to protect against scenarios where wp-config.php could be displayed in plain text via an HTTP request, rather than scenarios where it could be exposed to other PHP code running on the host.
- 1
- 2012-12-11
- Ian Dunn
-
@ Ralf912 -non èesattamente accurato.Le definizioniglobali sono ACCESSIBILI datuttii file diprogrammain tutte le directorymanon vengono visualizzate.Per VEDEREi valori ènecessarioesserein grado di riscrivereil codicemodificato sul server.Considerando che un server configuratomale con wp-config.phpin doc rootmostreràprontamente quei valori cometestonormale.Questo èilpuntofondamentale.Vedereil codiceper uno qualsiasi deiplugin/temi non causa danni.@Ralf912 - that is not exactly accurate. The global defines are ACCESSIBLE by all program files in all directories but not displayed. In order to SEE the values you would need to be able to write modified code back to the server. Whereas a mis-configured server with wp-config.php in doc root will readily display those values as plain text. That is the underlying point. Seeing the code for any of the plugins/themes causes no harm.
- 0
- 2012-12-12
- Lance Cleveland
-
Un ottimopunto su come `define`globalizza qualunque cosa venga definita.Really good point about how `define` globalizes whatever is being defined.
- 0
- 2014-06-16
- Goldentoa11
-
- 2020-07-21
Mi spiace sbattere un vecchiopost,manonesiste solo una soluzione ovvia atutto questo. Sappiamo che ci sono alcuni vantaggiper la sicurezzanello spostareilfile wp-config.php dalla directory delle rotte di wordpress. Alcuni sostengono chei vantaggi sonominimi,altrino.
D'altro canto,cipossonoessere alcuniinconvenientinello spostareilfile dalla suaposizionepredefinita,come rompere alcuniplugin chenon hannofunzionalitàper cercareilfile wp-config.phpin altreposizioni.
La cosapiù ovviaperme è creare unfile secret-info.php al difuori della directory delle rotte di wordpress che contiene variabilipertuttii tuoinomi utentee password,adesempio
$ userName=& quot; utente & quot ;;
$ databasePassword=& quot; 12345 & quot ;;
Lasciailfile wp-config.phpnella directory di rottapredefinita di wordpress,rimuovii valori dinome utentee password da wp-config.phpma lasciatuttoil resto. Quindifai semplicemente riferimento alla variabile $ userNamee $ databasePassword richiedendo secret-info.phpin wp-config.php,adesempio
<"require('PATH-TO-FILE/secret-info.php');"
Sembra la cosapiù ovvia dafare,mi manca qualcosa qui?
Sorry to bump an old post but is there not just an obvious solution to all this. We know there is some security benefits from moving the wp-config.php file out of the wordpress route directory. Some would argue that the benefits are minimal others would not.
On the flip side there can be some drawbacks to moving the file out of it's default location such as breaking some plugins that do not have functionality to look for the wp-config.php file in other locations.
Most obvious thing to me is to create a secret-info.php file outside of the wordpress route directory which contains variables for all your usernames and passwords i.e.
$userName = "user";
$databasePassword = "12345";
Leave the wp-config.php file in the default wordpress route directory, remove the username and password values from wp-config.php but leave everything else. Then just simply reference the $userName and $databasePassword variable by requiring secret-info.php in wp-config.php i.e.
require('PATH-TO-FILE/secret-info.php');
Seems the obvious thing to do, am I missing something here ?
-
In realtà è davvero unabuona cosa aggiungere una risposta a una vecchia domanda,[c'èpersino unbadgeperessa] (https://wordpress.stackexchange.com/help/badges/44/necromancer).[WPSE vuoleessere un archivio di conoscenza] (https://wordpress.stackexchange.com/tour),piuttosto che unforum.It's actually a really good thing to add an answer to an old question, [there's even a badge for it](https://wordpress.stackexchange.com/help/badges/44/necromancer). [WPSE is meant to be a repository of knowledge](https://wordpress.stackexchange.com/tour), rather than a forum.
- 1
- 2020-07-22
- Ian Dunn
-
- 2012-07-17
Oltre ai vantaggiin termini di sicurezza,ti consente anche dimantenere latuaistanza di WordPress sottoil controllo della versionemantenendoi fileprincipali di WordPress come sottomodulo/esterno.Ecco come Mark Jaquith haimpostatoil suoprogetto WordPress-Skeleton.Vedi https://github.com/markjaquith/WordPress-Skeleton#assumptions peri dettagli.
Apart from the security benefits, it also allows you to keep your WordPress instance under version control while keeping the core WordPress files as a submodule/external. This is how Mark Jaquith has setup his WordPress-Skeleton project. See https://github.com/markjaquith/WordPress-Skeleton#assumptions for details.
-
Lo haimpostatonella root del documento,non al difuori diesso,quindinon è rilevanteper questa domanda.Latecnica su cui è stataposta la domanda specifica che si sposta `wp-config.php` di una directory sopra * la radice del documento di vhost *,non solo una directory sopra la cartella diinstallazione di WordPress.Ilpunto èportarlofuori dalla cartella chepuòessere letta dalle richieste HTTP.He has it setup in the document root, not outside of it, so it's not relevant to this question. The technique that the question asked about specifies that you move `wp-config.php` one directory above *the vhost's document root*, not just one directory above the WordPress installation folder. The whole point is to get it outside of the folder that can be read by HTTP requests.
- 8
- 2012-07-17
- Ian Dunn
Una dellemiglioripratiche di sicurezzapiù comuniin questigiorni sembraessere spostare
wp-config.php
una directorypiù alta della root del documento del vhost . Non homaitrovato unabuona spiegazioneper questo,mapresumo che siaper ridurre alminimoil rischio che uno script dannoso oinfetto all'interno della webroot legga lapassword del database.Tuttavia,devi comunque consentire a WordPress di accedervi,quindi deviespandere
open_basedir
perincludere la directory sopra la root del documento. Questonon vanifica semplicemente l'intero scopoe potenzialmenteespone anchei log del server,i backup,ecc. Agli aggressori?Oppure latecnica sta solo cercando diprevenire una situazionein cui
wp-config.php
verrebbemostrato cometestonormale a chiunque richiedahttp://example.com/wp-config.php
,invece diessere analizzato dalmotore PHP? Sembra uneventomolto raroe non supererebbegli svantaggi dell'esposizione di log/backup/ecc. Alle richieste HTTP.Forse èpossibile spostarlofuori dalla root del documentoin alcune configurazioni di hosting senzaesporre altrifile,manonin altre configurazioni?
Conclusione: Dopo un sacco di avantie indietro su questotema,sonoemerse due risposte che secondome dovrebberoessere considerate autorevoli. Aaron Adams è unbuon argomentoin favore di spostare wp-confige chrisguitarguyfa unbuon causa contro diessa . Queste sono le due risposte che dovresti leggere se seinuovonelthreade non vuoi leggere l'intera cosa. Le altre risposte sono ridondanti oimprecise.