Secure customizations

When customizing an application that is intended to run in Secure Mode, it is necessary to conform to a set of security guidelines. In general, it is always safe to apply styling customizations. Any customizations that involve programming require special attention.

The following is a non-exhaustive list of things one should keep in mind while customizing Secure Mode applications. Be aware that it is not guaranteed that one will write a secure customization when these guidelines are followed. Careful thought is always required.

• Whenever possible, require a session ID as the only query parameter. Validate this parameter using the correct validation function before use. Refer to Validation functions for more information on these functions.
• Be aware that multiple ITP/Server sessions may be sharing the same ASP.NET session state. Therefore, when you store items in the ASP.NET session state, use the session ID as a part of the key, like this: Session[ Request.QueryString["sessionid"] + "_my_data_item" ].
• Perform extensive checks on all query string and form parameters that you use.
• Sometimes it is not possible to determine the set of allowed values for a query parameter at design time. In such cases, it is often possible to determine which values are allowed when generating the calling web page. If it is possible to determine which values are allowed, store the set of allowed values somewhere in the session state, and validate the parameters against that set.
• Take care when using the request parameter collections Request.Params, Request.Form and Request.Querystring to retrieve query parameters. In general, instead of using the collection Params, it is advisable to specify exactly which source is intended, i.e., to use Request.QueryString or Request.Form. Furthermore, it is very important to ensure that a parameter is always accessed using the same collection. This prevents the situation where the parameter value from one collection is validated, but the value from another collection is actually used. An easy way to ensure this is to read every parameter value only once.
• Always consider what happens if the value of a query parameter does not match one that is expected because of the logic of the application. For instance, if you generate a page that includes a url "mythings.aspx?thingnumber=5", then consider what happens when a malicious user changes this into "mythings.aspx?thingnumber=7".
• Never use untrusted user data, such as query string parameters and form data, as file names or parts of file names. This can be exploited by malicious users in numerous unexpected ways. Instead, use the mechanisms provided by ITP/OnLine ASP.NET for generating secure request-temporary and session-temporary files. For more information, refer to the descriptions of functions itp.GetRequestTemporaryFile and itp.GetSessionStoragePath in chapter Customization APIs for ITP/OnLine ASP.NET . These functions have the added advantage that the files will be automatically cleaned up when the request or session expires.
• Never include untrusted user data in command lines. Again, this can be exploited in numerous unexpected ways.
• Never rely on client side validation logic. JavaScript validation logic is very useful to provide the user with instant feedback, but a malicious user can easily circumvent the validation. Furthermore, JavaScript can be disabled in the client browser. Therefore, server side validation logic is always required.
• Never pass untrusted user data to ITP/Server without applying validation, or without making sure that ITP/Server does not use the data in ways that pose a security risk. For instance, ITP/Server should not be allowed to use untrusted user data in file paths, in command lines, or even as extra parameters to a model run.
• Whenever a url is constructed in the code, always make sure that query string parameters are properly escaped. Unescaped query string parameters may lead to unexpected behavior that may be exploited by malicious users.
• Whenever JavaScript code is generated by the code, always make sure that parameters are properly escaped. Unescaped JavaScript parameters may lead to unexpected behavior that may be exploited by malicious users.