Description
The Registry software employs an authentication cookie to recognise authenticated users; normally this cookie is specified with a short time-to-expire.
In current configuration, the all communication with the Registry service employs HTTP - which means that the authentication cookie is passed in clear text and thus exposes the Registry service to man-in-the-middle attacks. The worst case exploitation would be for an administrator's cookie to be stolen & then maliciously used to give administrator privileges to some third party who would then have full control over the Registry content until such permissions were revoked.
Although the likelihood of such an attack is small (it is both a sophisticated action and requires sufficient motivation to execute) it still seems worthwhile resolving this security flaw.
It is important that the majority of users remain using (plain) HTTP to access the registry; the registers and terms therein are all given HTTP URIs (not HTTPS URIs).
I propose that all interactions from authenticated users MUST use HTTPS;
i) following authentication (login), the user should be redirected to https://{register-root}
ii) all URLs (used for navigation within the web-application) should be specified as HTTPS if a user is authenticated
iii) if a user with a valid authentication cookie attempts to access the Registry service (via web-application or programmatic API) using (plain) HTTP, the authentication cookie SHALL be revoked immediately (as it has been exposed in clear text and is subject to potential theft) ... in this situation, the user should be notified that their current "login" has been revoked and indicate how to correct access the Registry whilst authenticated using HTTPS.
It would also seem appropriate that requests to /system/security (e.g. /login, /logout, /createpassword, /apilogin & /response?{...} ) are undertaken using HTTPS.
Given that /system/security/apilogin needs amending to HTTPS, the "example login command" provided to the user following creation of a temporary API password should be modified to indicate a HTTPS request ... I think this is as simple as amending the URL to be https://{registry-root}/system/security/apilogin
Advice on other resources requiring HTTPS is appreciated.
(I note that all the interaction with the OpenID provider occurs using HTTPS)
Activity