Vulnerability # 1: SQL Injection & URL Hacking.
The problem: WordPress is a database-backed platform that executes server-side scripts in PHP. Both of these characteristic can make WordPress vulnerable to malicious URL insertion attacks. Commands are sent to WordPress via URL parameters, which can be abused by hackers who know how to construct parameters that WordPress may misinterpret or act on without authorization.
SQL injection describes a class of these attacks in which hackers embed commands in a URL that trigger behaviors from the database. (SQL is the command language used by the MySQL database.) These attacks can reveal sensitive information about the database, potentially giving hackers entrance to modifying the actual content of your site. Many of today’s web site defacement attacks are accomplished by some form of SQL Injection.
Other versions of URL hacks can trigger unintended PHP commands which, again, can lead to injecting malware or revealing sensitive information.
The defense: Most WordPress installations are hosted on the popular Apache web server. Apache uses a file named .htaccess to define the access rules for your web site. A thorough set of rules can prevent many types of SQL Injection and URL hacks from being interpreted.
The code below represents a strong set of rules that you can insert into your web site’s .htaccess file that will strip URL requests of many dangerous attack injections:
[php]<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]
RewriteRule ^(.*)$ – [F,L]
RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} tag\= [NC,OR]
RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
RewriteCond %{QUERY_STRING} http\: [NC,OR]
RewriteCond %{QUERY_STRING} https\: [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|ê|"|;|\?|\*|=$).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*("|'|<|>|\|{||Wink.* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare).* [NC]
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteRule ^(.*)$ – [F,L]
</IfModule>
[/php]
Vulnerability # 2: Access to Sensitive Files.
The problem: A typical WordPress install contains a number of files which you don’t want outsiders to access. These files, such as the WordPress configuration file, install script, and even the “readme” file should be kept private.
The defense: As with preventing URL hacking, you can add commands to the Apache .htaccess file to block access to sensitive private files. For a typical WordPress installation, the following code will block access to directory listings, plus a set of specific files related to WordPress and the Web server itself.
[php]
Options All -Indexes
<files .htaccess>
Order allow,deny
Deny from all
</files>
<files readme.html>
Order allow,deny
Deny from all
</files>
<files license.txt>
Order allow,deny
Deny from all
</files>
<files install.php>
Order allow,deny
Deny from all
</files>
<files wp-config.php>
Order allow,deny
Deny from all
</files>
<files error_log>
Order allow,deny
Deny from all
</files>
<files fantastico_fileslist.txt>
Order allow,deny
Deny from all
</files>
<files fantversion.php>
Order allow,deny
Deny from all
</files>[/php]
Vulnerability # 3: Default Admin User Account.
The problem: Many default WordPress installs include an administrator user account whose username is simply “admin”. Hackers may try to log into this account using guessed passwords.
The defense: Any element of predictability gives hackers an edge. Although a hacker would still need to guess or brute-force your password to access the admin account, you are even more secure without an “admin” account at all.
Instead, log into WordPress and create a new user with an unpredictable name. Assign administrator privileges to this user. Now delete the account named “admin”. A hacker would now need to guess both the username and password to gain administrator access, a significantly more challenging feat.
Credits to Esecurity Planet
