A formidable input security system covers these aspects of security:

• Knowledge
• Auditing
• Detection
• Logging
• Blocking
• Neutralization
• Impeding

Knowledge

Good security starts with your knowledge on how hackers employ SQL Injection, Script Injection, and Input Tampering. Some very informative white papers are available on the subject. The Peter's Input Security User's Guide provides you with primers on all three forms of attacks, with examples and links to other resources for more details.

Through its logging feature, Peter's Input Security collects the details behind each attack, including IP addresses, the exact text entered, and a descriptive error message. You can use this information to refine your security.

Its Security Analysis Report tells you exactly how your inputs are secure and advises you on improvements.

Auditing

You need a way to get a clear picture of your page's inputs and their security. Otherwise, you can easily:

• overlook a control, hidden field, query string parameter, or cookie
• misunderstand the protection provided by a validator
• forget to neutralize the data that gets past your validator

Use the Security Analysis Report to fully audit and document your input security. It creates HTML files that you can keep as a record of your defenses.

Detection

Without the ability to detect an attack, you cannot log, block, or impede. Detection plays a significant role in input security.

Validators are used to detect illegal values within inputs, but they have their limitations:

• They only handle visible fields. Other inputs - hidden fields, query string parameters, and cookies - are still vulnerable
• They cannot tell the difference between an injection attack and a data entry error
• They cannot identify many types of attacks within free-form text fields
• They cannot log injection attacks

ASP.NET 1.1 includes the ValidateRequest attribute on each page to detect possible Script Injection. It has several limitations:

• It blocks all inputs. If you have a field that permits some HTML tags, you must turn this feature off, leaving the page unprotected on all other inputs.
• It enforces its findings by throwing an exception instead of displaying a helpful validator error message.
• It looks for HTML tags. It cannot find dangerous javascript embedded into the text that creative hackers might use. For example, if a hacker knows that you will be embedding their input as a parameter of javascript, they don't have to write any HTML tags. They just add their new javascript code.
• It does not log any attacks

Peter's Input Security introduces the PageSecurityValidator and FieldSecurityValidator to detect SQL Injection, Script Injection and Input Tampering on all types of inputs. You control their detection rules on an input-by-input basis.

Logging

Logging has aleady been presented several times. It is a very important aspect of a good security system.

• It keeps you informed of attacks and other errors
• It gives you information to improve your security
• It directs you to the garbage that hackers added to your database so you can clean up
• It lets you provide friendly error messages to your users while keeping you informed of the real issues. Hackers use the technical errors to attack your site. You block them from this valuable information.

Peter's Input Security provides the Log And Respond Engine to record every attack, exception, and error with great detail. The PageSecurityValidator and FieldSecurityValidator automatically use it. You can use it from your own code to record anything you like.

Blocking

The more attacks that you can block, the less garbage you have in your database and you lower the amount of resources lost to the attack.

Peter's Input Security provides several ways to block attacks:

• Validators can display an error message and force the user to clean up before the page is accepted.
• The FieldSecurityValidator and PageSecurityValidator can use the Log And Respond Engine to redirect to another page or throw an exception.
• The FieldSecurityValidator can use a mixture of these approaches depending on how severe the attack is. This lets you provide friendly error messages to users who make minor input errors while being more aggressive with attackers.