Well about the Security Requests... I have been trying to promote this idea/change since almost 2 years[1] but even if we change the perspective of the problem this change isn't going to happen... even that exist a variation of the version enumeration[2] (introduced in milestone 2.6) that makes every plugin-based solution totally ineffective (example[3]).
As for user enumeration on login, well you can still hide that messages truth the login_errors filter but you can still enumerate users via /author/<username>, which also can prevented by changing (directly in the BD) the user_nicename to something different to the user_login. As and example: i have my own personal/private plugin which contains all this changes (plus one more), you can view it here[4], as you can see is fairly simple what the plugin does, just as remind about the version hidden: its changed only inside the admin panel so in order to fully work you would need to first change the version number on wp-includes/version.php to something different to real version. However i must notice that this modifications won't enhance your wordpress-based site security, they would make just the exploitation of _critical_ vulnerability more hard (but just a little), a good cracker can still be very dangerous even if you hide your version and other sensitive information, so the best advice is always keep up to date your WordPress based-site. Regards [1] http://trac.wordpress.org/ticket/4155 [2] http://trac.wordpress.org/ticket/7545 [3] http://activeblogging.com/wp-admin/gears-manifest.php [4] http://paste.ideaslabs.com/show/xgJhcf4a0g 2008/12/1 Jacob Santos <[EMAIL PROTECTED]>: > See reply below previous messages. > > Admin wrote: >> >> Hi - I'm sorry I'm a bit late to this list, but I encountered some bugs >> (w/fixes) in the code - hope it's not too late to add them. As well, I had >> some security requests: >> >> Bugfix: >> ------- >> "Warning: Cannot modify header information - headers already sent by..." >> >> Caused on windows/apache install, when starting with no wp-config.php file >> - auto-creating it adds spaces at end, which gives this message (first >> visible during the install pages). The fix is to change this line >> 158@/wp-admin/setup-config.php to add +b for binary: >> >> $handle = fopen('../wp-config.php', 'w+b'); >> >> this prevents the function from defaulting to text format, and inserting >> the extra lines (tested) > > I don't think writing text is binary, but okay. It isn't about that, as it > is about the new line character. I've been using the > wp-admin/setup-config.php and not once has it created an extra newline where > it shouldn't. Would be nice to do it, if it works and fixes the problem. > >> Security Request: >> ----------------- >> Remove the generator meta display in themes when called by wp_head(), >> which is the hook set at line 173@/wp-includes/default-filters.php: >> >> add_action('wp_head', 'wp_generator'); >> >> Although it can be removed in the theme or via plugin (I did a blog post >> at >> http://activeblogging.com/info/wordpress-security-version-numbers-and-themes/ >> explaining how), broadcasting the version by default seems a bad idea - an >> easy way for a spam program to patrol for older installs (or zero day >> exploits). > > Like you said, you can already remove it. That was the reason it was added > as to the filter as opposed to being hard coded. Well, one of the reasons. > >> Request: >> -------- >> Add non-indexing code to the login page to keep it out of indexes - it >> doesn't help search results, and exposes details of the site to casual >> viewers. To solve, you can insert this around about line [EMAIL PROTECTED]: >> >> <meta name='robots' content='noindex,nofollow' /> > > Well, you could probably do this using a plugin as well. Also you can add it > to the robots.txt file for good measure. > >> >> Security Request: >> ----------------- >> While a bit more involved, the security for the login page reveals a lot >> of information - if I enter a correct user name but bad password, it tells >> me; if I enter an invalid user name, it tells me. It might be a good idea to >> replace the specific messages with generic ones - eg "error: incorrect >> password or invalid username." This makes fishing for information less >> useful (for example, guessing user names and checking the message to see if >> they exist). The error strings involved all have ">ERROR<" in them, in >> wp-login.php > > This horse as already been beaten to death, risen from the dead and then set > on fire to prevent the zombie from coming back. The reason for it (from what > I can remember from past discussions) are 1) security through obscurity > usually isn't and 2) It is very helpful when you've forgotten both your > username and password and don't have immediate or any access to the database > tables. > >> >> >> Misc: >> ----- >> While fixing the generator metatag issue, I read the documentation at >> http://codex.wordpress.org/Function_Reference/remove_action that: >> >> "To remove a hook, the $function_to_remove and $priority arguments must >> match when the hook was added...No warning will be given on removal >> failure." >> >> While not a problem in my case, it means that if later on you change the >> priority of an action added, other code with remove actions will fail >> silently (unless they are updated to the same priority). This could be an >> unnecessary maintenance issue in the future. Perhaps a function could be >> exposed allowing ALL occurrences of the action function, regardless of >> priority, to be removed. I'd be happy to submit one if no one has time to >> write it. > > It is never going to change. You have no need to worry. > > Jacob Santos > > _______________________________________________ > wp-testers mailing list > [email protected] > http://lists.automattic.com/mailman/listinfo/wp-testers > -- _________________________ g30rg3_x _______________________________________________ wp-testers mailing list [email protected] http://lists.automattic.com/mailman/listinfo/wp-testers
