Hi, I notice that WP's install system is such that the place in which it is installed is also where the website itself is run! Has this not been obvious to the developers of WP now that we're on version 2.3.3? Just permalinking doesn't help, because permalinks run from the "/wp/" directory too! What is a workaround for this? Is there a plugin or this? Many thanks
WP security: masking WP's existence (16 posts)
-
erick_paper
Posted 4 years ago # -
Err... what? I fail to understand what you're talking about or what the security problem you're claiming to see is.
Security is not based on hiding things. Hidden stuff is insecure.
-
Posted 4 years ago #I think masking stuff is a VERY critical step in security. Of course, that shouldn't be all.
With Movable Type or Expression Engine, I can have the software installed here:
http://domain.com/mt/mt.cgi
http://domain.com/ee/index.phpBut my blog can be anywhere. E.g.,
http://domain.com
http://domain.com/blog/Etc. With WP, it seems everything I do, the blog runs from the same place WP itself is installed!
WP install:
http://domain.com/wp/wp-admin/WP blog:
http://domain.com/wp/ !! -
Jeremy Clark
Posted 4 years ago #You can do that.
http://codex.wordpress.org/Giving_WordPress_Its_Own_Directory -
It's a wise thing to read the documentation first... (I mean before making false statements).
Giving_WordPress_Its_Own_Directory
WP install in example.com/subdir
blog display = example.com -
Well, as they pointed out, you can indeed do what you want to do.
However, I would argue that this is not any sort of security measure in any way, because the information about where the program is actually installed can be determined from the outside.
Note that this is also the case for both Movable Type and Expression Engine. Putting the blog elsewhere than the administration is not a form of security in any sense.
Contrary to popular understanding, security is not about layers. It's not a series of steps. Either the system is secure or it is not. If they can get through the hardest layer, then adding less-difficult layers to get through does not increase security one iota. Your total security is only as strong as the strongest point of that security. Negligible security levels are just that: negligible.
-
Posted 4 years ago #I agree with Otto, all this does really is make your root directory cleaner.
As far as security goes, the biggest issue isn't with wordpress but with poorly configured servers, and a$$hats of server admins. You can do all you want to the way wordpress works but in the end of the day you've left the directory world writable then that's just poor admining.
-
Posted 4 years ago #Thanks. Yes I did read that page, but it doesn't work. As per the instructions, I wanted to move my http://domain.com/wp/ to the following:
WP INSTALL: http://domain.com/cms
BLOG: http://domain.com/vaultSo I made these changes in the Options, and then saved them. This came back with a 404, because the "wp" directory is not "cms" yet. So I quickly changed the folder name of "wp" to the new "cms", as per step 6 in that instruction list.
I still see a 404 at http://domain.com/cms/wp-admin. Any thoughts?
(I don't mean to denigrate WP in comparison to others, but something like this should be basic functionality and REALLY not require the manual copying of files and editing a line in index.php!)
-
I still see a 404 at http://domain.com/cms/wp-admin. Any thoughts?
If you actually have the wp-admin directory at /cms/wp-admin/ and still get a 404, then that's a problem with your webserver. Nothing to do with WordPress.
(I don't mean to denigrate WP in comparison to others, but something like this should be basic functionality and REALLY not require the manual copying of files and editing a line in index.php!)
What do you expect it to do? I mean, the files must be in the locations where you're putting them for that sort of thing to work. Some manual intervention would always be required, because that's how webservers actually work. WordPress is not a webserver, it has no control over that sort of thing.
-
Posted 4 years ago #MT and EE allow me to setup paths with zero manual labor. It's the way an application is designed.
If copying a file to a location and modifying a line in it is required, then it surely does not need manual intervention. Many WP plugins themselves do this all the time.
Anyway, yes the file exists. I can see the wp-admin now but the http://domain.com/vault still does not work. I have changed the permalinks to reflect the vault etc. What else should I check for errors? There is no "error_log" file being generated.
Thanks for any pointers!
-
MT and EE allow me to setup paths with zero manual labor. It's the way an application is designed.
No, they don't. At most, MT and EE can allow you to adjust paths inside their own directory. But if I have MT setup at http://example.com/mt/directory, then it absolutely cannot pretend to be http://example.com/vault without me doing some manual intervention to make it work.
On a side note, it's entirely possible to make WP do the same thing here. A minor bit of screwing around with the Permalinks settings can create "pretend" directory paths underneath the WordPress root directory. But only underneath the existing directory, you can't move up in the path without actually *being* up further in the path.
In other words, if you had installed WP at the root directory to begin with, then making it pretend to be in /vault would be just a minor matter, entirely doable without moving files around. But since you installed it in /wp to begin with, everything must have /wp in front of it. See?
If copying a file to a location and modifying a line in it is required, then it surely does not need manual intervention. Many WP plugins themselves do this all the time.
Of course it does. Why in the world would you want the main web directory to be writable by the web application itself? That's a giant gaping security problem if I've ever seen one.
Okay, so yes, WordPress does write to the .htaccess file when Permalinks are changed. However, it always writes the same thing, and really is expecting to not be able to do it, because it will give you the text to put into .htaccess manually as well.
Anyway, yes the file exists. I can see the wp-admin now but the http://domain.com/vault still does not work. I have changed the permalinks to reflect the vault etc. What else should I check for errors? There is no "error_log" file being generated.
Does the /vault directory exist? Did you put the WordPress root directory files into there as explained on the codex page given above?
-
Posted 4 years ago #Thanks for the tip about creating the vault directory. But since WP does not generate any actual content, why is it essential to have a physical folder called "vault"? I checked the mod_rewrite rules and they seem to be pointing just fine (vault --> /cms/..).
The Codex instructions never mention creating index.php for the "blog URL" (vault in my case), only for the "wordpress URL" (cms in my case). Am I missing something? Again, why does WP need a physical vault folder?
As for MT, yes the MT install would remain in /cms/ for example, but my actual generated files have nothing to do with that folder. I can have MT create html/php files into pretty much any place in my system, and this value is entered in the MT web interface. Which was superlative, but that's besides the point here.
-
Posted 4 years ago #Ok, sorry I stand corrected. I did follow the step 7 of the instructions. I have the vault folder and I have the index.php as follows:
<?php
/* Short and sweet */
define('WP_USE_THEMES', true);
require('./cms/wp-blog-header.php');
?>The Codex is for putting the "blog directory" in the root, so that dot in front of cms makes sense. In my case, I'm in a vault directory, so I made that two dots, and it works now.
I still think this need not be manual at all, it's a simple mod_rewrite issue for those who have it enabled (and most of us do these days, to use permalinks).
Ideally, the design of a CMS should make sure that the CMS itself is separated from the content. Easy for MT to do as it generates physical HTML files. WP should have a nicer way of doing it without having manual index.phps in physical folders.
Thx a bunch for your help.
-
Ideally, the design of a CMS should make sure that the CMS itself is separated from the content.
Meh.. I don't really see that as being entirely necessary. And anyway, the "content" of importance is really in the database. The "CMS" in this case would be the PHP files. Fully separated. The webpage you actually see is only the output of the two.
-
Posted 4 years ago #Well, this is why a number of WP installs get hacked. Because script kiddies can easily find out where the wp-admin is, and then use the Admin account. I see the WP community dismissing this as "not WP's fault, stupidity of blog owner" but both EE and MT give me huge messages in red suggesting that I should change these simple things.
You're right. In WP's case, the content is in the DB. Which makes separation of the path much simpler (mod_rewrite rules only).
Anyway, with whatever kludge is advocated by the WP codex, my site is working. (Until I get to running several blogs, but I can live with that).
Thanks.
-
Because script kiddies can easily find out where the wp-admin is, and then use the Admin account.
Huh? That has nothing to do with how sites get hacked. Knowing where wp-admin is helps you not in the slightest.
Topic Closed
This topic has been closed to new replies.
