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:
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.
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.