What measures will be taken to reduce the risk of a session hijacking attack in Web eID?
As explained in the Cybernetica analysis, Web eID is protected against the session hijacking attack as well as all other common authentication protocols, such as OpenID Connect, SAML, Web Authentication, or mobile-ID and Smart-ID. Although common authentication protocols do not prevent session hijacking, the risk can be mitigated in most cases by using good development practices, proper configuration, and security measures to prevent session identifier leakage. There are four main ways to hijack a session:
- vulnerability of e-service to session fixation,
- cross-site scripting attack against the website of the e-service,
- man-in-the-middle attack, which enables the attacker to eavesdrop on traffic that contains the session identifier,
- malware on the victim’s device.
To avoid session fixation, the e-service must update the session identifier after user authentication. The session identifier must be random enough to prevent guessing attacks. The session identifier must be transported between the client and server over a secure HTTPS channel using a secure version of TLS and settings.
The website of the service provider must have security measures in place to prevent cross-site scripting attacks. To provide additional protection against cross-site scripting attacks and other common vulnerabilities, the session cookie must have the following flags: HttpOnly, Secure, SameSite.
The possibilities of man-in-the-middle attacks and protection against them are discussed in the answer to the question ‘How does Web eID contribute to the mitigation of man-in-the-middle attacks?’.
Unfortunately, the service provider cannot protect the user’s session if the user’s device is infected with malware.
How does Web eID contribute to the mitigation of man-in-the-middle attacks?
Web eID is protected against man-in-the-middle attacks by checking the origin of the website. The e-service generates a challenge nonce to authenticate the user and transmits it to the Web eID browser extension. In addition to the challenge nonce, the browser extension securely transmits the origin of the e-service website to the Web eID application. The Web eID application adds up the challenge nonce and origin and hashes the value, signs the received hash and returns the signature within the authentication token to the e-service via the browser extension. The e-service uses the originally generated challenge nonce and the origin of its website to verify the signature of the authentication token and the signature check fails if a different challenge nonce or origin has been used for signing. Due to this protection measure, an authentication token issued for a website under the control of the attacker (for example teeenus.ee etc.) cannot be used in the attacked e-service which is located on another website (for example teenus.ee). The steps for validating the authentication algorithm, authentication token and safeguards against man-in-the-middle attacks are described in more detail in the ‘Authentication’ chapter of the Web eID System Architecture document, see https://github.com/web-eid/web-eid-system-architecture-doc#authentication-1.
In summary, in order to authenticate a user, a message that is signed with an ID-card is prepared in such a way that it precludes a normal man-in-the-middle attack, during which the authentication token issued to one website is attempted to be used on another website.
If a man-in-the-middle attacker has control over the DNS resolution of a user’s computer and has hacked into some user trusted certification authority, a more complex and powerful first level man-in-the-middle attack is possible in which the attacker may:
- resolve the host name of the attacked e-service (for example teenus.ee) to an IP address of a server which is under the attacker’s control and where the fake site is located;
- issue a certificate for the fake site through the corrupted certification authority which is trusted by the user’s browser.
Trusted certification centres are protected by comprehensive security measures and in case of a break-in their certificates are operationally revoked, therefore the likelihood of such an attack is very low.
Even if the beak-in to the certification authority succeeds then such an attack will be prevented by Certificate Transparency (CT) protection on the official certificate issued to the domain of the attacked e-service. If the official certificate issued to the domain of the e-service is registered in the CT registry, the browser detects the forged certificate and the attack fails.
If a man-in-the-middle attacker has control over the certificate store and browser security policy in addition to the DNS resolution of a user’s computer, then even more complex and powerful man-in-the-middle attack is possible in which the attacker may:
- install their rogue certificate authority certificate in the certificate store of the user’s computer;
- configure the user's browser security policy so that the CT protection for the e-service domain is turned off;
- resolve the host name of the attacked e-service (for example teenus.ee) to an IP address of a server which is under the attacker’s control and where the fake site is located;
- issue a certificate for the fake site through the rogue certification authority which is trusted by the user’s browser (because of the rogue certification authority certificate in the certificate store).
CT protection does not apply in this case, because the attacker has turned off CT control. If all the preconditions of the attack are met and the user opens the website of the e-service being attacked in the browser and authenticates, the described powerful man-in-the-middle attack will succeed, because the data exchange takes place through the fake site. The browser transmits the correct host name of the attacked e-service as a origin to the Web eID application (for example teenus.ee), but the authentication token reaches the attacker’s service on the fake site and the attacker can use the token to access the attacked e-service.
In summary, the preconditions for a powerful man-in-the-middle attack are extremely difficult to carry out in practice and require control over the user’s computer. Having control over the user’s computer makes other, simpler attack vectors possible which makes it pointless to carry out a more complex attack. Thus, according to RIA, the risk of a powerful man-in-the-middle attack is minimal when using Web eID.
No other common authentication protocol nor authentication services such as the State Authentication Service are protected against such an attack.
Why is Web eID the most secure with the Mozilla Firefox web browser?
An analysis indicated that only in Firefox do browser extensions have access to a website’s HTTPS certificate, and only in Firefox can additional protection against the previously described very complex and impractical man-in-the-middle attack, where an attacker can control the DNS resolution, forge the website’s certificate and turn off CT check (a so-called powerful man-in-the-middle attack), be implemented. Experimental additional protection for Firefox was realized at the beginning of the project, but because of other negative side effects, the experiment was abandoned. According to RIA, the risk of a powerful man-in-the-middle attack is low and the Web eID solution already functions properly and with sufficient security with all common modern browsers. The Web eID protocol is as secure as other common authentication protocols, such as OpenID Connect, SAML, WebAuthentication, and mobile-ID and Smart-ID.
If the e-service handles information in the security class ‘top secret’, RIA recommends to continue using Client Certificate Authentication (TLS CCA), but this may, for reasons beyond RIA’s control, reduce the ease of use and reliability for which the Web eID project was initiated.
Please note that the analysis did not claim that Web eID is vulnerable to man-in-the-middle attacks per se. As described above, Web eID is protected against a man-in-the-middle attack where a token issued to one website is attempted to be used on another website, because the origin of the website is part of the authentication token.
