CSSCurrent en:Connection

Aus Cryptshare Documentation
Version vom 17. Juli 2023, 12:34 Uhr von imported>Frorathm (Frorathm verschob die Seite CSSBackend en:Connection Settings nach CSSBackend en:Connection)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu:Navigation, Suche

Connection Security

Base URL 

The base URL is used to create the download link in the email notifications sent to the recipients of a transfer. Enter the URL under which your server will be available in the network/internet. When using the Electronic Identity feature, the base URL is used for redirecting a user back to the Cryptshare Web App after a sender or recipient identification.

Please note: If you are using the feature Electronic Identity, changing the Base URL may mean that this feature can no longer be used. Please contact your Cryptshare Sales Contact before you change the Base URL.

Force redirect 

For both, the Cryptshare User Interface and the Administration Interface you can enable a redirect to a secure channel. If enabled, all incoming http connections will be redirected to https connections. This setting is not dependent on the URL you have set, so it is irrelevant whether you have set the URL using 'https' or 'http'.

iFrame Security

For security reasons embedding of Cryptshare into other websites can be restricted to avoid the 'ClickJacking' attack scenario (http://en.wikipedia.org/wiki/Clickjacking). The setting allows two modes:

  •  Only allow embedding within the same source
  •  Generally allow embedding

The default setting does only allow embedding within the same source. This prohibits external web sites to show Cryptshare within a frame. The setting will influence the CSP header directive 'frame-ancestors'

What is the risk if embedding is generally allowed?
This kind of attack works by presenting the user with a website and redirecting any click of the user, without him noticing, to a hidden website in the background. This way a specific behaviour of the Website in the background (in this case to Cryptshare) can be triggered. The user shall be tempted to send data via Cryptshare without him noticing.


Restarting the Cryptshare Service
By clicking the "Save changes" button, you can re-start the Cryptshare service, even when not having changed any settings on the page.

CORS

CORS (Cross-Origin Resource Sharing) is a system restricting which other web pages can make HTTP requests to a web site or web API. The web-browser only allows a web site to perform HTTP requests against either the origin it is running on (e.g. a site under 'https://cryptshare.example.com/resources/client.owa/index.html' can make requests against other resources on 'https://cryptshare.example.com'), or different origins which explicitly allow the requesting origin to do so. This prevents an attacker, which has tricked a user into visiting a malicious site, from sending unauthorized requests to a legitimate site with the users credentials. This affects Cryptshare for OWA clients when attempting to download Cryptshare Transfers from a Cryptshare Server different from the one the current add-in is installed on. In order to allow the recipients, that users of your Cryptshare Server send Cryptshare Transfers to, to download the transfers in Cryptshare for OWA, you will have to allow their Cryptshare Servers URL in your Cryptshare Servers CORS settings.

Options

The following options are available:

  • Disable: No Cryptshare for OWA instances on other Cryptshare Servers may access this Cryptshare Servers transfers.
  • Individual Hosts: Only the Cryptshare for OWA instances on other Cryptshare Servers for which the other Cryptshare Servers origin has been entered may access this Cryptshare Servers transfers.
  • Allow all: Cryptshare for OWA instances on any Cryptshare Servers may access this Cryptshare Servers transfers.
'Allow all' allows any client to send Cross-Origin Requests to this Cryptshare Server which is a security risk. Intentionally disabling the CORS restriction is not recommended.

Scenario 1 - Transfer from a different Cryptshare Server

In the following example, User A sends a Cryptshare Transfer to User B, using their own Cryptshare Server, "Cryptshare Server A". 65670371.png

In order for User B to be able to download the Transfer via Cryptshare for OWA, Cryptshare Server B's URL ('https://cryptshare.example.com') has to be allowed in the CORS configuration of Cryptshare Server A.

19 Cryptshare for OWA EN.png

Scenario 2 - Transfer from the Same Cryptshare Server

When sending Transfers between Users on the same Cryptshare Server, the CORS configuration will not be need to be changed. 65670370.png