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 recommendations to keep in mind while customizing Secure Mode applications. Also be aware that following these guideline may not guarantee a secure customization. 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. See Validation functions for more information on these functions.

• Be aware that multiple KCM Core 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. The user can determine which values are allowed, store the set of allowed values somewhere in the session state, and validate the parameters against that set.

• Pay attention 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, such as 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 success 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 note 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 KCM ComposerUI ASP.NET for generating secure request-temporary and session-temporary files. For more information, see the descriptions of functions itp.GetRequestTemporaryFile and itp.GetSessionStoragePath in the chapter Customization APIs for CM ComposerUI ASP.NET. These functions have the added advantage that the files are 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 KCM Core without applying validation, or without making sure that KCM Core does not use the data in ways that pose a security risk. For instance, KCM Core should not be allowed to use untrusted user data in file paths, in command lines, or even as extra parameters to a Master Template 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.