Security with Dreamweaver and PHP/MySQL

Report · Dec 08, 2009

Having recently been the victim of a SQL injection attack on one of my web sites I thought it might be useful to list what I did to find out what was happening and, hopefully, stop it happening in the future. This link by Steven Whitney was invaluable to me: [Moderator's note: link removed because it was reported as displaying a bogus security message.]

1. Make sure that you have updated all recordsets to the latest (CS4) version. Older ones created before the GetSQLValueString function was introduced are vulnerable. It is particularly important to look for recordsets that you may have customised (so they no longer show up in the Bindings panel).

2. Don't use the same name for form fields and table fields - it can give hackers a clue to the underlying structure of your database. Especially important on login pages.

3. On your production server, don't have error reporting set at too verbose a level (either MySQL or PHP). Same reason as above.

4. Disable PHP functions that you don't need. For example, in my php.ini I now have:

disable_functions = "show_source, system, shell_exec, passthru, exec, popen, proc_open, allow_url_fopen, eval, parse_ini_file, dl, ini_set"

I also set allow_url_fopen = Off and allow_url_include = Off

5. Use strong passwords, don't store them in plain text or in a field called password, and hash them (with something like sha() or hash().

6. Consider restricting the display/updating of sensitive data (e.g. user names and passwords) by IP (i.e. only let your IP have access to those pages).

7. Consider coding your login page to email you, not only on unsuccessful logins, but also on successful ones, and put the IP address of the remote computer in the email (helps when you have to search your server logs).

8. Make sure you keep your server logs for at least a month (most rotate daily by default, which is usually not long enough to find an attack attempt).

9. Use .htaccess to discard suspicious query strings (useful against Remote File Inclusion - RFI - attacks). At least discard anything with http:// in the query string. Link at top of this post is very helpful for this.

10. Back up all databases and the site files regularly, and keep older backups for a reasonable period of time.

In my case, getting the IP address(es) of the intruders was critical, and I then used it to search the web stats and find out both where they were coming from and how they were exploiting my one php file (out of several hundred!) that was insecure.

Ed

Report · Dec 08, 2009

Very sensible advice. However, the second sentence in the following statement is incorrect:

1. Make sure that you have updated all recordsets to the latest (CS4) version. Older ones created before the GetSQLValueString function was introduced are vulnerable.

The GetSQLValueString() function has always existed in Dreamweaver server behavior code. However, versions of this function prior to Dreamweaver 8.0.2 are vulnerable to SQL injection.

Unfortunately, you can't update older server behaviors simply by deleting the old version of the function and replacing it with one from DW 8.0.2 or later. Other small changes were made in the server behavior code for compatibility with the revised function. PHP server behaviors created prior to DW 8.0.2 need to be deleted and rebuilt. Yes, it's a pain, but far less of a pain than being hacked.

Report · Dec 08, 2009

Yes, Thanks for the list.

Report · Oct 24, 2015

If I have coded my server behaviors instead of using Dreamweaver server behaviors, do I still need to delete them and recode? Aren't server behaviors now gone from Dreamweaver? I've bookmarked this discussion to refer to in the future. Thanks for the advice.

Report · Oct 25, 2015

I'm not sure why you have resurrected a six-year-old thread. Dreamweaver server behaviors prior to Dreamweaver 8.0.2 (released in 2006) were subject to a serious threat known as SQL injection. The 8.0.2 updater fixed the problem. However, Dreamweaver server behaviors were deprecated and removed from Dreamweaver a couple of years ago.

Why were they deprecated? Dreamweaver's server behaviors rely on a set of functions for connection to MySQL that have been dropped from PHP 7, the next major version of PHP that is scheduled for release in November 2015. The functions were deprecated by PHP in June 2013, and many hosting companies began turning them off in PHP 5.5 and 5.6. Anyone relying on Dreamweaver's server behaviors is living on borrowed time. Even if you decide not to upgrade to PHP 7, official support for PHP 5.6 will end in less than two years' time (August 2017). After that, if you're still running PHP 5, you're running a version of PHP that will never get security updates.

Unfortunately for people who don't want to get involved with hand-coding, Adobe has not updated the server behaviors, nor has it announced plans to do so in future. Although it's possible to adapt the code generated by Dreamweaver, it's actually much simpler to ditch it completely and start from scratch using either MySQL Improved or PDO. Whichever approach you take, it's vital to protect database queries against SQL injection. The safest way to do this is to use prepared statements, which are supported by PDO and MySQLi. If you're using the techniques taught in my book PHP Solutions (2nd or 3rd editions) or my database course on lynda.com, you should be safe.

Report · Oct 25, 2015

I do my own coding (SQL and now PDO) and have not used server behaviors in several years. I did not resurrect this six-year-old thread and didn't even notice that it was 6 years old, since it appeared at the TOP of the server-side application discussion list. Yes, I am using prepared statements as taught in your book. In fact, your book stays on my desk next to my laptop.

There is a link near the top of the posting that brings up a popup with a bogus security report. Someone needs to remove the post.

Thanks for all your help.

Report · Oct 25, 2015

ElizabethGailLittle wrote:

I did not resurrect this six-year-old thread and didn't even notice that it was 6 years old, since it appeared at the TOP of the server-side application discussion list.

If it appeared at the top of the list, even though it was a six-year-old post, it almost certainly means that someone posted spam to the thread. When the spam was deleted, the thread will have remained at the top of the list. It's a good idea to check the date of a post before responding to it.

ElizabethGailLittle wrote:

There is a link near the top of the posting that brings up a popup with a bogus security report. Someone needs to remove the post.

If you find a post that's inappropriate, click the Actions menu at the bottom-left of the post, and select Report Abuse. Without knowing which link you're referring to, it's impossible for moderators to resolve the issue.

This forum, by the way, is not regularly frequented because of the deprecation of Dreamweaver's server behaviors. You might find it better to post questions related to server-side related issues in the Coding Corner forum, which was recently set up to handle coding issues that aren't related to a particular Adobe product.

Report · Oct 25, 2015

I suppose because it's six years old there is no Actions option. I will try the Coding Corner - thanks!

‌

Report · Oct 26, 2015

With the first post in a thread, the Actions are listed to the right of the post rather than in a drop-down menu at the bottom-left. It's confusing, but that's the way the forum was designed. The suspect link has been removed.

Report · Oct 25, 2015

‌I think there's only one link in this thread. First post, first paragraph.