Client Input Filtering Practices

Client input filtering is needed to prevent specific attacks.

Cross Site Scripting (XSS)

Cross-site scripting vulnerabilities allow malicious attackers to take advantage of web server scripts written in languages such as PHP, ASP, .NET, Perl or Java that do not adequately filter data sent along with page requests to inject JavaScript or HTML code that is executed on the client-side browser. These flaws occur anywhere a web application uses input from a user in the output it generates without validating it. Any type of variable that comes from a user or comes from a place where you do not control needs to be validated. This malicious code will appear to come from your web application when it runs in the browser of an unsuspecting user.

Note: A secure connection does not protect against this issue.

Best practices for prevention

In general, the following practices should be followed while developing dynamic web content

  • Use APIs to escape untrusted data
  • Audit the affected URL and other similar dynamic pages or scripts that could be relaying untrusted malicious data from the user input
  • If you are displaying user supplied input, the data should be displayed by a function that either escapes or converts the data into appropriate HTML
  • Explicitly set the character set encoding for each page generated by the web server
  • Identify special characters
  • Encode dynamic output elements
  • Filter specific characters in dynamic elements
  • Examine cookies
  • For ASP.NET applications, the validateRequest attribute can be added to the page or the web.config. For example:

<>

-OR-

<system.web>

        <pages validateRequest="true" />

</system.web>

  • Dynamic content should be HTML encoded using HTML::Entities::encode or Apache::Util::html_encode (when using mod_perl).
  • For PHP applications, input data should be validated using functions such as strip_tags and utf8_decode.
  • For PERL applications, input data should be validated using regular expressions whenever possible.

References

CERT CA-2000-02

Wikipedia Cross_Site_Scripting

Penn Computing Top 10 Web Application Security Vulnerabilities A4

SQL Injection

Web applications that do not properly sanitize user input before passing it to a database system are vulnerable to SQL injection. This could potentially allow a malicious user to read and/or modify any data that the application has access to.

Best Practices for Prevention

  • Use APIs to escape untrusted data
  • Ensure that the script properly validates user input before passing it to the underlying database system.
  • Avoid accessing external interpreters wherever possible.
  • Use bind variables wherever possible. If not, escape all user variables.
  • Use pattern matching to verify user input is an expected value.
  • Limit access to the web account that is accessing the database.
  • Use procedures to insert records and update data; do not give the application direct access to the tables.
  • Limit application to READ-only access where possible.

References

Wikipedia Sql_injection

MSDN SQL Injection

OWASP SQL Injection

Penn Computing Top 10 Web Application Security Vulnerabilities A6