Input

Client Input Filtering Practices

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: SSL connectivity does not protect against this issue.

Best practices for prevention

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

  • 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

 

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

  • 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

Web Security Standard

Web Security Standard

The Web Standard provides measures to prevent, detect, and correct compromises on web servers that host RIT Confidential information or use RIT Authentication services. The standard includes configuration and documentation requirements.

Documented Standard

When am I required to follow the standard?

  • If you own, administer, or maintain an official RIT web page that hosts or provides access to Private or Confidential Information.
  • If you have a web page at RIT, official or unofficial, and you use RIT authentication services.

Scanning

  • The RIT Information Security Office provides scanning services to support RIT web pages. Contact Paul Lepkowski, RIT Security Engineer, for more information.

Resources

 

Subscribe to RSS - Input