Data Management

Protect your sites from potential Dreamweaver vulnerabilities

If you use any version of Dreamweaver MX, MX 2004, or UltraDev 4, you need to learn what vulnerabilities exist and what steps your development team can take to resolve these problems.

If you develop applications and e-commerce Web sites with any version of Dreamweaver MX, MX 2004, or UltraDev 4, they may contain serious to critical vulnerabilities that can allow an attacker to access the back-end database server without discovering a valid user ID and password.

This isn't the result of poor programming practices; therefore, this probably affects everyone who uses these development platforms in conjunction with a SQL database. Even if you're a veteran and/or careful security-conscious developer, you still need to check out this potential threat.

Dreamweaver's problem isn’t a bug in the code, so it won’t require any reprogramming or other changes to the deployed code other than the removal of a file or two. The problem arises from the fact that developers often use the affected Macromedia tools to create a link with databases. These databases are associated frequently with e-commerce and may contain very sensitive data. In developing these applications, it's necessary to test those database links, which is where the threat arises.

During development, the ASP script mmhttpdb.asp uploads routinely to the Web site in order to evaluate database connectivity. The development team is the only intentional user of this script. The script doesn't have any security features, and it doesn't require a user ID or password.

When a developer routinely opens the Database Connections dialog box and specifies Using Driver On Testing Server or Using DSN On Testing Server, this creates the ASP script and uploads it to the testing server.

If the databases and DSNs already have password protection, the attacker's ability to issue SQL commands is blocked. If password protection hasn't been implemented, then a critical concern is mmhttpdb.asp’s ability to list all Datasource Names as defined on the server. In combination with a second operation, which allows users to test the site using any arbitrary SQL query, this makes it possible for an attacker who knows about this file to compromise the back-end database server and download any data in the database or alter data.

The solution is simple: Delete the directories where the ASP script is normally installed. Dreamweaver MX creates the _mmServerScripts directory, and UltraDev creates the _mmDBScripts directory.

Remote testing of an e-commerce Web site's ability to access a database is essential, and Macromedia development tools provide a simple and efficient method for doing this. However, it's so transparent that developers may not realize that a dangerous ASP script allowing remote HTTP manipulation of the database server has been created and uploaded to the Web server. It's essential that someone on your team delete this script, in light of the fact that this isn't necessary on a deployed application.

If the database has password protection, this will mitigate the threat; but leaving the ASP script on the server is still a bad practice from a security standpoint. This is a prime example of a hidden security threat that may not be obvious to even the savviest developer. It should serve as an excellent incentive to have at least development team members constantly monitor security bulletins that may affect the development software you use or the platform on which you deploy applications.

For more details about this threat, read Macromedia's Security Bulletin MPSB 04-05, Potential Risk in Dreamweaver Remote Database Connectivity.

Editor's Picks