Protecting PHP server behaviors from SQL injection vulnerability

Some databases let you send multiple SQL statements in a single query. Because of this, there are potential security risks when you pass parameters in a query string to a dynamically generated database query. Hackers might try to modify URL or form variables in a dynamic query by appending malicious SQL statements to existing parameters. This is often referred to as a SQL injection attack. Some of the server behavior code created by Dreamweaver should be modified to reduce the risk of SQL injection attacks. For more background information on SQL injection, see this Wikipedia article. (Ref. 201713)

Note: The issue described in this TechNote has been fixed in the Dreamweaver 8.0.2 Updater.

This TechNote covers Dreamweaver's PHP server behaviors. There are separate TechNotes for the ColdFusion, ASP VBScript, ASP JavaScript and JSP server behaviors. The ASP.NET server behaviors are not affected.

When you let a query string pass a parameter, ensure that only the expected information is passed. Adobe has created a Dreamweaver 8.0.2 Updater that reduces the risk of SQL injection attacks. These fixes will be incorporated into all future releases of Dreamweaver. After updating Dreamweaver 8, you will need to reapply the server behaviors to the pages that use them, and redeploy those pages to your server.

The remainder of this TechNote documents how to manually edit Dreamweaver MX 2004 code to prevent SQL injection attacks with the PHP server model. Server behaviors that are vulnerable to these attacks are listed below, along with fixes:

• Recordset with a filter
• Insert, Update, and Delete Record server behaviors and Record Insertion Form Wizard
• Log In User
• Check New User
• Master Detail Page Set
• Record Update Form Wizard

Unfiltered recordsets do not need to be modified, but filtered recordsets do. In the example below, a Dreamweaver MX 2004 recordset named "rs_byDate" is filtered by a date value passed in from a URL parameter. The highlighted code below is what will need to be changed:

To protect the recordset from SQL injection attacks, a custom GetSQLValueString() function should be created near the top of the page. This function will verify the data type of the query parameter. Once the function has been created, then update the recordset code to use the GetSQLValueString() function.

The Insert, Update and Delete Record server behaviors and Record Insertion Form Wizard already use the GetSQLValueString() function, so they just need to be refined to prevent SQL injections. The only changes needed are in the GetSQLValueString() function.

Here is the original code. The line that will be changed is highlighted in yellow:

Original code:

Modified secured code:

Here are the steps to fix the Log In User server behavior:

The Check New User server behavior requires that an Insert Record server behavior be added to the page first. The GetSQLValuesString() function is included with the Insert Record server behavior. All that needs to be done is to update the GetSQLValuesString() to better handle SQL Injection and update the Check New User server behavior to use this function when a parameter is passed in.

For the Master Detail Page Set application object, the changes are mainly in the recordset that Dreamweaver creates for the Detail Page. If you don't have a filtered recordset in the Master Page, then no changes need to be made to the Master Page. If you have a filtered recordset, then see recordset with a filter to update the recordset code.

Dreamweaver creates a filtered recordset in the Detail Page, so that recordset code needs to be updated to use a GetSQLValueString() function to pass in parameters and sprintf() to construct the SQL string.

Please refer to the following article for more information about SQL injection: Wikipedia article on SQL injection.

Adobe Security Bulletin: APSB 06-07 Dreamweaver Server Behavior SQL Injection vulnerability.