KB003338

This article describes ways you can secure your K2 applications. Use this article along with information in Securing the K2 Platform to mitigate potential security issues in your K2 environment and the applications that run in the environment.

This article is divided into three sections:

• Designing secure solutions
• Securing SmartObjects, forms, workflows, and sites
• Additional security settings

Use the approaches described in this article as a starting point to design secure solutions with K2. However, this article is not meant to be a comprehensive list of all security-related issues that may represent a risk to your infrastructure or applications; your environment may have additional or unique security requirements. Additionally, not all applications may require a high degree of security – you could use a subset or selection of these practices to apply an appropriate level of security based on the intended use of your applications. Also, there is often a balance between effort and cost versus the level of security to implement an efficient and effectively-secured application. 

This article is intended for solution architects and enterprise architects. Should you require additional assistance in designing secure applications for your particular requirements, consider working with K2's Professional Services teams.  

Designing secure solutions

Use the following general guidelines when designing K2 applications: 

• Enhanced Validation
  While you can perform data validation in SmartForms, and configuring form-level validation is useful to help form users provide the right information, you should attempt to validate data using tools and best practice design approaches available in the data provider. For example, if you store data in Microsoft SQL Server, use SmartObjects based on stored procedures rather than ones built directly from SQL tables. In the stored procedure logic, verify that the data from the SmartForm is valid before committing it to your database. For other systems, use similar validation procedures so that you are not only relying on SmartForms' validation for business-critical data.
   
• Cross-site scripting (XSS)
  According to the Open Web Application Security Project (OWASP), cross-site scripting attacks "are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites." This particular vulnerability is present in SmartForms that use the Data Label control in Literal mode and you uncheck the Prevent XSS option. Be careful not to inadvertently allow malicious code if you use the data label control in this way, especially if you pass data entered in the form into the data label control. If you need the Data Label control to be literal, cannot use the Prevent XSS option, and user-entered data is used in the label, use the HTMLEncode expression function to encode the user value to prevent XSS.
   
• Build Smart Layers
  You build K2 solutions in many layers using LOB data and other integration to your forms, reports, and workflows. Take your time to design each of these layers as securely as possible, with as much logic, validation, resilience and intelligence as possible to make sure that each layer can handle edge cases, errors, and malicious intent. Building layers quickly without this level of detail and attention is acceptable for proof-of-concept solutions to demonstrate to your team and get approval from stakeholders, but when it comes to building the production version of your solution, take your time and make each layer as secure as possible.

Securing SmartObjects, forms, workflows, and sites

Use these security guidelines when creating SmartForms.

• Enforce data security through LOB Logic
  Similar to the general guidelines above, use functionality and tools provided by your LOB system to validate and secure data going into and coming out of the system. Do this before you create your SmartObjects that you use in your SmartForms. Using this approach minimizes the number of rules and amount of logic you must configure in your forms. In addition to making your forms easier to create, you can also leverage LOB logic in other, non-K2 scenarios when you access data from the LOB.
   
• Set security and policies on K2 artifacts
  Use the Authorization Framework to set View, Create, Modify, Execute, Delete, and Security rights on categories, views, and forms. Keep in mind that the denying a right overrides any other allowed right. Use this security framework on objects to control who can design and interact with them. For SmartForm views, you may want to turn off the Allow Standalone option so that views cannot be opened without being part of a form. Set data access policies on sensitive SmartBox SmartObjects especially, since anyone with design capabilities may be able to access data using these SmartObjects.
   
• Obfuscate or hide parameters 
  You can configure parameters on forms, however it is a best practice to not pass data directly in parameters. Use IDs to load data from a SmartObject instead of passing data directly in parameters. If you must pass IDs in the query string, an extra security measure is to create a data mapping table with GUIDs or some other type of long number to pass as a parameter, then lookup the sensitive value using this GUID. This prevents form users from modifying the parameters of a form's URL to load data that they should not have access to. When opening a task form in the context of a workflow, do not use the Record ID to load data associated with a task. Instead, use the serial number instead and retrieve the record ID from workflow variables. Note that tasks have built-in security that checks the user's identity with the task configuration to ensure they have rights to see the task. Obfuscating parameters can also help you guard against content injections and redirects.
   
• Do not pass user identity from the user interface
  Thinking of the STRIDE approach, specifically with regard to tampering and repudiation, do not pass a user’s identity into SmartObject methods using SmartForms, because the browser’s developer tools or other tools like Fiddler can allow replays of web requests with changed data. To mitigate this, use system values in the service object as explained in KB002942: Sending Identity Information to a Line of Business System . If you’re using SQL Server, you can instead use the DBContextInfo option as explained in KB003062: Pass Identity Information to Microsoft SQL Server for Security and Auditing . When calling services, use authentication/authorization technologies such as claims or OAuth to securely identify users. If you have access to the underlying code in the Service Type, you can retrieve the connected user's identity with code like this: 
  this.broker.Service.ServiceConfiguration.ServiceAuthentication.UserName;
• Use auditing, reports, and thresholds
  You can use the Security Audit SmartObject to see all security-related changes in your environment. You can also use the Process Instance Audit Report and the Process Instance Data XML Audit Report to see historical information about tasks. These reports are helpful when you need to look at process data. You can also use the Process Overview Report to spot trends and spikes in the number of workflow instances. Lastly, use Instance Threshold Policies to limit the number of workflows that can start within a specified timeframe, and familiarize yourself with auditing and logging features of the K2 platform. Keep in mind that auditing data may impact performance and increases the amount of data stored in the K2 platform. Also, if you need to log messages and data from other systems, you may have implement a custom logging solution to use with both K2 and non-K2 systems.
   
• Design with GDPR in mind
  When creating your solutions, limit the amount of personal data that you store in your workflow variables, including the folio. Try as much as possible to limit the amount of data you store in K2 objects, such as K2 SmartBox and workflows, so that your exposure is limited to LOB systems covered by your internal and external data policies. If you have external K2 solutions, keep in mind that you must supply privacy notices and potentially gain consent, depending on the data you're collecting.
   
• Clear and disable task forms
  When using SmartForms to action tasks, if the serial number is not valid, you may want to clear the entire form and disable all controls. This prevents any unwanted exposure to data that might appear on the form even when the tasks' serial number is not valid. You can configure a rule that uses the When the Form is in Error event to capture the invalid serial number error and then configure a rule action to clear out the form. 

Additional security settings

You can apply additional security settings in your environment to further secure your K2 applications. Examples of such settings include: 

• Disable debugging and stack tracing on runtime servers (K2 Five only)
  Debugging is normally switched off as is stack tracing, however in version prior to K2 Five 5.3 and K2 Cloud Update 7, you must turn off stack tracing in error messages. For more information, see How to hide stack trace in error messages in SmartForms .
   
• Anonymous sites and forms (K2 Five only)
  If you've setup a secondary SmartForms runtime site that is accessed anonymously , or you have turned on the Anonymous Access option on a view or form, make sure that you have protection from denial of service (DoS) attacks that could make your server unavailable for normal use. Use defense techniques to protect your K2 and non-K2 infrastructure from these types of attacks.
   
• Configure Strict Transport Security (HSTS) (K2 Five only)
  This IIS setting prevents SSL-based connections from switching to non-SSL. See How to enable HTTP Strict Transport Security (HSTS) in IIS7+ for more information.
   
• Create a separate runtime SmartForms site for external users (K2 Five only)
  For external forms, create an additional SmartForms runtime server in your DMZ and use the Authorization Framework to deny execute rights for internal forms to external users.
   
• Define blocked file types for the file attachment control
  Carefully review blocked file types (blacklist) and configure additional ones, if necessary.
   
• Review other common Web Security recommendations
  Refer to the OWASP Top 10 Cheat Sheet (A1- A10) for additional security considerations.