- From: Aditya Mitra via GitHub <sysbot+gh@w3.org>
- Date: Sat, 16 Sep 2023 14:38:45 +0000
- To: public-webauthn@w3.org
I absolutely agree and I have a proposed mitigation strategy that can be added into the suggested implementation guidelines. The mitigation strategy might be able to prevent such attacks: A JavaScript vulnerability allows an adversary to perform Self-XSS to override the navigator.credentials.get() function and to use a custom implementation of the same. The custom implementation allowed the adversary to export the ‘options’ and send them to the legitimate user over a Trojan, get it signed and then return the same to the RP Server. This allowed the adversary to takeover the accounts of legitimate users. While this is not particularly a vulnerability of Web Authentication, it arises from JavaScript itself. This would mean, most browsers are affected by the same. The suggested mitigation might not be absolute, and it is a suggestion to improve the implementations of WebAuthn. There might be ways to bypass this mitigation but that involve more sophisticated attack setup than the current attack scenario. However, to the best of our knowledge, this might be capable of mitigating the risk in most scenarios. An example of a WebAuthn implementation that is vulnerable might be:  Here, as we can see in line 19, the program calls navigator.credentials.get() function. This function can be overridden using a Self-XSS attack. For example, if the following code is entered into the browser console, the custom implementation of navigator.credentials.get() is called instead of the original:  However, it is known that the script in head tag of the page executes first before anything else. And non-async functions in the head tag will always execute before any other onload function is called or before the Self-XSS is performed in the console. This feature would be advantageous to deal with the vulnerability. In the recommended implementation of WebAuthn, we would suggest the developer to ‘backup’ the actual navigator.credentials.get() function with a name that might not be known to the adversarial actor. This name might also be dynamic or randomized. This name of the backup can also be obfuscated so that the adversary may not know it. This can be done with, for example a line of code like: const randomnameattackerwontknow=navigator.credentials.get.bind(navigator.credentials); Subsequently in the actual body of the webpage, the function ‘randomnameattackerwontknow()’ needs to be called instead of ‘navigator.credentials.get()’. For example, the modified version of the WebAuthn implementation might be:  This modified implementation is resistant to the Self-XSS attack that was discussed earlier. This is because the XSS attack will override the navigator.credentials.get() function. However, a pointer to the original function already stays with the browser which cannot be overridden if the name is obfuscated. This might be a probable mitigation of the problem. This mitigation just provides a better practice for WebAuthn implementation and has been tested to be secure against overriding the native function with a Self-XSS. -- GitHub Notification of comment by AdityaMitra5102 Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1965#issuecomment-1722244005 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 16 September 2023 14:38:47 UTC