ASP Tutorials - Herong's Tutorial Examples - Version 5.10, by Dr. Herong Yang
Data Submission Issues
This section describes data submission issues like data length truncation; special character handling; spamming detection, etc.
Whenever you connect your ASP pages to databases, there are some data submission issues to be considered.
1. Truncating input values. You should always truncate all input values to make sure their lengths are not longer than some predefined limits. If you don't do this, users may enter large mount of text to crash your database file, or use up all your free space to bring your server down.
Tuncating input values should started in the HTML form fields. Every <input> tag should have a "maxlength" option like this: "<input type=text maxlength=40 name=Email>". "maxlength" option will stop user enter more characters than the specified value.
However, "maxlength" alone is not enough to protect your database. Users do not have to use your form to post values to your server. Any one can easily modify your form, use their own form, or write a simple client program to post values with any lengths to your server. So you have to use a truncation logic on your server side to protect your database.
In hyBook, I wrote a simple function called myTrim() to trim white spaces on both ends of a given string, and truncate it to a given length.
2. Setting submission limits for any single IP address. You should also consider setting up a submission limit for any single IP address. If you don't do this, users may keep submitting values to your server to use up all your free space to bring your server down.
In hyBook, user's IP addresses are recorded in the database. If too many submissions from the same IP address are received, hyBook will reject the submission.
3. Escaping (') in string values. You should check for single quotes (') in all string values to be used in SQL statements, because (') is used as the string quoting character in SQL statements. Any (') found in a string value must be escaped by replacing it with two single quotes (''). If you don do this, users may get an invalid SQL statement error, if (') is used in an input text field.
For example, if you are writing a search page like this:
... Set rSelect = Server.CreateObject("ADODB.Recordset") sSQL = "SELECT * FROM [myTable]" _ & " WHERE [Content] LIKE '" & Request.Form("Key") & "'" rSelect.Open sSQL, oConn ...
When a user submits "Key = Today's paper", he/she will get invalid SQL statement error, because your page will try to run this SQL statement:
SELECT * FROM [myTable] WHERE [Content] LIKE 'Today's paper'
Things could get even worse if a user submits "Key = Today' OR [Content] <> 'Today". The SQL statement will be valid, but it will return all records in your table, because you page will actually run this SQL statement:
SELECT * FROM [myTable] WHERE [Content] LIKE 'Today' OR [Content] <> 'Today'
4. Removing (#) from date values. You should check for pond signs (#) in all date values to be used in SQL statements, because (#) is used as the date quoting character in SQL statements. Any (') found in a string value must be removed. If you don't do this, users may get an invalid SQL statement error, if (#) is used in an input date field.
5. Removing HTML tags in string values. You should consider removing HTML tags from all user entered text. If you don't do this, when you display user-entered text back to a Web page, those HTML tags may corrupt your page design.
Of course, there are many other issues related to database supported Web pages. You should do more researches in this area, if you concerned.
Last update: 2006.
Table of Contents