Security and Licensing
Introduction
The Windchill Extension Framework provides a set of rules and checks to help developers keep their Windchill Extensions secure for their users. All the standard security protocols are defined here.
Security Levels
The developer needs to assess the security level that has to be applied to the extension: based on that, different levels of testing and reporting will be required. The security level of an extension can be determined in the following way:
- A - High - Indicates that an Extension has communication with other systems using one or more of the following: Network access, Password Management, Encryption.
-
B - Medium - Updates and/or deletes data in Windchill. Uses admin access (e.g., Privilege escalation). Exposes i-frames or has pages or part of pages that are not part of the standard Windchill architecture. Does file creation on the server. Processes URLs and accesses parameters.
-
C - Low - Read-only UI using standard Windchill UI components.
- D - Very Low - Internal only, no UI access
Note that B and A will require security tests and A should have a threat model completed.
Reporting and Analysis
During the build a report is generated using some defined and online resources.
Each extension must define this file src\main\security\meta.json which defines the security level and manages the level that the developer considers valid
{
"level":"B",
"approval": {
"review": { "name":"Ellis Douglas", "date":"2023-2-20" },
"approve": { "name":"Simon Heath", "date":"2023-2-20" }
},
"suppress": [
{ "id":"CVE-2022-45688", "reason":"This API is encapsulated and there is no attack, hutool-json not used" },
{ "id":"CVE-2022-26336", "reason":"poi-scratchpad is not used" }
],
"assessments": {
"LevelA": [
{ "desc":"Offers services to other systems", "valid":"false" },
{ "desc":"Server to server with other systems", "valid":"false" },
{ "desc":"Browser based communication with other systems", "valid":"false" },
{ "desc":"Stores and manages credentials", "valid":"false" },
{ "desc":"Any direct database access", "valid":"false" }
],
"LevelB": [
{ "desc":"Escalation privilage access to Windchill", "valid":"false" },
{ "desc":"Administration Only UIs", "valid":"false" },
{ "desc":"Direct access UIs e.g. downloads", "valid":"false" },
{ "desc":"Requires XSS/CSRF testing", "valid":"true" }
],
"LevelC": [
{ "desc":"Implements a Windchill UI", "valid":"true" }
]
}
}
Windchill Vulnerabilities and Exploitations WVE
This is augmented by automatic checks using a mechanism call WVE (Windchill Vulnerabilities and Exploitation)
The database of these checks are held here https://raw.githubusercontent.com/wincomplm/edk/main/access/wve.json and are used to determine a minimum security score that the extension is required to have
wve approval:https://raw.githubusercontent.com/wincomplm/edk/main/external/wve-approvals.json
Approvals: com.wincomplm.wex-example-security:[WVE-2022-0204, WVE-2022-0101, WVE-2022-0201, WVE-2022-0202, WVE-2022-0301, WVE-2022-0401, WVE-2022-0402, WVE-2022-0403, WVE-2022-0501, WVE-2022-0501]:[WVE-2022-0301]
Approved: WVE-2022-0101:Privilege escalation using direct database access path:src\main\java\com\wincomplm\wex\example\security\examples\SQLBad.java Line#10 (9) Level:B
Approved: WVE-2022-0201:Privilege escalation using POM layer path:src\main\java\com\wincomplm\wex\example\security\examples\WindchillPrivilegeEscalation.java Line#23 (7) Level:B
Approved: WVE-2022-0202:Privilege escalation using session path:src\main\java\com\wincomplm\wex\example\security\examples\WindchillPrivilegeEscalation.java Line#27 (7) Level:B
Approved: WVE-2022-0202:Privilege escalation using session path:src\main\java\com\wincomplm\wex\example\security\examples\WindchillPrivilegeEscalation.java Line#31 (7) Level:B
Approved: WVE-2022-0204:Privilege escalation using session path:src\main\java\com\wincomplm\wex\example\security\examples\WindchillPrivilegeEscalation.java Line#27 (7) Level:B
Approved: WVE-2022-0204:Privilege escalation using session path:src\main\java\com\wincomplm\wex\example\security\examples\WindchillPrivilegeEscalation.java Line#31 (7) Level:B
Approved: WVE-2022-0301:Java network access path:src\main\java\com\wincomplm\wex\example\security\examples\NetworkAccess.java Line#14 (3) Level:A [False Positive]
Approved: WVE-2022-0402:Extension Listener path:src\main\java\com\wincomplm\wex\example\security\examples\StateListener.java Line#11 (5) Level:C
Approved: WVE-2022-0402:Extension Listener path:src\main\java\com\wincomplm\wex\example\security\examples\StateListener.java Line#12 (5) Level:C
Approved: WVE-2022-0402:Extension Listener path:src\main\java\com\wincomplm\wex\example\security\examples\StateListener.java Line#22 (5) Level:C
Approved: WVE-2022-0402:Extension Listener path:src\main\java\com\wincomplm\wex\example\security\examples\StateListener.java Line#24 (5) Level:C
Approved: WVE-2022-0501:JSP calls backend, possible XSS issue path:src\main\wex\jsp\edkHelloWorld.jsp Line#4 (3) Level:B
Done. No errors.
-------------------------------
Minimum Security Level: B
-------------------------------
A report is generated after build with the following sections
- Overview - Wincom Approvals and Review
- Overview - Details
- Security - Details
- Security - CVE Suppressions
- Security - Information
- Test Plan > Uses annotations in the Junit test area
- Windchill Vulnerabilities and Exploitations
- SCA Software Component Analysis
- Build Configuration
- Owasp Dependency Report CVE
- Additional information > All PDF that are present
Approval SCA and WVE
The security scan can be customised to add the following parameters
- wex.security.wveadb - The json contained approved WVEs
- wex.security.scaadb - The json containing approved SCA (e.g. third party libraries)
- wex.security.wveexcluded - A json that will exclude files from the scan
Exclusions are normal to avoid testing code being included in the scan. This is the default setting.
CVE Build Checks
All developers must be aware of the security testing and standards to apply to code.
Java Dependencies Checks
Built into the extension build is the OWASP plugin that will fail the build if any security threat above 2 is reported for any dependency. It uses the NIST national threat database as a source, and it is advised that Windchill Extensions are periodically rebuilt for the express purpose of rechecking against the national database, which may have issued a new threat report on one of the libraries used.
User Interface Checks
If an extension implements a UI, it may use 3rd party libraries to generate the UI.
| Language | Examples |
|---|---|
| JavaScript | jQuery, Moustache |
| CSS | Bootstrap |
At present the WEX build architecture does not have a automatic check on these, so it is up to the developer to make sure no security issues arise from their usage.
GDPR
Developers that implement a UI must be aware of the GDPR regulations and security protocols.
Security Coding Practices
Note: None of the techniques here are guaranteed to secure code and Wincom is not responsible for the security or otherwise of code created using these APIs and methods
User Interface Security
We generally leave the security and access control to the back-end. All APIs that call Windchill will only return data to which the user has access. Windchill also only allows authenticated users to access the UI, so this ensures access control is respected. Therefore, for the majority of use cases, it is not necessary to add security code into the UI. However, some actions do not involve the DB or need to be secured to ensure certain features are not available to the end user.
We cannot just use validators to control access as user can access the JSP link directly. Therefore we must secure the actual page.
We never do this in front-end code, we must secure the page by calling a method in the back-end.
Implementation
The new security module can be included as a dependency in any extension and provides easy-to-use API to secure JSP access, among other security-related functionalities.
It is available here, from wex-parent 2.5 onwards:
<dependency>
<groupId>com.wincomplm</groupId>
<artifactId>wt-security-commons</artifactId>
</dependency>
The following API should be added to MVC components used on an admin only page:
WexSecurePage.secureAdminOnly();
Cross Site Scripting Prevention
To avoid XSS attacks we need to secure the request as follows, this will ensure all parameters are cleaned and any resulting HTML output is sanitized. There are various APIs in included in wt-security-common can assist here
Sanitize example
WexSecurePage.secureAdminOnly();
WexSecureRequestWrapper httprequest = new WexSecureRequestWrapper(httprequestUnsafe);
// No XSS can be passed in
String fid = httprequest.getSecureParameter("id");
// No XSS can be sent out
String safeOutput = WexSanitizer.sanitize("javascript could be here");
// This will be picked up by WVE-2023-0506
httpresponse.getOutputStream().print(safeOutput);
Encode example
public String getUniquePageNumber(NmCommandBean commandBean){
String uniquePage = commandBean.getRequest().getParameterMap().get("unique_page_number")[0];
return Encode.forHtml(uniquePage);
}
JSP Usage
Note that parameter handling in the JSP is not allowed as it cannot be secured
This must be recoded as a request passed into the backend
Rate limiting
If any code could cause an exhausting of resources e.g. memory or disk then a rate limiter should be used. Indicated by WVE-2024-0511 which is looking for doOperation a Windchill API indicating a UI but there may be other cases.
static WexPerUserRateLimiter limiter = WexPerUserRateLimiter.newPerUserRateLimiter(100, TimeUnit.MILLISECONDS.convert(10, TimeUnit.MINUTES));
limiter.check();
Windchill Feedback sanitizaion
The Windchill feedback must be sanitized to avoid XSS and path disclosure. Indicated by WVE-2024-0510 and can be removed using WexSanitizer.sanitizeFeedbackMessage
Before
result = new FormResult(FormProcessingStatus.FAILURE);
FeedbackMessage message = new FeedbackMessage(FeedbackType.FAILURE, null, e.getLocalizedMessage(), null);
result.addFeedbackMessage(message);
After
result = new FormResult(FormProcessingStatus.FAILURE);
FeedbackMessage message = WexSanitizer.sanitizeFeedbackMessage(FeedbackType.FAILURE, null, e.getLocalizedMessage(), null); result.addFeedbackMessage(message);
Cross Site Request Forgery (CSRF) Prevention
Overview
Like any other system, Windchill can be vulnerable to a CSRF attack:
This type of attack is used to alter data in the target system by hijacking a request from a legitimate user.
Given the nature of this type of attack, it is specific to Update and Delete actions from the standard CRUD model. We are typically not leaking sensitive information and it must call a web request that exists in the system. Therefore any new service in the system that we add in an extension that updates, deletes or potential exposes data (such as sending an email) must be secured.
The security is done by the implementation of a NONCE code that is sent with the request. This code changes frequently (ideally on each request) and therefore prevents a CRSF attack.
Implementation
Extensions should use the standard appsec API com.ptc.core.appsec.CSRFProtector that generates and checks the NONCE.
First we must generate the code in our calling JSP:
<%
String nonce = com.ptc.core.appsec.CSRFProtector.getNonce(request.getSession());
%>
...
<!-- Place the code in a javascript input -->
<input type="hidden" id="CSRF_NONCE" name="CSRF_NONCE" value="<%=nonce%>"/>
and then in our Ajax call:
data['CSRF_NONCE']=$('#CSRF_NONCE').val();
$.post( getUrl("saveReportDesigner"), data, function( response ) {
...
}
Finally, we check the NONCE in the backend:
@WexMethod(name = "save-reportDesigner", description = "Save reportDesigner")
public void saveReportDesigner(HttpServletRequest httprequest, HttpServletResponse httpresponse) throws Exception {
checkAccess(); // Check access in this case are we admin
CSRFProtector.checkNonce(httprequest); // Check the nonce code
....
}
Note: this is not a fully compliant NONCE as it is time limited to 24hours, however this conforms to the Windchill standard as documented here.
Security Review and Testing
All WVEs (Windchill Vulnerabilities and Exceptions) must be reviewed and approved. In order to track this we require a test case specifically to track this. It should be the first test case
Example
@Test
@TestDef(
title = "WVE Review",
description = "Example Review all WVES<br/><br/>"
+ "- 501 - All back end access secure<br/>"
+ "- 501 - global.jspf - Secure backend call only<br/>"
+ "- 502 - ZipHelper.java - File creation secured<br/>",
category = TestDef.Category.Other,
otherCategory = "Review",
execution = TestDef.Execution.Manual
)
public void reviewWVEs() throws Exception {
}
WVE Definitions
Following is a list of WVEs that may be identified and remediation and testing notes
| WVE | Description | Severity | Level | Allowed |
|---|---|---|---|---|
| WVE-2022-0301 | Java network access | 3 | A | Yes |
| WVE-2022-0302 | iframe usage | 5 | A | Yes |
| WVE-2023-0303 | FTP Usage | 5 | A | Yes |
| WVE-2023-0304 | Sharepoint usage | 5 | A | Yes |
| WVE-2022-0101 | Privilege escalation using direct database access | 9 | B | No |
| WVE-2022-0202 | Privilege escalation using session | 7 | B | Yes |
| WVE-2022-0203 | Privilege escalation using wex API | 7 | B | Yes |
| WVE-2022-0401 | Persistent Event | 9 | B | No |
| WVE-2022-0501 | JSP calls backend, possible XSS, CSRF and access issue | 3 | B | Yes |
| WVE-2023-0502 | File creation | 6 | B | Yes |
| WVE-2023-0504 | Use of request parameter (XSS risk) | 5 | B | No |
| WVE-2023-0505 | Use of request parameter map (XSS risk) | 5 | B | No |
| WVE-2023-0506 | Use of output stream (XSS, Path disclosure risk) | 6 | B | Yes |
| WVE-2023-0507 | Use of Windchill temp area | 5 | B | Yes |
| WVE-2023-0508 | Use of Java temp area | 5 | B | No |
| WVE-2023-0509 | Use of Java temp file | 5 | B | No |
| WVE-2024-0510 | Use of Feedback that must be sanitized | 5 | B | No |
| WVE-2024-0511 | Some operations that consume resources must be rate limited | 5 | B | Yes |
| WVE-2022-0402 | Extension Listener | 5 | C | Yes |
| WVE-2022-0403 | ServiceEventListenerAdapter | 5 | C | Yes |
Notes and remediation
| Key | Notes |
|---|---|
| Severity | Indicates the level of risk using this technique |
| Test Case | If possible there should be an associated test case created |
| Check resources | Make sure files are deleted and cannot lead to disk or memory over usage |
| Secured code API | Ensure this is replaced with the wex secure API in wt-security-commons |
| Sanitize | The output must be sanitized by wt-security-commons to remove XSS and Path Disclosure |
WVE Resolution
A link the the WVE DB is here
| WVE | Notes |
|---|---|
| WVE-2022-0301 | Network access. Note as the detection is for the URL class there are some false positives |
| WVE-2022-0302 | Iframe usage can be considered dangerous and any link to external source must be inidcated to the user and must be added to the security notes |
| WVE-2023-0303 | FTP Usage must be reviewed and checked. SFTP should be used. |
| WVE-2023-0304 | Sharepoint usage must be reviewed and checked. |
| WVE-2022-0101 | Direct SQL DB access is NOT allowed |
| WVE-2022-0201 | Privilege escalations are important as they indicates that an API is being used that does not enforce Access control “PersistenceServerHelper” it is sometimes necessary to use this API but it is considered very dangerous. The security team need to approve this API due to the possible access to unauthorized information, |
| WVE-2022-0202 | Is dangerous as this is due to usage of setAccessEnforced or setAdministrator both of which allow the thread to access data the user normally cannot. It is important that if these are used and approved and a correct “finally” statement is used to revert to the original user when the escalation is not longer needed |
| WVE-2022-0203 | Dangerous as above but using Wex APIs |
| WVE-2022-0401 | A listener on Persistent events is called significantly during standard Windchill operation. It is not advised to use this as a hook as a more specific listener event is preferable. As with listener code it must be very low expense it terms of overhead e.g no queries at all |
| WVE-2022-0501 | XSS and Path Disclosure is a very common vulnerability and this needs to be checked. We have a library to help sanitize for XSS but if your team understands XSS risks they can check and approve. |
| WVE-2023-0502 | Temporary file creation is important to review to ensure that the files are deleted (we have seen incorrect usage can fill up the temp area and cause system instability) also it is important that we check that there is no path traversal possible for any RCE. Wex uses its own library to ensure temp files are managed correctly. |
| WVE-2023-0504 | XSS and Path Disclosure (see above) |
| WVE-2023-0505 | XSS and Path Disclosure (see above) |
| WVE-2023-0506 | Output streams that stream to the UI should be checked for XSS and Path Disclosure, note the MIME type can indicate that the data is not affected. |
| WVE-2023-0507 | Temporary file creation (see above) |
| WVE-2023-0508 | Temporary file creation (see above) |
| WVE-2023-0509 | Temporary file creation (see above) |
| WVE-2024-0510 | XSS and Path Disclosure (see above) |
| WVE-2024-0511 | Rate limiting is important to add to any user function that consumes resources |
| WVE-2022-0402Li | Listener code must be very low expense it terms of overhead e.g no queries at all |
| WVE-2022-0403 | Listener code must be very low expense it terms of overhead e.g no queries at all |
If a WVE cannot be resolved using code then it must be marked as reviewed and the comment must include any valid information
Signing
Extension Signing
During the build process the extension is sent to be signed; this is done by a service provided by Wincom
It will ensure the following
- The extension has a signature.dat added that will match the codebase. Only signed extensions can be added to Windchill.
- The wincom jar files within the extension are all signed (note this applies only to jar files containing the package com.wincomplm)
The following curl command on Windows can be used to send a wex file to be signed
For 1 file
curl -F "file=@my.wex" https://sign.wex.solutions/wex-sign -u "automation@wincom-plm.com:c!f=xxxxxx" -o my.wex
For many
forfiles /p w:\cdb /m *.wex /c "cmd /c curl -F "file=@@file" https://sign.wex.solutions/wex-sign -u "automation@wincom-plm.com:c!f=xxxxxx" -o @file"
Licensing
EDK Licensing
The EDK license terms and conditions can be found here. We recommend that all developers are aware of the terms of this license before making use of the Extension Development Kit.
Third Party Licenses
Many extensions will make use of third party libraries. These can be included as required, but it is very important for a developer to ensure these libraries are correctly licensed. Typically permissive licensing is used used such as Apache 2 or MIT, but even these licenses require the software to include a license, even if they are free to use commercially.
The WEX Framework includes a methodology to make sure the correct licenses and copyright notices are included. There is also an optional license section in the definition.xml file of the WEX.
Example of Apache License
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wex-definition>
...
<license>
<dependency>
<groupId>net.acmesoft</groupId>
<artifactId>superzip</artifactId>
<version>2.1</version>
<type>Apache</type>
<license-version>2.0</license-version>
<copyright/>
</dependency>
</license>
...
</wex-definition>
Example of MIT License with Copyright Notice
<license>
<dependency>
<groupId>net.acmesoft</groupId>
<artifactId>clicky.js</artifactId>
<version>1.0</version>
<type>MIT</type>
<license-version>1.0</license-version>
<copyright>Copyright (c) 2021 Mickey Mouse</copyright>
</dependency>
</license>
The licenses will appear in the Extension Manager UI as shown below:
End Points
<% // To inform security scanned of parameterization for XSS test // #params: id // #action: read String id = request.getParameter("id"); %>All End Points must be annotated with the params and action (create,read,update,delete,download)
Security Testing
See the testing section for more information