WordPress database error: [Table 'sicksens_wp221.wp_categorymeta' doesn't exist]
SELECT category_id, meta_key, meta_value FROM wp_categorymeta WHERE category_id IN (321) ORDER BY meta_id ASC

Database Protection Archives - Naper Design | Naperville Web Design and SEO

Database Protection

Another Saturday Night in Web Development

How many times must it be said?


I'm 5 cups of coffee past sanity and still have an hour or two before I can sleep.  Recently many of our clients began getting hacked by the children on the Defacement Logging Website that shall remain nameless.  (Quite frankly, I don't want to add ourselves to the hit-list.) They targeted three of our clients sites this past week. Their targeting was very general in nature, and used a few different methods.  Two were injections, and one is still being debated.   The portion that hurts is that one of our clients didn't back up his database. After a forced entry into your website, it is generally considered a good idea to burn the damage.  IE... kill the database and erase data from the server to ensure that back door code has not been left in the site. Tonight, that is not an option.  our client had apparently gone three months without an xml backup, and has misplaced where that copy is located. Instead of the famous 5 Minute Install, or in some cases 5 Minute Reset", we get to go through tons of lines of MySQL database to ensure that we eliminate all code that may have been left.  I will not be a very happy person in the morning, and I'm grateful that it will be Sunday.  Hopefully we get a day off.

Protecting Against SQL Injections

No, this is not a replay of 2002.  SQL Injection is still in an active exploit for hijacking and defacing a database driven website.  While there are several methods and builds of site that can be attacked in this method, we will be confining our feeds to SQL Injections into a Wordpress MySQL database.  Here is the first we will be referencing.  It comes from G4B1DEV and is a good article on ways t protect your PHP and MySQL Database.  In None of these feeds will we reference the "How To" in SQL Injection, but we will be adding regular post on how to protect your website. -Enjoy-

SQL Injection Protection in PHP With PDO

Database abstraction layers like PHP’s Portable Data Objects (PDO) are not a new concept, but a lot of developers don’t seem to realise the security benefit they’re getting for free by using them – inherent protection against SQL injection. SQL injection is the buffer overflow of the web application world – it’s been around forever, and every web application developer should know how to write secure code that’s not vulnerable to it. For those not in the know, SQL injection is a technique whereby a malicious attacker can exploit inadequate data validation to inject arbitrary SQL code into your application’s queries and have it executed as though it is a legitimate query. I won’t go too deeply into SQL injection in this article, but here’s a simple example: The front page of your application has a login form, which is submitted to a PHP script to validate the user’s credentials and allow or deny access to the application. The login form submits two variables by POST as follows: username=fred&password=Fr3dRul3z The POSTed data is then used to build an SQL query to validate the credentials, like this: $sql = “SELECT * FROM users WHERE username = ‘”.$_REQUEST['username'].”‘ AND password = ‘”.$_REQUEST['password'].”‘”; This would result in the SQL query: SELECT * FROM users WHERE username = ‘fred’ AND password = ‘Fr3dRul3z’ Assuming a row exists in the database with these credentials, the user would be allowed to log in. An attacker could easily circumvent this authentication scheme by escaping out of the username field into the SQL query by entering nothing into the password field and this into the username field: ‘ OR 1==1 – The resulting SQL query string would look like this: SELECT * FROM users WHERE username = ‘fred’ OR 1==1 — ‘ AND password = ” Which, as I’m sure you can see, would select all users from the database as the condition 1==1 will always be true. The rest of the query is discarded with the comment operator ‘–’. The way to avoid this kind of attack is to sanitise the data submitted to the form by escaping everything that could be used to escape the confines of the quotes around the fields (e.g. mysql_real_escape_string() if you’re using MySQL). However, in a land far away somebody was inventing database abstraction layers… The primary objective of database abstraction layers like PDO is clean abstraction in your code away from the database platform – so, theoretically, you could switch database platforms from, say, MySQL to PostgreSQL or Oracle with minimal changes to the code. In practice this depends heavily on how much your code relies on platform-specific features like triggers and stored procedures, but if you’re not relying on them at all and you’re just doing simple INSERT/UPDATE/DELETE operations it’s a free ride. Sounds moderately useful, but nothing exciting, right? Right. Another neat feature invented a long time ago is prepared statements, and most database abstraction layers (including PDO) implement this as a way to perform the same query multiple times with different data sets (e.g. inserting a whole bunch of new rows). Now, when building statements with PDO, instead of building the SQL string manually as demonstrated earlier, we build the statement with placeholders like this: $sql = “INSERT INTO fruits (name, price) VALUES (?, ?)”; and then execute the query with a data set passed to the abstraction layer as follows: $sth = $dbh->prepare($sql); $sth->execute(array($fruit, $price)); When the data is handed to PDO like this, it then either passes the data on to the database driver directly, or builds the query internally in a safe manner with any potentially malicious data encoded or escaped. As you can see, this is an easy way around the problem of SQL injection. However, prepared statements with PDO aren’t all puppies and rainbows. Using prepared statements can introduce a number of interesting caveats of which developers should be aware. For example, in the MySQL client API prepared statements can not execute certain types of queries[1] and they do not use the query cache[1][2] which may have an impact on your application’s performance. The inherent security in using prepared statements sounds great, but developers should not let PDO and other abstraction layers/prepared statement implementations lull them into a false sense of security. Untrusted data should always be validated and sanitised, PDO is just another line of defense. It doesn’t cover the territory of a multitude of other input validation vulnerabilities like cross site scripting, but it does do a good job of protecting applications against SQL injection. The best strategy is only allowing known good data by whitelisting characters and matching input data against regular expression patterns, then using prepared statements to catch anything SQL injection-wise that the input validation misses, all in conjunction with a web application firewall like ModSecurity. PDO has been built in to PHP since version 5.1.0, which was released in Nov 2005. Unless you’ve got a good reason for not using it in your PHP apps, you should be – it is a portable replacement for the old mysql_* functions and other platform-specific functions with the added benefit of protection against SQL injection. Author: Loukas Kalenderidis Article Source: EzineArticles.com Provided by: Duty on LCD/Plasma TV