GramThanos / WebDevAuthn

A tool to test & analyze FIDO2/WebAuthn requests and responses
https://gramthanos.github.io/WebDevAuthn/
GNU General Public License v3.0
23 stars 2 forks source link

Firefox: Credential creation and get operations may succeed only after multiple attempts #4

Closed pal1000 closed 1 year ago

pal1000 commented 1 year ago

Windows 11 22H2, Firefox 117.0.1 x64. Popups have been strictly disabled, but they don't affect this bug reproducibility. The only difference is the extension spawning new tab attempting the same operation on every silent/error-less failure. Screenshot 2023-09-13 191720 Tested with Yubiko demo sites https://demo.yubico.com/webauthn-technical/registration Screenshot 2023-09-13 185656 https://demo.yubico.com/webauthn-technical/login Screenshot 2023-09-13 190632

GramThanos commented 1 year ago

This was a fallback mechanic I implemented. Whenever the extension is not able to create a JavaScript pop up (alert/prompt), a fake pop up (in HTML) is implemented by the extension with minimum changes to the page, so that the WebDevAuthn actions can be performed.

I am not sure what problem your are trying to describe here. Can you explain a bit more what you expected to see, and what actually happened?

pal1000 commented 1 year ago

Another screenshot with browser tabs included. The credential get operation remains stuck at Getting credentials and a new tab with another attempt is opened. I also allowed popups for gramthanos.github.io to avoid the no popup fallback. Screenshot 2023-09-14 182952

GramThanos commented 1 year ago

The pop ups should be also allowed on the target website (Yubico in your case). Essentially the new tab fails to communicate with the Yubico website.

I will have a look but I don't think this can be fixed.

pal1000 commented 1 year ago

It happens even if popups are allowed on Yubico website. Plus popups being blocked on target website should only ruin the final step, send credentials response,

pal1000 commented 1 year ago

Since Firefox 118.0.2 or 119.0 I couldn't reproduce it anymore. This might have been a bug in Firefox or NoScript extension that got fixed sometime between late September and early October.