Input validation methods to help prevent attacks through:
Buffer Overflow:
One simple way to prevent simple buffer overflow or overrun is to limit the maxium characters in a textbox or other ASP.NET control by setting the "MaxLength" property to the same value as that of the field in the database table. The second part of this is to always perform a second check for length in the BLL as part of the data validation protection described in "Cross-site scripting" discussed below.
A more complex buffer overflow discussion will not be done here since this wanders into the area of systems and network responsibility. A good network should have some type of intrusion detection to prevent malicious code from interfering with operating system managment of stack-based and heap-based buffer management.
Cross-site scripting (XSS):
Cross-site scripting occurs when a web application allows a user to inject code, usually JavaScript through controls like textboxes, that has the intent to do harm to the site or obtain data from the server or database that would benefit the attacker.
To prevent simple forms of cross-site scripting at the client web form, use Microsoft ASP.NET JavaScript validators. The first line of defense is the client-side Regular Expression Validator that allows the programmer to check for allowed input to the application. For example,
The regular expression in the "ValidatorExpression" property is "^[a-zA-Z0-9^;]+$" which allows lower case a through z, upper case A through Z, numbers 0 through 9, and the semi-colon only will prevent any other characters from entering the application code-behind and other layers.
The BLL provides the second level of input validation with validation using the same Regular Expression. The code-behind calls a BLL method that returns a true if the input meets the criteria, and a false if it does not:
UserBLL uiBLL = new UserBLL(); if (uiBLL.ValidateText(this.txtUserList.Text.Trim()) == true) {
//Pass the input to the BLL and DAL layers for database inserting or updating
)
The BLL "ValidateText" method calls and abstract base class method inherited by all domain BLL classes that accepts the text and a Regular Expression string and returns a true if it all is okay, and a false if the validated text is not okay.
///---------------------------------------------------------------------------
/// <summary>
/// Method Name: ValidateText
/// Description: Validate user list string separated with semicolons
/// </summary>
///
/// <param name="text">text string to be validated</param>
/// <returns>bool true or false representing validation results</returns>
///---------------------------------------------------------------------------
public bool ValidateText(string text) {
if (AppBase.BLL.ValidateItem("^[a-zA-Z0-9^;]+$", text) == true) {
return true; }
else
{
return false; }
}
This double check insures that if a hacker somehow can bypass the Microsoft JavaScript validators, then the second level of input validation will catch the malicious code string.
SQL injection:
If a programmer concatenates strings to send to the database as stored procedures, then they are either novice coders, or they don't know anything about SQL injection. Stored procedures should be created in advance of their use, and they should include parameters that are variables passed to the precompiled stored procedure from the application. These parameters should be validated by client-side (if possible) and server-side (at a minimum) checks to prevent malicious SQL injection.
Yes, even stored procedure parameters can be utilized for injection. For example, if a stored procedure has a search parameter like last name passed to it as a search parameter:
SELECT Last, First, Middle, SSN
FROM Client
WHERE Last = @Last
If the programmer doesn't validate and reject malicious input to these parameters before they are passed to the stored procedure, then the malicious user can send the following string to the database:
'Smith' OR 1 = 1
Since 1 is always equal to 1, then the stored procedure returns all of the data in the Client table. This would include Social Security Numbers! This is a lawsuit waiting to happen.
Canonicalization:
This long word represents unauthorized access to files on your server from allowing a malicious user to enter a file path in a text field. Why would a program allow a user to input a file path in a textbox? Unfortunarely, some applications do this, and if this must be done, then use a Regular expression validation check to secure the location. Once again, however, why take the chance?