Currently, the Registry is configured so that all communication uses HTTP - with the exception of login which uses secure connections with the OpenID provider.
However, the session-cookie (JSESSIONID) for the Registry application is passed in clear-text and, therefore, the session is susceptible to hi-jacking.
In most cases this is not a problem as the user will not have modify-permissions to the registry. But, a small proportion of users will have modify-permissions (potentially as administrators) - which means that if they have authenticated & their session is hijacked, the Registry would be open to unauthorized change.
At worst, a hijacked session may be used to grant administrative priviledges to a third party who can then modify the registry content at their leisure!
A session may also be hijacked if the api-login token* is intercepted.
(unlike normal authenticated sessions, because we use an external IdentityProvider only the Registry-IdentityProvider and User-IdentityProvider sessions are in HTTPS; the User-Registry session remains HTTP)
Initially, one might attempt to protect the server by making forcing all POST, PUT, PATCH and DELETE HTTP requests (plus GET requests to {registry-base}/system/security) to use HTTPS; e.g. by redirecting those requests arriving on HTTP over to HTTPS. However, the problem is that the entire session is vulnerable as the session-cookie itself may be stolen from any HTTP request.
So my questions are:
i) (so long as the session cookies and api-login tokens are short-lived) is the risk of session hijack leading to unauthorised modification sufficiently low so as it can be accepted?**
ii) (answer above is "no") are there any simple mechanisms available to secure the registry?
iii) is it acceptable to use HTTPS to serve information about resources identified with HTTP URIs?
Given some analysis of (i) I think the risk appears to be acceptable to operate in HTTP clear text.
Thoughts appreciated.
this is the username-password token that an authenticated user can generate at http://{registry-base}/system/security/createpassword and is passed to the server at http://{registry-base}/system/security/apilogin to establish an authenticated session.
\ noted that the exploit only allows unauthorized modification of the registry content. If we were talking about confidentiality issues (e.g. for financial transactions) the motivation to hikack the session would be high, but we are only talking about protecting the integrity of data. Also note that we intend to put in place measures to review registry content changes on a daily basis (most days, there are unlikely to be any changes) allowing for the registry content to be refreshed should unauthorized changes be detected.
Currently, the Registry is configured so that all communication uses HTTP - with the exception of login which uses secure connections with the OpenID provider.
However, the session-cookie (JSESSIONID) for the Registry application is passed in clear-text and, therefore, the session is susceptible to hi-jacking.
In most cases this is not a problem as the user will not have modify-permissions to the registry. But, a small proportion of users will have modify-permissions (potentially as administrators) - which means that if they have authenticated & their session is hijacked, the Registry would be open to unauthorized change.
At worst, a hijacked session may be used to grant administrative priviledges to a third party who can then modify the registry content at their leisure!
A session may also be hijacked if the api-login token* is intercepted.
(unlike normal authenticated sessions, because we use an external IdentityProvider only the Registry-IdentityProvider and User-IdentityProvider sessions are in HTTPS; the User-Registry session remains HTTP)
Initially, one might attempt to protect the server by making forcing all POST, PUT, PATCH and DELETE HTTP requests (plus GET requests to {registry-base}/system/security) to use HTTPS; e.g. by redirecting those requests arriving on HTTP over to HTTPS. However, the problem is that the entire session is vulnerable as the session-cookie itself may be stolen from any HTTP request.
To overcome this, one might put the entire registry under HTTPS ... but then this would be at odds with the HTTP URI identifiers used for content! From a user perspective, I could see confusion arising when people are looking for, say, http://ukgovld-registry.dnsalias.net/def/dataset-categories/economic but the browser is showing https://ukgovld-registry.dnsalias.net/def/dataset-categories/economic ...
So my questions are: i) (so long as the session cookies and api-login tokens are short-lived) is the risk of session hijack leading to unauthorised modification sufficiently low so as it can be accepted?** ii) (answer above is "no") are there any simple mechanisms available to secure the registry? iii) is it acceptable to use HTTPS to serve information about resources identified with HTTP URIs?
Given some analysis of (i) I think the risk appears to be acceptable to operate in HTTP clear text.
Thoughts appreciated.