Cross origin token usage attack?

[kaaboaye]

Let's assume that there are two websites using web3-token:

• website1 which is under my control
• website2 which is under my competitors control.

What stops me from performing the following scenario?

1. A user logs into my website1 and sends it into my server.
2. My server makes a request to website2 using the valid user's token created for my website1.
3. Since I now have access to the website2 as the user I can steal confidential data.
4. user have no way of knowing about this attack unless website2 sends some notifications about for example new ip address being used.
5. website2 also has no way of knowing about this attack since the token is freshly signed valid.

[bytesbay]

Thanks for your comment. Im currently preparing update to fit this standard.

Will add domain option which will fix this issue. Meanwhile, you can add a custom domain field with your domain while signing a token and then check on server-side if there's a valid domain in token's body.

[kaaboaye]

What will stop me from putting website2's domain in my website1 frontend? I'll still be able to easily create a valid token for website2. Just use their domain while signing the token.

OAuth2 usually prevents it with callbacks allowlists.

• https://auth0.com/docs/login/redirect-users-after-login#redirect-users-to-callback-urls-on-the-allowlist
• https://datatracker.ietf.org/doc/html/rfc6749#section-10.15

[bytesbay]

@kaaboaye actually nothing will stop to do it , but the user always see what he is signing

[kaaboaye]

Relying on users paying attention to what they are doing is not the best idea for security.

[gregorym]

@kaaboaye Just curious, how are you doing auth?

[kaaboaye]

OAuth2.

In one project we have auth0 and in another custom auth0 like service. But in general when using external authorization authorities like Google or Facebook OAuth2 a golden standard. It’s well designed, documented and battle tested.

On 7 Nov 2021, at 17:17, Gregory @.***> wrote:

 @kaaboaye Just curious, how are you doing auth?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[john--]

@kaaboaye How are you doing proof of ownership of a web3 wallet in the oauth flow?

[kaaboaye]

We’re using only password and google authentication at the moment.

On 9 Nov 2021, at 03:45, John Jardine @.***> wrote:

 @kaaboaye How are you doing proof of ownership of a web3 wallet in the oauth flow?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[AntMarras]

any update on this? or any way that I can use to mitigate this scenario in the meantime? thanks

[kaaboaye]

1. Server will generate a challange
2. Client will sign the challenge
3. Client will send the challenge back with signature and all required session information
4. Server will check if challenge is legitimate, created by authorized server
5. Server will check challenge signature
6. Server will generate a bearer token for the client containing userId, scopes etc

notes

• challenge can be a random string signed with cryptographically secure hmac algorithm which means that server will most likely be sending challenge and serverSignature which client will be sending back with clientSignature
• The serverSignature can be created with asymmetric algo like ecc or rsa, then client will also have a chance of validating server authority. It may act like certificate pinning.
• userId should also be signed with the same clientCert to prevent impersonation
• Bearer token will most likely be just a JWT token but then the JWT should be short lived and be created with long lived refresh token which can be revoked at will

Disclaimer This is a quick algorithm that I just described while on the gym. It’s likely I’ve missed something

[bytesbay]

@kaaboaye @AntMarras Added domain option in new version

[kaaboaye]

Ok, but what stops me from providing another, not mine domain on client side?

[bytesbay]

@kaaboaye Nothing. For now all the responsibility is on user's shoulders. We can only wait for EIP-4361 to be implemented in wallets, so the wallets will prevent this vulnerability.