If you are developing an on-line store you need to protact your data so the information doesn't go in the wrong hands. Read how Macromedia Dreamweaver MX allows you to safely interact with your database.
In contrast to physical and virtual security, internal security refers to the steps that you take within the actual code of your application. This includes the way in which you connect to the database and the accounts that you use in your connection. Here are some pointers to keep in mind as you develop.
Use stored procedures for all your data access. This allows you to deny direct table access for your application's user. You can create your database components, views, and stored procedures using your regular SQL Server account. But do not use that account login in your connection string. Instead, use a login that you have established specifically for your application.
Make sure this login executes the stored procedures that are part of the application and nothing else. This login will not be able to query tables directly or add or update any data outside the confines of the stored procedures you have constructed and the specific parameters they expect to see. Even if your web application is compromised and login information is obtained, hackers will not be able to perform any operation on the database other than those they could using the application itself.
To do this, open a stored procedure that you have created and click the Permissions button in the upper-right corner of the window. You will be presented with a list of all the logins that have been given permission to access the database in which you are working. The Select, Insert, Update, and Delete columns will appear, but because these do not apply to stored procedures there are no boxes for you to check. Locate the Execute column and check the box next to the login that you will be using in your site’s connection string.
Securing your database is an excellent first step to protecting your data. It can either be reinforced or totally nullified depending on the way in which you construct your application in Dreamweaver MX.
Dreamweaver MX authentication
Authentication is an important part of most data-driven websites. Whether users take orders or upload content, you will want to know who is signed in so that you can control the parts of the system that they have access to and track the changes they make. Typically, authentication is performed by a login script where a visitor provides a username and password, which is then checked against a database. How you collect that user information and pass it to your database needs attention in Dreamweaver.
The default login scripts simply collect the field data from a username and password form and pass it unaltered to a SQL query. This is understandable because it allows for the greatest amount of flexibility in your programming, but it's not a safe way to leave your code. Databases use nonalphanumeric characters (%, *, etc.) to indicate wildcards in searches.
Depending on how your queries are written, wildcard characters entered into a login form could be passed to the database, resulting in a successful login when no valid user information was supplied. Some have suggested that Macromedia should re-release these behaviors with a more secure method, but that's not necessary and it would limit the usefulness of the extensions for other purposes. You can correct this problem yourself in a more dynamic fashion, allowing you control over how your data is processed.
When initializing a recordset server behavior, you are asked to supply both default and runtime variable information in the user interface. This defines for the server behavior whatever values to use for the parameters in your SQL statement for testing, during production, and in cases where no data is supplied by the user. There are two important points to remember here.
First, do not supply default values that represent valid data. While it may be convenient to input values that pull real data for testing purposes, change these values before deployment so that a user cannot simply leave information blank and receive records that they did not request and are not authorized to view.
Second, think carefully about the runtime values you use here and take advantage of the ability to manipulate data in the variable. For instance, to solve the wildcard character issue, you can simply HTML-encode your form fields right in the variable declaration. Instead of entering Request(“username”) as the runtime value, enter HTMLEncode(Request(“username”)). The HTMLEncode function converts wildcard characters to their HTML equivalents (e.g., "<" = "<"). The downside is that your users cannot use these characters as part of their username and password combinations, but that is a small tradeoff for the security it provides both you and them.
Dreamweaver MX scripts
One of the great things about Dreamweaver MX is the way it introspects your data sources and makes table and field information available to use in a visual environment. It accomplishes this with a folder of server scripts that get deployed to your server. These scripts read information about your database and supply it to the Dreamweaver interface. It's an ingenious way of managing this complex task but it does not belong on your production server.
These script files were meant to be a part of your development process, but they need to be removed when you publish your site to a production server. They are in a folder called _mmserverscripts in the root of your site. This folder contains three files. It is not my intention to breed a cartel of Dreamweaver hackers, so I’ll not go into the details.
Suffice to say that someone who knows where to look for these files and has examined them, which is easy to do if you own Dreamweaver MX, can get a surprising amount of information about your data in just five or six easy steps—especially if you use DSN connections. When I made a quick review of web sites that I know were developed in Dreamweaver, I found these files present in most cases.
So there you have it: a few quick steps to help secure your data in a Dreamweaver MX application. Entire books can be written about this topic and there are certainly more considerations to make. The lengths to which you go to learn about this topic will typically be driven by the degree of sensitive data you plan to handle in your applications.
Take the time to review security practices thoroughly before taking and storing credit card information or providing structured access to sensitive data over the web. Read articles like this one and consult tech note resources. Only by keeping yourself up to date will your data remain safe.
DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.