Heartwood

Thanks for the clarification, @hassan . I should have explored the database structure more before replying.

So if the nicename is simply the slug, i.e. a URL-friendly version of the name (currently the username), and it’s not editable without a plugin, then could it be that the original idea was to make the required Nickname be the place where you set the slug/nicename, but somehow the developers lost track of that somewhere along the way?

If the core team did get (back?) on track with a proper purpose for the Nickname (beyond giving the Display Name drop-down menu another option), it would solve the security issue without needing a plugin fix.

It would also make more sense to include the Nickname field in the registration process if it’s going to be required, because users don’t always go to their profile page to edit it after the fact.

I certainly hope the core team has got something in the works.
??

@hassan, your explanation to @pha3z is great — but I’m afraid your correction needs a correction. ??

There are 5 fields under the heading ‘Name’ in the user’s profile settings page (wp-admin/profile.php) :

• Username (cannot be changed)
• First Name
• Last Name
• Nickname (required)
• Display name publicly as (dropdown menu of all of the above)

Usernames are chosen at registration and cannot be changed except directly in the database. They’re used for logging in, so should never be revealed publicly, for security reasons.

The Nickname, being required, is by default set to the Username, since registration only provides two fields: username and email. The registered user CAN indeed change the Nickname by logging in and going to the Users > Your Profile page (wp-admin/profile.php). — Or the admin can do it for them by going to the Users page (wp-admin/users.php) and clicking the Edit link under the user’s name in the list of users.

That’s also where you can set the Display name. It, too, is filled in by default with the Username, but should be changed.

It would be best if WordPress core code created the author URL with the Display name if available, or the Nickname as a second choice, and only fell back on the Username if nothing else was set. But unfortunately, that’s not what’s happening as of the current version (3.5.1). It uses the Username for the URL, even though you’d think having the Nickname be a required field would mean that that’s what it would use. Well, it doesn’t. That’s why this plugin is useful.

What the plugin uses is the Display name. Which is perfect, because the Display name can be set to any of the other names, including the real name if you wish, or the Nickname if you prefer, which is useful if you don’t want to use the Username for security reasons AND you don’t want to use your real name for privacy reasons.

I’m not sure whether the “nicename” is supposed to be the Nickname or the Display name, but either way, the author URL isn’t using either without this plugin (or something similar).

??

I found the problem: the latest version of the Block Bad Queries plugin was interfering. I deactivated it long enough to save the theme option settings, then reactivated it.

Since John at EthicalHost has updated the configserver scanner, I’ve been able to update Bulletproof to v.0.47.5 without a problem, and no longer have any 404 (not-found) errors. (Thanks, John!)

Thanks for your patience with this. I’ll get in touch with my web host.

Aaaargh! I re-downloaded it to check that it was still intact, and now it doesn’t have the WordPress code in it. I’m not getting the 404 errors but the Hotlink Protection has enabled itself again and is again showing the

(%0A|%0D|%27|%3C|%3E|%00)
\.opendirviewer\.
users\.skynet\.be.*

code
???

… and then I got the 404 errors again. So I’ve put back the one with the WordPress code at the top, and it all seems to be working again.

Does that give you any clues?

No, the WordPress code was the basic code I used to get the .htaccess file to stop disappearing, and I just didn’t remove it. It didn’t get added automatically. I’ve removed it now, and re-uploaded the two files.

I didn’t think I had enabled Hotlink Protection throughout that whole process, but sure enough it said it was enabled:

URLs to allow access:

(%0A|%0D|%27|%3C|%3E|%00)
\.opendirviewer\.
users\.skynet\.be.*

Block direct access for these extensions (separate by commas):
.*

I clicked the Disable button and now it’s back to what it had been when I originally checked (which I did for the first time in response to your mention of it in your first post to this thread). So now it just has the list of the site’s domain names as URLs, and the list of extensions in the second box are now back to saying
jpg,jpeg,gif,png,bmp
but says it’s disabled.

Do you mean try to put the original secure.htaccess back first? That’s what kept disappearing and I had to edit it to make it stop doing that.

The downloaded root .htaccess was missing most of the code I thought I’d managed to put back in. I replaced it first with the version on my computer that I had thought was working:

# BEGIN WordPress

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

</IfModule>

# END WordPress

#   BULLETPROOF .47.5 >>>>>>> SECURE .HTACCESS

# If you edit the  BULLETPROOF .47.5 >>>>>>> SECURE .HTACCESS text above

# you will see error messages on the BPS Security Status page

# BPS is reading the version number in the htaccess file to validate checks

# If you would like to change what is displayed above you

# will need to edit the BPS /includes/functions.php file to match your changes

# If you update your WordPress Permalinks the code between BEGIN WordPress and

# END WordPress is replaced by WP htaccess code.

# This removes all of the BPS security code and replaces it with just the default WP htaccess code

# To restore this file use BPS Restore or activate BulletProof Mode for your Root folder again.

# BEGIN WordPress

# IMPORTANT!!! DO NOT DELETE!!! - BEGIN WordPress above or END WordPress - text in this file

# They are reference points for WP, BPS and other plugins to write to this htaccess file.

# IMPORTANT!!! DO NOT DELETE!!! - BPSQSE BPS QUERY STRING EXPLOITS - text

# BPS needs to find the - BPSQSE - text string in this file to validate that your security filters exist

# TURN OFF YOUR SERVER SIGNATURE

ServerSignature Off

# ADD A PHP HANDLER

# If you are using a PHP Handler add your web hosts PHP Handler below

# DO NOT SHOW DIRECTORY LISTING

# If you are getting 500 Errors when activating BPS then comment out Options -Indexes 

# by adding a # sign in front of it. If there is a typo anywhere in this file you will also see 500 errors.

Options -Indexes

# DIRECTORY INDEX FORCE INDEX.PHP

# Use index.php as default directory index file

# index.html will be ignored will not load.

DirectoryIndex index.php index.html /index.php

# BPS PRO ERROR LOGGING AND TRACKING - Available in BPS Pro only

# BPS Pro has premade 403 Forbidden, 400 Bad Request and 404 Not Found files that are used 

# to track and log 403, 400 and 404 errors that occur on your website. When a hacker attempts to

# hack your website the hackers IP address, Host name, Request Method, Referering link, the file name or

# requested resource, the user agent of the hacker and the query string used in the hack attempt are logged.

# BPS Pro Log files are added to the P-Security All Purpose File Manager to view them.

# All BPS Pro log files are htaccess protected so that only you can view them. 

# The 400.php, 403.php and 404.php files are located in /wp-content/plugins/bulletproof-security/

# The 400 and 403 Error logging files are already set up and will automatically start logging errors

# after you install BPS Pro and have activated BulletProof Mode for your Root folder.

# If you would like to log 404 errors you will need to copy the logging code in the BPS Pro 404.php file

# to your Theme's 404.php template file. Simple instructions are included in the BPS Pro 404.php file.

# You can open the BPS Pro 404.php file using the WP Plugins Editor or by using the BPS Pro File Manager.

# NOTE: By default WordPress automatically looks in your Theme's folder for a 404.php template file.

# ErrorDocument 400 /wp-content/plugins/bulletproof-security/400.php

# ErrorDocument 403 /wp-content/plugins/bulletproof-security/403.php

ErrorDocument 404 /404.php

# DENY ACCESS TO PROTECTED SERVER FILES - .htaccess, .htpasswd and all file names starting with dot
RedirectMatch 403 /\..*$

RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# PLUGINS AND VARIOUS EXPLOIT FILTER SKIP RULES
# IMPORTANT!!! If you add or remove a skip rule you must change S= to the new skip number
# Example: If RewriteRule S=5 is deleted than change S=6 to S=5, S=7 to S=6, etc.

# Adminer MySQL management tool data populate
RewriteCond %{REQUEST_URI} ^/wp-content/plugins/adminer/ [NC]
RewriteRule . - [S=12]
# Comment Spam Pack MU Plugin - CAPTCHA images not displaying
RewriteCond %{REQUEST_URI} ^/wp-content/mu-plugins/custom-anti-spam/ [NC]
RewriteRule . - [S=11]
# Peters Custom Anti-Spam display CAPTCHA Image
RewriteCond %{REQUEST_URI} ^/wp-content/plugins/peters-custom-anti-spam-image/ [NC]
RewriteRule . - [S=10]
# Status Updater plugin fb connect
RewriteCond %{REQUEST_URI} ^/wp-content/plugins/fb-status-updater/ [NC]
RewriteRule . - [S=9]
# Stream Video Player - Adding FLV Videos Blocked
RewriteCond %{REQUEST_URI} ^/wp-content/plugins/stream-video-player/ [NC]
RewriteRule . - [S=8]
# XCloner 404 or 403 error when updating settings
RewriteCond %{REQUEST_URI} ^/wp-content/plugins/xcloner-backup-and-restore/ [NC]
RewriteRule . - [S=7]
# BuddyPress Logout Redirect
RewriteCond %{QUERY_STRING} action=logout&redirect_to=http%3A%2F%2F(.*) [NC]
RewriteRule . - [S=6]
# redirect_to=
RewriteCond %{QUERY_STRING} redirect_to=(.*) [NC]
RewriteRule . - [S=5]
# Login Plugins Password Reset And Redirect 1
RewriteCond %{QUERY_STRING} action=resetpass&key=(.*) [NC]
RewriteRule . - [S=4]
# Login Plugins Password Reset And Redirect 2
RewriteCond %{QUERY_STRING} action=rp&key=(.*) [NC]
RewriteRule . - [S=3]

# TIMTHUMB FORBID RFI and MISC FILE SKIP/BYPASS RULE
# Only Allow Internal File Requests From Your Website
# To Allow Additional Websites Access to a File Use [OR] as shown below.
# RewriteCond %{HTTP_REFERER} ^.*YourWebsite.com.* [OR]
# RewriteCond %{HTTP_REFERER} ^.*AnotherWebsite.com.*
RewriteCond %{QUERY_STRING} ^.*(http|https|ftp)(%3A|:)(%2F|/)(%2F|/)(w){0,3}.?(blogger|picasa|blogspot|tsunami|petapolitik|photobucket|imgur|imageshack|wordpress\.com|img\.youtube|tinypic\.com|upload\.wikimedia|kkc|start-thegame).*$ [NC,OR]
RewriteCond %{THE_REQUEST} ^.*(http|https|ftp)(%3A|:)(%2F|/)(%2F|/)(w){0,3}.?(blogger|picasa|blogspot|tsunami|petapolitik|photobucket|imgur|imageshack|wordpress\.com|img\.youtube|tinypic\.com|upload\.wikimedia|kkc|start-thegame).*$ [NC]
RewriteRule .* index.php [F,L]
RewriteCond %{REQUEST_URI} (timthumb\.php|phpthumb\.php|thumb\.php|thumbs\.php) [NC]
#RewriteCond %{HTTP_REFERER} ^.*demo5.local.*
RewriteRule . - [S=1]

# BPSQSE BPS QUERY STRING EXPLOITS
# The libwww-perl User Agent is forbidden - Many bad bots use libwww-perl modules, but some good bots use it too.
# Good sites such as W3C use it for their W3C-LinkChecker.
# Add or remove user agents temporarily or permanently from the first User Agent filter below.
# If you want a list of bad bots / User Agents to block then scroll to the end of this file.
RewriteCond %{HTTP_USER_AGENT} (havij|libwww-perl|wget|python|nikto|curl|scan|java|winhttp|clshttp|loader) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (;|<|>|'|"|\)|\(|%0A|%0D|%22|%27|%28|%3C|%3E|%00).*(libwww-perl|wget|python|nikto|curl|scan|java|winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]
RewriteCond %{THE_REQUEST} \?\ HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} \/\*\ HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} etc/passwd [NC,OR]
RewriteCond %{THE_REQUEST} cgi-bin [NC,OR]
RewriteCond %{THE_REQUEST} (%0A|%0D|\\r|\\n) [NC,OR]
RewriteCond %{REQUEST_URI} owssvr\.dll [NC,OR]
RewriteCond %{HTTP_REFERER} (%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_REFERER} \.opendirviewer\. [NC,OR]
RewriteCond %{HTTP_REFERER} users\.skynet\.be.* [NC,OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=https:// [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC,OR]
RewriteCond %{QUERY_STRING} \=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC,OR]
RewriteCond %{QUERY_STRING} (\.\./|\.\.) [OR]
RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
RewriteCond %{QUERY_STRING} http\: [NC,OR]
RewriteCond %{QUERY_STRING} https\: [NC,OR]
RewriteCond %{QUERY_STRING} \=\|w\| [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)cPath=https://(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*embed.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^e]*e)+mbed.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*object.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^o]*o)+bject.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^i]*i)+frame.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} base64_(en|de)code[^(]*\([^)]*\) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|%3c|%3e|%5b|%5d).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\x00|\x04|\x08|\x0d|\x1b|\x20|\x3c|\x3e|\x5b|\x5d|\x7f).* [NC,OR]
RewriteCond %{QUERY_STRING} (NULL|OUTFILE|LOAD_FILE) [OR]
RewriteCond %{QUERY_STRING} (\./|\../|\.../)+(motd|etc|bin) [NC,OR]
RewriteCond %{QUERY_STRING} (localhost|loopback|127\.0\.0\.1) [NC,OR]
RewriteCond %{QUERY_STRING} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{QUERY_STRING} concat[^\(]*\( [NC,OR]
RewriteCond %{QUERY_STRING} union([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} union([^a]*a)+ll([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} \-[sdcr].*(allow_url_include|allow_url_fopen|safe_mode|disable_functions|auto_prepend_file) [NC,OR]
RewriteCond %{QUERY_STRING} (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC,OR]
RewriteCond %{QUERY_STRING} (sp_executesql) [NC]
RewriteRule ^(.*)$ - [F,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# DENY BROWSER ACCESS TO THESE FILES
# wp-config.php, bb-config.php, php.ini, php5.ini, readme.html
# Replace Allow from 88.77.66.55 with your current IP address and remove the
# pound sign # from in front of the Allow from line of code below to access these
# files directly from your browser.

<FilesMatch "^(wp-config\.php|php\.ini|php5\.ini|readme\.html|bb-config\.php)">
Order allow,deny
Deny from all
#Allow from 88.77.66.55
</FilesMatch>

# IMPORTANT!!! DO NOT DELETE!!! the END WordPress text below
# END WordPress

The secure.htaccess was also incomplete, so I replaced that first too.

Then I followed your instructions. At step 4, the secure.htaccess was back to the original version rather than what I thought I had just uploaded — it had the FORBID EMPTY REFFERER SPAMBOTS and REQUEST METHODS FILTERED code back in it. However, I followed your directions exactly, and copy-pasted it into the downloaded root .htaccess and re-uploaded that, overwriting the one that was on the server. I changed the permissions to 644. The file immediately disappeared and the 404 errors were back.

I’ve re-uploaded the file that has the above code, both in the root as .htaccess with 604 permissions, and in the BPS admin/htaccess folder as secure.htaccess with 644 permissions, and all is working again.

[Moderator Note: Please use the pastebin for large blocks of code. 250 lines of .htaccess directives is just a little excessive.]

I just got some alerts from the WordPress Firewall 2 plugin, concerning my edits of the .htaccess files, so maybe that’s where some of the problems are from when trying to save the edits. I’ll have to remember to disable the firewall temporarily next time.

Okay, I got the 404 errors to disappear by also removing this part of the code:

# FORBID EMPTY REFFERER SPAMBOTS
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} (wp-comments-post\.php)
#RewriteCond %{HTTP_REFERER} !^.*demo5.local.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule .* - [F]

Web host is EthicalHost.ca
Server API is CGI
Attempting to change permissions to 404 resulted in them being changed to 604 (server override).

Locking the root .htaccess within BPS after editing resulted in some of the code disappearing — not the end of the code being truncated, but all the code for PLUGINS AND VARIOUS EXPLOIT FILTER SKIP RULES, TIMTHUMB FORBID RFI and MISC FILE SKIP/BYPASS RULE, and BPSQSE BPS QUERY STRING EXPLOITS. I’d already removed FORBID EMPTY REFFERER SPAMBOTS and REQUEST METHODS FILTERED.

I’ve left it “unlocked” in BPS, with permissions set to 604.

Clicking the Update File button sent me to
[website URL]/#bps-tabs-5
instead of
[website URL]/wp-admin/admin.php?page=bulletproof-security/admin/options.php#bps-tabs-5
but using the browser’s Back button enabled me to get back to the BPS tabs.

I spoke too soon — getting 404 errors for all but the homepage. But at least the .htaccess files are staying put…

I ran into the same problem — the root .htaccess and secure.htaccess files both disappearing and being “not found or nor re-writable” by BPS. Neither were they visible in Filezilla and Cpanel but NOT because of being hidden files: the wp-admin folder’s .htaccess file was visible.

I uploaded a basic .htaccess file to the root and duplicated it as secure.htaccess in the BPS admin/htaccess directory, and then painstakingly copied over each portion of the code, one at a time, to see which part was making it break. This is the only one that triggered the problem:

# REQUEST METHODS FILTERED
# This filter is for blocking junk bots and spam bots from making a HEAD request, but may also block some
# HEAD request from bots that you want to allow in certains cases. This is not a security filter and is just
# a nuisance filter. This filter will not block any important bots like the google bot. If you want to allow
# all bots to make a HEAD request then remove HEAD from the Request Method filter.
# The TRACE, DELETE, TRACK and DEBUG request methods should never be allowed against your website.
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK|DEBUG) [NC]
RewriteRule ^(.*)$ - [F,L]

So I removed that part of the code and it works fine again. Hope this helps figure out why, and how to accomplish the intended goal in some other way that’s not as problematic.
??

I imagine the disregard for breaking older themes is probably related to the idea that all themes in the repository are required to be kept current with any core upgrades. I imagine all themes in there now are able to accommodate the admin bar, or they wouldn’t still be in the repository. When the admin bar was added and needed a spatial spot left open for it, I imagine the themes that didn’t already have the body code in a wrapper div had to have one added to keep the theme in the repository.

Premium themes, which are not in the repository in the first place, would tend to be updated as well (at least for a few years after release), since you can’t very well sell something that’s not going to keep pace with what it’s meant to be used for.

If you wanted to use a theme that’s no longer in the repository, the way to fix it to accommodate the admin bar would be to add a <div> tag right after the <body> tag (in the theme’s header.php file), and a </div> tag right before <?php wp_footer(); ?>, which in turn is right before the </body> tag (in the theme’s footer.php file). Putting everything but the admin bar into a wrapper div allows the added top-margin to push everything down while still keeping the same spatial relationships between the elements inside it, because for anything with an absolute positioning, it’s absolute in relation to its containing element rather than in relation to the body.