BCDE 7.3 introduces a new feature called the content domain that is designed to improve security by mitigating cross site scripting (XSS) attacks originating in authentic server content. This note aims to explain the feature and to explain the implications for those clients who choose to host their BCDE server under a non-withbc.com domain name.
|
|
Product(s):
|
BCDE
|
|
|
Version(s):
|
7.3 and above
|
|
|
Area:
|
Miscellaneous
|
|
|
Original Author:
|
Bentley Global Technical Support
|
|
|
Date Logged
& Current Version
|
02/212022
|
What does the content domain do?
In use, the content domain is a separate host name, based on the main server’s name that is used purely to access document content as opposed to browsing the BCDE server and carrying out actions.
For example, normal login and browsing of the server would involve pointing your web browser at customer.withbc.com and all subsequent requests are made to that server name too. Previously, requests to access document content – to download or view a file – were also made to the same host name.
Because of the trust/security model that the web browser uses, that document content is as trusted as any other content served by the application. This opens the opportunity for a malicious user to insert malicious content that could theoretically access session information and allow impersonation of a user. BCDE already implemented several mitigations against this kind of attack including session expiry and notification of sessions switching source IP, but the new approach eliminates that issue by addressing the root cause.
By providing a separate host name (typically customer-content.withbc.com) from which all file data is served, there is no opportunity for that content to exploit the browser security model and maliciously obtain session information.
Authentication on the content domain is handled by short lived, one-off authentication tokens which are useless outside of the intended purpose of authorizing a single download of whatever document has been requested.
Users will notice almost no difference in day-to-day usage as the only change is to the document’s URL which is usually not visible when carrying out a normal download. Existing links to documents are automatically redirected to the new URL.
Implications for customers
There are three areas where actions may be required from BCDE customers and the users of the customers’ servers.
- Proxy and Firewall – allow equivalent access to the additional hostname
- DNS – if the customer is responsible for DNS, a new record is required
- SSL – if the customer is responsible for SSL certificates a valid cert for the additional hostname is required
Proxy and Firewall
In most cases where a customer’s users have unrestricted Internet access, no further action will be required. But for those customers who have put in place specific proxy server or firewall rules to allow access to the BC server then equivalent rules will need to be put in place for the additional content serving hostname. This additional hostname will typically point to the same IP address as the main server’s name and may be configured as a DNS CNAME record. This may negate the need to alter the proxy or firewall rules if they have been implemented by reference to IP rather than by DNS name. Note that in general we would recommend referencing services by DNS name to avoid issues due to IP changes in the future.
DNS
For the typical customer for whom BCDE manages the DNS records associated with the BCDE server, no action is required.
For those customers who have a custom server name on their own domain and for whom BCDE do not manage the DNS, an additional hostname will need to be added to allow access to the content domain.
We would suggest that for a BCDE server with hostname: <host>.<customer>.com that the content domain is of the form: <host>-content.<customer>.com
This host can be implemented as a CNAME pointing to the original BCDE server name as they will be implemented on the same server IP on the server side.
SSL
For the typical customer for whom BCDE manages the SSL/TLS certificate associated with the BCDE server, no action is required.
For those customers who have a custom server name on their own domain it would be usual for an SSL certificate to be in place that has been purchased and verified through the customer’s internal team. Either an additional certificate will be required that matches the additional hostname or it may be possible to amend the existing certificate and combine the two names via a “Subject Alternative Name” (SAN) certificate. If you are uncertain about this, then please talk to your certificate supplier. As usual, BCDE can supply a CSR upon receipt of the details you wish the certificate to contain.
If you have any problems at all, contact your project administrator or BCDE Support