The risk of session hijacking and man-in-the-middle attacks in Web eID

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 threat as well as all other common authentication protocols, such as OpenID Connect, SAML, or 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:

  1. vulnerability of e-service to session fixation,
  2. cross-site scripting attack against the website of the e-service,
  3. man-in-the-middle attack, which enables the attacker to eavesdrop on traffic that contains the session identifier,
  4. 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 source of the website. The Web eID application creates an authentication token in the JSON Web Token format with the source in the aud field and forwards the authentication token to the e-service. During the validation of the authentication certificate, the e-service checks if the source in the certificate is equal to the actual source of the e-service and interrupts the authentication with an error if the source is different. Due to this protection measure, an authentication token issued for a website under the control of the attacker (for example, pankk.ee, panķ.ee, etc.) cannot be used in the attacked e-service which is located on another website (for example, pank.ee). The steps for validating the authentication algorithm and authentication token are described in the ‘Authentication’ chapter of the Web eID System Architecture document, see https://github.com/web-eid/web-eid-system-architecture-doc#authentication-1.

If a man-in-the-middle attacker has control over the name resolution of a user’s computer and has hacked into a trusted certification authority, a more complex and powerful first level man-in-the-middle attack is possible in which the attacker may:

  1. resolve the host name of the attacked e-service (for example pank.ee) to an IP address of a server which is under the attacker’s control and where the fake site is located;
  2. issue a certificate for the fake site through the corrupted certification authority which is trusted by the user’s browser.

Such an attack is generally 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. CT makes it particularly difficult to carry out an attack.

If a man-in-the-middle attacker has control over the certificate store and name resolution of a user’s computer, then even more complex and powerful second level man-in-the-middle attack is possible in which the attacker may:

  1. install their rogue certificate authority certificate in the certificate store of the user’s computer;
  2. resolve the host name of the attacked e-service (for example pank.ee) to an IP address of a server which is under the attacker’s control and where the fake site is located;
  3. 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 CT does not check certificates issued by private certification authority. 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 source to the Web eID application (for example pank.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, with CT protection, a powerful man-in-the-middle attack is not possible without having control over the user’s computer with high-level access rights. However, if an attacker already has administrator rights, they can already do whatever they like on the user’s computer, which makes it pointless to carry out a more complex attack.

No other common authentication protocol, such as OpenID Connect, SAML, Web Authentication, nor authentication services such as the State Authentication Service and bank authentication are protected against such an attack.

However, because properly implemented TLS client certificate authentication (TLS CCA), which the current OpenEID authentication solution provides, protects against powerful proxy attacks, the Information System Authority (RIA) has explored ways to provide equivalent protection in the Web eID solution. Currently, Firefox has implemented the transmission of the TLS certificate fingerprint (hash) of the source to the e-service in the aud field of the authentication token. The service can check if the fingerprint of the certificate matches the fingerprint of the official certificate of the service and interrupt the authentication with an error if the fingerprints do not match. This is an experimental functionality which only works in one browser; RIA does not recommend using it. It should be noted that both TLS CCA and experimental certificate fingerprint verification make it impossible to use TLS proxies, which, for example, does not allow the use of web access protection provided by anti-virus software and ID-card authentication on corporate intranets that use TLS proxies to secure network traffic.

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 a very complex and impractical man-in-the-middle attack, where an attacker can control the name resolution and forge the website’s certificate (a so-called powerful man-in-the-middle attack), be implemented. As explained above, trusted certificate issuers use the Certificate Transparency system, in which case the browser is able to detect forged certificates and disconnect, foiling the powerful man-in-the-middle attack. 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 source of the website is part of the authentication token.