Re: [FIDO-DEV] Digest for fido-dev@fidoalliance.org - 4 updates in 2 topics

[Perla nallely Guadalupe Alejandre Ramón]

Cuando ustedes arreglen lo que no ise hablen con la verdad y mi gobierno se comunique conmigo para darme la notificación hablamos recuerden que mi tiempo es valioso pues yo sí trabajo y no ando abusando de nadie 

El vie., 2 de diciembre de 2022 4:58 p. m., <fido...@fidoalliance.org> escribió:

fido...@fidoalliance.org

Google Groups

Topic digest
View all topics

• Digest for fido...@fidoalliance.org - 5 updates in 3 topics - 1 Update
• Detached FIDO Authentication - 3 Updates

Digest for fido...@fidoalliance.org - 5 updates in 3 topics

"Perla nallely Guadalupe Alejandre Ramón" <nallelyale...@gmail.com>: Dec 02 06:52AM -0600 Mi teléfono está sincronizado con el correo de mi esposo gracias a eso tengo las pruebas nombres de las personas estados de cuenta gastos que isieron y todo para meterlo a la cárcel porque no se vale no es justo más sin embargo solo quiero un documento firmado por las autoridades y una restricción   El jue., 1 de diciembre de 2022 4:58 p. m., <fido...@fidoalliance.org> escribió:

Back to top

Detached FIDO Authentication

Emil Lundberg <em...@yubico.com>: Dec 02 11:51AM +0100 What I mean is that even without XSS, if a user falls victim to a phishing attack they'll have loaded a phishing page under the attacker's control. The scenario is that the attacker is in control of JavaScript running in the victim's non-FIDO browser, but not in control of the browser itself.   In this case the attacker's phishing webpage, and any script it serves, will be loaded and running in the non-FIDO WebView on the victim's client device, so any requests originating from that page will originate from the victim's IP address (1.2.3.4 in your examples), not from the phishing server's address (6.6.6.6). So if the phishing page uses AJAX requests to interact with the IDP, it'll bypass the IP address validation, and the IDP will return any secrets and cookies to the phishing page. If those secrets and cookies are accessible to the attacker's JavaScript, the attacker can intercept them without routing the requests through a proxy server. Thus the attacker can initiate the detached FIDO flow and receive the privateToken, call out to the FIDO Browser which will correctly complete the FIDO authentication, and then use the compromised privateToken to redeem a session secret. It doesn't matter if the authentication in the FIDO browser is secure if the phishing page in the non-FIDO browser can still acquire a session secret, or indeed other sensitive data, in the end.   On further thought, I don't think HttpOnly cookies is enough. I *think* HttpOnly should suffice to secure the initial session cookie, but the session cookie is far from the only sensitive piece. While the attacker won't have direct access to the session cookie, they can still exercise the cookie in AJAX requests to access and exfiltrate sensitive data. Furthermore we should assume the attacker has the victim's password, since they're on a phishing page. They can also use AJAX to enroll new WebAuthn credentials under the attacker's control - not by calling the WebAuthn API in the browser of course, but by simply constructing the PublicKeyCredential structures in pure JavaScript (or, if the server requires trusted attestation, by calling out to a remote server with an approved authenticator connected). Then the attacker can access the account directly from any other device, since they now have full control of the password and a FIDO credential registered to the account.   Did I miss something that would prevent these kinds of attack?   Emil Lundberg   Software Engineer | Yubico <http://www.yubico.com/>

Dennis Kniep <kniep...@gmail.com>: Dec 02 03:23AM -0800 I think its not possible for the phishing page to use AJAX requests to interact with the IDP. Because the phishing page is hosted on a different domain than the IDP. The CORS Policy of the Browser will prevent such Ajax requests (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) The CORS Policy will identify the IDP as cross-origin resource. Therefore all AJAX requests from the phishing page to the IDP will be denied. Example error in Chrome: Access to XMLHttpRequest at 'https://microsoft.com/' from origin 'https://www.google.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.     I hope I have understood your concerns correctly?   Cheers, Dennis   On Friday, 2 December 2022 at 11:51:47 UTC+1 Emil Lundberg wrote:

Emil Lundberg <em...@yubico.com>: Dec 02 12:56PM +0100 Ah right, of course, that's what I forgot. Thanks!   Emil Lundberg   Software Engineer | Yubico <http://www.yubico.com/>

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to fido-dev+u...@fidoalliance.org.